Rendering
Rendering is the step where a search engine runs a page's code, including JavaScript, to build the final version it sees, just like a browser does. What gets rendered is what gets indexed.
Rendering is the part of the pipeline where a search engine takes the raw code it fetched and actually runs it to build the page a human would see. For a plain HTML page, there is barely anything to do. For a modern site built with React, Vue, or any framework that assembles content in the browser, rendering is where the real content finally appears.
This matters because a lot of pages send almost nothing in their initial HTML. The first response is a near-empty shell, and the actual headlines, body text, and links get injected by JavaScript after the page loads. If the search engine never executes that JavaScript, it sees the empty shell and indexes nothing useful.
Search engines index what they render, not what your code intends to display. If the content only appears after JavaScript runs, the engine has to run that JavaScript to count it.
How Google handles rendering
Google uses what it describes as a two-wave or two-phase process. First it crawls and indexes whatever is in the raw HTML. Then, when resources are available, it puts the page in a rendering queue, runs the JavaScript using an up-to-date Chromium engine, and indexes whatever new content showed up. The gap between those two phases can be short, but it is not always instant.
- 1The crawler fetches the raw HTML response.
- 2The engine indexes what it can see immediately in that HTML.
- 3The page is queued for rendering when compute is available.
- 4The renderer executes JavaScript and builds the full page.
- 5The engine re-evaluates the rendered output and updates the index.
Rendering strategies and how friendly they are
| Strategy | What the engine gets first |
|---|---|
| Static HTML | Full content in the initial response, easiest to index |
| Server-side rendering (SSR) | Full HTML built on the server, then hydrated, very crawl-friendly |
| Client-side rendering (CSR) | An empty shell, content only appears after JavaScript runs |
| Dynamic rendering | Pre-rendered HTML served to bots, a workaround, not a long-term fix |
warningWATCH OUT
Do not assume Google sees what your browser sees. Your browser runs every script with no time limits. The engine may delay rendering, skip resources blocked in robots.txt, or fail on errors your browser quietly tolerates. Always verify with a tool, never by eyeballing the page yourself.
targetHow to test rendering
Use the URL Inspection tool in Google Search Console and look at the rendered HTML and the screenshot it produces. Compare that to your source. If important text or links are missing from the rendered version, the engine cannot see them either, and you have a rendering problem to fix.
Put content in the HTML
The safest move is to make sure your critical content, your headings, body copy, and internal links, exists in the HTML the server sends, not just in JavaScript that runs later. Server-side rendering or static generation removes the rendering gap entirely.
One more trap worth naming: resources blocked in robots.txt. If you disallow the JavaScript or CSS files a page needs to render, the engine tries to render and comes up short, because you blocked the very files that build the page. The rendered result looks broken or empty, and indexing suffers. When you audit rendering, always confirm the engine can fetch every script and stylesheet the page depends on, not just the HTML document itself.
If your site leans on JavaScript for content, rendering is the single most important thing to get right, and it deserves its own deep dive. Read my JavaScript SEO guide for the full playbook, and the technical SEO guide for where rendering fits in the bigger pipeline.
RELATED TERMS
Want this handled by someone who has measured search for 20 years?
Work with me