JavaScript SEO: raw vs rendered HTML, and what to fix

Every page has two versions. The raw HTML is what the server sends. The rendered HTML is what exists after the browser has run the page’s JavaScript. On a server-rendered site they’re nearly identical. On a single-page app, or any site that builds content in the browser, they can be very different.

Google does render pages. Its JavaScript SEO documentation describes three phases: crawling the raw HTML, rendering it in a headless Chromium, and indexing the result. Rendering is queued, so it can happen later than the crawl. And Google isn’t the only crawler you care about. Many other bots, link-preview scrapers and AI crawlers read the raw HTML and stop there.

This guide covers the four differences worth checking, and how to find them across a whole site.

How do you compare raw and rendered HTML?

For a single page you can do it by hand:

• Raw: curl -s https://example.com/page, or View source in the browser
• Rendered: the Elements panel in devtools, or the URL Inspection tool in Search Console

That works for one URL, not for thousands. In Crawlens, turn on Render JavaScript when you start a crawl. Each HTML page is fetched as-is and also rendered in Chromium, and the two versions are compared automatically. The differences feed four audit checks:

What happens when JavaScript changes SEO tags?

This is the most serious difference: the title, meta description, canonical or meta robots tag in the raw HTML differs from the rendered one. Common causes:

• A framework sets <title> in the browser, so the raw HTML has a placeholder like Loading…
• A script injects or changes the canonical, for example based on URL parameters
• A noindex is added or removed by JavaScript

The last one is the dangerous case. Google states that when it encounters noindex it may skip rendering, so JavaScript that removes the tag may never run. Its advice is direct: if you want the page indexed, don’t put noindex in the original code. Canonicals get similar guidance: don’t use JavaScript to change the canonical to something other than what’s in the original HTML.

Fix: serve the final tags in the server response, using server-side rendering, static generation or pre-rendering. Tags that decide indexing shouldn’t depend on JavaScript.

Why do links that only exist after rendering matter?

Some navigation only appears after scripts run: menus built from an API call, “load more” buttons, links added by a client-side router. Crawlers that don’t render never find those links. Google finds them later than it would otherwise, because link discovery from rendered HTML waits for rendering.

Watch for links that aren’t really links. Google can only reliably follow <a> elements with an href attribute, as its guide to crawlable links explains. A <div onclick> or a <button> that changes the route won’t be followed, rendered or not.

Fix: output important navigation and internal links as <a href> in the server HTML, and give infinite scroll real paginated URLs behind it.

When is content too dependent on JavaScript?

Crawlens flags a page when it has at least 50 words after rendering and less than half of those words are in the raw HTML. In other words, most of what the page says only exists after rendering.

For Google that means slower indexing and more risk if rendering fails. For crawlers that don’t render, including many AI crawlers, the page is close to empty, so it won’t be cited, summarised or previewed with anything useful.

Fix: render the main content on the server, or pre-render the pages that need to rank. Interactive widgets can stay client-side. The text that answers the query shouldn’t.

Why do some pages fail to render?

Sometimes the rendered version never arrives: scripts throw errors, an API call hangs, or the page keeps loading forever. Crawlens reports these as Pages that failed to render, with the error, so they don’t look like pages that passed.

Fix: check the browser console on an affected URL. Look for slow third-party scripts, endless spinners and unhandled errors. If the site is simply slow, raising the request timeout in the crawl settings will get you a result, but the slowness is worth fixing for users too.

In what order should you fix JavaScript SEO issues?

1. Tag changes first, especially anything touching noindex or canonical. These decide whether pages are indexed at all.
2. Then links. If crawlers can’t find pages, nothing else about them matters.
3. Then content, starting with templates that cover many pages: product, category, article.
4. Re-crawl with rendering on and compare against the previous crawl to confirm the fixes, and that nothing else moved.

Do you need to render every crawl?

No. Rendering is slower and heavier than fetching raw HTML. A sensible routine is a regular raw crawl for the everyday checks, plus a rendered crawl after front-end releases or framework upgrades. If the site is a single-page app, render every time: on those sites the raw HTML alone tells you very little.