Small Ecommerce Catalogue Optimisation: A Before-and-After SEO Workflow

Start with the outcome: one catalogue that stays accurate

For a small ecommerce site, catalogue optimisation is the work of making product and category pages easy for people to browse, easy for search engines to discover, and consistent wherever product information is reused. That includes the visible product page, structured data, Google Merchant Center if you use it, internal navigation, variant URLs, filters, stock states and the way you verify changes.

There is no special Google definition of a “small catalogue”, and there is no separate technical recipe just because AI features are now part of Search. The practical advantage of a smaller catalogue is that you can usually keep the architecture simpler, inspect more of the catalogue manually, and fix inconsistencies at their source instead of building layers of exceptions.

What catalogue optimisation actually covers

A useful catalogue audit should separate problems that affect discovery from problems that affect product-data quality. Schema alone cannot rescue a product page that is unreachable through the site, and a perfect category structure cannot compensate for stale prices or availability in a feed.

• Discovery and hierarchy: important category and product pages should be reachable through ordinary links. Google specifically recommends linking through the ecommerce hierarchy and using crawlable <a href> links. For the broader architecture, see ScanMySEO’s guide to site structure.
• Product-page accuracy: the page should clearly show what the product is, whether it can be bought, its current price and availability, and the information a shopper needs to make a decision.
• Product structured data: appropriate Product and Offer markup can improve Google’s understanding of product details and make pages eligible for merchant-listing or product-snippet experiences. Eligibility does not guarantee that a rich result will be shown.
• Merchant Center data: if you use Merchant Center, the feed and landing page should agree. Google recommends using both product structured data and Merchant Center data where feasible because they serve complementary purposes. See Google’s guidance on sharing product data with Google.
• Variants and filters: colour, size, material and other variants need a deliberate URL and data model. Filters should not accidentally create a near-infinite crawl space.
• Inventory lifecycle: an individual product that is temporarily out of stock, an empty category and an impossible filter combination are different cases and should not all be handled with the same status code.

Diagnose the catalogue before changing templates

Start with a baseline rather than assuming that every visible imperfection needs a rebuild. For a small catalogue, export or list your important category and product URLs, note which templates they use, record current Search Console page/query performance, review Merchant Center “needs attention” issues if applicable, and identify the product pages that matter most commercially. That gives you something to compare after the change.

Then inspect representative products across different states: in stock, out of stock, discounted, variant-heavy, low-stock, and any product that is difficult to reach from a category page. If the catalogue is genuinely small, checking every product URL may be more efficient than designing a sampling methodology.

1. Check that the page, structured data and feed agree

Pick a product and compare the visible page with its structured data and Merchant Center data, if present. Price, currency, availability, product identity and the selected variant should describe the same offer. Google’s merchant-listing documentation explains the supported Product and Offer properties and the Search Console reports used to monitor them: Merchant listing structured data.

Do not treat Merchant Center automatic updates as a substitute for accurate source data. Google describes its automations as a way to reconcile attributes such as price, availability and condition with the landing page; your normal product-data updates still need to be reliable.

2. Check variants, shipping and returns only where they apply

If products vary by size, colour, material or another meaningful option, make sure the implementation reflects the actual shopping experience. Google supports ProductGroup and related variant properties, with different guidance for single-page and multi-page variant setups. Review the current product variant structured-data documentation rather than forcing every platform into one URL pattern.

Business-wide return and shipping policies can also be represented in structured data when the information is accurate and applicable. Treat these as enhancements after the underlying product and offer data is trustworthy. Do not add policy markup merely to fill schema fields.

3. Decide which filter URLs deserve crawling

Faceted navigation lets shoppers filter a category by attributes such as colour, size or price. The SEO problem is not the filter itself; it is the number of URLs a filter system can generate. For a small catalogue, most filter combinations are often navigation tools rather than useful standalone search landing pages.

If filtered URLs do not need to appear in Search, Google documents options such as preventing their crawl in robots.txt or using URL fragments where the site design permits it. If filtered URLs do need to be crawled, keep parameter handling consistent, avoid duplicate filter combinations, and return a real 404 for filter combinations that produce no results. Google’s faceted-navigation crawling guidance is the primary reference.

Do not turn this into a theoretical crawl-budget project if the catalogue has no evidence of crawl waste. The goal is to stop useless URL multiplication and preserve clear discovery paths. For a fuller decision framework, see ScanMySEO’s crawl-budget decision matrix for ecommerce sites.

4. Check discovery paths and lifecycle states

Google recommends linking from menus to categories, categories to subcategories where needed, and onward to product pages. Products that exist only behind an internal search box can be harder for crawlers to discover because Googlebot generally does not submit searches into site search. A sitemap or Merchant Center feed can supplement discovery, but they should not be used as an excuse for broken browsing paths. See Google’s ecommerce site-structure guidance.

