Product page SEO is the work of making an individual product page clear, accessible, technically eligible and accurate for both shoppers and search engines.
Meaning and scope
A product page should first answer a shopper's real questions: what the item is, which variant is shown, its relevant specifications, current availability and how to proceed. Search optimisation cannot replace missing or misleading product information. Avoid invented word-count minimums: the right amount of copy depends on the product and what a buyer needs to decide.
Practical workflow
Create one preferred URL per product or well-defined variant. Supply a unique, descriptive title and visible product facts; write meaningful alt text for informative images; and prevent filters, sort orders or tracking parameters from becoming accidental competing pages. Product structured data must match visible facts, especially price, availability and identifiers where they are provided.
What to inspect
Inspect a sample from each product template and variation state. Compare rendered title, main content, image alt text, canonical URL, availability display and Product structured data. Validate markup syntax, then verify that the graph describes the visible page rather than a stale feed or a default value. Keep a distinction between a validation pass and eligibility for any particular search feature.
Limits and common mistakes
Do not use reviews, ratings, price or stock markup unless the corresponding information is visible and current. Do not consolidate different products to one canonical page for convenience. A maintainable product page relies on a reliable catalogue data model before SEO enhancements.
Product data and page-state checks
A product page often changes by variant, stock state and market. Test the state a user can actually select, not only a default preview. For each representative product, record the canonical URL, selected variant, visible name, price if displayed, availability wording, identifier if present, primary image and any structured data fields. The public page and structured data should describe the same current offer, not a stale feed or a generic template default.
{ "@type": "Product", "name": "Example product", "offers": { "@type": "Offer", "availability": "https://schema.org/InStock" } }Inspect image treatment separately. Informative product images need useful alternative text that identifies what the image conveys; decorative controls need an empty alt. Multiple variants should not all reuse a vague filename-like description. Verify that image requests are public, resolve successfully and do not depend on a signed session URL that a crawler or a shopper cannot use.
A worked release check compares one in-stock product, one out-of-stock product, one variant product and one discontinued route. The pages need distinct intended behavior: a truthful availability state, a relevant replacement or retirement policy, and no accidental duplicate canonicalisation. This catches issues that a single valid product markup example cannot reveal.
Google's Product structured-data guidance defines supported properties and eligibility conditions, but a valid graph does not guarantee a rich result. Do not claim ratings, reviews or shipping facts the page cannot substantiate. Keep catalogue data as the source of truth and let templates render it consistently rather than manually patching individual product pages.
Track changes where they originate. If availability comes from inventory, price from a feed and title from catalogue data, record each source and refresh rule. This lets a team diagnose a mismatch without editing markup by hand. After an update, compare the rendered product page, its structured graph and the selected variant in the same session.