E-commerce SEO: structure, product data, Merchant Center and out-of-stock pages

Where product information can appear in Google

Google's e-commerce guides open with the problem every store owner knows: “A critical challenge for any ecommerce website is being discovered in Search.” The good news is that a store has more places to be found than an ordinary site. Google puts it like this: “Google has multiple surfaces where your ecommerce content can appear, such as in search results and on Google Maps.”

The surfaces Google documents for e-commerce content are:

• Google Search. Ordinary results, plus product rich results that can show price, availability, ratings, shipping and returns.
• Google Images. Product images can carry a product label and product details.
• Google Lens. Visual search results that can list similar products. Google ties this to Merchant Center: upload your product details, opt in to product listings and follow the image best practices.
• Google Shopping tab. “If you want your products to be found in the Google Shopping tab, upload your products to Google Merchant Center.”
• Business Profile. Your business details, linked to Merchant Center.
• Google Maps. Products with inventory location data in Merchant Center can appear in Maps results.

Merchant Center Help adds that free listings can appear on “Google Search, Google Maps, Gemini, YouTube, the Shopping tab, Google Images, and Google Lens.” Inside Google Search, product information can show up as a product snippet (a text result with ratings, price and availability), as popular products (a visual block of products for sale), in a shopping knowledge panel (one product with a list of sellers) and as annotated images.

Google separates two kinds of product markup. Product snippets are “For product pages where people can't directly purchase the product.”, such as editorial reviews. Merchant listings are “For pages where customers can purchase products from you.” If you sell the product on the page, merchant listings are your target, and the required merchant listing properties usually make the page eligible for product snippets too.

What Google officially says

A few more statements from the same documentation set the rules for the rest of this lesson:

• “Web crawling is not guaranteed to find all products on your site.”
• “Googlebot generally doesn't try to submit searches into a search box as part of crawling a site.”
• “Only pages where a shopper can purchase a product are eligible for merchant listing experiences, not pages with links to other sites that sell the product.”
• “Return an HTTP 404 status code when a filter combination doesn't return results.”

Structured data and Merchant Center: two channels, one truth

Google recommends two ways of telling it about your products, and they work best together. The first: “Include structured data in your site's product pages.” The second is to upload a product feed to Google Merchant Center. Neither is a ticket into ordinary search results on its own. “While structured data isn't required to appear in Google Search results, it can help Google understand your page better and display it as a rich result.” And: “While uploading product data to Google Merchant Center isn't mandatory to appear in Google search results, it can enhance Google's understanding of your products.”

The difference shows on specific surfaces. “Participation in Google Merchant Center is required to appear in the Google Shopping tab.” Structured data is what Google Search uses for product rich results, and it also helps Merchant Center verify your feed against the page.

Choosing a feed method

Google describes three options. Smaller stores that change rarely can use an automated feed that Merchant Center builds from your crawled pages; good structured data makes that extraction more accurate. Larger stores, or stores where prices and stock change often, should upload feed files on a schedule. And “The Content API allows immediate content updates, which is particularly useful for stock level updates.”

Keep the two in sync

“When Google combines data from your website and Google Merchant Center feeds, it can lead to data inconsistency issues due to lag.” The classic case: a product sells out, the page says so at once, but the feed still says “in stock” until the next upload. Google's fix is to let Merchant Center automatically update its copy of your product data from the website when it notices a difference. Merchant Center Help gives the rule in plain words: “Match your product data in Merchant Center with your online store to ensure customers view the same information, such as prices, across both.”

Data also flows the other way: “For example, product snippets may use pricing data from your merchant feed if it's not present in the structured data on the page.” So a wrong price in the feed can appear in your organic result. In practice:

