Rendering is the step where a browser, or a search engine’s crawler, turns a page’s code into the finished page a person sees: it runs the JavaScript, applies the styles and assembles the final content. For SEO, it is the moment Google sees what is really on the page, rather than only what was in the first file the server sent.
How rendering works
A page arrives as an HTML file that may refer to stylesheets, images and scripts. Some sites send nearly complete HTML; others send an almost empty shell and rely on JavaScript to fetch and insert the content. The browser parses the HTML into the DOM (its working model of the page), runs the scripts that change it and paints the result on screen.
Googlebot handles this in stages. It fetches the HTML and reads any links and text it finds there. The URL then joins a queue for Google’s Web Rendering Service, which loads the page in a recent version of Chromium, runs the JavaScript and captures the rendered HTML. That rendered version is what Google indexes. Google renders essentially every page it crawls, but the queue means rendering can lag behind the first fetch, and anything that fails during rendering is simply not seen.
Where the work happens matters. With server-side rendering, the server builds the full HTML before sending it, so content and links are present from the first fetch. With client-side rendering, the browser or crawler has to run the JavaScript to get the content at all. Static generation builds the HTML in advance. Many modern frameworks mix these approaches page by page.
Why it matters
If Google cannot render the content, the content does not exist for search purposes. I see this most often on sites built with JavaScript frameworks, where product descriptions, prices or internal links appear only after a script runs or after the visitor opens a tab. A Shopify store with a heavy reviews app, or a brochure site built with an elaborate page builder, can have a milder version of the same problem.
Not every crawler renders. At the time of writing (October 2026), several AI crawlers are reported to read only the raw HTML, so content that appears only after JavaScript runs may be invisible to them even when Google indexes it. For a UK business that wants to be cited in AI answers as well as ranked, sending meaningful HTML from the server is the safer design.
Common mistakes
- Blocking scripts or stylesheets in robots.txt, so Googlebot cannot load what it needs to build the page.
- Links that are not real links. Menus built from buttons and click handlers rather than anchor elements with an href give Google nothing to follow.
- Content behind interaction. Google’s renderer does not click, scroll or type, so text that loads after a click or during infinite scroll may never be seen.
- Different signals before and after rendering. If the raw HTML carries one title, canonical or robots tag and the rendered page another, Google may act on the wrong one. A noindex in the raw HTML can stop Google rendering the page at all, so removing it with JavaScript does not work.
- Checking only in your own browser, which has the scripts cached and behaves nothing like a crawler.
How to act on it
Use the URL Inspection tool in Search Console on a few important templates: a service page, a product page, a blog post. Run a live test, then open the rendered HTML and the screenshot. Check that the main text, internal links, title and canonical are all there. Compare with View Source in your browser, which shows the raw HTML before any scripts run.
If key content appears only after rendering, the fix is usually architectural: server-side rendering or static generation for the pages that need to rank. That is a conversation with your developer, and it forms part of the technical SEO work I do when a site’s content is not reaching the index. The entry on JavaScript SEO covers framework choices in more depth.