Small ecommerce catalogue optimisation: a practical before-and-after example

What small ecommerce catalogue optimisation actually means

Catalogue optimisation is the work of making the products you genuinely want people to find easy for shoppers and search engines to discover, understand and keep up to date. For a small ecommerce site, that usually comes down to three connected jobs: making important product pages reachable through normal links, keeping each product page and its machine-readable product data consistent, and preventing filters or variants from creating a confusing inventory of low-value URLs.

Structured data—the machine-readable information added to a page—can make a purchasable product page eligible for richer merchant-listing experiences in Google Search. It does not guarantee that a rich result will appear, and it is not a substitute for a useful, crawlable product page. Google recommends using product structured data and, where appropriate, a Merchant Center product data source together because the two can help Google understand and verify product information. See Google’s guidance on Product structured data and sharing product data with Google.

A useful first decision: do not begin by “optimising every URL”. First find out whether your problem is discovery, duplicate/filter URLs, incorrect product data, feed mismatches, or weak product pages. The fix is different in each case.

Why catalogue optimisation matters for users and search engines

A small shop does not need a complicated technical architecture to be understandable. It needs a catalogue that behaves consistently. A shopper should be able to move from a category to the products in it, and Google should be able to follow the same crawlable links. Google’s ecommerce documentation specifically recommends linking from menus to categories, from categories to subcategories where needed, and from those pages to the product pages you want found. Products that can only be reached by submitting an internal search form may be missed by ordinary crawling. For a broader explanation of this relationship, see ScanMySEO’s guide to site structure and internal linking.

Product data consistency matters for a separate reason. Price, currency, availability, condition and other attributes can appear in structured data on the product page and in Merchant Center. If those sources disagree with what a shopper sees, Google may be unable to use the data as intended and Merchant Center can report product-level issues or disapprovals. Accurate data improves eligibility and reduces avoidable mismatch problems; it does not, by itself, guarantee higher rankings or a higher click-through rate.

How to diagnose catalogue SEO issues

Use a sample that represents the catalogue rather than checking only the homepage. Pick at least one product from each important category, one in-stock and one out-of-stock item if both exist, a product with variants if you sell them, and a few filtered category URLs. Then work through the following checks.

Start with this priority check

Diagnostic check 1: can Google reach the product pages you care about?

Start with navigation, not structured data. Google explains that its crawlers generally discover pages by following links, and that ecommerce products should be reachable through the site’s navigation or supplemented by a sitemap or Merchant Center data source when normal crawling cannot expose everything. Its guidance also notes that crawlers generally do not click “load more” buttons or trigger user actions simply to reveal more products.

• Open an important category and follow the same links a visitor would use. Can you reach every product that should be indexable?
• Check that product links are real <a href="..."> links rather than JavaScript-only controls.
• If the category uses pagination, make sure later result pages have crawlable URLs and links.
• If the store uses infinite scroll or “load more”, make sure there is still a crawlable path to products that are not in the initial HTML.
• Check your XML sitemap as a discovery aid, but do not treat sitemap inclusion as a replacement for sensible internal linking.

Google’s ecommerce site-structure guidance and pagination guidance are the primary references for these checks.

Diagnostic check 2: decide what your filters are for before controlling their URLs

Faceted navigation means filters such as colour, size, brand or price that change the products shown on a category page. The mistake is not “having parameters”; the mistake is allowing an uncontrolled number of filter combinations to become crawlable when those URLs do not provide useful, distinct landing pages.

For each filter, make a deliberate choice:

• If the filtered page has no search value: it may be better to keep the filtering experience for users while preventing those URLs from consuming unnecessary crawling. Google’s current faceted-navigation guidance says robots.txt can be used to disallow crawling of unwanted filter URLs, and URL fragments can be used for filters that do not need to be crawled or indexed.
• If the filtered page should be discoverable: give it a stable URL, useful content and sensible internal links. Use standard parameter formatting where parameters are needed, keep filter ordering consistent, and return a real 404 response for nonsensical or empty combinations where your platform allows it.
• Do not rely on canonical tags as the main crawl-control mechanism: Google describes canonicals and nofollow as generally less effective over time than preventing unwanted faceted crawling directly.