Also separate temporary stock changes from genuinely missing pages. An out-of-stock product can remain a valid product page. Google Merchant Center explicitly supports an out_of_stock availability state and expects the landing page, structured data, checkout and product data to agree. A temporary stock outage is therefore not, by itself, a reason to return a 404.

Before-and-after example: a small apparel catalogue

Consider a hypothetical independent clothing shop with a manageable catalogue of product styles, each offered in several sizes and colours. The example below is not a traffic case study; it shows how to turn a muddled implementation into a clearer system without pretending that the fixes guarantee rankings or rich results.

Before: several small inconsistencies create one unreliable catalogue

After: fix the catalogue in dependency order

1. Restore clear discovery paths. Make sure important products are linked from relevant category or subcategory pages with normal crawlable links. Confirm the intended canonical and indexing state before polishing schema.
2. Make the product page the reliable source. Correct the visible price, availability, selected variant and purchase state. Then make structured data and Merchant Center data match that reality.
3. Model variants deliberately. If the platform uses one product URL with selectable variants, keep that single-page pattern internally consistent. If variants have separate URLs, follow Google’s multi-page variant guidance instead of canonicalising or linking them by habit.
4. Reduce filter noise. Decide which filtered pages, if any, deserve to be search landing pages. Prevent unnecessary combinations from consuming crawl resources; return 404 for impossible or empty faceted combinations that are exposed as URLs.
5. Handle stock states accurately. Keep temporarily unavailable product pages available where they still help shoppers, mark the product as out of stock in the visible page and relevant product data, and remove permanently discontinued products from Merchant Center data when they are no longer sold.
6. Add policy data after core product data is sound. If your return or shipping policy is stable and applies to the business, add the appropriate structured data accurately. Product-specific exceptions should not be hidden by an inaccurate business-wide default.

Out-of-stock products, empty filters and empty categories are not the same problem

• Temporarily out-of-stock product: the product page can remain live. Keep the visible availability and any structured/merchant data consistent. Google Merchant Center supports out_of_stock, backorder and preorder states where their requirements are met. See Google’s availability documentation.
• Empty faceted combination: if a filter URL has no matching products, Google’s faceted-navigation guidance recommends a proper 404 response at that URL rather than redirecting it to a generic error page.
• Empty category: Google’s ecommerce URL guidance says an empty category can use noindex; if the category is removed from browse/search and is effectively gone, returning 404 can be appropriate. That decision is different from a temporary stock change on one product.

Verify the implementation, not just the search-result appearance

A rich result appearing in one search is not a dependable pass/fail test, and the absence of a rich result does not prove your markup is broken. Google explicitly does not guarantee that eligible structured-data features will be shown. Verification should therefore test the implementation first and performance second.

1. Validate before release. Test representative product templates with Google’s Rich Results Test and fix invalid merchant-listing markup before deploying widely.
2. Check Search Console after indexing. Use the Merchant listings report for pages where shoppers can buy products. Watch valid and invalid items after template changes rather than relying on a manual SERP check.
3. Re-crawl the catalogue. Confirm that intended category and product URLs are reachable, canonical targets are sensible, status codes match the page state, and filters have not created new duplicate paths.
4. Review Merchant Center diagnostics. Check for price, availability, landing-page and product-data mismatches. Automatic updates can help reconcile some fields, but recurring mismatches usually mean the underlying publishing process needs repair.
5. Compare page and query performance. Use Search Console and analytics to compare the affected product/category pages with the baseline. Look for changes at the page and query level rather than assuming any traffic movement was caused by the catalogue work.
6. If generative Search visibility matters, measure it separately. Google’s current 2026 guidance points site owners to the Generative AI performance report in Search Console. Use that alongside normal Search performance instead of treating individual AI Overview sightings as a stable KPI.

Small ecommerce catalogue optimisation checklist

• Important product pages can be reached from browseable category paths, not only internal search.
• Visible price, currency and availability match structured data and Merchant Center data where used.
• Product/Offer markup represents the product actually shown on the page.
• Variant handling matches the site’s real single-page or multi-page setup.
• Only useful filter URLs are allowed to become crawlable landing pages.
• Impossible or no-result faceted URLs return an appropriate 404 response.
• Temporary out-of-stock products are not automatically treated as missing pages.
• Shipping and return policy markup reflects real policies rather than filling optional schema fields.
• Search Console and Merchant Center are checked after template or feed changes.
• Performance is judged against a recorded baseline, not against whether one rich result appears.

For a small store, the strongest catalogue is usually the simplest one that keeps these relationships consistent. Fix discovery and product-data integrity before adding more markup, more indexable filters or an “AI optimisation” layer. That reduces the number of places where the catalogue can disagree with itself and makes future changes easier to verify.