Product Page SEO: Which Pages Can Actually Rank

The two guides currently ranking highest in the US for "product page seo" are both checklists of seventeen items. They tell you what to put on the page: descriptive URL, unique title, schema, alt text, breadcrumbs, reviews. Both are competent. Neither answers the question a store owner asks immediately after doing all seventeen, which is how much search traffic a product page can earn once it is perfect.

The answer is uncomfortable and worth knowing before you spend a month on it. A product page wins the queries that name the product. It rarely wins anything else, because Google usually serves category pages and buying guides for everything broader. That is not a defect in your page. It is what the result type is for.

This article covers the seventeen items, because they matter, and then covers the part the checklists leave out: the arithmetic of product-level demand, the markup Google documents as required, the variant rules that quietly duplicate your catalog, and where the rest of the demand actually lives.

What a product page can win, and what it cannot

A product page competes for three families of query, and only three.

• Named product queries: brand plus model, the SKU, the exact product name. "Vitamix A3500", "Darn Tough 1466".
• Transactional variants of those: "buy X", "X price", "X in stock", "X review" when you host reviews on the page.
• Attribute long tails that match one item: "waterproof merino hiking socks men size 13". Low volume, high intent, often zero recorded search volume in any keyword tool.

Broader queries go elsewhere. Search "hiking socks" in the US and count how many results are single product pages. In most categories the answer is zero or one, and the rest are category pages, listicles and marketplaces. Google decides the format that satisfies a query, and for a query that names a category it has decided the answer is a page with many products on it.

This is the audience check we run for customers, applied to your own catalog: before you optimize a page for a keyword, look at what kind of page is already ranking for it. If the first page of results holds no product pages, no amount of on-page work moves yours into that set. Pick the query the format can win.

Now the arithmetic. Take a store with 400 SKUs. Product-name searches for anything that is not a famous brand typically sit between 0 and 40 per month, and the majority record zero. Even at a generous average of 15, the total addressable demand across the whole catalog is 6,000 searches a month, spread across 400 pages, before you subtract the share that goes to Amazon and the manufacturer.

That number is not a reason to skip product page SEO. It is a reason to size the effort correctly: do the mechanical work once, in bulk, on all 400 pages, and spend your writing time on the twenty pages that carry the revenue. The same arithmetic decides whether the whole channel is worth it for your store.

The markup Google documents as required

Google splits product structured data into two experiences, and most stores mark up for the wrong one without noticing.

A merchant listing is for a page where the visitor can buy. A product snippet is for a page that discusses a product without selling it, like an editorial review. The distinction is not cosmetic. Google's product structured data documentation, last updated 2025-12-10 UTC, states plainly: "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."

For a merchant listing, the required properties are short:

Here is a complete merchant listing that satisfies the required set and most of the recommended one. Paste it into the page as JSON-LD, one block per product:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Merino Hiking Sock, Cushioned Crew",
  "image": ["https://example.com/img/sock-1x1.jpg"],
  "description": "Full-cushion merino crew sock, 66% merino wool, made in Vermont.",
  "sku": "DT-1466-BLK-L",
  "gtin13": "0000000000000",
  "brand": { "@type": "Brand", "name": "Example Outfitters" },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "182"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/merino-hiking-sock-cushioned-crew",
    "price": "27.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

One rule governs all of it, and breaking it is the most common reason a listing stops appearing: the markup has to match what the visitor sees. Google repeats this in its guidance on AI features, updated 2025-12-10 UTC, when it lists the ordinary practices that still apply, including ensuring "structured data matches the visible text on the page". A price of 27.00 in JSON-LD and 24.00 in the template is a defect, not an optimization.

Be honest with yourself about what this buys. Structured data is documented as what makes a page eligible for a display feature. Google does not document it as a ranking input, and treating markup as a ranking tactic is how stores end up with perfect JSON-LD and no traffic. Check your work in the Rich Results Test and then in the Merchant listings report in Search Console, which shows the errors Google actually hit on your pages rather than the ones a local validator predicts.

