Category Page Pagination Reference

Pagination on category pages determines how Googlebot discovers your catalog and how link equity flows to products on pages 2, 3, and beyond. Wrong choices here can cause large portions of your catalog to be invisible to search engines.

1. Pagination Models Compared

Model 1: Numbered Pages (Recommended Default)

Products split across numbered pages with URL-based navigation:

/womens/boots/          <- page 1
/womens/boots?page=2    <- page 2
/womens/boots?page=3    <- page 3

SEO characteristics:

• All pages are crawlable and indexable
• Each page has a distinct URL - Googlebot can reach all products
• Link equity flows to page 1 most strongly, diminishing for deeper pages
• Products on page 10 receive very little direct PageRank
• Standard for most e-commerce stores

Canonical rules:

• Page 1 canonical: <link rel="canonical" href="https://example.com/womens/boots/">
• Page 2+ canonical: <link rel="canonical" href="https://example.com/womens/boots?page=2">
• Each page canonicals to itself - do NOT canonical all pages to page 1

Meta robots:

• All pages: index, follow
• Exception: If pages beyond 3-4 have fewer than 10 products, consider noindex, follow

Title tag differentiation:

Page 1: Women's Boots | StyleStore
Page 2: Women's Boots - Page 2 | StyleStore
Page 3: Women's Boots - Page 3 | StyleStore

Optimal page size:

• 24-48 products per page is the standard range
• More products per page = fewer paginated pages = more link equity per product
• Balance against page load time (more product images = slower initial load)

Model 2: View-All Page

A single page displaying all products in the category:

/womens/boots/            <- view-all (the main URL)
/womens/boots?page=2      <- paginated versions (canonical to view-all)

SEO characteristics:

• All products on one page - each product gets a direct link from the category
• No pagination dilution of link equity
• Risk: slow page load with hundreds of products
• Risk: Googlebot may not fully render/scroll through a very long page

When to use:

• Category has fewer than 100 products
• Products load fast (no heavy images, uses lazy loading correctly)
• Server-side render (not client-side) so Googlebot sees full content

Canonical implementation:

<!-- On /womens/boots?page=2 (and all paginated pages) -->
<link rel="canonical" href="https://example.com/womens/boots/">

<!-- On /womens/boots/ (the view-all, canonical to itself) -->
<link rel="canonical" href="https://example.com/womens/boots/">

Testing view-all renderability: Use Google Search Console > URL Inspection > "Test Live URL" to see exactly what Googlebot renders. If products below the fold are missing from the rendered HTML, the view-all approach is not working for those products.

Model 3: Infinite Scroll

Products load dynamically as the user scrolls. No new URLs generated by default.

SEO characteristics (pure JavaScript implementation):

• Only page 1 content is indexed
• Googlebot renders the initial load but may not trigger scroll events
• All products below the initial viewport are invisible to search

Making infinite scroll SEO-compatible:

Use history.pushState to update the URL as the user scrolls, creating bookmarkable URLs that Googlebot can crawl:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const page = entry.target.dataset.page;
      // Update URL without full page navigation
      history.replaceState(null, '', `/womens/boots?page=${page}`);
    }
  });
});

// Observe each "page boundary" sentinel element in the DOM
document.querySelectorAll('[data-page-sentinel]').forEach(el => {
  observer.observe(el);
});

Then ensure each ?page=N URL is server-side renderable (returns full page N content when fetched directly, not just the first page with JavaScript scroll position).

Alternative: Load More button

A "Load More" button is better for SEO than pure infinite scroll because:

• Products load in discrete chunks with explicit user intent
• URL can be updated when more is loaded
• Googlebot sees initial page content correctly without needing scroll simulation

<!-- Load More implementation with URL update -->
<div id="product-grid"><!-- initial products --></div>

<button id="load-more" data-next-page="2">Load More</button>

<script>
document.getElementById('load-more').addEventListener('click', async (e) => {
  const nextPage = e.target.dataset.nextPage;
  const res = await fetch(`/api/products?category=boots&page=${nextPage}`);
  const products = await res.json();
  appendProducts(products);

  // Update URL to reflect loaded content
  history.pushState(null, '', `/womens/boots?page=${nextPage}`);
  e.target.dataset.nextPage = parseInt(nextPage) + 1;
});
</script>

