Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is how your storefront renders its pages, and it is made early. Category and product pages carry most of the organic traffic on a commerce site. If the architecture sends them to search engines half-built, the fix is a front-end rebuild. A few extra tags will not close that gap.
Why single page applications struggle with search by default
A single page application (SPA) loads one HTML document and builds every view in the browser with JavaScript. Shoppers get fast transitions between pages. A crawler that reads only the first response gets a near-empty page with a script tag.
Google does render JavaScript, but it does so in a second pass that runs on its own schedule, so new products and price changes can reach the index late. Other search engines tend to render less, and several of the crawlers that feed AI answer engines read the raw HTML and little else. The difference between an SPA and an installable web app is explained in what SPAs and PWAs are. For search, the question is narrower: how much of the page exists before the browser does any work.
Server-side rendering is the foundation to build on
Server-side rendering means the server builds the full HTML for the first page view and the browser takes over from there. The crawler and the shopper receive the same finished page. After that first load, the application behaves like an SPA again.
The Salesforce PWA Kit (Composable Storefront) works this way out of the box. It renders the first view on Managed Runtime, the Salesforce hosting layer for headless storefronts, and hydrates it in the browser. Salesforce also launched Storefront Next in the Summer '26 release, a newer storefront that is server-first as well. We built Fast FORWARD, our own headless storefront, on the Composable Storefront for exactly this reason: search visibility is settled in the architecture. The wider case for this stack is set out in headless commerce with the Composable Storefront.
Every product and category needs its own crawlable URL
A crawler can only index what it can reach, and it reaches pages through links with real addresses. Every product, category and content page needs a clean URL that returns that page when requested directly. Hash-based routes and navigation built on click handlers hide pages from search engines, even when shoppers can use them without trouble.
Status codes are the second trap. Many SPAs answer every request with a success code and then show a "not found" message in the browser. Search engines call that a soft 404 and waste crawl budget on it. A discontinued product should return a proper 404 or 410 from the server, and a moved product a permanent redirect.
Variants and filters need a decision too. Colour and size pages, sorted listings and filtered categories can multiply into thousands of near-identical URLs. Canonical tags and a clear rule on which filter combinations deserve their own indexable page keep that under control.
