Case Study 19.1 — How Google Learned to Render JavaScript (and What the Two-Wave Era Taught SEOs)

A Tier-1 case built entirely from the public, documented record of Google's own guidance and announcements. No statistics are invented; where exact figures are not public, we say so.

Background

For most of the web's first two decades, "the page" and "the HTML" were the same thing. A server sent a document; the content was in it; crawlers read it. Then JavaScript frameworks made it normal to send an almost empty document and build the page in the browser, and search engines — Google included — had to catch up to a web where the content increasingly did not exist until code ran. The story of how Google caught up is one of the most useful things a JavaScript SEO can know, because each chapter of it left behind a rule that still holds.

The search/SEO issue, in four public chapters

1) The AJAX crawling scheme (2009) — and its retirement (2015–2018). Recognizing that it could not render JavaScript well at the time, Google published a scheme in which sites could expose an HTML "snapshot" of JavaScript-built pages to crawlers, signaled by a special #! ("hashbang") fragment in the URL. It worked, in the narrow way stopgaps work. In October 2015, Google announced it was deprecating the scheme, saying its systems had become able to render and understand pages "like modern browsers," and it later fully retired support. The lesson banked: bot-only snapshot schemes are stopgaps that Google eventually walks away from — build for real rendering, not for the crawler's crutch.

2) The "two waves" reveal (Google I/O, 2018). In a widely-referenced conference talk, Google engineers described indexing of JavaScript sites as happening in two waves: Google would index the raw HTML first, then — because rendering is resource-intensive — come back to render and index the JavaScript-dependent content later, sometimes after a meaningful delay. This was the moment the SEO industry got a public, mechanistic explanation for a phenomenon it had been observing: JavaScript content that took a long time to appear in search, or appeared incompletely. The lesson banked: rendering is decoupled from crawling; content that needs rendering can be seen late.

3) Evergreen Googlebot (May 2019). Google announced that Googlebot would run a current, continuously updated version of Chromium rather than a years-old fixed browser. Overnight, the "Googlebot uses an ancient browser" era ended: modern JavaScript features that used to break silently now ran. The lesson banked: Google genuinely renders modern JavaScript — "Google can't read JS" became false.

4) Dynamic rendering: recommended, then downgraded. Around the same period Google suggested dynamic rendering (serving pre-rendered HTML to bots, client-rendered JavaScript to users) as a workaround for sites that could not easily server-render. In later documentation, Google reframed dynamic rendering as a workaround rather than a long-term recommendation, steering teams toward server-side rendering, static generation, or hydration instead, and cautioning that the two versions must not diverge (or it becomes cloaking). The lesson banked: even Google's own suggested workaround was superseded by "just put the content in the HTML for everyone."

What it shows

  • Google's JavaScript handling improved dramatically — and the goalposts for SEOs moved from "can Google see it at all?" to "will Google see it reliably and in time, and does everything else that reads the web see it too?" The problem did not disappear; it matured.
  • Every bot-specific accommodation Google offered was temporary. The #! scheme and, later, dynamic rendering were both eventually described as stopgaps. The durable path each time was the same: server-render or pre-render the content so no special treatment is needed.
  • Public guidance is a moving target, and reading it at its date matters. Advice that was current in 2016 (use the AJAX scheme) or 2019 (dynamic rendering is a reasonable workaround) is not current now. This is why the evidence-tier habit from Chapter 2 applies to dates, not just sources.

Outcome

The modern consensus, reflected in Google's current Search Central documentation, is exactly the chapter's thesis: Googlebot renders JavaScript with an evergreen engine, but rendering is a separate step that can be delayed or fail; the recommended architectures are server-side rendering and static generation because they put real content in the HTML for all consumers; and dynamic rendering survives only as a discouraged workaround that must never become cloaking. The industry that once argued about whether Google could handle JavaScript at all now argues about hydration cost and render budgets — a sign of how far the baseline moved.

The lesson

Accommodations for crawlers age out; content in the HTML does not. Across fifteen years and four policy chapters, the advice that never expired was the least clever one — make the content plainly present before the JavaScript runs. Learn the history not for nostalgia but for inoculation: the next "clever trick to make Google see your JavaScript site" will, in all likelihood, follow the same arc as the #! scheme, and you can skip straight to the durable answer.

Discussion questions

  1. The #! AJAX scheme and dynamic rendering were both, in the end, described by Google as stopgaps. What do they have in common structurally, and what does that suggest about evaluating the next bot-specific workaround someone pitches you?
  2. Evergreen Googlebot (2019) made "Google can't read JavaScript" false. Why did it not make JavaScript SEO a solved problem? Tie your answer to at least two of the failures in §19.6.
  3. A blog post from 2016 recommends the AJAX crawling scheme; a post from 2019 recommends dynamic rendering. Both were reasonable at their date. How should a practitioner read dated SEO advice so as not to be misled by it? (Connect to the evidence-tier habit from Chapter 2.)
  4. Google reframed dynamic rendering from "suggested workaround" to "not recommended long-term." If a client is currently running dynamic rendering successfully, does this history mean they must rip it out tomorrow? Argue both sides, then state your recommendation.