Category, product and article pages: an on-page checklist for each template

Why page type matters

Each page type matches a different kind of search. Someone typing women's running shoes wants to compare options, so the best result is a category page. Someone typing trail x2 men's size 42 wants one product. Someone typing how to choose trail running shoes wants an explanation. If the wrong page type answers the query, good copy will not save it.

The second reason is scale. A shop with 40 categories and 8,000 products has 8,000 product pages built from one template. If that template prints the manufacturer's description, an empty <h1> or a price in the markup that does not update after a sale, the mistake is repeated 8,000 times. The same is true for good decisions. Product page SEO, category page SEO and article page SEO are mostly template work.

This lesson covers the on-page side. Site-wide shop topics such as architecture, feeds and migrations are in the lesson E-commerce, the full markup reference is in Structured data in 2026, and the title formulas are in Title tags.

What Google officially says

Google's e-commerce documentation is short and practical. The points that shape page templates:

Google also describes the link path it expects: “add links from menus to category pages, from category pages to sub-category pages, and finally from sub-category pages to all product pages.” And it explains why internal links matter beyond discovery: “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.”

Category (listing) pages: the checklist

A category page is a hub. It has to help a person narrow down a range and give Googlebot a clean path to every product in it.

Title and H1 pattern

Use the plural, browsing form of the term and keep the brand at the end, for example the title Women's Running Shoes | Example Store with the H1 Women's running shoes. Generate the pattern from the category name, then hand-edit your most important categories. Avoid stuffing the title with every subcategory. The lesson Title tags covers length and rewrites.

Unique intro copy

Put a short paragraph of unique text above the grid: what the range includes, who it is for and how to choose. It gives Google context the product cards cannot. Longer buying advice can sit below the grid. What does not work is a block of keyword-heavy text at the bottom that nobody reads, or the same paragraph pasted on every category with only the name swapped.

A product grid Google can crawl

Every product card must link to the product with a real link. Google is specific: “To ensure Googlebot correctly locates the link, use <a href> tags when creating links to other content.” A grid built from onclick handlers, or a “load more” button that fetches products without changing the URL, can hide most of the range. Search boxes do not help either: “Googlebot generally doesn't try to submit searches into a search box as part of crawling a site.” Use the product name as anchor text; Google recommends “meaningful text between <a href> and </a> tags where possible, such as the title of the product being linked to.”

Subcategory links

If the category has children, link to them near the top as plain text links. This is the “from category pages to sub-category pages” step in Google's link path, and it lets people narrow down before scrolling.

Sorting, filters and pagination

These create most of the URLs on a shop. The rules in short: each paginated page has a self-referencing canonical and is reached through normal links; Google no longer uses rel="prev" and rel="next"; sort orders are not indexed; only filter combinations with real demand get indexable URLs. The full treatment is in the lesson Pagination and faceted navigation.

Images

Product thumbnails on a category page are links first. Give them alt text with the product name, and lazy-load images below the first screen without lazy-loading the links themselves.

Structured data

Add BreadcrumbList, which Google says helps it “understand the hierarchy of pages on your site”. Do not put Product markup for the whole grid on the category page. Google states: “Product rich results only support pages that focus on a single product (or multiple variants of the same product).”

FAQs, if useful

A few questions buyers really ask (sizing, care, returns for this range) can help people decide. Write them for people. Google stopped showing FAQ rich results in May 2026 (see "Structured data in 2026"), so add questions for readers, not for markup.

Canonical

The clean category URL has a self-referencing canonical. Sorted and tracking-parameter versions point their canonical to it. Use the same URL format everywhere: “Use the same URL in internal links, sitemap files, and <link rel="canonical"> tags.”

Empty and thin categories

Google documents two options. For a temporarily empty category: “Avoid linking to, or at least indexing, pages without useful content. If a category has no items, use a noindex robots meta tag.” For a category your platform removes automatically: “If your site detects that a category has become empty and automatically removes the category from on-site search and browse, consider returning a 404 (not found) HTTP status code for the page.” Categories with one or two products and no unique text are usually better merged into their parent.

Product pages: the checklist

A product page has to answer every question a buyer has, and give Google a single, consistent set of facts: name, price, availability, images and reviews.

Title and H1 pattern

Build the title from brand, model and the attribute people search for, then the store name: Trail X2 Running Shoe, Men's | Example Store. The H1 is the product name without the store. If two products end up with the same title, the template is missing the attribute that tells them apart.

A unique description

The manufacturer's description is published by every retailer that sells the product. There is no duplicate content penalty, but identical copy gives Google no reason to choose your page over theirs. Write your own: who the product is for, how it differs from the previous model or the cheaper option, what buyers ask your support team. For large catalogues, start with the products that sell or get searched most.

Specs

Put specifications in an HTML table or a definition list, not in an image: dimensions, weight, materials, compatibility, what is in the box. They answer long-tail searches and the same attributes feed your structured data and Merchant Center feed.

Images