2. The rel="next" / rel="prev" Deprecation

Google deprecated support for rel="next" and rel="prev" pagination hints in March 2019. These tags are now ignored by Google.

Do not use:

<!-- These do nothing for Google SEO in 2024 -->
<link rel="prev" href="https://example.com/womens/boots/">
<link rel="next" href="https://example.com/womens/boots?page=3">

Bing still supports rel="next" / rel="prev". If Bing traffic is significant for your store, you may include these tags without harm (they are ignored by Google, not penalized).

The correct approach for Google is the canonical strategy described in Model 1 (each page canonical to itself).

3. Category Page Content Optimization

Beyond pagination mechanics, category pages need content to rank for head and mid-tail queries like "women's boots", "running shoes for men", "best laptop bags".

Introductory copy

Required: 100-250 words of unique introductory copy, placed above the product grid.

This copy should:

• Include the primary category keyword naturally in the first sentence
• Describe what the shopper will find (brands, styles, price ranges)
• Link to 2-3 important subcategories with descriptive anchor text
• Be unique - not shared with meta description or any other page

Example (good):

Women's Boots at StyleStore

Find the perfect pair of women's boots from our collection of over 300 styles.
Whether you're looking for everyday ankle boots, knee-high riding boots, or
waterproof hiking boots, we carry top brands including UGG, Timberland, Sam Edelman,
and Stuart Weitzman.

Browse by style: [Ankle Boots] | [Knee-High Boots] | [Over-the-Knee] | [Combat Boots]
Or shop by brand: [UGG Boots] | [Timberland Women's] | [Steve Madden]

Example (bad):

Welcome to our boots section. We have many boots available for you to buy.
Shop our boots collection today.

H1 tag

One H1 per category page, matching the primary keyword:

<h1>Women's Boots</h1>

Do not use decorative copy like "The Best Women's Boots You'll Love". Be direct about what the page is.

Category page schema

Use CollectionPage or ItemList schema to mark up the product grid:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "Women's Boots",
  "description": "Shop women's boots including ankle boots, knee-high boots, and hiking boots from top brands.",
  "url": "https://example.com/womens/boots/",
  "breadcrumb": {
    "@type": "BreadcrumbList",
    "itemListElement": [
      {
        "@type": "ListItem",
        "position": 1,
        "name": "Home",
        "item": "https://example.com/"
      },
      {
        "@type": "ListItem",
        "position": 2,
        "name": "Women's",
        "item": "https://example.com/womens/"
      },
      {
        "@type": "ListItem",
        "position": 3,
        "name": "Boots",
        "item": "https://example.com/womens/boots/"
      }
    ]
  }
}
</script>

4. Subcategory Architecture

Depth and hierarchy

Optimal hierarchy depth for e-commerce: 3 levels maximum.

Level 1: /womens/                       <- "women's clothing"
Level 2: /womens/shoes/                 <- "women's shoes"
Level 3: /womens/shoes/boots/           <- "women's boots"
Level 4: /womens/shoes/boots/ankle/     <- "women's ankle boots" (edge case)

Level 4+ pages are typically:

• Harder to crawl (deeper from homepage)
• Lower authority (fewer internal links reach them)
• Often low volume enough to handle as filtered views of level 3 pages

Exception: Level 4 is justified when the subcategory has its own clear search demand and enough SKUs to warrant a full page (20+ products).

Subcategory link placement on category pages

Place subcategory links near the top of the category page, before the product grid. This ensures Googlebot follows them early in the crawl and that users can refine their browse path immediately.

<nav class="subcategory-nav" aria-label="Browse by type">
  <ul>
    <li><a href="/womens/shoes/ankle-boots/">Ankle Boots</a></li>
    <li><a href="/womens/shoes/knee-high-boots/">Knee-High Boots</a></li>
    <li><a href="/womens/shoes/hiking-boots/">Hiking Boots</a></li>
    <li><a href="/womens/shoes/rain-boots/">Rain Boots</a></li>
  </ul>
</nav>

URL structure for subcategories

Use the full hierarchical path:

/womens/shoes/boots/ankle-boots/    <- GOOD: reflects taxonomy
/ankle-boots/                       <- BAD: flat, loses context
/womens/shoes/boots/?type=ankle     <- BAD: parameter-based, facet control needed

