Category and Product Page Optimisation: A Before-and-After Workflow for Small Businesses
A practical way to decide which ecommerce pages should be crawlable and indexable, fix category-to-product discovery, control filter URL growth, validate product data and measure the result—without inventing special “AI SEO” rules.
The short answer: optimise the path from category to product
Category and product page optimisation is not mainly about forcing keywords into URLs or adding schema everywhere. For a small ecommerce site, the biggest gains usually come from making important products easy to reach through normal links, deciding which category and filter URLs are actually useful search landing pages, keeping duplicate or variant URLs under control, and making the visible product information match the structured data you publish.
This also applies to Google’s generative AI features. Google’s current guidance says the same SEO fundamentals continue to apply to AI Overviews and AI Mode; there is no separate technical requirement or special schema that makes a page “AI optimised”. Product feeds, product structured data, crawlability and useful content still matter because they support Google Search and shopping experiences generally, not because they are a secret AI-only layer. See Google’s guidance for generative AI features in Search.
If you only do five things, do these:
- Make sure every important category and product is reachable through crawlable
<a href>links. - Separate intentional search landing pages from filter and sort combinations that exist only for browsing.
- Do not migrate URLs just because a path looks more “SEO friendly”; fix discovery, duplication and consistency first.
- Put Product structured data on product pages where it accurately matches visible price, availability and variant information.
- Verify crawling, indexing and structured data first; measure impressions, clicks and conversions separately as outcomes.
What category and product page optimisation actually means
Category pages and product pages have different jobs. Treating every URL as if it should rank independently is what often creates the mess.
| Page type | Primary job | Typical SEO decision |
|---|---|---|
| Main category or subcategory | Help shoppers browse a meaningful group of products and reach individual items. | Usually indexable if it is useful, stable and has real inventory. |
| Product page | Explain and sell one product or product family, including variants, price and availability. | Usually indexable while the product remains a useful destination. |
| Filter or sort URL | Change the current product list for the shopper. | Often does not need to be indexed unless it is an intentionally useful landing page. |
| Product variant URL | Preselect a colour, size, material or other variant. | Can be valid; canonical and structured-data handling depends on whether variants share one page or have separate pages. |
| Empty category or impossible filter | Provides no useful product set. | Usually should not remain an indexable search landing page. |
The relationship between these pages is communicated primarily through links, not through how many folders appear in the URL. Google explicitly says it generally does not use URL structure to work out ecommerce site structure; it analyses the links between pages. A sensible path can still be useful for humans and crawl efficiency, but changing /product/123 to /shoes/trainers/product-name is not a substitute for good navigation. Google’s ecommerce site-structure guidance recommends linking from menus to categories, categories to subcategories, and onward to products.
Diagnose the failure before changing templates or URLs
Start with evidence. A small retailer does not need to rebuild its information architecture because an audit found query parameters. First establish whether important products are discoverable, whether unwanted URL combinations are expanding crawl space, whether Google is selecting the intended canonical URLs, and whether product information is internally consistent.
1. Can Google reach every important product through normal links?
Click through the site as a user would: home page → category → subcategory → product. Then check the underlying HTML. Important navigation should use crawlable links with an href. If the only way to reveal more products is a “Load more” button or infinite scroll that has no crawlable paginated URLs, a crawler may not discover the later items through that interface. Google’s pagination and incremental-loading guidance explains why paginated URLs and crawlable links matter.
Also check whether the same product is linked through several inconsistent URL forms—for example with and without tracking parameters, mixed case, or different category paths. Consistency between internal links, canonical tags and XML sitemaps reduces ambiguity. If canonical selection is already a problem, the ScanMySEO guide to canonical issues covers the decision in more depth.
2. Does the product page say the same thing everywhere?
Compare the visible product page, Product structured data and any Merchant Center feed. Price, currency, availability and variant identity should agree. Structured data is not a ranking guarantee and it does not force a rich result to appear. It makes a page eligible for supported search features when Google’s requirements are met.
For products that can be purchased, Google distinguishes merchant-listing markup from product-snippet use cases. It also supports product-variant markup using ProductGroup and Product. The important point for a small business is accuracy: do not add properties merely because a plugin can generate them. Mark up the product information that is genuinely present and current. Google’s Product structured data documentation explains the supported approaches.
Category pages are different. Google’s product rich-result guidance is focused on pages for a single product or variants of that product, not generic “all shoes in our shop” category listings. Do not assume that copying Product markup onto a category grid is a substitute for optimising the actual product pages.
3. Is “out of stock” being confused with “page not found”?
A temporarily unavailable product is not automatically a 404. If the product page is still useful and the item may return, keep the landing page available, show the stock state clearly and make the availability in structured data or Merchant Center match what the shopper sees. Google Merchant Center explicitly supports out_of_stock, backorder and preorder states; its availability guidance requires the feed to match the landing page.
A genuinely empty category is a different case. Google’s ecommerce URL guidance says an empty category can use noindex, and if the category is removed from the site’s browse experience it may be appropriate to return a 404. An impossible filter combination with no results should also return an appropriate 404 rather than a soft error page.
A before-and-after workflow for a small retailer
Consider a hypothetical small shop selling trail-running shoes. The site has 600 products, colour and size filters, and a “Load more” category design. The problem is not that the URLs look untidy; the problem is that important product pages are hard to discover while thousands of low-value filter combinations are easy to crawl.
Fix example 1: repair discovery before rewriting URLs
Before: /trail-shoes displays the first 24 products. More products appear only after a JavaScript button is pressed. Product links after the first 24 are not present in crawlable paginated URLs. The owner proposes moving every product into a longer folder path because it “looks more SEO friendly”.
After: Keep stable product URLs unless there is a separate business reason to migrate them. Add a crawlable path from category to subcategory to every product, and make additional result sets available through real paginated URLs with crawlable links. Use the same preferred product URL in internal links, canonical tags and the sitemap.
This change improves discovery without creating a site-wide redirect project. Google does recommend descriptive words in ecommerce URLs where you control the design, but it also accepts query parameters for product variants. Its ecommerce URL guidance is about consistency and crawlability as much as appearance.
Fix example 2: decide which facets deserve crawl access
Before: Every combination of size, colour, brand, price order and stock filter creates a unique crawlable URL. Most combinations duplicate the same products in a different order or produce no results.
After: Split facets into two groups. Keep a small number of genuinely useful, stable search landing pages crawlable and indexable. Prevent crawling of filter patterns that exist only for interactive browsing and would otherwise create near-infinite URL combinations. Return a real 404 for impossible or empty filter combinations rather than redirecting them all to one generic category page.
Google’s faceted navigation guidance specifically warns about overcrawling and slower discovery when parameter combinations generate very large URL spaces. On larger ecommerce sites, this is where crawl management becomes more important; the ScanMySEO crawl-budget decision matrix for ecommerce sites can help distinguish a real crawl-capacity problem from a smaller indexing or internal-linking issue.
Do not stack crawl and indexing controls blindly. If you use noindex, Google must be allowed to crawl the page to see that rule. A URL blocked in robots.txt may still be known to Google even though its content is not crawled. Choose the control according to the goal: reducing crawler traffic and removing a URL from the index are related but different tasks.
Fix example 3: make product data accurate and testable
Before: A shoe page says “Sold out”, the embedded Product markup says InStock, the Merchant Center feed still submits the previous price, and colour variants can only be selected after JavaScript runs.
After: Make the visible page the source of truth, then align structured data and the merchant feed with it. Give variants stable, directly addressable states where appropriate. If variants share one canonical product page, follow the single-page variant guidance; if each variant has its own page, use self-contained markup for those pages. Test the deployed page rather than validating only a code snippet.
Google supports both single-page and multi-page variant architectures, including variants selected with query parameters. The product variant documentation explains the different canonical and markup requirements. That is why a blanket rule such as “remove query parameters from product URLs” is too simplistic.
What to fix first
Small teams rarely have time to tackle every audit finding at once. Prioritise by whether the issue prevents discovery or indexing, multiplies low-value URLs, misstates product information, or merely makes a URL less tidy.
| Finding | Why it matters | Typical priority | How to verify |
|---|---|---|---|
| Products only reachable after a button click, with no crawlable pagination | Important products may be difficult for crawlers to discover through the category path. | High | Crawl the category and inspect rendered HTML and linked URLs. |
Important category or product accidentally noindex or canonicalised elsewhere | The preferred page may not be eligible to appear as intended. | High | Use URL Inspection and inspect the canonical signals. |
| Unbounded filter combinations | Can consume crawl resources and create duplicate or low-value URL spaces. | High on larger or rapidly changing sites; otherwise evidence-led | Review crawl logs or crawl samples, URL counts and Search Console indexing patterns. |
| Visible availability disagrees with structured data or merchant feed | Creates unreliable product information and can affect shopping eligibility. | High | Compare page, structured data and Merchant Center diagnostics. |
| Product URL is numeric but stable and well linked | Less descriptive for humans, but not proof of a structural SEO problem. | Low unless there is another reason to migrate | Check discovery, indexing and performance before changing it. |
| Category copy is generic filler | Adds little value and can distract from product discovery. | Medium | Replace only if you can add useful buying context, comparison help or scope information. |
Verify technical success separately from search performance
A fix can be technically correct without producing an immediate traffic increase, and a traffic increase does not prove that the technical fix caused it. Close the loop in stages.
- Discovery: Crawl the updated category path and confirm that important products are reachable through ordinary links. For pagination or infinite scroll, confirm that later result sets have unique, crawlable URLs.
- Indexing: Use Google Search Console’s URL Inspection and Page Indexing reports to check whether representative category and product pages are crawlable, indexable and using the intended canonical URL.
- Structured data: Use Google’s Rich Results Test on representative product pages, then inspect live URLs in Search Console. Passing a test means the markup is technically eligible; it does not guarantee that a rich result will be shown.
- Product-data consistency: Check Merchant Center diagnostics where you use a feed. Price and availability should match the landing page.
- Performance: Compare impressions, clicks, query mix and conversions before and after the change. Segment by page type so a strong product launch does not hide a category-page decline.
- Generative AI visibility: If this matters to your business, use Search Console’s Generative AI performance report. As of 31 August 2026 Google says these insights have rolled out worldwide, although a property may still show no report if it lacks sufficient impressions.
Do not use “a rich result appeared” as the only success criterion. Google states that correct structured data creates eligibility, not a guaranteed search appearance. Likewise, more impressions can be an encouraging outcome, but they are not proof that Google suddenly “understands your hierarchy”.
What not to change just for AI search
Google’s 2026 guidance is unusually clear here. You do not need special AI-only schema, tiny content chunks, an llms.txt file for Google Search, or a separate page for every conceivable query variation. For category and product pages, the practical work remains familiar: useful content, crawlable architecture, consistent product information, sensible controls for duplicate URLs, and a good experience for shoppers.
That means a category refresh should not become a hunt for cosmetic “GEO” changes. If the category already helps users find products, important items are crawlable, the indexing signals are coherent and the page answers the shopping task well, leave the sound parts alone.
A final checklist before you publish changes
- Important categories and products are linked with crawlable
<a href>links. - Load-more or infinite-scroll interfaces have crawlable paginated URLs where needed.
- Internal links, canonical tags and sitemap URLs consistently use the preferred version.
- Facet URLs are intentionally classified: useful search landing page, browsing-only filter, or invalid/empty state.
- You are not relying on a prettier URL path to communicate site hierarchy.
- Product structured data is on appropriate product pages and matches the visible page.
- Variant URLs and canonicals match the actual single-page or multi-page variant architecture.
- Temporary out-of-stock products are not automatically treated as missing pages.
- Empty categories and impossible filter combinations return an intentional indexing/status response.
- You have tested representative URLs, not just one perfect example.
- You are measuring technical validation separately from traffic and conversion outcomes.
The strongest optimisation is usually the one that removes uncertainty: shoppers can move from category to product without friction, crawlers can discover the same important pages, duplicate URL patterns are controlled deliberately, and product information is consistent wherever Google reads it.