Fetch the raw HTML first, then inspect the rendered DOM. Google processes JavaScript in three phases — crawling, rendering and indexing — and can only see content that survives into the rendered HTML. If price, stock, variants or specifications exist only after scripts run, compare both versions side by side and confirm what actually appears in Google's rendered output before assuming it is indexable.
Why does Google see two different versions of a product page?
Googlebot queues pages for crawling and rendering separately, and it is not immediately obvious which queue a URL is waiting in. When Googlebot fetches a URL, it first reads robots.txt. If the URL is disallowed, Googlebot skips the HTTP request entirely, and Google Search will not render JavaScript from blocked files or on blocked pages (JavaScript SEO basics).
For classic or server-side rendered pages, the HTML in the HTTP response already contains the content. For JavaScript-heavy storefronts using the app shell model, the initial HTML holds the shell and the real product content appears only after scripts execute. That distinction is the whole reason a comparison matters: the first response and the rendered result are not the same document.
Googlebot queues pages with a 200 HTTP status code for rendering unless a robots meta tag or header says not to index them. During rendering, Google executes the JavaScript and produces a rendered HTML version of the page, so only content visible in the rendered HTML is available. Google's own recommendation is to check the rendered HTML in the Rich Results Test or the URL Inspection Tool.
How do I compare initial HTML and rendered HTML for a product URL?
Use a repeatable sequence rather than a one-off glance. The goal is to see exactly which product facts survive each stage.
- Capture the raw response. Request the product URL and save the HTML before any script runs. This is what Googlebot receives first.
- Capture the rendered DOM. Use the URL Inspection Tool or Rich Results Test to see the rendered HTML Google produces (Fix Search-related JavaScript problems).
- Diff the two. List what appears in each: title, price, availability, variant names, dimensions, materials, delivery information, canonical tag, structured data.
- Check link discovery. Googlebot parses the href attribute of HTML links in the response to find new URLs. JavaScript-injected links are acceptable if they follow crawlable link best practices, so confirm that navigation and variant links are real anchors, not click handlers on divs.
- Check what is blocked. Confirm robots.txt and any noindex directives are not preventing rendering of the scripts or the page itself.
A useful worksheet column set: element, present in initial HTML (yes/no), present in rendered HTML (yes/no), source (server or client), and action. That single table turns a vague "is our JavaScript SEO okay?" question into a list of specific gaps.
Example: a variant selector that hides the price
Suppose a hypothetical product page for a jacket loads a shell, then fetches price and stock per size from an API after the shopper picks a variant. In the initial HTML there is no price at all. In the rendered HTML, the default variant's price appears, but the other sizes' prices do not, because they only exist after a click.
That does not automatically mean the page fails. It means the comparison tells you which facts are reliably present and which depend on interaction. The practical fix is usually to render the default variant's essential facts in the initial response and expose variant URLs as crawlable links, so each variant has a stable address. These figures are illustrative only; the point is the method, not the numbers.
What content should a product page keep in the initial HTML?
The elements that determine whether a page can rank and convert are the ones worth protecting. A product page should match a specific search and answer buyer questions before the cart, as covered in product page SEO: the details buyers actually need. If those details arrive only after rendering, you are relying on a second processing stage to do work the first response could have done.
Prioritise:
- The product name and a clear descriptive heading.
- Price and currency, or a server-rendered placeholder that is replaced with the same value.
- Availability and shipping basics.
- Core specifications: dimensions, materials, compatibility, model identifiers.
- Canonical URL and any structured data you rely on.
- Crawlable links to variants, related products and category pages.
Secondary content — reviews widgets, recommendation carousels, recently viewed modules — can reasonably load later. The test is whether the page still answers the primary query without them.
Which testing tools actually show rendered output?
Google names two: the Rich Results Test and the URL Inspection Tool in Search Console. Both let you see the rendered DOM. The URL Inspection Tool is the closer match to production because it reflects how Google crawls and renders a live URL.
Google also notes that Googlebot and its Web Rendering Service continuously analyse resources and may not fetch those that do not contribute to essential page content. Client-side analytics may not provide a full or accurate representation of Googlebot and WRS activity on your site. The Crawl Stats report in Search Console is the intended place to monitor Googlebot and WRS behaviour.
A browser's view-source and a browser's Elements panel are useful for development, but neither is Google's rendered output. Treat them as diagnostics, not proof.
What are the limits and uncertainties?
Rendering is not instantaneous, and Google does not publish a fixed schedule for when a queued URL is rendered. A page can be crawled before it is rendered, so a change may appear in one report and not another. This is why comparing initial and rendered HTML is a snapshot method, not a guarantee.
There is also a scope limit: the official guidance describes how Google Search processes JavaScript. It does not promise that every scripted element will be fetched, and it explicitly warns that some resources may be skipped. Other search engines and AI crawlers may handle JavaScript differently, and their behaviour is outside this comparison.
Finally, the method tells you what is present, not why a ranking changed. Use it to remove rendering as a suspect, then investigate content, links and competition separately. For a broader approach to evidence-led content decisions, see SEO content writing tips: start with a question and evidence.
Frequently asked questions
Does Google index content that only appears after JavaScript runs?
It can, because Google renders pages with an evergreen Chromium version. But rendering happens after crawling, and Google only sees content visible in the rendered HTML. If a script fails, is blocked, or depends on a resource Googlebot skips, that content may never reach indexing. Comparing both versions is how you find out which case applies to a specific URL.
Should I switch my storefront to server-side rendering?
Not automatically. Server-side rendering puts content in the initial response, which can simplify the comparison and reduce dependence on a second stage. But the decision depends on your platform, team and how much content genuinely needs to be interactive. A safer first step is to render the essential product facts in the initial HTML and keep interactive extras client-side, then verify with the tools above.
What to do next
Pick one high-value product URL. Capture the initial HTML, capture the rendered HTML, and fill in the worksheet. Any row where an essential fact is missing from the initial response but present after rendering is a candidate for server-side output or a crawlable variant URL. Any row missing from both is a content problem, not a rendering problem. Recheck after changes using the same two captures so the comparison stays honest.