Flat URL structures (/ankle-boots/) can be used but make breadcrumb and internal linking harder to implement correctly.

5. Internal Linking on Category Pages

Links that matter for SEO

Footer copy with internal links

Adding a paragraph of copy at the bottom of category pages with links to related categories boosts internal linking depth:

<div class="category-footer-copy">
  <p>
    Looking for more footwear? Browse our full range of
    <a href="/womens/shoes/">women's shoes</a> including
    <a href="/womens/shoes/sneakers/">sneakers</a>,
    <a href="/womens/shoes/sandals/">sandals</a>, and
    <a href="/womens/shoes/heels/">heels</a>. For complementary styles,
    check out our <a href="/womens/accessories/socks/">women's socks</a> and
    <a href="/womens/accessories/shoe-care/">shoe care accessories</a>.
  </p>
</div>

This creates topical depth signals and distributes authority to related categories through in-copy anchor text.

6. Pagination Checklist

Before launching paginated category pages

• Page 1 has unique introductory copy (100-250 words)
• Each paginated page (?page=N) is server-side rendered (not client-side only)
• Canonical on each page points to itself, not page 1
• Title tags include "- Page N" for pages 2 and beyond
• Page 2+ are discoverable via next/previous links in the HTML
• URL structure is consistent (?page=2, not ?p=2 on some, ?page=2 on others)
• Product count per page is consistent (not 24 on page 1, 12 on page 6)
• No noindex accidentally applied to paginated pages (check with URL Inspection)
• rel="prev" / rel="next" omitted (deprecated, not needed)
• Product images on all pages use loading="lazy" with width/height attributes
• Category page included in XML sitemap (page 1 only - paginated pages optional)

Validating pagination SEO health

1. Submit page 1 URL to Google Search Console > URL Inspection, confirm indexed
2. Submit /category?page=5 (a deep page) to URL Inspection, confirm it can be fetched and rendered
3. Check Crawl Stats in Search Console for crawl frequency of paginated URLs
4. In a site: search (site:example.com/womens/boots), verify both page 1 and deeper pages appear in results

Faceted Navigation Reference

Faceted navigation is the single largest technical SEO challenge in e-commerce. This reference explains the problem, quantifies the impact, and provides concrete solutions with implementation code for each approach.

1. The Faceted Navigation Problem

What is faceted navigation?

Faceted navigation lets users refine product listings by filtering on multiple attributes simultaneously. A typical clothing store might offer filters for:

• Brand (Nike, Adidas, Puma)
• Color (Black, White, Red, Blue, Green)
• Size (XS, S, M, L, XL, XXL)
• Price range ($0-50, $50-100, $100-200, $200+)
• Rating (4+ stars)

Each filter combination typically generates a unique URL. The combinatorial math is brutal:

3 brands x 5 colors x 6 sizes x 4 price ranges x 2 ratings
= 720 URL combinations from a single category page

A store with 50 categories, each with comparable filter dimensionality, could generate 36,000+ URLs from facets alone - for a catalog of 5,000 actual products.

Why this is an SEO problem

1. Crawl budget exhaustion: Googlebot allocates a crawl budget per domain based on site size, authority, and crawl health. If 80% of crawlable URLs are low-value filter pages, Googlebot never reaches new or updated product pages.

2. Duplicate content: /womens/boots?color=black&size=8 and /womens/boots?size=8&color=black show identical products. So do /womens/boots?sort=price_asc and /womens/boots?sort=price_desc for small categories.

3. Thin pages: A filter for size 14 in a category with 3 products matching produces a page with very little content. Scaled across thousands of filter combinations, this generates a mass of thin pages.

4. Diluted PageRank: Internal links spread PageRank across all indexed URLs. Thousands of thin filter pages dilute the equity flowing to the high-value category and product pages.

2. Measuring the Problem

Before choosing a solution, measure the extent of crawl waste.

Using Google Search Console

1. Go to Index Coverage > filter by "Crawled - currently not indexed"
2. Look for URL patterns matching filter parameters (?color=, ?sort=, ?size=)
3. Check Crawl Stats to see how many URLs Googlebot crawled in the last 90 days

Using log file analysis

If you have access to server access logs:

