Schema Markup for E-commerce Category Pages (ItemList Pattern)

Last updated: April 2026 8 min read

Why category pages matter
Itemlist schema basics
Enriched listitem with product
Pagination handling
Combining with breadcrumb
Avoiding cannibalization
Frequently Asked Questions

E-commerce sites obsess over Product schema for individual product pages and forget about category pages entirely. But category pages drive a huge share of e-commerce traffic — searches like "best running shoes" or "leather wallets under $100" land on collection pages, not product pages. The right schema for these is ItemList. Most stores skip it, which is exactly why adding it is high-leverage.

Why Category Pages Are an SEO Goldmine

Category pages tend to rank for higher-volume, broader keywords than individual product pages. "Running shoes" gets 100x the search volume of "Nike Air Pegasus 41 men's size 10." Category pages are the front line for these head terms.

The challenge: most category pages are thin from a content perspective — just a grid of products with minimal text. Without schema, Google has very little structured signal to work with. Adding ItemList schema gives Google a clear understanding of what the page contains and which products it features.

Stores that mark up category pages tend to see better performance for category-level searches because Google can accurately interpret the page as a curated list rather than a generic landing page.

ItemList Schema Basics

ItemList is a simple schema type that represents an ordered list of items. For e-commerce categories, each item is a product. The basic structure:

{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "Men's Running Shoes",
  "url": "https://yourstore.com/category/mens-running-shoes/",
  "numberOfItems": 24,
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "url": "https://yourstore.com/products/nike-pegasus-41/",
      "name": "Nike Pegasus 41"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "url": "https://yourstore.com/products/asics-novablast-4/",
      "name": "ASICS Novablast 4"
    }
  ]
}

Each ListItem has a position (the order it appears on the page), URL, and name. That's the minimum. Google parses this as a structured list of products on the category page.

Enriched ListItem With Embedded Product Data

You can go further by embedding Product data directly in each ListItem. This is more verbose but gives Google more structured signal:

"itemListElement": [
  {
    "@type": "ListItem",
    "position": 1,
    "item": {
      "@type": "Product",
      "url": "https://yourstore.com/products/nike-pegasus-41/",
      "name": "Nike Pegasus 41",
      "image": "https://yourstore.com/images/pegasus-41.jpg",
      "offers": {
        "@type": "Offer",
        "price": "129.99",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock"
      }
    }
  }
]

The "item" field nests a full Product object inside the ListItem. Google can use this to show prices, availability, and images in some rich result formats.

Tradeoff: more verbose, harder to maintain. For most category pages, the simple version (URL and name only) is enough. Use the enriched version when you want maximum structured signal for high-priority categories.

Handling Paginated Category Pages

Most category pages are paginated — page 1 shows products 1-24, page 2 shows 25-48, etc. The schema should reflect what's actually on each page, not the entire category.

Best practice:

Page 1: ItemList with itemListElement for products 1-24
Page 2: ItemList with itemListElement for products 25-48 (positions 25-48, not 1-24)
numberOfItems on every page should reflect the TOTAL category count, not the page count

The position field is critical for paginated pages — it should be the global position in the category, not the position on the current page. Page 2's first product is position 25, not position 1.

For SEO, also use rel="next" and rel="prev" link tags to signal pagination to Google. Schema and rel tags work together.

Combining ItemList With BreadcrumbList

Category pages should have BOTH ItemList (for the products) AND BreadcrumbList (for the navigation hierarchy). They serve different purposes:

ItemList tells Google what products are on the page
BreadcrumbList tells Google where the page sits in your site hierarchy

Both can coexist on the same page. Add them as separate script tags or combine them in a single script with @graph:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "ItemList",
      "name": "Men's Running Shoes",
      "itemListElement": [...]
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        {"@type": "ListItem", "position": 1, "name": "Home", "item": "https://yourstore.com"},
        {"@type": "ListItem", "position": 2, "name": "Men", "item": "https://yourstore.com/men/"},
        {"@type": "ListItem", "position": 3, "name": "Shoes", "item": "https://yourstore.com/men/shoes/"},
        {"@type": "ListItem", "position": 4, "name": "Running", "item": "https://yourstore.com/men/shoes/running/"}
      ]
    }
  ]
}

The @graph pattern is cleaner because it ties both schemas together as belonging to the same page. Google parses each entry independently.

Avoiding Cannibalization With Product Pages

Risk: if both your category page and individual product pages target similar keywords, they cannibalize each other. The fix is keyword differentiation, not schema differentiation:

Category page targets: "running shoes," "men's running shoes," "best running shoes 2026" (head terms)
Product page targets: "Nike Pegasus 41 review," "Pegasus 41 men's size 10" (long tail with product names)

Schema reinforces this — ItemList signals to Google "this page is a list of products in a category" while Product schema signals "this page is about one specific product." Google uses the schema type to disambiguate intent.

For more on schema validation, see our validator workflow guide.

Try It Free — No Signup Required

Runs 100% in your browser. No data is collected, stored, or sent anywhere.

Open Free Schema Markup Generator

Frequently Asked Questions

Do category pages need schema markup?

Yes. Most stores skip them, which is exactly why adding ItemList schema is high-leverage. Category pages drive head-term traffic ("running shoes" vs "Nike Pegasus 41"), and schema helps Google understand the page as a curated product list.

Should I use ItemList or CollectionPage schema?

ItemList for the products listed on the page. CollectionPage is a more generic page-type schema that doesn't structure the items themselves. Use both if you want — CollectionPage as the outer wrapper, ItemList for the actual product listings.

How do I handle pagination in ItemList?

Use the position field for global product position (not page-relative). Page 2 starts at position 25 if page 1 had 24 products. The numberOfItems field should reflect the total category count across all pages, not just the current page.

Can I include all 200 products on a category page in the schema?

Technically yes, but only include what's actually visible on the current page (typically 24-48 products). Schema should match visible content. For very large categories, use pagination with separate ItemList per page.

Will ItemList schema show products in search results?

Sometimes. Google can use ItemList for visual list-style rich results, but the schema is more often used as a structural signal that helps the category page rank rather than triggering a specific rich result format.

Should I add Product schema to each product on the category page too?

Either embed Product data inside ListItem (the enriched version) or rely on the actual product page's Product schema. Don't duplicate Product schema standalone on the category page — that creates conflicts. ListItem with optional embedded Product is the clean pattern.