Moving category listings into HTML lifted top-3 keywords 28%

A mid-market retailer, StreetStyle24, moved the product listings, pagination, descriptions and internal links on its category pages into base HTML in May 2025, and within three months had 28% more keywords ranking in positions one to three. The case appears in Sitebulb’s guide to rendering approaches for e-commerce sites, published September 29 by Patrick Crier, a technical SEO specialist at the agency ICS-digital. Before the change, only the first six products on a category page existed without JavaScript.

What that fix changed is how much of the site Googlebot can act on in its first pass. Google crawls a URL and pulls the links out of the initial response. The page then waits in a queue for its Web Rendering Service before any JavaScript-generated links become available. Crier’s own example is a category page with 100 products. If those products are standard links in the initial HTML, Google finds them on the first crawl. If the grid is populated entirely by JavaScript, none of them exist until the page has been rendered.

The framework a site runs on does not tell you which case you are in. Crier sets ASOS against Samsung. ASOS has its core content, internal links, H1 and canonical in place before scripts execute. Samsung’s smartphone category page renders its listings fine, but the individual product data, model names like the Galaxy A57, sits in page JSON rather than in HTML product listings.

Core Web Vitals do not separate the two either.

Site	LCP	INP	TTFB
ASOS	1.6s	218ms	0.7s
Samsung	1.4s	139ms	0.6s

Crier’s conclusion is that rendering architecture alone is not enough to predict how a website will perform. The stronger version is that these are two separate audits. Field metrics describe how quickly a browser assembles the page, and say nothing about how much of that page a crawler can read from the response.

That makes rendering a decision per template rather than per site. Account pages, baskets, wishlists and checkout are not there to win organic traffic, and Crier is explicit that client-side rendering suits them. Homepages, category pages, product pages, brand pages and editorial content are the ones that have to be discoverable from the server response. Most modern frameworks let you set this per route, a difference covered in this site’s comparison of Astro and Next.js for SEO.

One figure in the StreetStyle24 results is worth carrying into any business case. Top-10 rankings rose 22% while organic sessions rose more than 4% year on year. Sitebulb’s write-up does not account for the gap, but the likelier explanation is that the newly discoverable pages were long-tail category terms, which move ranking counts faster than they move traffic.

What to do

Run the check per template, on one representative URL each, before deciding anything about the stack.

• View source on a category page and a product page, then search the raw HTML for a product link, the H1, the canonical and the metadata. Presence is not enough. Count how many product links are there against how many the rendered page shows.
• Reload with JavaScript disabled. If the main content or the navigation goes, that template depends on client-side rendering.
• Crawl the site twice, rendered and non-rendered, and diff internal links, canonicals, metadata and structured data. Sitebulb supports this directly; the comparison is the point, not the crawler.
• Watch the network tab for product listings arriving by API call after the initial response. That is the signal the listing is JavaScript’s to deliver.
• Check a few URLs in Search Console’s URL Inspection to see what Googlebot retrieved and rendered.

Where the answer comes back bad, the fix is not a rewrite. StreetStyle24 moved its listings, pagination, descriptions and links into base HTML on one template. Start where the internal links are.