# Count crawl requests per URL pattern (simplified)
grep -i "googlebot" access.log | grep "GET" | \
  awk '{print $7}' | \
  grep -E "\?(color|size|sort|brand)=" | \
  wc -l

Compare filter page crawls against total crawls to quantify crawl budget waste.

Using a crawler (Screaming Frog, Sitebulb)

Crawl the site with "Follow all links" enabled. Export URL list and count URLs matching filter parameter patterns. Compare against number of unique product pages.

3. Solutions

Option A: robots.txt Disallow

Block Googlebot from crawling filter URLs entirely using robots.txt.

User-agent: Googlebot
Disallow: /*?color=
Disallow: /*?size=
Disallow: /*?sort=
Disallow: /*?brand=
Disallow: /*?page=

When to use:

• All filtered combinations have zero organic search demand
• You want zero crawl budget spent on these URLs
• The filter combinations are pure UX features, not SEO assets

Trade-offs:

• No PageRank flows through these URLs to linked pages (since Googlebot never crawls them)
• Google cannot see the content of filtered pages (acceptable if you don't want them indexed)
• Must be combined with clean pagination strategy (see category-pagination.md)

Wildcard syntax note: robots.txt supports * wildcards. Disallow: /*?color= blocks any URL containing ?color= regardless of path prefix.

Option B: noindex, follow Meta Tag

Allow Googlebot to crawl filter pages (to follow links and pass PageRank) but instruct it not to index them.

<!-- Add to <head> on filtered pages only, not on base category pages -->
<meta name="robots" content="noindex, follow">

When to use:

• Filter combinations have no search demand and should not appear in search results
• You want Googlebot to follow internal links on filtered pages (e.g., links to products)
• You need a softer approach than robots.txt blocking

Implementation: dynamic insertion

// Pseudo-code: inject noindex on server-side render
function getMetaRobots(url) {
  const params = new URL(url).searchParams;
  const filterParams = ['color', 'size', 'sort', 'brand', 'rating'];
  const hasFilters = filterParams.some(p => params.has(p));

  if (hasFilters) {
    return 'noindex, follow';
  }
  return 'index, follow'; // default for base category and paginated pages
}

Trade-offs:

• Googlebot still crawls these pages (consuming crawl budget slightly)
• PageRank flows through links on the page
• More gradual deindexing - Google may continue showing these in index for weeks

Option C: Canonical Tag Consolidation

Use the rel="canonical" tag to tell Google which URL is the "master" version of a set of near-duplicate filtered pages.

<!-- On /womens/boots?color=black&size=8 -->
<link rel="canonical" href="https://example.com/womens/boots">

<!-- On /womens/boots?sort=price_asc -->
<link rel="canonical" href="https://example.com/womens/boots">

When to use:

• Filter combinations may have thin organic demand but you're unsure
• You want to consolidate PageRank into the base category URL
• You need a fallback for parameter combinations you didn't predict

Implementation: canonical should be absolute URL, not relative

<!-- GOOD -->
<link rel="canonical" href="https://www.example.com/womens/boots">

<!-- BAD - relative canonical can cause errors if crawled from a filtered URL -->
<link rel="canonical" href="/womens/boots">

Trade-offs:

• Google treats canonical as a hint, not a directive - it may choose to ignore it
• Does not prevent crawling (Googlebot will still crawl canonicalled pages)
• Works well combined with noindex, follow for belt-and-suspenders approach

Option D: AJAX/JavaScript-Only Filtering

Filter results without generating new URLs. The URL stays at /womens/boots regardless of what filters are selected. Filter state is managed in JavaScript only.

// Filter updates product list via fetch/XHR, URL does not change
document.getElementById('filter-color').addEventListener('change', async (e) => {
  const products = await fetch(`/api/products?category=boots&color=${e.target.value}`);
  updateProductGrid(await products.json());
  // URL is NOT updated - intentional
});

When to use:

• All filtering is purely a UX feature with no SEO intent
• You have a large number of filter dimensions and all combinations are thin
• You're building a new store and can design the architecture from scratch

Trade-offs:

• Eliminates the crawl problem entirely - no filter URLs exist
• Users cannot share filtered results via URL (major UX trade-off)
• You give up any possibility of indexing filter combinations even if some have demand

Option E: Selective Indexing for High-Value Combinations

For filters that do have real organic search demand (e.g., "Nike running shoes", "black leather boots"), allow specific combinations to be indexed while blocking the rest.

Identifying high-value combinations:

1. Export all filter combination URLs from your faceted nav log
2. Run them through a keyword research tool or Google Keyword Planner
3. Filter for combinations with >100 monthly searches
4. These are candidates for selective indexing

Implementation:

For high-value combinations, create clean URLs (not parameter-based):

/womens/boots/black/          <- "black women's boots" - indexed
/womens/boots/leather/        <- "women's leather boots" - indexed
/brands/nike/running-shoes/   <- "Nike running shoes" - indexed

For all other filter combinations, apply noindex, follow or canonical.

Optimization of selectively indexed filter pages:

• Add unique introductory copy (100-150 words specific to the filter combination)
• Ensure title tag reflects the filtered query: "Black Women's Boots | Store"
• Do NOT just show the same category page intro with different products

4. URL Parameter Handling in Google Search Console

Google Search Console has a legacy "URL Parameters" tool (available via Settings > Crawl > URL Parameters in some accounts). However, Google has discouraged its use and it does not work for all sites.

Preferred approach in 2024: use robots.txt, noindex, or canonicals as described above. Do not rely on the URL Parameters tool as a primary strategy.

Handling parameter order canonicalization

The same filter combination can appear in different parameter orders:

/boots?color=black&size=8
/boots?size=8&color=black

These are technically different URLs but render identical content. Solutions:

1. Normalize parameter order server-side before responding (alphabetical sort)
2. Apply canonical on both pages pointing to the normalized version
3. Use robots.txt or noindex to prevent both from being indexed

# Server-side parameter normalization (Python/Django example)
from urllib.parse import urlencode, urlparse, parse_qs

def normalize_url_params(url):
    parsed = urlparse(url)
    params = parse_qs(parsed.query)
    sorted_params = urlencode(sorted(params.items()), doseq=True)
    return parsed._replace(query=sorted_params).geturl()

5. Pre-rendered Filter Pages for High-Value Combinations

When a filtered combination has real search demand and enough products to justify a full page, create a pre-rendered landing page:

/womens/black-boots/      <- dedicated landing page, not a filter URL

Requirements for this to work:

• At least 12-20 products matching the combination (otherwise thin)
• Unique introductory copy written specifically for this query
• Proper breadcrumb: Home > Women's > Boots > Black Boots
• noindex on the original filter URL (/womens/boots?color=black)
• Canonical on the landing page pointing to itself

This approach is most used for high-value attribute combinations that generate clear organic traffic patterns (verified in Search Console).

6. Decision Framework

For each filter dimension, ask:
  |
  +-- Does filtering by this attribute produce queries with search volume?
  |     (e.g., "red dresses", "Nike shoes", "waterproof jackets")
  |
  |     YES -> Selective indexing (Option E) or dedicated landing pages
  |
  +-- Does Googlebot crawl these URLs frequently but never index them?
  |
  |     YES -> robots.txt Disallow (Option A) to reclaim crawl budget
  |
  +-- Do filtered pages contain internal links to products you want indexed?
  |
  |     YES -> noindex, follow (Option B) to allow PageRank flow
  |
  +-- Are you unsure and want a safe default?
  |
        YES -> Canonical to base category (Option C) + noindex, follow (Option B)

7. Common Faceted Navigation Mistakes

Product Page Optimization Reference

A complete checklist for making every product detail page (PDP) perform in organic search. Product pages target high-intent, specific queries. The goal is to match searcher intent, load fast, and earn rich snippets.

1. Title Tag

Formula

{Product Name} - {Key Differentiator} | {Brand or Store Name}

Examples:

Nike Air Max 270 - Men's Running Shoes in Black | SportStore
Victorinox Swiss Army Knife - Classic SD 58mm Red | KnifeShop
Bose QuietComfort 45 - Wireless Noise Cancelling Headphones | AudioGear

Rules

• Keep under 60 characters (Google truncates at ~600px width, roughly 60 chars)
• Include the primary product keyword near the front
• Do NOT use the same title across variants - Nike Air Max 270 Black and Nike Air Max 270 Red should have different titles
• Avoid keyword stuffing: Nike Air Max 270 Running Shoes Best Running Shoe Buy Nike is not a title, it's spam
• For variants consolidated under one URL: use the base product name without the variant attribute in the canonical URL's title

Dynamic title template (CMS / server-side)

{product.name} - {product.type} in {product.primary_color} | {store.name}
// Output: "Levi's 501 Original - Men's Jeans in Dark Blue | DenimCo"

2. Meta Description

Formula

{Action verb} the {Product Name}. {Price or deal}. {Key feature or benefit}.
{Shipping/returns info}. {CTA}

Examples:

Shop the Nike Air Max 270 for $129. Max Air heel unit for all-day comfort.
Free 2-day shipping. Easy 30-day returns.

Buy the Bose QC45 Headphones for $279. 24-hour battery life and active noise
cancellation. Ships tomorrow with free Prime delivery.

Rules

• 140-160 characters (longer gets truncated in mobile SERPs)
• Include price - it drives CTR for transactional queries
• Mention availability ("In stock", "Ships today") if it converts
• Dynamic generation: pull from product.price, product.shipping_message
• Never duplicate meta descriptions across products - even templated ones must have unique data (product name + price makes them unique)

3. Heading Structure

<h1>Nike Air Max 270</h1>          <!-- One per page, matches primary keyword -->
<h2>Product Details</h2>           <!-- Section breaks -->
<h2>Customer Reviews</h2>
<h2>You May Also Like</h2>

• H1 must be the product name, matching the URL slug and title tag keyword
• Do not use H1 for taglines or promotional copy ("Our Best Seller!")
• H2s structure the page for both users and crawlers

4. Product Description Copy

What makes a description SEO-effective

• Unique: Never copy the manufacturer's description verbatim. Every major retailer receives the same manufacturer copy - you will never rank above the brand with duplicate content.
• Specific: Include dimensions, materials, use cases, compatibility
• Natural keyword inclusion: Write for the customer; keywords appear naturally
• Minimum length: 150-300 words for mid-range products, 300-500 for high-value items
• Structured: Use short paragraphs, bullet lists for specs, numbered lists for steps

Template structure for product descriptions

[Opening paragraph - what is it and who is it for? 2-3 sentences]
[Key features list - 4-6 bullets with specifics]
[Use case paragraph - when/how would someone use this? 2-3 sentences]
[Technical specs - table or bullets]
[Social proof mention - "Rated 4.6/5 by 2,300+ customers"]

Example (good)

The Nike Air Max 270 is designed for all-day wear. The oversized Air Max unit
in the heel delivers 270 degrees of visible cushioning - the most Air Nike
has ever put in a lifestyle shoe. The lightweight mesh upper keeps feet cool
during long days on your feet.

Key features:
- Full-length Phylon midsole for lightweight cushioning
- 270-degree Max Air heel unit - tallest Air bag in Nike history
- Breathable mesh upper with molded overlays
- Rubber outsole with circular traction pattern

Ideal for: street style, casual wear, light gym use. Runs true to size.

5. Product Images

Filename and alt text

Image SEO rules

• Multiple angles: Provide at minimum: front, side, back, top, on-model (if apparel). Google Images drives significant e-commerce traffic.
• High resolution: At least 800x800px. Google requires minimum 160x90px but larger images are preferred for rich results eligibility.
• WebP format with JPEG/PNG fallback: Reduces file size without quality loss
• Serve from CDN: Images must load fast. Use width and height attributes to prevent layout shift (CLS).
• Image sitemap: Include product images in your XML sitemap or use a dedicated image sitemap for large catalogs

ImageObject schema for primary image

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Air Max 270",
  "image": {
    "@type": "ImageObject",
    "url": "https://example.com/images/nike-am270-black-front-800x800.jpg",
    "width": 800,
    "height": 800
  }
}
</script>

6. Review Integration

Reviews serve dual purposes: ranking signal (freshness, engagement) and rich snippet eligibility (star ratings in search results).

Requirements for review rich snippets

Google's requirements for review rich snippets on product pages:

• Reviews must be written by real customers (editorial reviews from staff do not qualify)
• AggregateRating schema must reflect actual ratings shown on the page
• Rating counts must be accurate - inflating rating count is a manual action risk
• Cannot show stars for reviews that are not genuinely about the specific product on the canonical URL

Schema implementation

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Air Max 270",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "bestRating": "5",
    "worstRating": "1",
    "reviewCount": "2341"
  },
  "review": [
    {
      "@type": "Review",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "author": {
        "@type": "Person",
        "name": "Sarah M."
      },
      "reviewBody": "Extremely comfortable for all-day wear. True to size.",
      "datePublished": "2024-11-15"
    }
  ]
}
</script>

UX recommendations that support SEO

• Display review count prominently near the product name (builds trust + schema signal)
• Show star distribution (1-5 star breakdown) - reduces bounce rate
• Allow filtering reviews by verified purchase, rating, recency
• Show most recent reviews first, not just "most helpful" - signals freshness to Google

7. Variant Handling

When to consolidate variants under one URL (recommended default)

Consolidate when variants differ only by color, size, material, or other minor attributes:

• /products/nike-air-max-270 with a color selector on the page
• Canonical URL: always the base product URL
• Title tag: base product name (no specific color/size)
• All variants share one Product schema block with multiple Offer items

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Air Max 270",
  "offers": [
    {
      "@type": "Offer",
      "name": "Black - Size 10",
      "sku": "NK-AM270-BLK-10",
      "availability": "https://schema.org/InStock",
      "price": "129.99",
      "priceCurrency": "USD"
    },
    {
      "@type": "Offer",
      "name": "White - Size 10",
      "sku": "NK-AM270-WHT-10",
      "availability": "https://schema.org/OutOfStock",
      "price": "129.99",
      "priceCurrency": "USD"
    }
  ]
}
</script>

When to give variants separate URLs (exception)

Give variants their own indexed URLs when:

• Each variant targets a distinct search query with meaningful volume (e.g., "red nike air max" vs "black nike air max" - check Search Console data)
• Variants are substantially different products (e.g., a hoodie vs a zip-up version)

For separate variant URLs:

• Each gets its own canonical, unique title, and unique description
• Include a <link rel="canonical"> pointing to the variant's own URL (not the parent)
• Cross-link variants via a "Also available in:" section

URL parameter handling for variants

Avoid: /products/nike-air-max-270?color=black&size=10 as the canonical URL. Prefer: /products/nike-air-max-270 with color/size passed via JavaScript state or form submission.

If you must use URL parameters for variants, use the canonical tag to consolidate:

<!-- On /products/nike-air-max-270?color=black -->
<link rel="canonical" href="https://example.com/products/nike-air-max-270">

8. Cross-selling and Related Products

SEO value of related products

Related product sections create internal links from product pages back to other product pages, distributing PageRank through the catalog and reducing dead-end pages.

Implementation rules

• Use the product name as anchor text ("Nike React Infinity Run"), not "Related Product 1"
• Link to products in the same category or complementary categories
• Include 4-8 related products - enough to be useful, not so many it dilutes the page
• Place above the fold if possible for crawl depth

Schema for related products

Use isRelatedTo on the Product schema to signal relationships:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Nike Air Max 270",
  "isRelatedTo": [
    {
      "@type": "Product",
      "name": "Nike React Infinity Run",
      "url": "https://example.com/products/nike-react-infinity-run"
    }
  ]
}
</script>

9. Product Page Technical Checklist

Before launch

• Title tag: unique, under 60 chars, includes product name
• Meta description: unique, includes price or key feature, 140-160 chars
• H1: matches product name, one per page
• Description copy: unique (not manufacturer copy), 150+ words
• Images: descriptive filenames, alt text on all images
• Product schema with Offer: valid, availability matches page state
• AggregateRating schema (if reviews displayed): review count matches page
• Canonical URL: points to itself (or base product for variants)
• Breadcrumbs: present with BreadcrumbList schema
• Internal links: at minimum 4 related products with product name anchor text
• Page speed: LCP < 2.5s on mobile (run via PageSpeed Insights)
• No duplicate title/meta across products - spot check 10 products
• Validate schema with Google's Rich Results Test

After launch

• Monitor Search Console > Enhancements > Products for schema errors
• Check Index Coverage for product pages - are they indexed within 2-3 weeks?
• Watch Crawl Stats for crawl frequency on product pages (indicates freshness signals)
• Track position for top product keywords (brand + product name queries)