First decide which pages should exist
Commercial categories are chosen around the range and shoppers’ needs. Once the structure is approved, however, the developer needs a different document: a list of page types and rules for their behaviour. These include a category, a product page, a variant, the next catalogue page, internal search results, and a combination of filters.
For each type, define its URL, crawlability and the route from other sections. For example, an indexable product page needs a stable URL and must be reachable through catalogue links. Google’s guidance on store structure explains the importance of links between the homepage, categories and products. A search box does not replace this navigation.
Every interface change need not become a separate search page. Sorting by price helps visitors but usually displays the same range. The decision to create a distinct URL should follow from the page’s content and search task, rather than the number of possible buttons.
Filters need their own rules
Imagine a shoe catalogue with size, colour, material and price filters. Shoppers need combinations of these attributes. Allowing crawlers to access every combination generates many URLs, including duplicates and empty selections. Google’s faceted navigation documentation links such URL spaces to excessive crawling and slower discovery of useful pages.
The project must therefore distinguish useful standalone selections from technical filter states. The former need manageable pages, stable URLs and real products. The latter need an agreed crawling policy. A blanket instruction to “block all filters” can remove useful pages; “open everything” creates a different problem.
Canonical should not be treated as a crawl switch either. According to Google’s documentation, specifying a primary URL may reduce crawling of its non-primary variants over time, but does not prohibit it. The particular combination of canonical, robots.txt and other measures depends on whether URLs should be discovered, crawled and appear in search. These tasks cannot be collapsed into one setting.
What a crawler receives when opening a URL directly
An approved design does not yet show whether a product is accessible to a search engine. Before handover, check a product page by opening its URL directly: the heading, description, price, availability and links should belong to that particular product. For a JavaScript website, separately examine what the server returns and what appears after scripts execute.
Google publishes JavaScript SEO guidance. The practical question for the client is simpler: the developer should explain how the chosen technology makes the product accessible to search and demonstrate the result on the finished page. There is no need to prescribe one rendering method to the whole market; the particular website needs a verifiable answer.
The brief should also specify how links, pagination and unavailable products behave. If a button reveals the next catalogue segment, the implementation must still provide a route for crawlers to reach those products. Decide what happens to temporarily unavailable items in advance so that routine stock updates do not destroy catalogue URLs.
The catalogue must provide consistent data
The name, price and availability appear in several places: the product page, structured data, and a product feed if one is used. They need an agreed source. Manually fixing one copy does not resolve discrepancies in the others.
Structured data helps a search engine understand content. It does not guarantee a particular search result presentation. To choose the markup, developers should use Google’s ecommerce documentation, while clients should check that the values match the visible page. Invented reviews must not be marked up, nor a different price supplied in the markup.
In our public Art Kormushka case study, we describe the connection between the catalogue, search pages and confirmed purchases. This is an example of work delivered by the studio. It does not establish future traffic growth for another store: a different range, competitors and existing website require separate analysis.
How to include SEO readiness in acceptance
The recommended development deliverable is a list of checked URLs for each page type and a report on exceptions. It should show product page accessibility, headings and descriptions, primary URLs, links, filter rules, the sitemap, and consistency of product data. Test the finished version with the actual range: an empty demonstration catalogue conceals many errors.
If the store replaces an existing website, a mapping of old and new URLs is also required. This is a separate migration task that cannot be replaced by creating a fresh sitemap. We discuss this work in our guide to redesigning without losing SEO traffic.
To discuss online store development with pommeDeTerre, start with the catalogue, current website and intended sales channels. These help determine which requirements belong in the project immediately and which belong to subsequent promotion. Acceptance can then establish a concrete result: the store is prepared for crawling and measurement in the agreed scenarios, giving further work on search demand a clear technical foundation.