One Page or Five? A Variant & Schema-Parity Audit
Objective: Given a frame family's five color-variant URLs and its live schema, diagnose which variant strategy is actually running, whether it's complete, and whether the schema still matches what the page visibly shows.
Warby Parker's "Percey" frame ships in five colors, each with its own URL. You're auditing this one frame family before a catalog-wide rollout, checking both the variant-URL structure and whether the live schema still matches the page when stock changes.
Two checks: crawl the five color URLs to see which of the lesson's two variant strategies is actually in play, then compare a sold-out variant's visible page state against its JSON-LD Offer block.
Is this frame family's five-color variant setup a deliberate, complete strategy, or an unfinished one leaking duplicate content and stale schema?
Before you start
What you'll need
- —Basic familiarity with crawling a site in Screaming Frog and reading Title/Canonical columns
- —Understanding of what JSON-LD structured data is used for on a product page
- Canonical Tag
- an HTML tag that tells search engines which URL is the preferred version among near-duplicate pages, so authority isn't split between them.
- JSON-LD Offer Block
- the structured-data snippet on a product page that tells Google the price and stock availability, which Google uses to power rich results like star ratings and stock badges in search.
Free path (everything below is enough to finish)
Free tier comfortably covers a single frame family's variant set in one crawl.
Free, and the only way to see exactly what Google's own renderer reads from the live page's schema.
Paid upgrades (optional, faster/deeper)
Both checks in this audit are fully completable free, a five-URL crawl and one URL Inspection lookup cost nothing.
The free path (Screaming Frog plus GSC) is complete for auditing one frame family; Ahrefs earns its cost once checking hundreds of product families at once.
The process
2 steps
Step 01 of 02
The lesson names two deliberate variant strategies, a single URL with a variant selector, or separate indexable pages per variant with unique SKUs and genuinely different descriptions and images, and says whichever one you skip should canonicalize back to the version you want indexed.
The Percey frame has five color URLs, each with an identical title, description, and images except a swapped color word, and none of the five carries a canonical tag. Which of the lesson's two strategies is actually running here, and what's missing to make it work?
Procedure
- List all five color URLs for the Percey frame
- Crawl them and export Title, H1, Meta Description, and Canonical for each
- Confirm whether the title/description text differs meaningfully between colors or is identical apart from the color word
- Check the Canonical column for whether any of the five points at a single preferred version
Percey frame, 5 color-variant URLs ---------------------------------- /percey-eyeglasses-crystal Title: "Percey - Crystal | Warby Parker" Canonical: none /percey-eyeglasses-jet-black Title: "Percey - Jet Black | Warby Parker" Canonical: none /percey-eyeglasses-cognac Title: "Percey - Cognac | Warby Parker" Canonical: none /percey-eyeglasses-eastern-bluebird Title: "Percey - Eastern Bluebird | Warby Parker" Canonical: none /percey-eyeglasses-rye-tortoise Title: "Percey - Rye Tortoise | Warby Parker" Canonical: none Body description: identical 140-word paragraph on all 5 URLs apart from the color name.
Healthy
Either all five are consolidated onto one URL with a color-swatch selector, or all five carry unique SKUs, genuinely different descriptions, and a canonical pointing at whichever is the primary indexable version.
Unhealthy
Five separate, indexable URLs with only a swapped color word and zero canonical tags, splitting whatever authority and reviews the frame has earned across five competing near-duplicates.
What this means
This is the lesson's "separate indexable pages per variant" strategy running without its required conditions: no unique descriptions, no canonical fallback. It's not that separate pages are wrong here, it's that they were never finished.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| Five color URLs compete for the same query with near-identical content and no canonical | Either write genuinely distinct copy per color and add self-referential canonicals, or consolidate to one URL with a color selector | dev ticket |
Step 02 of 02
The lesson's rule that trips people up most: schema and the visible page must match. If the page shows out of stock but the schema still says InStock, Google treats that as misleading structured data and can strip the rich result sitewide, not just on that one page.
The live page for the Percey frame in Rye Tortoise shows an "Out of Stock" banner to visitors, but its JSON-LD Offer block still reads availability: InStock. What does the lesson say happens if this ships as-is?
Procedure
- Open the Rye Tortoise URL in a browser and confirm the visible "Out of Stock" banner
- Run the same URL through URL Inspection's Test Live URL
- Compare the schema's availability value against the visible page state
- Flag the mismatch and identify the correct availability value to ship
Live page (visible to shoppers): "Out of Stock" banner shown, no Add to Cart button. JSON-LD Offer block (from URL Inspection): "availability": "https://schema.org/InStock" MISMATCH: schema claims InStock, page visibly shows Out of Stock.
Healthy
The schema's availability value updates automatically from the same inventory feed that drives the visible stock badge, so the two can never drift apart.
Unhealthy
The visible stock badge is hand-edited by a merchandiser while the schema is generated once at page-template build time, letting the two silently disagree the moment stock changes.
What this means
This isn't a cosmetic mismatch, the lesson is explicit that Google can strip rich-result eligibility across the entire site, not just this one URL, once it detects structured data that misrepresents what's visibly on the page.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| The Rye Tortoise variant's schema says InStock while the page shows Out of Stock | Automate schema generation from the same inventory feed driving the visible stock badge, don't hand-maintain the two separately | dev ticket |
Analyze your findings
What to look for
- Copy uniqueness
- Is the description genuinely different per variant, or just the color word swapped inside an identical paragraph?
- Canonical presence
- Does any of the near-duplicate URLs point to a single preferred version, or is the field empty on all of them?
- Schema-to-page match
- Does the JSON-LD availability value match what a shopper actually sees rendered on the page right now?
- Update source
- Is the schema generated from the same live inventory feed as the visible stock badge, or built once and left stale?
Make the call
The five Percey color URLs share identical copy apart from the color word, carry no canonical tags, and the Rye Tortoise variant's schema says InStock while the page visibly shows Out of Stock. What's the correct fix to recommend?
Recommendation · Priority: High
“Formally adopt one variant strategy for the Percey frame family: either write genuinely distinct copy per color with self-referential canonicals, or consolidate to a single URL with a color-swatch selector. In parallel, automate the JSON-LD availability field from the same inventory feed that drives the visible stock badge so schema and page state can never disagree, this is the fix that prevents the sitewide rich-result risk the lesson warns about, not a one-time correction to the Rye Tortoise listing.”
Common mistakes
What trips people up
Treating five near-identical URLs as automatically fine because each has a unique color name — a swapped color word inside an otherwise identical paragraph is not meaningfully different content; the lesson requires genuinely different descriptions and images for the separate-pages strategy to work.
Fixing only the visible mismatch and not the pipeline that created it — correcting the Rye Tortoise schema value by hand solves today's problem but leaves the same drift ready to happen on the next stock change.
Assuming a schema mismatch is a minor, page-level issue — the lesson is explicit that Google can strip rich-result eligibility sitewide, not just on the one offending URL, once it detects a pattern of misleading structured data.
Final deliverable
An audit memo naming which variant strategy to formally adopt for the Percey frame family, the specific canonical fix needed, and a corrected schema availability value that matches the live page.
See a reference example
The same two-check audit applied to a Lenskart eyewear frame family (illustrative): five color URLs shared identical copy with no canonical, the same defect pattern, resolved by consolidating to one URL with a color swatch selector rather than writing five unique descriptions. A separate sold-out shade's schema still read InStock three days after the frame sold out, traced to a schema cache that wasn't invalidated on stock change.
Success criteria
You're done when you can:
- Correctly identified the five color URLs as running an incomplete 'separate indexable pages' strategy, not simply calling it 'duplicate content'
- Named a specific fix (unique copy plus canonicals, or consolidation to one URL) rather than a vague 'fix the duplication'
- Caught the InStock-vs-Out-of-Stock schema mismatch as a critical, sitewide-risk defect, not a minor one
- Proposed automating schema generation from the inventory feed as the actual fix, not a one-time manual correction
Key takeaway
A variant family and its schema can look fine at a glance while hiding two unrelated but equally serious defects: incomplete duplicate-content handling and stale structured data. Checking both, side-by-side crawl comparison and a live schema-versus-page check, catches problems a single-angle audit would miss.