Googlebot Waits for Your GTM-Injected Schema. AI Crawlers Don’t.

Google Tag Manager was never a blocking problem for Google, just a slower one. The trade-off was simple: fast implementation, no developer queue, one custom HTML tag, and the job gets done. Googlebot eventually executes the JavaScript, reads the JSON-LD, and processes the entities. That is why many technical SEO teams have relied on this shortcut for years: Google’s infrastructure was built to tolerate the delay.

AI search infrastructure was not built the same way. It does not wait.

For a site that relies on schema for entity recognition in ChatGPT, Claude, or Perplexity, that architectural gap means a complete structural absence from the AI retrieval layer.

Here is the data behind that claim. The Vercel and MERJ analysis of AI crawler traffic, published in December 2024, found that GPTBot fetches JavaScript files in roughly 11.5% of its requests, and ClaudeBot in roughly 23.84%. Neither crawler executes what it fetches. The same fetch-without-execute pattern continues to show up across independent SEO analyses through 2026, and the conclusion stays consistent: outside of Google’s and Apple’s own infrastructure, none of the major AI crawlers currently render JavaScript.

In practice, that means a site can have a GTM-implemented schema that Googlebot eventually sees and processes, while that same schema remains structurally invisible to ChatGPT, Claude, and Perplexity. Same schema, same site, two different outcomes. Most technical SEO audits still don’t check for the second one.

This blog post is that check.

What Google’s Own Documentation Says About Structured Data and Google Tag Manager

Google’s own documentation on generating structured data with JavaScript groups Google Tag Manager alongside custom JavaScript as a method for producing structured data dynamically. Both sit apart from a third option: including structured data directly in server-side rendered output. In other words, Google Tag Manager and server-side rendering are not the same category of solution. They sit on opposite sides of a rendering boundary that Google’s own documentation draws explicitly.

A second, separate Google resource confirms the same divide from another angle. Google’s documentation on dynamic rendering (the same technique this post later calls prerendering) is equally direct about its own status: no longer framed as a recommendation, but as a workaround for sites that cannot migrate to genuine server-side rendering. Server-side rendering, static rendering, and hydration are the preferred long-term paths instead.

Read together, these two documents establish the foundation for everything that follows. Google’s own crawler can bridge the gap between client-side and server-side structured data through its render queue.

What this blog post answers next is what happens when the crawler on the other end cannot.

How Googlebot’s Render Queue Differs From an AI Crawler’s Fetch-and-Go Behavior

Googlebot’s Two-Wave Crawl

Googlebot operates as a two-wave crawler. The first wave reads the raw HTML a server returns. The second wave, run through Google’s Web Rendering Service, executes the page’s JavaScript and captures whatever that execution produces, including Google Tag Manager’s DOM injections.

Once a page reaches the front of that queue, Google’s own median processing time is measured in seconds. The variable part is the wait to get there. An independent crawl experiment measured that wait at anywhere from hours to well over a week, depending on a domain’s crawl budget and how often Google judges it worth revisiting.

In short, Google Tag Manager schema arrives late for Googlebot. It is not invisible to it.

Why AI Crawlers Skip the Second Wave

GPTBot, ClaudeBot, and PerplexityBot do not run a second wave at all.

OpenAI’s own crawler documentation confirms that GPTBot and OAI-SearchBot are separate, purpose-built crawlers governed independently through robots.txt. Neither one includes a rendering step.

Anthropic tells a similar story. Anthropic updated its crawler documentation to clarify the distinct roles of ClaudeBot, Claude-User, and Claude-SearchBot. Separately, Anthropic’s documentation on Claude’s web fetch tool, a related but distinct system used when someone pastes a URL directly into Claude, states plainly that the tool does not currently support websites that render dynamically through JavaScript. That web fetch tool is not the crawler itself, but the design choice behind it is the same one: fetch the initial HTML, extract what is there, and move on.

The Technical Reason: No Browser, No Execution

Google Tag Manager’s Custom HTML tags fire only after gtm.js loads and executes inside a browser environment. That is the mechanism, not an incidental implementation detail. A Node.js server process has no window object and no document object for gtm.js to act on. That absence is exactly why Google Tag Manager cannot run inside a standard server-side rendering pipeline the way a framework’s own component code can.

Whatever Google Tag Manager injects exists only after a JavaScript engine executes it in a browser context. An AI crawler that never opens a browser context never sees it.

GTM Schema Across Seven Crawlers: A Direct Comparison

The practical question for a technical SEO audit is which crawlers actually reach GTM-injected schema and which ones stop at the raw HTML. The table below answers that question crawler by crawler.

Gemini is the one AI surface on this list that reads Google Tag Manager schema without a workaround, and its advantage has nothing to do with being more advanced. Gemini simply borrows Googlebot’s own rendering infrastructure instead of running independent crawler infrastructure.

Apple’s own documentation confirms a similar exception. Applebot, which powers Siri, Spotlight, and Apple Intelligence web answers, explicitly states that it may render page content within a browser, and lists JavaScript among the resources it needs to do so. Like Gemini, Applebot represents genuine infrastructure investment, not a workaround – a real rendering capability built into the crawler itself.

Every other AI surface in the table above runs its own crawler, built for speed and scale rather than rendering fidelity, and none of those crawlers inherit the kind of rendering investment Google and Apple have made.