• Generate the markup and the feed from the same product database, not from two separate exports.
• Send the same URL in the feed's link or canonical_link attribute as the page's canonical.
• Give every product a strong identifier. Merchant Center Help asks you to “Provide strong product identifiers (GTIN, MPN+Brand) for your products to be added correctly into the knowledge panel.”
• Do not hide the add-to-cart button to stop sales. “Google may use add-to-cart as a part of verifying the final price details, including tax and shipping costs.”

Which properties to add and how to validate them is covered in the lesson Structured data in 2026.

Store architecture: home, categories, subcategories, products

Google reads a store's structure from its links, not its URLs: “Google generally doesn't look at the structure of URLs to work out the structure of a site.” It looks at how many links lead to a page and how many clicks it takes to reach it. “As a general rule, the more links a page has to it within a site, the higher the relative importance of the page to other pages on your site.”

The recommended path is simple: “For example, add links from menus to category pages, from category pages to sub-category pages, and finally from sub-category pages to all product pages.” If a product can only be found through the search box, Google will probably never see it, because it does not type into search boxes. When linking every product is not possible, a sitemap or a Merchant Center feed can list the URLs Google would otherwise miss.

Three habits make this structure work:

1. Keep products close to the home page. A product that sits ten clicks deep, behind page 40 of a category, gets little attention. Add subcategories, link best sellers from the home page and from guides, and show “related products” and “also in this range” blocks.
2. Use real links. Google asks for <a href> links and warns against navigation built on JavaScript events. Product cards, menus and pagination should all be crawlable links.
3. Add breadcrumbs. They give every product a link back up the tree, and BreadcrumbList markup can show that trail in search results.

How to turn keyword groups into a hierarchy of hubs, and how deep is too deep, is covered in the lesson Structure from keywords: hubs and depth.

Category pages vs product pages: what each one targets

Google's own advice on catalogue content already splits the job: “Provide informative product descriptions that match search terms used by shoppers when they're searching for the product. Also provide category descriptions to cover less specific queries.”

One search intent should have one URL. If your category “Trail running shoes” and a filter page “Running shoes · terrain: trail” both target the same query, they compete with each other. Pick one, link to it consistently, and canonicalise or block the other. Markup follows the same split: Google recommends “focusing on adding markup to product pages instead of pages that list products or a category of products.”

Page-level details, such as what to put in a category intro, how to write a product title and which blocks a product page needs, are in the lesson Category, product and article pages.

Faceted navigation, sorting and pagination

Filters by colour, size, brand and price are useful for shoppers and dangerous for crawling. Every combination is a new URL, and a few filters can create more URLs than you have products. Google's view of most of them: “Oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit”.

The working rule for stores:

• Index a small, chosen set of filter pages that match real searches, such as brand within category. Give them static URLs, their own title, H1 and intro, a self-referencing canonical and internal links.
• Keep the rest out. Block crawling of other filter parameters in robots.txt, or let them be crawled with noindex. Do not use both on the same URL: a blocked page is never fetched, so its noindex is never seen.
• Never index sort orders. ?sort=price shows the same list in a different order.
• Return 404 for empty combinations under the URL itself, instead of redirecting to a general “not found” page.

For paginated categories, give each page its own URL and its own canonical: “Don't use the first page of a paginated sequence as the canonical page.” Link the pages to each other with ordinary links, because “Google's crawlers don't "click" buttons and generally don't trigger JavaScript functions that require user actions to update the current page contents.” rel="prev" and rel="next" are not a fix either; about those tags Google says: “Google no longer uses these tags, although these links may still be used by other search engines.”

The full method, with robots.txt patterns and the choice between pagination, “load more” and infinite scroll, is in the lesson Pagination and faceted navigation.

Product variants

A T-shirt in five colours and six sizes is one product with thirty variants. Google's first rule: “To help Google understand your product variants, make sure that each variant can be identified by a separate URL.” Either a path segment (/t-shirt/green) or a parameter (/t-shirt?color=green) works. Fragments do not, because “Google does not use fragment identifiers in indexing.”

There are two common set-ups, and the canonical rule differs:

• Single page with selectors. All variants live on one page, and parameters preselect a variant. “For single-page sites, there must be only one distinct canonical URL for the overall ProductGroup that all variants belong to.” And: “If you use optional query parameters to identify variants, use the URL with the query parameter omitted as the canonical URL.” So /coat?size=small&color=green has its canonical set to /coat.
• A page per variant. Each variant has its own page with full, self-contained markup. Here there is no single group URL, and each page is treated as equally important.

Either way, group the variants. In markup that means ProductGroup with productGroupID, variesBy and hasVariant, and “Each variant must have a unique ID in its corresponding structured data markup (for example, using the sku or gtin properties).” In the feed, item_group_id ties the variants together. Each preselected variant URL should show the right image, price and availability and let the user add that variant to the cart.

When does a variant deserve its own indexable page? In practice, only when people search for it on its own and you can say something specific about it, for example a colour with its own name and photos. Sizes almost never qualify.

Out-of-stock, discontinued and seasonal pages

Google's e-commerce documentation does not give one rule for products that sell out. It does give the tools: the availability values in merchant listing markup include “https://schema.org/OutOfStock: The item is currently out of stock.” and “https://schema.org/Discontinued: The item has been discontinued.”, along with BackOrder, PreOrder and SoldOut. The decision below is standard practice built on those values and on normal status codes.

Temporarily out of stock

Keep the page live with status 200 and the same URL. Change the availability in the markup and in the feed, say on the page when the product is expected back, offer a “notify me” option and link to similar products. Do not redirect, noindex or delete a page that will be selling again in a few weeks: you would throw away its rankings and links for a short gap. If you still take orders, use BackOrder or PreOrder instead of OutOfStock.

// Offer inside Product markup, product temporarily sold out
"offers": {
  "@type": "Offer",
  "url": "https://example.com/p/pace-3/",
  "price": "129.00",
  "priceCurrency": "EUR",
  "availability": "https://schema.org/OutOfStock"
}

Discontinued for good

If there is a direct successor (Pace 3 replaced by Pace 4), a 301 redirect passes visitors and signals to the new page. If there is no successor but the old page still gets links, search traffic or visits from owners looking for manuals and spare parts, keep it, mark it Discontinued and point to alternatives. If none of that applies, return 404 or 410. Avoid redirecting every dead product to the home page or a loosely related category: Google tends to treat such redirects as soft 404s, and visitors are confused.

Empty categories

Here Google is specific. “If a category has no items, use a noindex robots meta tag.” And if your platform hides empty categories automatically, “consider returning a 404 (not found) HTTP status code for the page.”

Seasonal pages

Pages for Black Friday, Christmas or summer sales work best on one permanent URL without the year, such as /black-friday/. Keep the page live all year, update it each season and, between seasons, show when the next sale starts and link to evergreen categories. A new URL every year starts from zero each time. Google lists seasonal offers among the content that helps stores reach shoppers: “Describe your special offers during special seasonal sales events such as Mother's Day.”

Launching before products are on sale

One of Google's launch options is to publish the full site with products marked out of stock, so everything can be indexed before sales begin. Even then, keep the cart working: “Don't disable add-to-cart functionality as a way to stopping users from purchasing products.”

Internal search pages, reviews, shipping and returns

Internal search result pages

Pages such as /search?q=red+shoes can be generated in endless numbers and usually repeat category content. Keep them out of the index: block the search path in robots.txt or serve noindex, and do not link to search results from crawlable navigation. If a search term shows real demand, build a proper category or landing page for it instead.