Several real photos from different angles, a descriptive file name and alt text. For markup, Google prefers “Pictures clearly showing the product (for example, against a white background)”. Image URLs must be crawlable, so do not block your image folder in robots.txt. More in the lesson Images: alt, formats, sizes, lazy loading.

Price and availability, everywhere the same

The price and stock status a person sees must be the values in your Product markup and in your Merchant Center feed. Google recommends using both channels: “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility to experiences and helps Google correctly understand and verify your data.” It also warns that the two can drift: “When Google combines data from your website and Google Merchant Center feeds, it can lead to data inconsistency issues due to lag.” The documented fix is to “tell Google Merchant Center to automatically update its copy of your product data based on the website contents, when such a discrepancy is noticed.” In the template, print the visible price and the markup price from the same variable, and put the markup in the server HTML. Google advises: “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.”

User reviews

Customer reviews answer questions your description cannot, and they add fresh, specific text. Show them as HTML on the page, not only in a widget loaded from another domain. If you mark them up, mark up what people can see: “if you include multiple reviews, make sure that you include all of the reviews that are visible to people on the page.” Never invent or import reviews: Google lists “fake reviews” as misleading content.

Internal links

Breadcrumbs back to the category, links to related products and accessories, and a link to the relevant buying guide. Promote your best sellers from the home page or articles; Google gives that exact example for showing which products matter most.

Canonical

The product URL has a self-referencing canonical. If the same product is reachable under several category paths, all of them point to one product URL, and internal links use that URL. Variants follow their own rules, below.

Product variants: how Google wants them handled

Sizes, colours and materials are where product templates most often go wrong. Google's documented approach has four parts.

1. A URL per variant. Each variant must be reachable at its own URL, as a path (/t-shirt/green) or a query parameter (/t-shirt?color=green). Google requires that the site can “preselect each variant directly with a distinct URL”, and explains what preselecting means: “Preselecting each variant includes showing the right image, price, and availability, as well as allowing the user to add the variant to the cart.”
2. The right canonical. “If you use optional query parameters to identify variants, use the URL with the query parameter omitted as the canonical URL.” And: “For products with unique URLs per variant, include the canonical product URL on all variant pages using a <link rel="canonical"> tag.”
3. ProductGroup markup. Group the variants with ProductGroup and its properties variesBy, hasVariant and productGroupID, in addition to Product markup for each variant.
4. Unique IDs. “Each variant must have a unique ID in its corresponding structured data markup (for example, using the sku or gtin properties).”

Google's wording for the single-page case: “For single-page sites, there must be only one distinct canonical URL for the overall ProductGroup that all variants belong to.” Whether a colour deserves its own indexable page is a demand question: if people search for trail x2 green and you have unique content for it, the multi-page approach gives it a page of its own. If you sell in several currencies, one more rule applies: “When offering products for sale in multiple currencies, have a distinct URL per currency.”

Out-of-stock and discontinued products

Stock changes all the time, and the page has to tell the truth about it. In markup, availability takes one value from schema.org: InStock, OutOfStock, BackOrder, PreOrder, PreSale, LimitedAvailability, InStoreOnly, OnlineOnly, Discontinued or SoldOut. Google adds: “Don't specify more than one value.”

Whatever you choose, change it in three places at once: the page, the markup and the Merchant Center feed. A product that is sold out on the page but in stock in the feed is exactly the lag problem Google describes.

Product structured data: a working example

Google has 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.” Only shops qualify for the second: “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.” A shop product page with the required merchant listing properties can also be eligible for product snippets.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail X2 running shoe, men's",
  "image": [
    "https://example.com/img/trail-x2-1x1.jpg",
    "https://example.com/img/trail-x2-4x3.jpg",
    "https://example.com/img/trail-x2-16x9.jpg"
  ],
  "description": "Light trail shoe with a 6 mm drop and a recycled mesh upper.",
  "sku": "TX2-M-GRN-42",
  "brand": { "@type": "Brand", "name": "ExampleBrand" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/shoes/trail-x2/",
    "priceCurrency": "USD",
    "price": 119.99,
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.4,
    "reviewCount": 128
  }
}
</script>

What each part does and what to watch:

• name, image, offers are required for merchant listings. Google recommends several high-resolution images in 16x9, 4x3 and 1x1.
• offers must be a single Offer for merchant listings, because the shop has to be the seller. AggregateOffer is accepted only for product snippets.
• sku or a GTIN identifies the exact item and is what makes variants distinguishable.
• aggregateRating belongs only on the product page that shows those reviews.
• Shipping details and return policies can be added per offer, or once for the whole shop under Organization, which Google recommends for shop-wide policies.

Test the template in the Rich Results Test, then check a few live URLs with URL Inspection. The full property reference and testing workflow are in the lesson Structured data in 2026.

Article pages: the checklist

Blog posts, guides and buying guides support the shop: they catch informational searches and link people to categories and products. Their template needs different parts.

Title and H1

The title states the topic or question in the words people search with, for example How to Choose Trail Running Shoes; the H1 says the same thing for the reader. For the markup, Google suggests: “Consider using a concise title, as long titles may be truncated on some devices.”

