Google’s John Mueller told a Reddit user that blocking a third-party age-verification popup through robots.txt “would generally work” to keep Googlebot from rendering it. Search Engine Journal reported the exchange on Tuesday, November 3, 2026, and Search Engine Roundtable covered it as well. The answer matters because Google has long told publishers to let Googlebot fetch every resource a visitor sees.
The question was framed as a hypothetical. A site, called websiteA.com in the post, shows a legally required age-verification popup hosted on another domain and pulled into the page via an API. The asker wanted to know whether a disallow rule in that other domain’s robots.txt would stop Google from rendering the popup.
Mueller’s first reply was short. He said the approach would generally work, and that a site relying on one specific JavaScript file to load the popup could disallow that file instead. He added a limit: if a single JS file handles many jobs, he would not block it.
Hours later, Mueller laid out two routes in more detail. In the first, the domain serving the embedded content disallows crawling in its own robots.txt. Googlebot does not crawl those URLs as standalone pages, but it tries to fetch them during rendering. A robots.txt block means it skips the fetch and cannot use the content. Mueller compared this to how many ad services behave.
The second route applies when you do not control the other domain’s robots.txt. In that case, you block the script that loads the popup, using a rule in your own site’s robots.txt, and the script never runs during rendering. Mueller called this less common in his experience, but described it as a workable option. He used a file named “load-verification-popup.js” as his example.
One condition applies to both routes. Mueller said pages must still load properly when Google cannot fetch the blocked URLs. For a popup of this kind, he described that as rarely an issue. The condition is the real test: if the blocked script also controls navigation, content loading, or layout, the rendered page Google sees could differ in ways that hurt indexing.
Context separates this from the old habit of blocking scripts. SEJ’s Roger Montti notes that early SEO practice involved disallowing JavaScript and CSS to conserve crawl budget, and that sites which kept blocking critical resources after Google began rendering pages temporarily lost rankings. Mueller’s answer does not reverse that guidance. It carves out a narrow case: a non-content overlay that exists for compliance, not for ranking.
The scope is also narrow in what Mueller actually addressed. He answered a single hypothetical about one popup. He did not publish new documentation, and he did not say that blocking other scripts, stylesheets, or interstitials is acceptable. Treating his reply as a general license to disallow JavaScript would misread it.
A practical difference follows for teams that run consent banners, age gates, or chat widgets from vendor domains. Those overlays can sit on top of the primary content in Googlebot’s rendered view, and some teams may prefer that Google never sees them. Mueller made his comments informally on Reddit, and Google has not placed them in Search Central documentation.
Before disallowing anything, test the page in the URL Inspection tool with the resource blocked and compare the rendered screenshot against the live page. If the blocked script is the only thing that changes, the rule is likely safe; if main content shifts or disappears, remove it and look for a different fix.
Search Engine Journal, by Roger Montti, published November 3, 2026, with additional reporting from Search Engine Roundtable.
