One page, one buyer
We separate retail, trade and spare-part intent, then give the primary page one clear job and a secondary block for the other audience. No page tries to be a catalogue.
WebSEOGrow / Product Sheet
Technical spec · rev 04
Figure 1 · page anatomy4 of 12 views
One page, one job
Product Page SEO
Product page SEO is decision design. The page has eight seconds to convince a stranger that this exact item solves their exact problem, and a much shorter window to convince a crawler that it is the definitive description of that item. Most pages fail the second test quietly, then wonder why the first never happens.
- Titles and H1s built from buyer language, not ERP codes
- Specifications written as text, with units and tolerances
- Variant logic and canonicals that consolidate rather than split
- Review, offer and FAQ structured data that validates
- Internal links that move authority from category to SKU
- Works on
- Shopify, WooCommerce, Magento, custom stacks, marketplace listings
- Starts with
- A free review of three live product URLs
- Output
- Templates, copy, schema and a prioritised SKU queue
Specification
What each block on the page has to do
Think of the page as a specification sheet for a buying decision. Every block either answers a question the buyer came with or gives the crawler a fact it can use. If a block does neither, it is decoration, and decoration does not rank.
| Block | What search reads | What the buyer needs | Frequent failure |
|---|---|---|---|
| Title tag | Query order, intent match, brand placement | The exact item, size and material, fast | Internal SKU codes and no dimensions |
| H1 | Confirmation that the page matches the query | Reassurance they landed in the right place | A duplicate of the title with stuffed keywords |
| Specification table | Units, materials, tolerances, compatibility | Whether it fits their application | Specs only inside a PDF or a photo |
| Variant selector | Distinct URLs and the canonical relationship | Whether their size, finish or pack exists | Every variant self-canonical, all competing |
| Review block | Aggregate rating, review text, markup validity | Evidence the item works in real use | An app widget with no structured data |
| Image set | Descriptive alt text and file naming | Scale, detail, packaging, in-use context | IMG_2231.jpg and white-background-only shots |
| FAQ | Question and answer pairs eligible for markup | Shipping, MOQ, warranty, returns | Answers buried in a support page elsewhere |
| Internal links | Breadcrumb path and related item context | Alternatives and accessories that fit | Orphaned SKUs reachable only by search |
01 GalleryLead image, scale shot, detail, packaging.
02 TitleItem, differentiator, size, pack.
03 SpecsUnits, tolerance, compatibility, files.
04 ReviewsReal ratings, marked up correctly.
05 FAQDelivery, MOQ, warranty, returns.
Diagnosis
Why product pages collect visits and lose orders
The most common cause is not a technical bug. It is that one page tries to serve three different buyers at once: the retail shopper, the trade buyer ordering in volume, and the person hunting a spare part for a ten-year-old unit. Each wants a different headline, a different specification emphasis and a different next step. Blended together, the page answers none of them well.
Underneath that, small failures compound. Variants multiply into twelve near-identical URLs, each declared canonical to itself, so the search engine picks one at random and the reviews scatter across all of them. Specifications live in a downloadable PDF, which means neither the index nor a phone screen can show the one number that decides the sale. Reviews arrive through a third-party widget with no markup, so the stars never appear in a result and the click-through rate suffers.
Then the page sits alone. Nothing links to it except the sitemap, the category page lists it as one of sixty identical tiles, and the buying guide that could send qualified traffic never mentions it. A product page that cannot be reached by a link is a page that cannot build authority, however good the copy is.
Deliverables
01 · Intent
02 · Naming
03 · Facts
04 · Structure
05 · Proof
06 · Reach
Six changes that move a SKU
Each item below is scoped per template or per SKU band, so you can start with the products that carry the most margin instead of waiting for a full catalogue rewrite.
Title and H1 architecture
Item type first, then the differentiator, then size and pack. Buyer words replace internal codes, and the H1 confirms rather than repeats, so the page reads like a specification, not a keyword list.
Specifications as text
Dimensions, materials, tolerances, standards, compatibility and lead time converted into a real table with units. Downloads stay, but they stop being the only place the data exists.
Variant and canonical logic
One indexable parent per product family, variant URLs handled deliberately, and unique copy on the variants that genuinely differ. Reviews consolidate onto the parent instead of splitting.
Reviews and structured data
Product, Offer, AggregateRating and FAQ markup that validates in the testing tools, applied only to genuine reviews. Ratings shown on the page match the markup, which is where most sites get caught.
Images and internal links
Alt text that describes the item and its context, an image order that answers objections, plus breadcrumbs, related items and buying-guide links from pages that already have authority.
Method
From a thousand SKUs to a working queue
Triage
Every SKU scored on impressions, revenue, margin, review count and competitive density. The top twenty per cent becomes the first release, because that is where a template change pays for itself fastest.
Intent split
Search results and sales conversations are read side by side to identify who the page is really for. Where two audiences collide, the secondary one is moved to a dedicated page rather than squeezed in.
Template rebuild
The product template is rebuilt once with the new title pattern, specification block, review module and FAQ slot, then tested on the first cohort before it goes catalogue-wide.
Variant consolidation
Canonicals, sitemap entries and internal links are aligned so each family presents one clear page. Redirects and parameter handling are checked against the crawl data, not assumed.
Iteration
Ninety days of impressions, add-to-cart and enquiry data decide which blocks stay. Weak FAQ entries are replaced, not padded, and the next SKU cohort enters the queue.
The template work sits inside On-Page SEO Services, and catalogue-level problems such as facet URLs and category duplication are handled under Ecommerce SEO Services so a single fix does not break the other.
Evidence
Three programmes, rounded
Anonymised at client request. These are outcomes from work we ran, not a projection for your catalogue.
A fastener supplier, 6 months: organic inquiries 5→23/mo, led by specification pages.
Template rebuildA furniture brand, 5 months: product page conversion 0.9%→2.2% after image and FAQ work.
Conversion layerA lighting manufacturer, 4 months: 1,240 variant URLs consolidated to 180 canonicals.
Variant clean-up
Scope
How a product page engagement is quoted
Scope, not a rate card. The number depends on how many templates you have, how many SKUs enter the first release, whether we write the copy or brief your team, and whether engineering support is needed for schema and variant logic. A typical engagement starts with a paid sample of ten pages, so you can see the writing and the markup before committing to a catalogue.
Platform work is quoted separately when it involves theme code, app configuration or feed changes. Everything is listed in a written scope before the first invoice, and the SKU queue is yours to reorder.
Questions
Asked before every catalogue project
01
How long until a product page ranks?
For an existing page with some history, title, specification and link changes usually show within four to eight weeks. A brand-new SKU in a competitive category needs a quarter or more, and often a buying guide or comparison page pointing at it.
02
Can you handle thousands of SKUs?
Yes, but not by writing every page by hand. We build the template, the title and description patterns, and the specification schema once, then apply them in cohorts. Hand-written copy is reserved for the high-margin and high-traffic items.
03
Do you need access to our CMS?
Editor access helps, but a staging copy plus a developer contact is enough to start. If we cannot touch the theme, we deliver specifications and copy in a structured sheet your team can implement.
04
How should variants be handled?
One indexable parent per family, with variants either consolidated or given genuinely different copy where the use case differs. The rule is simple: if two URLs answer the same query with the same words, one of them should not be indexed.
05
Is review markup risky?
Only when it is inaccurate. We mark up reviews that exist on the page, keep the rating consistent with what is displayed, and avoid self-serving review markup on organisation pages. Invalid markup is worse than none.
06
What do you measure?
Impressions and clicks on the SKU set, add-to-cart and enquiry rate, revenue per session, and the share of the catalogue with complete specifications. Rankings are a diagnostic; conversion is the outcome.
Next step
Send three product URLs
We will return a marked-up page, the three highest-impact changes, and the title and specification pattern we would use.