Author and dates

Show a byline that links to an author page, and show the publish date and, when you have really updated the article, the update date. Mark them up the same way. Google: “Make sure that all the authors that are presented as authors on the web page are also included in markup.” And: “In the author.name property, only specify the name of the author.” No job titles, no “posted by”, no publisher name in that field. Do not refresh the date without changing the content.

An intro that answers fast

Answer the question in the first paragraph, then expand. Readers decide in seconds whether the page is for them.

Images

Use your own photos, diagrams and screenshots where you can. For markup, Google asks to “Use images that are relevant to the article, rather than logos or captions.”

Article markup

Use Article, BlogPosting or NewsArticle. “There are no required properties; instead, add the properties that apply to your content.” In practice that means headline, image, datePublished, dateModified and author with name and url:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to choose trail running shoes",
  "image": ["https://example.com/img/trail-guide-16x9.jpg"],
  "datePublished": "2026-03-04T09:00:00+00:00",
  "dateModified": "2026-10-12T14:30:00+00:00",
  "author": [{ "@type": "Person", "name": "Jane Doe",
               "url": "https://example.com/authors/jane-doe/" }]
}

Related links

Link to related articles and to the categories and products the article discusses, with descriptive anchors. A buying guide that never links to the products it recommends wastes its value for the shop.

Canonical

Self-referencing on each article. For an article split over several pages, Google's rule: “For multi-part articles, make sure that the rel=canonical points at either each individual page or a "view-all" page (and not to page 1 of a multi-part series).”

Reviews: what Google calls high quality

Two different things are both called reviews. Customer reviews on a product page are user-generated and marked up with review and aggregateRating. Editorial reviews are articles in which you test and compare products. Only the second kind can get the pros and cons display: “Only editorial product review pages are eligible for the pros and cons appearance in Search, not merchant product pages or customer product reviews.”

For editorial reviews and buying guides, Google publishes a list of best practices. The core of it:

• “Demonstrate that you are knowledgeable about what you are reviewing—show you are an expert.”
• “Discuss the benefits and drawbacks of something, based on your own original research.”
• “When recommending something as the best overall or the best for a certain purpose, include why you consider it the best, with first-hand supporting evidence.”
• Google closes with: “focus on the quality and originality of your reviews, not the length”.

The same page also asks for evidence such as your own photos or measurements, comparisons with competing products and an explanation of how a product has changed from earlier models. For customer reviews, the rules are simpler: collect them from real buyers, show all of them, and keep the rating in the markup equal to the rating on the page.

The checklist side by side

Use this table when you review a template. Each row is one check; each column is a page type.

Template-level mistakes

These are the problems that show up across thousands of URLs at once. Each one is fixed in the template, not page by page.

• Manufacturer descriptions on every product. The same text as every other retailer, often with the same specs list. Start rewriting with the products that matter most.
• Thin categories. Dozens of categories with one or two products, no intro and a title that only differs by one word. Merge them or keep them out of the index.
• Boilerplate. A long delivery and returns block, a generic why buy from us text or the same category intro with the name swapped. Keep shared text short and put the unique part first.
• Empty categories returning 200. A no products found page that is indexable is a typical soft 404. Use noindex or 404 as Google documents.
• Links Google cannot follow. Product cards with onclick instead of <a href>, or infinite scroll with no paginated URLs behind it.
• Markup that disagrees with the page. Price in JSON-LD not updated after a sale, InStock hard-coded, a rating with no visible reviews, Product markup on category pages.
• Variant canonicals that break. All variants pointing to a URL that redirects or does not exist, or each colour page canonicalised to another colour.
• One title for everything. A pattern that leaves out the attribute that tells products apart, so dozens of pages share one title.

Common mistakes

• ✕Product markup on category pagesGoogle recommends product markup on product pages, not on listings.
• ✕Products reachable only through searchGooglebot does not type into your search box. Link every product from a category.
• ✕Copied manufacturer textNo penalty, but no reason for Google to prefer your page either.
• ✕Price or stock out of syncPage, markup and Merchant Center feed must say the same thing.
• ✕Variants without their own URLGoogle needs a distinct URL to crawl and identify each variant.
• ✕Discontinued products all redirected homeUse a true replacement or a 404/410.
• ✕Fake or hidden reviewsMark up only real reviews that people can see on the page.
• ✕Article dates changed without changesUpdate the date when the content really changed.

FAQ

Sources

• Google Search Central — Help Google understand your ecommerce website structure
• Google Search Central — Designing a URL structure for ecommerce sites
• Google Search Central — Share your product data with Google
• Google Search Central — Include structured data relevant to ecommerce
• Google Search Central — Write high quality reviews
• Google Search Central — Introduction to Product structured data
• Google Search Central — Merchant listing structured data
• Google Search Central — Product snippet structured data
• Google Search Central — Product variant structured data
• Google Search Central — Article structured data
• Google Search Central — General structured data guidelines

Quotes checked against the official pages on 30 October 2026.