Bing’s own guidance reinforces what the table above already shows. Bing’s webmaster guidelines state that content which cannot be reliably rendered may not be indexed or selected for grounding results, including Copilot citations. Since GTM-injected schema is JavaScript-dependent content, Bingbot’s inconsistent JavaScript handling applies to it the same way it applies to any other client-side element.

The Prerendering Exception, and Why It Rarely Applies to a WordPress Site

A genuine exception exists, and a technically rigorous audit has to name it rather than round it off: prerendering.

Elie Berreby’s January 2025 piece, written explicitly as a forward-looking take rather than a permanent snapshot, lists it as one of three ways to keep GTM-injected schema visible to AI crawlers, alongside static HTML and genuine server-side rendering – the same three-way split Google’s own documentation draws.

Here is how that exception actually works.

Prerendering, that same dynamic rendering workaround mentioned earlier, detects a bot’s user agent at the server level and returns a cached HTML snapshot that a headless browser produced earlier by executing the page’s JavaScript in full, Google Tag Manager included. A human visitor still receives the live, client-rendered page. A bot receives the frozen result of that same page, already fully executed.

Under a prerendering setup, and only under a prerendering setup, an AI crawler’s raw HTML request does contain GTM-injected schema, because the JavaScript execution already happened server-side before the bot ever made its request.

In practice, though, this exception rarely applies to the sites a technical SEO audit actually covers. Prerendering infrastructure, whether self-hosted through Puppeteer or purchased through a service like Prerender.io, exists almost exclusively on large, JavaScript-heavy applications retrofitting AI crawler visibility without a full framework migration. A WordPress site running RankMath or AIOSEO with a Google Tag Manager container in the header has no prerendering layer sitting in front of it, so the schema that container injects never reaches the raw HTML an AI crawler fetches.

The audit-level takeaway, then, is narrow and precise. Google Tag Manager schema is invisible to AI crawlers for the overwhelming majority of sites a technical SEO practitioner will ever touch. The exception that proves otherwise requires infrastructure most of those sites do not have, and that they are unlikely to build for this reason alone.

What Is Verifiable, What Is Inferred, and What Stays Unconfirmed

Verifiable: What Each Company Confirms

OpenAI’s, Anthropic’s, and Google’s own documentation confirm the mechanics above in each company’s own words. GPTBot and ClaudeBot do not execute JavaScript. Googlebot renders JavaScript on a delay through a two-wave crawl.

Applebot renders JavaScript through its own browser-based infrastructure, confirmed directly in Apple’s own documentation.

Google Tag Manager operates exclusively client-side, and prerendering, where implemented, produces a server-delivered snapshot that bridges the gap.

Inferred: What the Pattern Suggests

Independent crawler-traffic research, most notably the Vercel and MERJ analysis, consistently finds the same pattern across sampled sites: AI crawlers fetch JavaScript files without executing them, at measurable but low rates.

That pattern continues to be reported across independent SEO analyses through 2026. Still, the underlying AI crawler codebases are not open source, so no outside party can confirm the mechanism beyond observed behavior.

Unconfirmed: What No Company Has Said Publicly

Whether OpenAI, Anthropic, or Perplexity plan to add JavaScript rendering to their crawlers, and on what timeline, is not publicly documented by any of the three companies.

xAI’s Grok crawler adds a different kind of gap: whether it renders JavaScript at all is unaddressed in any documentation xAI has published.

Elie Berreby’s own January 2025 piece explicitly frames the no-rendering status quo as temporary rather than permanent, warning that the SEO industry should prepare for a shift rather than assume today’s mechanics will hold.

Nothing published since confirms a change. Nothing published since rules one out, either.

Where GTM Schema Work Leaves the Modern Technical SEO Audit

Optimizing for AI search is not a fully separate, isolated discipline from traditional technical SEO. It is a direct evolution of it.

The foundations stay the same; what changes is the tolerance threshold for technical shortcuts, and that threshold keeps narrowing.

Schema Sits Inside the Same Proxy-Signal Layer as E-E-A-T

Google Tag Manager schema sits inside the same proxy-signal layer as the entity coherence and author signal work covered in this blog’s earlier breakdown of E-E-A-T as infrastructure.

Structured data that never reaches an AI crawler’s raw HTML cannot contribute to entity coherence in that crawler’s eyes, no matter how well-built the schema is. In effect, a site can hold the same technical foundations that have always mattered to Google, and still get filtered out of every AI surface that never built its own rendering infrastructure.

The reason is simple: those crawlers apply the same standards Google eventually applies, just without Google’s patience for late-loading content.

Where the Fix Actually Starts

The fix is not complicated to describe, even where it is not trivial to implement.

Structured data belongs in the initial HTML response a server sends, whether through a clean CMS plugin, a backend-generated JSON-LD block, or a genuine server-side rendering pipeline, rather than through a client-side container that an AI crawler will never open.

Verifying which category a given implementation falls into takes roughly thirty seconds: open the page, view source rather than inspect element, and search for a distinctive string from the JSON-LD block. If the string is missing from view source, no AI crawler sees it either.

That thirty-second check is where a technical SEO audit starts, not where it ends.

Confirming that schema exists in the raw HTML is one data point. Mapping which entities need that schema, structuring it so it survives a plugin update without silently breaking, and validating it on a recurring schedule rather than once at launch is the work that actually holds up under an agentic web that keeps adding new crawlers to check for.

If you want a clear, prioritized read on where your structured data actually stands – visible or invisible to AI crawlers – let’s do your website AI search readiness audit – you can contact me here.