JavaScript SEO for Headless and SPA Storefronts

Why headless and SPA storefronts lose rankings before they start

Most traditional ecommerce platforms send a complete HTML page in the first response. A headless build splits the shop front from the commerce engine, then assembles the visible page in the browser. A React storefront, a Vue progressive web app or any single page application typically ships a thin shell first, then fetches the catalogue and paints it with JavaScript. That is brilliant for interactivity. It is a problem for search.

Google processes JavaScript pages in three phases: crawling, rendering and indexing. The crawler fetches the HTML, queues the page for rendering, and only once rendering resources free up does a headless version of Chromium run the JavaScript and reveal the content (Google Search Central, "Understand the JavaScript SEO basics", updated 4 March 2026). On a 40,000 product catalogue, that render queue becomes a bottleneck. Pages wait. Some wait a long time.

We see the commercial impact constantly. A collection page that renders its products client-side can sit unindexed for weeks while a server-rendered competitor is already ranking. To set this against the wider picture, start with our technical SEO ecommerce checklist, then come back here for the rendering detail.

How Google actually renders a JavaScript page

1. Crawl. Googlebot pulls a URL from the crawl queue and makes an HTTP request. It checks robots.txt first. If the file or page is blocked, rendering never happens.
2. Process and queue. Google parses the response, extracts links from href attributes, and queues any page returning a 200 status for rendering.
3. Render. When resources allow, a headless evergreen Chromium renders the page and executes the JavaScript. The page can sit in this queue for seconds, or considerably longer.
4. Index. Google parses the rendered HTML again, pulls any newly revealed links back into the crawl queue, and indexes the rendered content.

The detail that catches ecommerce teams out: the index is built from the rendered HTML, not the raw response. If your product schema, canonical tags, internal links or even your prices only exist after JavaScript runs, they are at the mercy of the render queue. Google itself states that server-side or pre-rendering "is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript" (Google Search Central, "Understand the JavaScript SEO basics").

That last clause matters more than ever. Googlebot renders JavaScript. Many AI answer engines and several secondary search crawlers do not, or do so inconsistently. A storefront that only exists after client-side rendering is invisible to a growing slice of discovery surfaces.

SSR vs CSR vs prerendering: the decision that sets your ceiling

The pattern we recommend to most headless clients is hydration: render the meaningful HTML on the server, then let JavaScript take over for cart, filters and personalisation. Shoppers get a fast page. Crawlers get real content immediately. Nobody waits on the render queue.

Google has been blunt about prerendering's status. It now describes dynamic rendering as "a workaround and not a long-term solution", recommending server-side rendering, static rendering or hydration instead (Google Search Central, "Dynamic rendering as a workaround", updated 10 December 2025). Treat prerendering as a bridge, not a destination.

Prerendering and dynamic rendering, used properly

Dynamic rendering works by detecting the user agent. When your server spots a crawler that struggles with JavaScript, it routes that request to a rendering service that returns static HTML. Human visitors carry on with the client-side experience. Google is explicit that this is not cloaking, as long as the rendered content matches what users see (Google Search Central, "Dynamic rendering as a workaround"). Serve dogs to crawlers and cats to users and you are cloaking. Serve the same content in a crawler-friendly format and you are fine.

Where prerendering earns its keep in ecommerce:

• A large React or Vue storefront mid-migration, where rebuilding to full SSR will take months.
• Highly dynamic catalogues with tens of thousands of URLs that would otherwise drain crawl budget on the render queue.
• Reaching crawlers and answer engines that do not execute JavaScript reliably.

Where it bites back:

• It adds a second system to maintain, monitor and pay for.
• Stale snapshots can serve outdated prices or stock, which is a trust and conversion problem.
• It masks the underlying architecture issue rather than fixing it.

If your render budget is already under pressure across a big catalogue, prerendering will not save you on its own. Read how we approach crawl budget on large ecommerce sites alongside any rendering decision.

JavaScript rendering at a glance

The entity laid out as attributes, so there is no ambiguity about what we mean and what to do about it.

How to debug a JavaScript storefront for indexation

1. Compare raw and rendered HTML. View the page source, then inspect the rendered HTML in Google Search Console's URL Inspection tool. Any product content, price or link missing from the raw version is a client-side rendering dependency.
2. Check your links are crawlable. Google only follows links that are anchor elements with an href attribute. Buttons and onclick handlers do not count. Avoid hash-fragment routing; use the History API for SPA navigation.
3. Confirm metadata survives rendering. Make sure your title, meta description, canonical tag and robots directives exist in the rendered HTML and are not duplicated or overwritten by JavaScript.
4. Validate product structured data. If you inject JSON-LD with JavaScript, test it in the Rich Results Test using the rendered output, not the source.
5. Hunt for soft 404s. Client-side routing often returns a 200 status for pages that should be errors. Redirect to a real 404 URL or inject a noindex robots tag when a product no longer exists.
6. Watch the render queue in logs. Server log analysis shows how often Googlebot renders versus crawls. Long gaps between crawl and render point to a budget problem.
7. Lazy-load images search-safely. Make sure lazy-loaded product imagery loads in a way Google can detect, or those images will not be indexed.

Set this against your wider ecommerce site architecture. Rendering and architecture are two halves of the same indexation story.

React, Vue and headless platform notes

A note on headless commerce SEO specifically: decoupling the storefront from the commerce engine gives you speed and flexibility, but it also hands you full responsibility for how pages render. The platform will not rescue a client-side-only build. That responsibility is exactly where an agency partner earns its fee.

What our data shows about rendering and rankings

In our analysis, storefronts that serve product content in the first HTML response are indexed faster and more completely than equivalent client-side-rendered stores. Rendering strategy is a ranking factor in practice, not just in theory.

We tracked rendering approach against indexation and visibility across the stores in our 2026 ecommerce SEO ranking factor study. The pattern was consistent: server-rendered and hydrated storefronts reached full catalogue indexation noticeably sooner than client-side-rendered equivalents, and they held visibility more steadily through algorithm shifts. Client-side-only stores showed the familiar symptoms: collection pages dropping in and out of the index, product pages indexed with missing prices, and thin rendered HTML flagged in coverage reports.

The takeaway for any store owner: rendering is not a developer-only concern. It sits directly between your products and your revenue. If you want a partner who treats it that way, we build ecommerce organic growth on exactly these foundations.

Why this guide goes further

Frequently asked questions