What "rendering" actually means in SEO
Rendering is the step where a browser (or Googlebot) takes your raw HTML, CSS, and JavaScript and turns it into the finished page a user sees, running any scripts that add or change content along the way. For search, the thing that matters is the gap between what the server first sends and what exists after the JavaScript finishes: Google indexes the rendered DOM, not the raw file, so anything your scripts inject has to survive that second pass to be seen.
The stakes are simple. If your title, body copy, internal links, or product data only appear after client-side JavaScript runs, and that render fails, times out, or gets deferred for days, Google indexes a hollow page. I have watched sites with beautiful, content-rich pages rank for nothing because the crawler saw an empty <div id="root"></div> and a spinner.
Raw HTML vs the rendered DOM: a concrete example
Here is the difference in plain terms. A client-side React or Vue app often ships a near-empty document:
<!-- What the server sends (view-source) -->
<!doctype html>
<html>
<head><title>Loading…</title></head>
<body>
<div id="root"></div>
<script src="/static/app.bundle.js"></script>
</body>
</html>After the bundle downloads, parses, and executes, the DOM becomes the real page:
<!-- What exists after rendering (Inspect element) -->
<div id="root">
<h1>Merino Wool Base Layer</h1>
<p>Lightweight, odor-resistant, machine washable…</p>
<span class="price">$89.00</span>
<a href="/collections/base-layers">More base layers</a>
</div>Two ways to see this yourself: View Source (Ctrl+U) shows the raw HTML the server sent; Inspect / Elements shows the rendered DOM. If your content is in the second but missing from the first, you are relying entirely on rendering, and that is exactly where things break.
In Google Search Console, the URL Inspection tool → "Test Live URL" → "View Tested Page" → "HTML" tab shows you the actual rendered HTML Googlebot produced. If your <h1> and body copy are not in that rendered HTML, Google is not seeing them either.
Rendering methods compared
| Method | Where HTML is built | What the crawler gets on first request | SEO risk | Good fit for |
|---|---|---|---|---|
| Static HTML | Ahead of time | Full content immediately | Lowest | Blogs, docs, marketing pages |
| Server-Side Rendering (SSR) | On the server, per request | Full content immediately | Low | Dynamic catalogs, logged-out views |
| Static Site Generation (SSG) | At build time | Full content immediately | Low | Content that changes infrequently |
| Client-Side Rendering (CSR) | In the browser, after JS runs | Empty shell + spinner | High | Logged-in app dashboards (not indexable content) |
| Dynamic Rendering | Prerendered copy served to bots | Full content (bot version) | Medium (Google calls it a workaround, not a fix) | Legacy JS sites you cannot rebuild yet |
Common CSR pitfalls that tank indexing
- Content only after user interaction. If copy loads on a click, scroll, or tab switch, Googlebot never triggers it. It does not click. Render your primary content on load.
- Blocked JavaScript. A
Disallow: /static/in robots.txt that hits your JS bundle means Google cannot render the page at all. Never block resources the render needs. - Router links that are not real anchors. A
<div onClick={navigate}>is invisible as a link. Use<a href="/real/url">so the crawler can discover pages. - Soft-404 shells. A failed data fetch that still returns HTTP 200 with an empty template gets indexed as a thin page.
How to check rendering on your own site
- Compare source vs DOM. Open the page, hit Ctrl+U for raw HTML, then right-click → Inspect for the rendered DOM. Search both for a sentence of your body copy. If it is only in Inspect, you depend on rendering.
- Run GSC URL Inspection. Paste the URL, click "Test Live URL", open "View Tested Page" → "HTML", and confirm your headline, copy, and links are present in Google's rendered output.
- Disable JavaScript. In Chrome DevTools, open Command Menu (Ctrl+Shift+P), type "Disable JavaScript", reload. Whatever disappears is content Google can only get through rendering.
- Fetch with curl. Run
curl -s -A "Googlebot" https://example.com/page/ | grep "your headline". No match means the server did not send it in the raw HTML. - Check the Crawl Stats report. In GSC → Settings → Crawl stats, watch for spikes in "Other error" or slow response times on JS files, which signal render budget problems.
Common mistakes and fixes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Full CSR for indexable content | Crawler sees an empty shell first | Move to SSR or SSG so HTML ships complete |
| Blocking JS/CSS in robots.txt | Google cannot render the page | Allow all render-critical resources |
| Lazy-loading main copy on scroll | Bot never scrolls, never loads it | Render above-the-fold and primary copy on load |
| Injecting canonical/meta via JS | Google may not pick up late-injected tags reliably | Emit canonical and title server-side |
| Treating dynamic rendering as permanent | Two codebases drift; cloaking risk if versions differ | Use it as a bridge, migrate to SSR |
FAQ
Does Google render JavaScript at all?
Yes. Googlebot uses an evergreen Chromium to render pages in a second wave after the initial HTML crawl. The catch is that rendering is deferred and resource-limited, so heavy JS pages can wait longer to be fully indexed, and anything that fails to render silently vanishes.
How do I know if my content depends on rendering?
View Source and search for your body text. If it is missing there but present in Inspect (the live DOM), that content exists only after rendering, so its indexing depends entirely on Google's render step succeeding.
Is server-side rendering always better for SEO?
For content you want indexed, SSR or static HTML removes the render dependency entirely, which is the safest path. For logged-in app UI that should never be indexed, CSR is perfectly fine.
What is the difference between rendering and pre-rendering?
Rendering is the general act of building the final page from HTML/CSS/JS. Pre-rendering means generating that finished HTML ahead of the request (at build time or via a bot-facing cache) so the crawler gets complete content without executing your app.
Why does my page look fine to me but rank poorly?
Your browser runs the JavaScript flawlessly, so you see the finished page. Googlebot renders on a delay with a budget, and if the render is slow, blocked, or interaction-gated, it indexes far less than you see. Always verify with the rendered HTML in URL Inspection, not your own screen.
Related reading
- Server-Side Rendering — the most reliable fix for render-dependent content.
- Pre-Rendering — generating finished HTML ahead of the request.
- Dynamic Rendering — serving a bot-facing prerendered copy as a bridge.
- Disallowed JavaScript File — why blocking JS breaks rendering outright.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
