E-commerce SEO guide: site structure, filters, product pages and product data

What makes SEO for an online store different

A store is a handful of templates (home, category, product, cart) that together produce thousands or millions of URLs. Every filter, sort order, variant and tracking parameter can add another address for content Google has already seen. Google defines a site's crawl budget as the set of URLs it can and wants to crawl, and its crawl budget guide is written for sites with over a million pages that change weekly, or over 10,000 pages that change daily. A catalogue of 10,000 products with daily price and stock changes already fits the second description.

So the first decision is which page types should be indexed, and which searches each one should answer:

Google's advice on ecommerce content matches this split: product descriptions that use the words shoppers search with, and category descriptions for less specific queries. Deciding which page answers which search is the same exercise as planning a topic cluster, which our semantic SEO guide walks through step by step.

Build a site structure that links to every product

Google works out what matters on a site from its links, not from its URL folders. According to its site structure guidance, it considers how many links it has to follow to reach a page and how many links point to it; the more internal links a page has, the more important it looks relative to the rest of the site. For a store, that means four things:

1. Link every product from browsable categories. Menus link to categories, categories to subcategories, and subcategories to every product. Googlebot generally does not type into search boxes, so a product reachable only through on-site search may not be found by crawling at all. Where linking every product is impossible, list them in an XML sitemap or a Merchant Center feed.
2. Use real links. Navigation should be <a href> elements with meaningful anchor text, such as the product name. Googlebot may not detect navigation done with JavaScript events on other elements, and it does not click buttons.
3. Promote what sells. Link best sellers and priority categories from the home page, buying guides and other prominent pages. The extra internal links tell Google those pages matter more than the rest of the catalogue.
4. Add breadcrumbs. A visible trail (Home > Shoes > Trail running) adds links up the hierarchy on every product page, and BreadcrumbList structured data describes that hierarchy to Google, which shows breadcrumb rich results on desktop.

Design URLs that crawl cleanly

Google's URL guidance for ecommerce sites prevents two failures: different pages that Google treats as one, and one page it crawls again and again under different URLs. Most platforms already follow it, but check your theme, apps and custom code:

• Put descriptive words in paths: /product/black-t-shirt-with-a-white-collar, not /product/3243.
• If the server treats upper and lower case the same, convert every URL to one case.
• Use ?key=value parameters (?color=green), not bare values (?green), and never repeat a parameter; combine the values instead (?type=candy,sweet).
• Keep session IDs, tracking codes and relative values such as location=nearby out of internal links.
• Never use fragments to show different content. Google ignores everything after #, so /product/t-shirt#black and /product/t-shirt#white are one page to it.
• Use exactly the same URL in internal links, sitemaps and rel="canonical" tags.

Make category pages worth ranking

Category pages carry the broad searches, and they are often the thinnest pages on a store: a heading and a grid of products. Give each one enough text to help someone choose: what separates the products in it, sizing or compatibility notes, and links to subcategories and buying guides. A short introduction above the grid and more detail below it both work. A block of repeated keywords helps nobody.

Keep empty categories out of the index. Google recommends a noindex robots meta tag on a category that has no items, and a 404 status code if your site automatically removes empty categories from browsing and search.

Paginate long categories

When a category holds more products than fit on one page, shoppers get numbered pages, a "load more" button or infinite scroll. Google's pagination guidance explains that its crawlers follow the URLs in the href of <a> elements and do not click buttons or trigger scripts that need a user action. Whichever pattern shoppers see, crawlers need paginated links behind it:

1. Link each page to the next one with an <a href>, and consider linking every page back to page one, which hints that page one is the best landing page.
2. Give each page its own URL, such as ?page=2, and its own canonical URL. Do not point the canonical of pages 2 and onward at page one: they list different products.
3. Do not use fragments (#page=2) for page numbers. Google may skip the link, thinking it has already fetched that page.
4. Reuse the same title and description across the sequence if you like; Google says paginated pages do not need distinct titles.

Google no longer uses rel="next" and rel="prev" link elements, although other search engines may. Sorted versions of the same list (?order=price) should stay out of the index, with a noindex tag or a robots.txt rule.

Keep faceted navigation from flooding the crawl

Faceted navigation, the filters for brand, colour, size, price and so on, is where a store's URL count usually gets out of hand. Google's faceted navigation guide notes that its most common implementation, URL parameters, can generate infinite URL spaces: a few filters with a handful of values each can produce more URLs than the store has products. The guide names two costs. Crawlers overcrawl, because they cannot tell a useless filter URL from a useful one without fetching it, and discovery slows down, because the time spent on filter URLs is not spent on new products.

Google offers two routes, and a store can use both, for different facets.

Facets you do not need in search: stop the crawl. The most reliable method is robots.txt, leaving the unfiltered category and the product pages crawlable:

User-agent: *
Disallow: /*?*color=
Disallow: /*?*size=
Disallow: /*?*price=
Disallow: /*?*sort=

Filters kept in the URL fragment (#color=green) stay out of the crawl too, since Google generally ignores fragments. A rel="canonical" from each filtered URL to the unfiltered page, or rel="nofollow" on filter links, is weaker: Google calls both generally less effective in the long term, and nofollow only works if every link to the URL carries it.

Facets worth indexing: make them clean. Some combinations match real searches, such as a brand within a category. Give those a stable URL, a unique title and a paragraph of copy, and link them from navigation like any other category. For facet URLs that stay crawlable, Google asks for three things:

• Separate parameters with &. Commas, semicolons and brackets are hard for crawlers to recognize as separators.
• If filters live in the path (/shoes/trail/waterproof/), keep their order fixed and never allow the same filter twice.
• Return a real 404 for combinations with no results, duplicate or nonsensical filters and page numbers past the end. Serve it at the URL that was requested; do not redirect to a shared "not found" page.

Write product pages that deserve to rank

Product pages carry the most specific searches, often a brand and a model number, and they compete with every other shop that sells the same item. What separates your page from theirs is information, not keywords.

Descriptions

Manufacturer copy appears on every site that stocks the product. Google's guidance on helpful content asks whether a page provides original information, and whether it avoids simply copying or rewriting its sources. Keep the manufacturer's specifications, then add what only you know: fit and sizing notes, compatibility, what is in the box, care instructions and answers to the questions customers ask your support team. Put the full product name, brand and model in the title and the h1, with the attribute that distinguishes this item, such as size, colour or capacity.

Images

• Use <img> elements with a src attribute, including inside <picture>. Google's image guidelines are explicit that it does not index images set in CSS.
• Give files short, descriptive names (trail-shoe-blue-side.jpg, not IMG_0042.jpg) and write alt text that describes what the photo shows.
• Provide several high-resolution photos. For product markup, Google recommends images of at least 50,000 pixels (width multiplied by height) in 16:9, 4:3 and 1:1 aspect ratios, and the image URLs must be crawlable and indexable.

Reviews

Customer reviews help shoppers decide and can add star ratings to your results, under rules Google enforces:

• The reviews and the aggregate rating you mark up must be visible on the page.
• They must be about this specific product, not a category or a list of products.
• Do not aggregate reviews or ratings from other websites.
• No fake reviews, and no reviews given in exchange for money, discounts or free products without clear disclosure.

Google's restriction on self-serving reviews applies to pages that review your own business with LocalBusiness or Organization markup, not to customers' reviews of the products you sell.

Shipping and returns

State shipping costs, delivery times and the return policy on the product page, or one click from it. Google lists clear shipping and return policies among the things that build shopper trust, and merchant listings can show both next to your products.

Handle variants and duplicate URLs with canonicals

On most stores the same product page is reachable at several URLs: with tracking parameters from ads and email (?gclid=), through category paths, with a variant preselected, in different letter case. Google groups duplicates and picks one canonical URL to show. You steer that choice with signals that add up:

Put a self-referencing canonical on every indexable page, link internally to canonical URLs only, and never let signals disagree, such as a sitemap listing one URL and the canonical naming another. Set the canonical in the HTML source and do not let JavaScript change it. Do not use robots.txt or noindex to choose a canonical: a blocked duplicate can still be indexed without its content, and noindex removes the page from Search entirely.

Product variants

Variants (sizes, colours, materials) are the duplicate problem no store can avoid, and Google's product variant documentation sets specific rules for them:

• Every variant needs a URL that preselects it: the right image, price and availability, and an add-to-cart that adds that variant. A path segment (/t-shirt/green) or a query parameter (/t-shirt?color=green) both work.
• When all variants live on one page and are selected with query parameters, the base URL without parameters (/coat) is the single canonical for the whole group.
• When variants are split across pages (/coat/lightblue, /coat/green), there is no single canonical for the group, and each page carries complete markup for the variants it shows.
• Mark the group up with ProductGroup: a productGroupID for the parent, variesBy for the attributes that change (https://schema.org/size, https://schema.org/color) and hasVariant listing each variant as a Product with its own unique sku or gtin. In a Merchant Center feed, the same grouping is the item_group_id attribute, identical across the variants, as the product data specification describes.

Add product structured data for merchant listings

Structured data states exactly what a product page offers: name, price, currency, availability and identifiers. Google splits product markup into two uses:

• Product snippets, for pages where the product cannot be bought directly, such as editorial reviews.
• Merchant listings, for pages where a shopper can buy from you. These feed the shopping knowledge panel, popular products, Google Images and product snippets, with price, availability, shipping and returns.

A product page that meets the merchant listing requirements is generally eligible for product snippets as well. The merchant listing rules that matter:

1. Required properties. name, image and offers. Merchant listings need an Offer with a price above zero and a priceCurrency in three-letter ISO 4217 format. Product snippets also accept AggregateOffer; merchant listings do not.
2. Recommended properties. availability (one value), the most specific gtin that applies, brand.name, sku, itemCondition, and aggregateRating and review where you have them. Google recommends declaring your store-wide shipping and return policies once, under Organization markup, and using shippingDetails or hasMerchantReturnPolicy on an offer only to override them.
3. One product per page. Markup belongs on product pages, not on category listings. A product sold in several currencies needs a separate URL for each currency.
4. Server HTML. Google recommends putting product markup in the initial HTML. Markup generated by JavaScript can make Shopping crawls less frequent and less reliable, which hurts the data that changes fastest: price and availability.

A minimal example for a product page:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": "Trail running shoe, blue, size 10",
    "image": [
      "https://example.com/photos/1x1/trail-shoe-blue.jpg",
      "https://example.com/photos/4x3/trail-shoe-blue.jpg",
      "https://example.com/photos/16x9/trail-shoe-blue.jpg"
    ],
    "description": "Lightweight trail running shoe with a rock plate and a gusseted tongue.",
    "sku": "TR200-BLU-10",
    "brand": { "@type": "Brand", "name": "ExampleBrand" },
    "offers": {
      "@type": "Offer",
      "url": "https://example.com/products/trail-shoe?color=blue&size=10",
      "price": 129.0,
      "priceCurrency": "CAD",
      "availability": "https://schema.org/InStock",
      "itemCondition": "https://schema.org/NewCondition"
    }
  }
</script>

Validate each template with the Rich Results Test, check a live product with the URL Inspection tool, then watch the Shopping reports in Search Console after every release.

Send your catalogue to Google Merchant Center

Structured data describes the products Google finds by crawling. A Merchant Center feed tells Google about your products directly. Google recommends doing both, for reasons that matter to stores:

• Crawling is not guaranteed to find every product; a feed lists them all.
• You control the timing. Feeds can update weekly, daily or hourly, while Google does not guarantee how quickly it processes changes it finds by crawling.
• A feed can carry data your pages do not show, such as inventory by physical store.
• Merchant Center is required to appear in the Shopping tab.

Free listings are the unpaid side of Merchant Center. Eligible products can appear at no cost on Google Search, the Shopping tab, Google Images, Google Lens, Google Maps, YouTube and Gemini, and new Merchant Center accounts are opted in by default. Free listings bring shoppers to product pages, not to your home page, policy pages or category pages. In many countries, including Canada, the United States, the United Kingdom, Australia, Germany and Japan, you also need shipping settings in Merchant Center or shipping costs in the feed.

There are four ways to get products in:

Keep the page, the markup and the feed in agreement

Merchant Center checks your feed against your landing pages. For availability, the value must match across the landing page, the structured data, the checkout and the data source, and a mismatch in any one of them gets the product disapproved.

Automatic updates narrow the gap between feed uploads. When they are on (the default), Google corrects price, sale price, availability and condition from your pages' structured data when it finds a mismatch. They are a safety net, not a replacement for frequent feed updates: Google warns they may not work for products whose price or availability changes more than once a day, and such products can be disapproved instead of updated.

Handle out-of-stock and discontinued products

Stock changes are routine on a store, and each state needs a different response from the URL, the markup and the feed:

Keep a temporarily unavailable product live. Google drops URLs that return a 4xx status code from its index, so a 404 on a product that is back next month means it has to be crawled and indexed again when stock arrives. In Merchant Center, deleting an item is also slow to undo: Google says adding an offer back after deletion takes a significant amount of time, so mark it out_of_stock instead.

Keep the page's content, too. A product page stripped down to "sold out" risks being treated as a soft 404: a URL that returns 200 but looks like an error or an empty page. Google excludes those from Search and lists them in Search Console. A page that keeps its description, specifications and reviews, says when stock returns and links to alternatives does not look like an error.

When a product is gone for good, a 301 to a real successor, such as the next model of the same product, sends shoppers and signals to the right place. Without a successor, return 404 or 410. Google treats the two the same: the URL leaves the index, and Google crawls it less and less often over time.

Keep product and category templates fast

Core Web Vitals measure what shoppers experience on real devices, and Google says good scores align with what its core ranking systems seek to reward. The three metrics and their "good" thresholds, measured at the 75th percentile of page loads on mobile and desktop, from web.dev:

INP replaced First Input Delay as a Core Web Vital in 2024. Stores usually lose these metrics in three places:

• LCP and the product photo. Never lazy-load the main product image: web.dev's LCP guide says a lazy-loaded LCP image always adds unnecessary delay. Give it fetchpriority="high", on one or two images per page at most, because a high priority on many images stops helping.
• CLS and late content. Images without width and height, and review widgets, banners and embeds injected after load, are common causes of layout shift. Set image dimensions and reserve space for anything that arrives later.
• INP and third-party scripts. Review widgets, chat, personalization and tag managers all run JavaScript, and scripts busy on the main thread delay the response to a tap. Test the filters, the variant picker and the add-to-cart button on a mid-range phone.

Search Console's Core Web Vitals report uses field data from real users and groups similar pages, so a slow product template shows up as one group of URLs rather than thousands of separate problems. Fix the template and every product that uses it improves. Our web design and development team builds with Core Web Vitals budgets enforced in CI and Schema.org structured data per template.

Platform notes: Shopify, WooCommerce and custom builds

Platforms handle the basics and leave the decisions in this guide to you. Each has a full guide of its own: Shopify SEO and WordPress SEO, which covers WooCommerce's underlying settings. How AI shopping and agent checkout change the rest of the store is in the future of e-commerce.

Shopify

• Every store generates sitemap.xml automatically, linking products, primary product images, pages, collections and blog posts. Submit it in Search Console. Current Shopify themes also include product structured data (price, availability, reviews) by default.
• Shopify ships a default robots.txt. To change it, add a robots.txt.liquid template and edit the rules with Liquid, which keeps Shopify's future updates. Replacing it with plain text is strongly discouraged, and Shopify Support does not help with edits to the file.
• The structured_data Liquid filter outputs a product as a Product, or as a ProductGroup when it has variants.
• The within filter builds collection-aware product URLs such as /collections/sale/products/trail-shoe. Shopify's own documentation warns that these show the same content as the standard product URL; link product grids to the standard URL and check the canonical your theme prints.
• The Google & YouTube sales channel, managed by Google, syncs products to Merchant Center.

WooCommerce

• With pretty permalinks on, product URLs default to /product/<name> and category URLs to /product-category/<name>. The "Shop base with category" option adds the category to product URLs. Decide before launch: changing the base later changes every product URL, and each old URL then needs a 301.
• WordPress has generated a sitemap at /wp-sitemap.xml since version 5.5, covering public post types and taxonomies. The WordPress settings that decide what gets indexed, from permalinks to archives, are in our WordPress SEO guide.
• WooCommerce core prints Product JSON-LD on product pages. For a variable product whose variations have different prices, it describes the parent with an AggregateOffer price range, which product snippets accept and merchant listings do not. Test variable products in the Rich Results Test.
• The Out Of Stock Visibility setting hides out-of-stock items from the catalogue, which also removes the category links to them. For short stock gaps, leaving products visible and marked out of stock keeps them linked.
• The Google for WooCommerce extension syncs product data to Merchant Center.

Custom and headless builds

A custom or headless storefront, in Next.js or anything else, owns every rule in this guide. Render product markup, canonical tags and category links in the server HTML, return real 404 and 301 status codes from the server rather than from client-side routing, and test each template with URL Inspection before launch.

Measure e-commerce SEO in Search Console and Merchant Center

Read the reports by page type and template, not one URL at a time.

Page indexing report. The statuses that matter most on a store:

Shopping reports. Under Shopping in Search Console, the Merchant listings and Product snippets rich result reports count valid and invalid product items (items, not pages) and the issues behind them. Check them after every template release: a fall in valid items without a rise in invalid ones often means the markup stopped being output.

Performance report. Group by Search appearance to separate clicks from rich product results, and by page to compare category and product templates.

URL Inspection. For a single product, it shows the canonical Google selected and the rendered page, which tells you whether markup and links survive rendering.

Merchant Center. The Needs attention tab on the Products page lists items with problems, and the Performance page can be filtered to free listings to show what unpaid listings bring in.

If you want a second pair of eyes on all of this, our SEO service starts with a technical audit of crawling, rendering, indexing, speed and structured data, covers canonicals, parameters and product and merchant markup, and reports from Search Console, server logs and field data.