# robots.txt: keep internal search and sort URLs out of the crawl
User-agent: *
Disallow: /search
Disallow: /*?*sort=

Reviews

Stores benefit from two kinds of reviews. Customer reviews on product pages help shoppers and can feed review stars through Review and AggregateRating markup, as long as the reviews are real and visible on the page. Merchant reviews and buying guides written by your own staff are content in their own right, and Google has published guidance for them. Among its points:

• “Evaluate from a user's perspective.”
• “Provide evidence such as visuals, audio, or other links of your own experience with what you are reviewing, to support your expertise and reinforce the authenticity of your review.”
• “Discuss the benefits and drawbacks of something, based on your own original research.”

Shipping and returns

Google lists customer service among the content that helps a store: “Improve customer trust by being clear on your return and shipping policies (including any shipping discounts based on order size), and by highlighting your customer support contact points.” Put it in three places:

• On the site: dedicated shipping and returns pages linked from the footer, plus a short summary on every product page.
• In markup: shippingDetails in the offer, and a store-wide MerchantReturnPolicy nested under Organization, which Google recommends for your business policies.
• In Merchant Center: shipping and return settings. Merchant Center Help says shipping settings or the shipping attribute are required for free listings in many countries.

Speed and rendering for stores

Stores are heavy: big category grids, many images, filters, reviews widgets and third-party scripts. Two Google statements matter most. “If you're a merchant optimizing for all types of shopping results, we recommend putting Product structured data in the initial HTML for best results.” And for markup injected later: “Be aware that dynamically-generated markup can make Shopping crawls less frequent and less reliable, which can be an issue for fast-changing content like product availability and price.”

In practice: render the product grid, prices and markup on the server; lazy-load images below the fold but never the main product photo; set image dimensions so the grid does not jump; and review every third-party app for the weight it adds. Metrics and fixes are in Core Web Vitals: LCP, INP, CLS, and image formats and sizes in Images: alt, formats, sizes, lazy loading. If you also sell in physical shops, Google Business Profile and local ranking covers the local side.

Common mistakes

• ✕Products reachable only through search or JavaScriptGoogle does not use your search box or click “load more”. Link every product with plain links.
• ✕Every filter combination indexableThousands of near-identical pages compete with your categories and eat crawling.
• ✕Feed and page disagreeDifferent price or stock in Merchant Center and on the page leads to warnings and wrong results.
• ✕Markup added only by JavaScriptShopping crawls become less frequent and less reliable for price and stock.
• ✕Variant URLs with fragments#black and #white are the same page to Google.
• ✕Out-of-stock pages deleted or redirectedA short stock gap costs the page its rankings and links.
• ✕All dead products redirected to the home pageLikely treated as soft 404s; use a successor, keep the page, or return 404/410.
• ✕A new seasonal URL every year/black-friday-2026/ starts from zero; keep one permanent URL.
• ✕Category and filter page targeting the same queryOne intent, one URL.

E-commerce SEO audit checklist

Use the same list before launch and in every audit. Work through it in this order, because problems early in the list hide the ones further down.

A crawler does most of the counting for you: export every URL with its status code, canonical and indexability, then compare the list with your product catalogue. Products missing from the crawl are not linked well enough; parameter URLs in the crawl show where filters leak. OurSEO Tools runs a 69-point checklist across indexation, URLs and duplicates, redirects, rendering and speed, security, on-page, internal linking, content and local signals, and a technical crawl of up to 1,000 pages with status code, canonical, indexability and load time per URL.

FAQ

Sources

• Google Search Central — Best practices for ecommerce sites in Google Search
• Google Search Central — Where ecommerce content can appear on Google
• Google Search Central — Share your product data with Google
• Google Search Central — Help Google understand your ecommerce website structure
• Google Search Central — Designing a URL structure for ecommerce websites
• Google Search Central — Pagination, incremental page loading, and their impact on Google Search
• Google Search Central — How to launch a new ecommerce website
• Google Search Central — Write high quality reviews
• Google Search Central — Managing crawling of faceted navigation URLs
• Google Search Central — Introduction to Product structured data
• Google Search Central — Merchant listing (Product, Offer) structured data
• Google Search Central — Product variant structured data
• Google Merchant Center Help — Free listings for products

Quotes checked against the official pages on 30 October 2026.