This is where the original “just refactor the URL structure” advice is too broad. A stable product or category URL should not be changed merely to look cleaner. URL migrations introduce their own work and risk. Change URLs when there is a genuine structural reason, not as a default catalogue-optimisation step. Google’s faceted-navigation documentation explains the trade-offs in more detail.

For most genuinely small catalogues, “crawl budget” should not be the starting concern. Google’s crawl-budget guide is aimed mainly at very large or rapidly changing sites. Even so, filter combinations can create a surprisingly large URL inventory, so it is still worth controlling them when you can see unnecessary crawling or indexation.

Diagnostic check 3: compare the visible page, structured data and Merchant Center

Pick several products and compare the same fields in three places: what a shopper sees on the product page, the page’s Product/Offer structured data, and the corresponding Merchant Center item if you use Merchant Center. The important point is agreement.

• Price and currency should match the purchasable offer shown on the page.
• Availability should match the real stock state shown to the shopper.
• Condition should be consistent where it applies.
• Product identifiers such as GTIN, MPN, brand and SKU should be accurate where they exist; do not invent identifiers.
• If a product has variants, check that the relationship between the parent product and variants is represented consistently on the page and in your product data.

For purchasable products, Google’s merchant-listing documentation recommends Product structured data that reflects the product actually being sold. Google also supports ProductGroup markup to describe variants such as colour or size. See the official guidance on merchant listing structured data and product variants.

If you use Merchant Center, automatic updates can use landing-page information to correct some price, sale-price, availability and condition mismatches. Treat that as a safety net, not a replacement for keeping your product data current. Google’s Merchant Center documentation explicitly says automations do not replace regular product-data updates. For frequently changing stock or prices, use an update method that matches how quickly your catalogue changes. See Google’s guidance on Merchant Center automatic product updates.

Diagnostic check 4: make sure the product page earns its place

Technical correctness cannot compensate for a product page that leaves the buyer guessing. A small retailer often gets more value from making a product page clearer than from adding another layer of markup.

Check whether the page answers the questions a real buyer needs answered: what the product is, who it is for, what makes this option different, the current price, stock state, key specifications, variant choices, delivery and returns information where relevant, and useful images. If several products reuse identical manufacturer copy, improve the information where you can genuinely add value rather than creating near-duplicate pages with different SKUs.

A practical fix order for a small ecommerce catalogue

Do not attempt every possible ecommerce SEO improvement at once. The following order reduces wasted work because each step establishes the foundation for the next.

Step 1: make the indexable product inventory explicit

List the category and product URLs you actually want people to find from search. Check that each important product is reachable through crawlable links and, where appropriate, present in your XML sitemap and Merchant Center product data. Remove obsolete products from your active navigation rather than leaving accidental dead ends, and handle discontinued items according to whether a useful replacement or successor exists.

If you discover that the only route to products is an internal search form, JavaScript interaction or an unlinked filter, fix discovery before spending time expanding structured data.

Step 2: control filters without rewriting stable URLs unnecessarily

Classify filter URLs into two groups: pages that deserve to exist as search landing pages, and filters that exist only to help shoppers narrow a list. Keep the first group stable, useful and internally linked. Control the second group so it does not create an uncontrolled crawl space. The right implementation depends on your platform, so avoid copying a blanket robots.txt or canonical rule without testing which URLs it would affect.

If your catalogue only has a few hundred products and Google already discovers them reliably, do not start a URL migration in the name of crawl-budget optimisation. Fix actual evidence of duplication, discovery problems or unnecessary filtered crawling.

Step 3: align visible product data, structured data and your feed

Update the page template so the structured data is generated from the same underlying product values shown to shoppers wherever possible. Then make sure your Merchant Center product data is refreshed frequently enough for your stock and pricing model. A store with prices that change several times a day needs a different update process from a small catalogue that changes once a week.

For a small site with relatively stable inventory, Google says a website-crawl data source can be a lower-effort way to get started in Merchant Center when suitable. For frequently changing catalogues, use a more direct and timely product-data process rather than relying on occasional crawling to catch up.

