Bots
Google-Read-Aloud: allow it or block it?
Google-Read-Aloud is the fetcher behind Google's text-to-speech: when a person asks Google to read a web page aloud, it fetches that page. Allow it. Each request is one reader, often one who needs audio. Google says its user-triggered fetchers generally ignore robots.txt, so a rule will not reliably stop it, and a Googlebot-only allowlist can silently break it.
7 days free · card required
0requests filed as Google-Read-Aloud · 30 days
of 143,601 AI crawler requests from 7 operators
We do not name Google-Read-Aloud. It falls through to the wildcard group, which allows everything except /api/. Its operator states robots.txt may not apply to it, so this group is a preference at most.
# No group names# Google-Read-Aloud, so it reads# the wildcard group.User-agent: *Allow: /Disallow: /api/
Analyst · reads the AI traffic boardAI traffic board, read over the Attensira MCP, and our live robots.txt · · n=143,601 AI requests
Karl-Gustav Kallasmaa, Founder & CEOLast updated Who runs Google-Read-Aloud, and what is it for?
Google runs it, and we file it under user-triggered fetch. Fetches one page because a person asked to hear it read aloud. Google does not describe the fetch as feeding Search or Gemini, so it does not decide whether you are cited.
From Google’s documentation, read . Why a training fetch and a search fetch are different decisions: the AI crawler guide.
How do I allow or block Google-Read-Aloud in robots.txt?
Paste this into the robots.txt at the root of your domain. The operator says the agent may not read robots.txt, so the group records your preference; enforce anything sensitive on the server.
# Do not rely on this block to# stop the fetch. Google documents# the user-triggered fetchers as# generally ignoring robots.txt,# because a person asked for the# page.## User-agent: Google-Read-Aloud# Disallow: /## Treat it as a reader, not a# crawler.Why should you let Google-Read-Aloud in?
Because it is a listener, not a crawler. Google documents that, upon user request, Google Read Aloud fetches and reads out web pages using text-to-speech1. Someone asked to hear your page. The request in your log is the mechanical result, one per person per page.
The reflex on seeing an agent you cannot block in robots.txt is to reach for the network layer. Here the thing being blocked is somebody's route into your writing, a route that exists disproportionately for people who need it. Whether you allow it is your decision, but making it in the belief that this is a crawl would be making it on a mistake.
How do I verify that a visit really came from Google-Read-Aloud?
A user-agent header is free text, so a log line naming Google-Read-Aloud is a claim until you check it.
Look up the visiting IP, confirm the hostname ends in one of the suffixes in the record, then look that hostname up and confirm it returns the same IP, or match the IP against the published ranges.
Google documents two masks for this category depending on whether the fetcher is Google-controlled or user-owned, with a separate range file for each. Neither is Googlebot's googlebot.com mask, so verification code written for Googlebot rejects every real request here.
Does robots.txt bind Google-Read-Aloud?
Not reliably. Google defines user-triggered fetchers as tools and product functions where the end user triggers a fetch4, and states that because the fetch was requested by a user, these fetchers generally ignore robots.txt rules3.
So a User-agent: Google-Read-Aloud group is not a control you can rely on. "Generally" leaves room for a fetch that honours it, but nothing tells you which, so the reader you meant to let in and the fetch you meant to stop look the same. The block in the robots.txt section above is commented out for that reason. A live group in a real file is a maintenance hazard: the next person to edit the file will read it as proof that the fetch is governed.
Why does read-aloud silently fail on some sites?
Because of verification code written for Googlebot. This category has its own path. Google documents the user-triggered fetchers' reverse DNS masks as *.gae.googleusercontent.com or google-proxy-*.google.com, depending on whether the fetcher is Google-owned or user-owned, and publishes their ranges in user-triggered-fetchers.json, user-triggered-fetchers-google.json and user-triggered-agents.json5.
An allowlist keyed to googlebot.com therefore rejects every genuine Read Aloud request, while admitting anything that copies the header. The visible symptom is not an error on your side. It is a person for whom your page is never read out. If someone reports that read-aloud fails on your site, look at the bot mitigation before you look at the page.
Verify properly instead: reverse-resolve the address, check the domain against the masks above, forward-resolve the hostname and confirm it returns the same address, or match the address against the range files listed in the verification section.
- Reverse DNS ends in
- *.gae.googleusercontent.com*.google.com
ResearcherTranscribed from Google documentation · In this entry
- Why should you let Google-Read-Aloud in?
- Does robots.txt bind Google-Read-Aloud?
- Why does read-aloud silently fail on some sites?
- Which header should you match, now that there are two Chrome versions?
- Where does Google-Read-Aloud belong in a crawler report?
- How does it compare with Google's other user-triggered fetchers?
- What can Attensira show you about Google-Read-Aloud?
Which header should you match, now that there are two Chrome versions?
The bare token. Google publishes two current strings, a desktop one on a Linux x86_64 preamble carrying Chrome/137.0.0.0 and a mobile one on an Android preamble carrying Chrome/138.0.0.0, both ending in a compatible clause that names Google-Read-Aloud and links to a Google support page. It also lists a former agent, google-speakr, as deprecated2.
Two live Chrome versions in two published strings, plus a retired token, show why a rule pinned to a full header has an expiry date. Match Google-Read-Aloud, case-insensitively, as a whole word. If an old allowlist still names google-speakr, replace it.
Where does Google-Read-Aloud belong in a crawler report?
Near readership, not in the crawl budget. In the four-way job taxonomy of the AI crawler guide it is user-triggered, a category defined by who started the request rather than by what the operator does with the result. It is not a crawl of your site, so its volume says nothing about crawling, indexing or training. Put it in its own row. A spike means people are listening to a page, which is worth knowing about that page.
How does it compare with Google's other user-triggered fetchers?
| Agent | What the user asked for |
|---|---|
| Google-Read-Aloud | Hear a page read aloud |
| Google-GeminiNotebook | Use a page as a source in a notebook |
| Google-Agent | Have an agent navigate and act on the web |
| Google-Site-Verification | Verify ownership of a site in Search Console |
All four are fetches a person started, and Google documents user-triggered fetchers as generally ignoring robots.txt.
What can Attensira show you about Google-Read-Aloud?
AI traffic, on Growth and Business, counts which pages agents and fetchers request, grouped by operator and declared purpose, measured at the edge. User-triggered fetches therefore stay out of crawl totals. It reports user agents as sent; checking the right reverse DNS mask stays your step. See crawler logs, and write rules for the tokens that do read robots.txt with the robots.txt generator.
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:/Agents filed beside Google-Read-Aloud
Should I allow Google-Read-Aloud in my situation?
Concrete cases, and what each one implies for this agent.
A robots.txt rule naming Google-Read-Aloud has had no effect and you think the rule is wrong.
Remove the rule; Google documents the fetcher as generally ignoring robots.txt.
Google documents that the user-triggered fetchers generally ignore robots.txt rules because the fetch was requested by a user. A rule that may not work is worse than no rule, because it leaves a maintainer believing there is a control where there may be none.
Your bot mitigation is challenging this agent and a user reports that read-aloud on your site fails silently.
Allow verified user-triggered fetchers through, and verify by address rather than by header.
The request represents a person who chose your page and wants it read to them. A challenge page cannot be answered by a fetcher, so the failure surfaces to the reader as your site not working, with nothing in your logs framing it as an accessibility problem.
You are counting bot traffic and Google-Read-Aloud hits are landing in the crawler bucket.
Count it as a reader-initiated fetch, in a row of its own.
A user-triggered fetch is one request standing in for one person, not a crawl of your site, so its volume behaves like readership rather than like crawl budget. Averaged into a crawler total it makes that total move for reasons that have nothing to do with crawling.
What else do people ask?
What is Google-Read-Aloud?
Should I allow Google-Read-Aloud?
What was google-speakr?
Where do these facts come from?
5 claims on this page, each with the page it was read from; last checked . The numbers in the text point here.
Google documents that, upon user request, Google Read Aloud fetches and reads out web pages using text-to-speech.
developers.google.com · retrieved
“Upon user request, Google Read Aloud”
Google publishes a desktop agent for Google Read Aloud built on a Linux x86_64 preamble with Chrome/137.0.0.0 and a mobile agent built on an Android preamble with Chrome/138.0.0.0, both ending in a compatible clause that names Google-Read-Aloud and links to a Google support answer, and lists google-speakr as a former, deprecated agent.
developers.google.com · retrieved · changes often, check the source
“(compatible; Google-Read-Aloud;”
Google states that because the fetch was requested by a user, the user-triggered fetchers generally ignore robots.txt rules.
developers.google.com · retrieved
“Because the fetch was requested by a user, these fetchers generally ignore robots.txt rules.”
Google documents user-triggered fetchers as tools and product functions where the end user triggers a fetch, giving Google Site Verifier acting on the request of a user as its example.
developers.google.com · retrieved
“User-triggered fetchers are initiated by users to perform a fetching function within a Google product.”
Google documents the user-triggered fetchers' reverse DNS masks as ***-***-***-***.gae.googleusercontent.com or google-proxy-***-***-***-***.google.com, and publishes their IP ranges in the user-triggered-fetchers.json, user-triggered-fetchers-google.json and user-triggered-agents.json objects.
developers.google.com · retrieved
“The user-triggered fetchers' reverse DNS mask, depending on whether the fetcher is Google or user owned, matches”
Want whatever it takes to win the answer?
7 days free · card required