Skip to content
metryn

JavaScript-rendered stores: what crawlers see

How Google processes JavaScript, why its documentation still recommends server-side rendering, and a five-minute test for any store or SaaS site.

By Metryn · Updated 16 October 2026 · 4 min read

Plenty of modern stores and apps are rendered in the browser. The page you see is built by JavaScript after a nearly empty HTML document loads. That works for people. For machines it's a gamble that depends on which machine.

What Google does

Google describes three phases: crawling, rendering and indexing. Pages that return a 200 status are queued for rendering, a headless Chromium runs the JavaScript, and the rendered HTML is what gets indexed. It also notes that it won't render JavaScript from blocked files or on blocked pages, and that pages with non-200 status may skip rendering entirely.

So Google can handle client-side rendering. Even so, its documentation still recommends server-side or pre-rendering, partly because it's faster for users and crawlers and, in its words, because not all bots can run JavaScript. Google isn't the only thing reading your site.

A five-minute test

  • Fetch your key page with curl or any plain HTTP client, not a browser.
  • Search the response for the product name, the price and the main heading.
  • Check the <title> and meta description are specific to that page.
  • Look for your JSON-LD in the raw HTML. Google's merchant listing documentation recommends it in the initial HTML and says JavaScript-generated markup can make shopping crawls less frequent and less reliable.

If the facts are all there in the raw response, you're fine regardless of how the page is enhanced afterwards. If they're missing, a crawler that doesn't run your bundle sees a blank shell.

Single-page-app traps Google names

  • Routing with URL fragments like #/product/12. Use the History API and real paths instead.
  • Links that aren't <a href> elements. Click handlers on a div aren't followed as links.
  • Soft 404s. If a missing product shows a friendly page with a 200 status, Google suggests redirecting to a URL that returns a real 404, or adding noindex to the error view.
  • A canonical tag set by JavaScript that differs from the one in the HTML. Keep one canonical, and the same value.

Don't assume every crawler does what Google does

Google documents how it renders pages. The OpenAI and Perplexity crawler pages describe what each bot is for and how to control it, and they don't describe JavaScript rendering. That's not proof they can't run it. It means nobody has promised you they will, and a page whose content is present in the HTML doesn't depend on the answer.

A couple of smaller notes from Google's documentation are worth knowing. If a page carries a noindex tag, Google may skip rendering it, so JavaScript that removes the tag later may never get a chance to. And content that isn't visible in the rendered HTML, such as content hidden away in a way the render doesn't flatten, won't be indexed.

Questions people ask

Does Google really render everything?

Google describes a rendering step that runs JavaScript in a headless Chromium for pages with a 200 status. It also says that blocked files or pages aren't rendered, and that a page with a noindex tag may be skipped before rendering.

Is dynamic rendering a good fix?

The JavaScript guidance I read recommends server-side rendering or pre-rendering, and doesn't present dynamic rendering as the way to go. If you're choosing today, building the important pages with real HTML in the first response is the more durable approach.

Can I keep my SPA?

Yes. Use real paths via the History API, return real status codes, give each route a unique title and keep links as <a href>. The marketing pages are what benefit most from server rendering.

What about product data loaded by an API?

If it's fetched after load, it isn't in the first response. Google's merchant listing documentation recommends Product markup in the initial HTML for that reason.

What to do this week

  • Run the curl test on your homepage, a product page and a category page.
  • Move the important content and JSON-LD into the server-rendered HTML.
  • Check your error view returns a real 404.
  • Check that internal links are real links.

Check your own site

Paste your address below. The free scan looks at robots.txt, your sitemap, access for the main AI crawlers and structured data, and shows what it found in seconds. It tells you what a machine can fetch and read. It doesn't predict rankings or citations.

Free scan · No account needed · Results in seconds

Sources

Keep reading

Want to check one file yourself? Try the free AI crawler robots.txt checker or the llms.txt validator, or read how the score is built.