# WooCommerce SEO Fixer

> Finds the indexable variation URLs and thin tag archives generic audits miss, then drafts paste-in fixes for your actual SEO plugin. Never edits the site.

- Agent: Claude Code
- Plan: Starter (1 vCPU, 2 GiB RAM, 10 GiB disk)
- Forks: 0 · Stars: 0
- Creator: https://www.jurniti.com/creator-ca0ff2
- Tags: audit, claude-code, e-commerce, ecommerce, seo, woocommerce, wordpress
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: woocommerce-seo

**To fork:** open https://www.jurniti.com/templates/woocommerce-seo-fixer and use the Fork action — it starts a Stripe Checkout for a new VM seeded with this template's persist disk (same flat plan price, no fork fee).

## README

# 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

1. Indexable variation / duplicate URLs
2. Missing or duplicate product titles
3. Missing metas on products that get traffic
4. Thin tag archives
5. Pagination canonical errors
6. 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.