Chapter 19 — Key Takeaways
The one sentence: Get your important content and links into the HTML that arrives before any JavaScript runs; let JavaScript enhance from there, never be the only way the content exists.
Core claims
- Google renders JavaScript with an evergreen, Chromium-based engine (since 2019) — but rendering is a separate, later step that can be delayed, partial, or fail. "Can render" ≠ "reliably renders your content in time."
- The Web Rendering Service does not scroll, click, hover, log in, wait indefinitely, or keep state between pages. Ask: "does this appear for a fresh, impatient, non-interacting visitor?"
- Client-side rendering (CSR) ships an empty shell and builds content in the browser — so the content exists only after a render that might not happen in time. This is the risk.
- The framework (React/Vue/Angular) is not the problem — the rendering mode is. The same React app can be a client-rendered liability or a server-rendered, fully-indexable asset.
The rendering options at a glance
| Option | Content in raw HTML? | Verdict |
|---|---|---|
| Client-side rendering (CSR) | No (empty shell) | Fine for pages that don't need to rank (behind login); risky for content that must rank |
| Server-side rendering (SSR) | Yes (per request) | Recommended; good for dynamic/fresh content |
| Static site generation (SSG) | Yes (built ahead) | Recommended; fastest/most robust for content that doesn't change per request |
| Dynamic rendering | Yes, for bots only | Workaround, not recommended long-term; becomes cloaking if bot/user content diverges |
The "can Google see it?" test (free, in order)
- View Page Source (Ctrl+U) → Ctrl+F for a sentence you can see. In the source = safe.
- Disable JavaScript and reload → what disappears is a hard dependency (a pessimistic stress test).
site:phrase search → quote a distinctive rendered sentence and search Google; page returns = indexed.- URL Inspection (Search Console) → read the rendered HTML and blocked resources = the ground truth.
The three classic failures (and the fix)
| Failure | Why it breaks | Fix |
|---|---|---|
Links that aren't links (<div onclick> instead of <a href>) |
No href → Google can't follow; pages orphaned, no authority flows |
Use real <a href> anchors (framework link components already do) |
| Content only on interaction (Load more, infinite scroll, click-to-load tabs) | Googlebot doesn't scroll/click | Render important content on load; provide real paginated URLs; put tab/accordion text in the HTML |
Hash-fragment routing (example.com/#/x) |
The # fragment isn't sent to the server; Google sees one URL |
Use path-based URLs via the History API (example.com/x) |
Also watch: JS/CSS folders blocked in robots.txt (Google can't render → indexes the shell); JavaScript-injected
title/canonical/noindex (can be missed or act on the initial-HTML version).
Myths busted
- 🚫 "Google can't read JavaScript." — False since 2019; it renders modern JS.
- 🚫 "Google renders JavaScript perfectly now, so JS SEO is solved." — Also false; a flawless renderer still can't follow a missing link, click a button, or split one URL into many.
- 🚫 "Dynamic rendering is cloaking." — Not if the content is equivalent; cloaking is serving different content to bots to manipulate rankings.
Key terms
client-side rendering (CSR) · server-side rendering (SSR) · static site generation (SSG) · dynamic rendering · hydration · two-wave index · prerendering
On your own site tomorrow
Run step 1 of the test on your most important page: View Source and Ctrl+F for a sentence you can see. If
it's there, mark it safe. If it isn't, run the site: phrase search and (if you have it) check the rendered
HTML in URL Inspection — then write one sentence recording exactly what Google can and cannot see.