Variants: one product, many URLs, one canonical

Variants are where catalogs quietly duplicate themselves. A shirt in six colors and five sizes is thirty combinations, and the platform will happily give each one a URL.

Google's ecommerce URL guidance, updated 2025-12-10 UTC, accepts two shapes: a path segment such as /t-shirt/green, or a query parameter such as /t-shirt?color=green. It then gives the rule that matters. For variants identified by optional query parameters, "use the URL with the query parameter omitted as the canonical URL. This can help Google better understand the relationship between product variants."

So the canonical is the bare product URL, and the color and size parameters point back to it. That single line prevents thirty near-identical pages from competing with each other for the same product name.

The dedicated product variant documentation, updated 2026-05-20 UTC, adds the structure. Variants nest under a parent ProductGroup with three properties doing the work: hasVariant for each nested Product, variesBy for the aspects that differ, and productGroupID for what your ERP calls the parent SKU.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Merino Hiking Sock, Cushioned Crew",
  "productGroupID": "DT-1466",
  "variesBy": ["https://schema.org/color", "https://schema.org/size"],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "DT-1466-BLK-L",
      "color": "Black",
      "size": "L",
      "offers": {
        "@type": "Offer",
        "url": "https://example.com/products/merino-hiking-sock?color=black&size=l",
        "price": "27.00",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}
</script>

The single-page and multi-page cases differ, and mixing them is a real failure mode. Google states that "for single-page sites, there must be only one distinct canonical URL for the overall ProductGroup that all variants belong to", while on multi-page sites the rule does not apply and instead "each page must have full and self-contained markup for the entities defined on that page".

Read that as an instruction to your template layer. If your store preselects variants with query parameters on one page, emit one ProductGroup and keep one canonical. If each variant is a genuinely separate page, each of those pages carries complete markup of its own and does not lean on the parent.

While you are in the URLs, take the free win Google spells out in the same document: use words. It recommends /product/black-t-shirt-with-a-white-collar and advises against /product/3243, because "the words in URLs may help Google better understand the page". Most platforms do this by default, and most migrations break it.

Descriptions, and the scaled content trap

The manufacturer sends you copy. Two hundred other retailers get the same copy. You paste it, and now your page's only substantial text is a paragraph that exists on two hundred URLs, which gives a search engine nothing to prefer about yours.

The reflex in 2026 is to generate a unique description per SKU with a model and move on. That works mechanically and is a real risk editorially, because Google names the pattern directly. Its spam policies, updated 2026-08-28 UTC, define the abuse: "Scaled content abuse is when many pages are generated for the primary purpose of manipulating search rankings and not helping users. This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created."

Read the two conditions. Generated at scale is one. Providing no value is the other. The tool that produced the text is explicitly not the criterion, which is the part most commentary gets backwards. A generated description that reworks the same spec sheet into flowery prose is unoriginal content at scale. A generated description that pulls in fit notes, compatibility, and the three questions your support inbox gets about that product is a different artifact.

The same policy page opens with a definition worth noticing, because it now covers assistants: spam includes "attempting to manipulate Search systems into ranking content highly or attempting to manipulate generative AI responses in Google Search".

What to write, in order of how much it changes a buying decision:

1. What this is for and not for. The sentence that stops the wrong customer from ordering.
2. Fit, sizing, compatibility. Whatever generates your returns and your support tickets.
3. Materials and specs as a table, so the page answers attribute queries without prose padding.
4. What is in the box, which is the question every support inbox receives.
5. The comparison against your own nearest product, which no manufacturer will write for you.

That list is also the reason a 40-word description often outperforms a 400-word one. Length is not the goal, and the honest version of "how many words should a product description be" is "as many as the answer takes".

The pages around the product page do most of the ranking

Once you accept that a product page wins named-product queries, the broader demand has to land somewhere else on your store. Three page types carry it.