Step 4: verify before scaling the change across the catalogue

Test a small representative set first. That makes template mistakes easier to spot before they affect every product.

• Run Google’s Rich Results Test on representative product and variant pages.
• In Search Console, check the Merchant listings report for purchasable product pages and inspect live URLs when debugging.
• In Merchant Center, review products that “Need attention”, especially price and availability mismatches.
• Crawl the site and confirm that important products are reachable, filter URLs behave as intended, canonicals are consistent and no accidental duplicate URL patterns have appeared.
• After deployment, watch query/page performance rather than assuming that a technically valid change must increase traffic.

Google specifically recommends monitoring the Merchant listings report after deploying or changing Product structured data. Its documentation also makes clear that valid structured data makes a page eligible for supported search features; it does not guarantee that those features will be shown.

Before-and-after example: a 180-product shop

This is a hypothetical example. Imagine a small shop with 180 products across four categories. It sells some products in multiple colours and sizes.

Before

• The first category page links to only 24 products; the rest appear after a JavaScript “load more” action with no crawlable paginated URLs.
• Colour, size, brand, price and sort controls can be combined freely, creating thousands of parameter URLs.
• Every filtered URL points a canonical tag at the main category, but the filters remain widely linked and crawlable.
• Product structured data uses a generic template value for availability, so some sold-out products still say InStock in the markup.
• Merchant Center is updated once a day even though stock changes throughout the day.
• Variant relationships are unclear: the page exposes several sizes, but the product data does not consistently identify which offer or variant the URL represents.

After

• Every sellable product can be reached through ordinary category/pagination links, with an XML sitemap and Merchant Center data source as supporting discovery mechanisms.
• The business chooses a small number of genuinely useful filtered landing pages to keep crawlable and controls the rest rather than trying to index every combination.
• Existing stable category and product URLs are retained; there is no cosmetic migration.
• Price, currency and availability in structured data are generated from the same product values shown on the page.
• Merchant Center updates are scheduled to match how quickly stock changes, with automatic updates used as a fallback rather than the primary synchronisation method.
• Variant markup and URLs are reviewed together so colour/size choices do not create contradictory canonical or product-data signals.

The expected improvement is not a guaranteed ranking jump. The catalogue becomes easier to crawl, its product data is less contradictory, eligible product pages are better prepared for merchant-listing features, and the business has clearer diagnostics when something goes wrong.

What not to fix first

• Do not rebuild stable URLs just to make them shorter. A migration needs redirects, link updates, sitemap changes and verification. Only take that cost on when the URL design itself is creating a real problem.
• Do not index every useful-looking filter combination. A filter is not automatically a valuable landing page just because it has a URL.
• Do not treat a canonical tag as a universal faceted-navigation solution. Decide whether the URL should be crawled and whether it deserves to be indexed before choosing the control.
• Do not mark up information that is not visible or true. Structured data should describe the product page, not an idealised version of it.
• Do not chase crawl budget as a headline KPI for a small site. Use evidence from crawling, Search Console and server behaviour before treating crawl capacity as the bottleneck.

Catalogue optimisation verification checklist

• Important products are reachable through normal crawlable links.
• Pagination or incremental loading does not hide products from crawlers.
• Filter URLs have an intentional crawl/indexing strategy.
• Empty or nonsensical filter combinations do not create endless soft duplicates.
• Visible price, currency, availability and condition agree with structured data.
• Merchant Center product data agrees with the landing page and is updated at an appropriate frequency.
• Variant URLs, canonicals and Product/ProductGroup markup tell a consistent story.
• Representative product pages pass the relevant structured-data checks.
• Search Console Merchant listings issues are reviewed after template changes.
• Merchant Center “Needs attention” issues are checked after feed or page changes.

If those checks pass, move on to the next constraint: product-page usefulness, category demand, internal linking, merchandising, or broader content strategy. Catalogue optimisation works best when it removes a specific obstacle rather than becoming an endless exercise in changing technically valid pages.