In short. Google-Read-Aloud fetches pages for requested audio, with a nopagereadaloud meta tag to opt out and published methods to verify requests.
Definition: As of 17 October 2026, Google documents
Google-Read-Aloudas the user-agent identifier sent in HTTP requests by its Read Aloud service. This user-triggered fetcher retrieves web pages for text-to-speech, the conversion of written text into spoken audio.
Key facts
- Google's user-triggered fetcher documentation lists mobile and desktop user-agent strings containing
Google-Read-Aloud. - Google's Read Aloud documentation specifies
nopagereadaloudas the opt-out meta tag and says robots.txt cannot provide this opt-out. - Google's paywall structured data guide uses
isAccessibleForFreeset tofalseto identify paywalled content. - Google's request verification guide provides reverse and forward domain-name lookups, plus published IP ranges for automated verification.
What happens when someone requests audio?
Google's Read Aloud documentation describes activation when a person visits a page with text-to-speech enabled. It renders without the listener's cookies and does not follow links.
Read Aloud caches pages, so a listening request can use a recent copy without another page visit. Repeated fetches of a page can still occur. These documented behaviors mean that server logs cannot provide a count of listening requests.
How can a website control Read Aloud?
Google's opt-out instructions give this HTML meta tag:
<meta name="google" content="nopagereadaloud">
The service may proactively access and render the page and embedded resources to recognize meta tags. After it recognizes this tag, future requests are reduced automatically. The instructions also direct publishers to set isAccessibleForFree to false in paywall structured data to prevent paywalled content from being read aloud.
Google's paywall markup guide shows a NewsArticle example with hasPart, a WebPageElement, and a cssSelector identifying the paywalled section. These properties describe which content is behind the paywall. The guide applies to content a publisher wants crawled and indexed.
How can requests be identified and verified?
Google's fetcher list gives this desktop example:
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/137.0.0.0 Safari/537.36 (compatible; Google-Read-Aloud; +https://support.google.com/webmasters/answer/1061943)
The same list warns that user-agent strings can be spoofed. Google's verification instructions call for a reverse domain-name lookup of the requesting IP address, checking the returned domain, then a forward lookup confirming that hostname resolves to the original address.
For automated checks, the guide lists separate IP ranges for user-triggered fetchers controlled by Google in user-triggered-fetchers-google.json. It says those addresses resolve to a google.com hostname. This supplies an additional identity check before a server rule trusts the request's name.
Related terms
- Googlebot
- robots.txt
- User-agent spoofing
- How do I check whether a request really comes from Googlebot?
FAQ
Can you block Read Aloud with robots.txt?
Google's Read Aloud documentation specifies nopagereadaloud for this purpose and says robots.txt cannot provide the opt-out.
What does google-speakr mean in older logs?
Google's fetcher list identifies google-speakr as the deprecated former agent. The current name is Google-Read-Aloud.
Sources
- Google, "List of Google user-triggered fetchers", updated 19 August 2026
- Google, "Google Read Aloud user agent", updated 2 December 2025
- Google Search Central, "Structured data for subscription and paywalled content (CreativeWork)", updated 8 September 2026
- Google, "Verify requests from Google crawlers and fetchers", updated 20 March 2026
Check how a page reads to answer engines. Open the GEO score analyzer