Category pages take the head terms. "Merino hiking socks" is a category query, and the page that satisfies it lists products with enough text to explain the choice. Most stores ship category pages with a heading and a grid, then wonder why the category ranks nowhere.

Comparison and buying guides take the deliberation queries: "merino vs synthetic hiking socks", "best socks for wide feet". These are the queries with real volume, and they are the ones that link down to product pages with an intent already formed.

Support and usage content takes the post-purchase and problem queries, which is where a surprising share of first-touch discovery happens.

Internal links tie the three together. Every product should be reachable from a category page, and every guide should link to the specific products it names. Orphan products, the ones only reachable from search or a sitemap, are the pages that never get crawled often enough to keep their price and availability fresh in the index.

This is the honest case for a store blog, and it is narrower than the one usually sold. The blog does not make your product pages rank. It captures the demand your product pages structurally cannot reach, and it hands that traffic to them. Which query families are worth writing for, and how to tell whether any of them paid, is the subject of our piece on content marketing for ecommerce. If a store is weighing content against paid acquisition, that is the comparison to make: what does each channel cost per qualified visitor, and which one keeps working after you stop paying. The cost side of that arithmetic is where most stores discover the honest answer.

Your catalog data is now read twice

Product discovery is no longer a single index. The same facts about a SKU get read by a search engine and by an assistant, through different pipes, and the failure modes differ.

On Google's side the guidance is deflationary and recent. The AI features documentation, updated 2025-12-10 UTC, states that "there are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary" and that "you don't need to create new machine readable files, AI text files, or markup to appear in these features". The concrete advice it does give for stores is to keep Merchant Center and Business Profile information current.

On the assistant side, feeds are becoming an explicit channel. OpenAI publishes a product feed specification for merchants, describing it in its own words: "Product feeds provide structured catalog data that helps ChatGPT surface the right products with accurate pricing, availability, and seller context." A store that wants to be considered there submits catalog data through that program rather than hoping a crawler infers it.

Two practical consequences follow, and neither is a new tactic.

The first is that price and availability accuracy is now a distribution problem, not a merchandising detail. A stale price in your markup or your feed is a wrong answer given confidently by a machine to a buyer, and that costs more than a missing rich result.

The second is that the language on your page is what an assistant paraphrases when it recommends a category. Whether a model names your store at all is measurable, and tracking how often assistants cite your domain is the only way to know. The mechanics of getting quoted are covered in our pieces on answer engine optimization and on what actually gets a page cited by ChatGPT, and both apply to a store exactly as they apply to a software company.

How to tell whether any of this worked

Product page SEO fails quietly. The pages exist, they look optimized, and nothing changes, because nobody separated the queries that were already yours from the ones you won.

Split the report by brand. Searches for your own store name were never in question, and they will flatter any before-and-after chart. What you want is non-brand impressions on product URLs, and the fastest way to get it is a page-and-query pull from the Search Console API:

curl -s -X POST \
  "https://searchconsole.googleapis.com/webmasters/v3/sites/https%3A%2F%2Fexample.com%2F/searchAnalytics/query" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "startDate": "2026-06-08",
    "endDate": "2026-09-06",
    "dimensions": ["page", "query"],
    "dimensionFilterGroups": [{
      "filters": [
        { "dimension": "page", "operator": "contains", "expression": "/products/" }
      ]
    }],
    "rowLimit": 25000
  }'

Then read impressions before clicks. A product page with impressions and no clicks is being shown and passed over, which is a title, price or review problem, not an indexing one. A product page with no impressions at all is a different failure: it is either not indexed or not matching any query, and no amount of copy editing fixes that. The rule that turns those two readings into a decision is in the four verdicts of a content audit.

We run this check on our own blog and publish what it says. As of this week, one of our articles sits at 448 impressions and zero clicks over 28 days in Search Console. That is a title and description to rewrite, not a second article to publish, and we have left it in the report rather than quietly fixing the number.

