About this template
Forty variation URLs competing with your own product pages
Your generic SEO tool told you about title lengths. It said nothing about the
indexable ?attribute_size=large URLs Woo generates, or the thirty tag archives
holding one product each.
Those are what's actually eating your crawl budget.
The traps generic audits miss
- Product variations generate URLs. Variation query URLs can get crawled and indexed as near-duplicates of the parent. Every indexable one that isn't canonicalised to the parent gets flagged — and this section is usually the largest single source of duplicate-content pressure on a Woo store.
- Categories and tags both generate archives. Most stores use tags carelessly, producing thin archives with one product. Anything under 3 products is flagged.
- Shop pagination needs self-referencing canonicals. A
/page/2/archive canonicalised to page 1 drops everything on page 2+ out of the index. - Short description is often your meta description. An empty excerpt is a common cause of missing metas, and nothing in the editor says so.
It identifies your SEO plugin first
Yoast, RankMath and AIOSEO each own the <title> — and each put the editable
field on a different screen. So it reads the HTML to work out which one you run,
then names the actual field to paste into.
If it can't tell, it says UNKNOWN_PLUGIN and names the generic field rather than
guessing and sending you to the wrong screen.
Report order is leverage, not alphabet
- Indexable variation / duplicate URLs
- Missing or duplicate product titles
- Missing metas on products that get traffic
- Thin tag archives
- Pagination canonical errors
- Missing image alt text
Sitemap discovery tries core wp-sitemap.xml, then Yoast's sitemap_index.xml,
then RankMath's — and records which one answered.
What you supply
Your own Claude Code login. That's it — no WordPress credential exists by design; the public sitemap and pages are the whole input.
Optionally paste a Search Console export into ~/woo/pages/ and "products that
get traffic" stops being an assumption.
The guard is a file, not a promise
~/woo/policy/WOO-RULES.md carries NEVER_AUTOEDIT, the platform traps and the
fix ordering. The skill reads it before every audit.
Where this stops
It reads your public storefront and drafts fixes. No WordPress login, no REST credentials, can't publish.
It won't predict rankings without Search Console data, and it won't tell you which plugin setting to change if it couldn't identify the plugin.
Verified on build: the skill, the working tree, the NEVER_AUTOEDIT guard, both
platform traps and the unknown-plugin rule are present on a fresh fork. Running it
on your own store is yours to do.