Two more checks close the loop. The Merchant listings report tells you whether Google parsed your markup on the pages you care about. Crawl stats tell you whether your deep product URLs are visited often enough for a price change to reach the index within a day, which is the whole point of the availability field.

Set expectations before you start. No one can guarantee a position for a product page, and results vary with your category, your domain, and who else sells the same item. What you can control is whether the page is eligible, correct, and reachable.

An order of operations for a store with no SEO team

If you have 500 SKUs and a few hours a week, run it in this sequence. The first three steps are template work that applies to the whole catalog at once, which is why they come first.

1. Fix the template, not the pages. One JSON-LD block, generated from the same data that renders the page, so markup and visible text cannot drift.
2. Settle the variant rule. Decide path segments or query parameters, set the canonical to the parameter-free URL, and emit one ProductGroup per parent.
3. Check internal reachability. Every product linked from a category page, breadcrumbs on every product, no orphans.
4. Rank your SKUs by revenue and take the top twenty. Those get written descriptions, real photography, and the comparison against your nearest alternative.
5. Write the three guides your category actually gets asked about, and link them down to those twenty products.
6. Instrument it. Non-brand impressions by product URL, monthly, and the Merchant listings report after every template deploy.
7. Leave the tail alone. The other 480 pages get correct markup, correct titles, and no hand-written prose, because the demand does not justify it.

Steps 4 and 5 are the ones that need a person and never get done, which is exactly the gap a publishing pipeline is supposed to close once the mechanics are correct. The mechanics come first: an automated content program pointed at a store with broken canonicals produces more pages competing with each other, faster.

FAQ

Do product pages need blog content to rank?

Not to rank for their own product names. A well-marked product page with a distinct description can win queries that name the item without a single blog post existing. Content matters for the demand a product page cannot reach: category-level queries, comparisons, and the problem-shaped searches people run before they know which product they want. Those are also the queries with the volume, which is why stores that only optimize product pages tend to plateau at their brand traffic.

Should each product variant have its own URL?

Google accepts both a path segment such as /t-shirt/green and a query parameter such as /t-shirt?color=green. If you use optional query parameters, its ecommerce URL guidance says to use the URL with the parameter omitted as the canonical. The mistake to avoid is thirty variant URLs each declaring itself canonical, because they then compete for the same product name and split whatever signals the product has earned.

Can I use the manufacturer's product description?

You can, and you will share it with every other retailer selling the item. There is no penalty aimed at that specifically, but there is also no reason for a search engine to prefer your copy of a paragraph it has indexed two hundred times. The workable middle is to keep the manufacturer's spec table and add what only you know: fit notes, compatibility, what the returns tell you, and how it compares to the nearest product in your own catalog.

Does product schema make you rank higher?

Google documents structured data as what makes a page eligible for a display feature, not as a ranking input. What it changes is how the result looks in the SERP, which affects clicks rather than position, and whether your data can be used in shopping experiences at all. The requirement that costs stores their listings is the boring one: the markup has to match the visible page, and prices drift when the two are generated from different sources.

Can ChatGPT recommend my products?

Assistants can name products they can find and verify. OpenAI publishes a product feed specification for merchants, describing feeds as structured catalog data that helps ChatGPT surface products with accurate pricing, availability and seller context, so a store that wants to be in that pipeline submits its catalog rather than waiting to be crawled. On Google's side, its AI features documentation says there are no additional requirements or special markup needed to appear in AI Overviews or AI Mode, and points stores at keeping Merchant Center current. Measuring whether any of it worked is a separate discipline, covered in our piece on LLM SEO.

How do I know if my product pages are indexed at all?

Use the page-level view in Search Console rather than a site: search, which is a rough sample and not a report. Filter to your product URL prefix and compare the number of pages with impressions to the number of products in your catalog. A large gap usually means orphan pages, a sitemap that omits products, or variant URLs eating the crawl budget that should reach the parents. That last case is the one to check first on a store with heavy filtering, and the fix is the canonical rule above, not more content.