Search Engine Optimisation
WooCommerce SEO
The opposite problem to Shopify. WooCommerce gives you complete control, and complete control is how stores end up with 60,000 indexable URLs and 400 products.
WooCommerce SEO tames what WordPress and WooCommerce generate automatically: product tag archives, attribute pages, and thousands of filtered URLs nobody asked for. The Nexclick decides what should be indexed, fixes the rest, and addresses the speed problems a plugin-heavy store accumulates.
Is this you?
What usually prompts the call
- Search Console reports tens of thousands of URLs and you have a few hundred products.
- Your store slows noticeably as the catalogue and the order table grow.
- Product tag and attribute archives are indexed and none of them rank for anything.
- You have four SEO and caching plugins and no idea which one is generating what.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Index bloat audit
- Product tags, attributes, filtered URLs, paginated archives and search results, quantified against your actual product count. The gap is usually startling and it is where the crawl budget is going.
- Archive indexing decisions
- WooCommerce generates archives for every tag and attribute by default. Most deserve noindex; a few with genuine search demand deserve to be treated as categories.
- Plugin conflict resolution
- Multiple SEO plugins emitting competing canonicals and schema, caching plugins fighting each other. Resolving this often fixes several apparently unrelated symptoms at once.
- Database and query performance
- WooCommerce stores slow down through post meta bloat and unindexed queries as much as through front-end weight. Both are addressed, because only fixing images gets you nowhere.
- Category content and structure
- Categories carry the commercial volume and are usually an unadorned product grid. Content added above the fold rather than dumped beneath it.
- Product schema at template level
- Implemented in the theme rather than relying on whichever plugin currently claims to handle it, with price and availability kept accurate.
- Out-of-stock and discontinued policy
- A written rule for what happens to a product page when the line ends, applied consistently instead of decided case by case by whoever is in the admin.
Comparison
What WooCommerce generates, and what to do with it
WooCommerce and WordPress create these URL types automatically, and most stores never make a decision about any of them. This is the decision, made once, applied everywhere.
| URL type | Default | Recommended | Why |
|---|---|---|---|
| Product page | Indexed | Index | The page that converts |
| Product category archive | Indexed | Index | Carries the commercial search volume |
| Product tag archive | Indexed | noindex, follow | Near-duplicate of categories, almost never searched |
| Attribute archive (size, colour) | Indexed | noindex, follow | Thousands of thin pages, no demand |
| Attribute with real demand ("waterproof") | Indexed | Index, treat as category | Genuine search volume — the exception worth making |
| Filtered / faceted URLs | Indexed | Canonical to parent | Combinatorial explosion of near-duplicates |
| Paginated category pages | Indexed | Index, self-canonical | Products must stay discoverable |
| Internal search results (?s=) | Indexed | noindex, follow | Infinite low-quality URLs; classic crawl sink |
| Author archives | Indexed | noindex or disable | Rarely relevant on a store |
| Date archives | Indexed | Disable | Meaningless for products |
| Cart, checkout, my account | Indexed | noindex | No search value; a privacy risk if indexed |
| Media attachment pages | Indexed | Redirect to parent | One thin page per uploaded image |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Crawl and quantify bloat
Full crawl plus index coverage. The URL count against product count comparison usually diagnoses the store in an afternoon.
- 02Week 2–5
Fix indexing and conflicts
Archive directives, canonical conflicts, plugin overlap. Changes staged and tested, because WooCommerce plugin interactions are unpredictable.
- 03Week 4–8
Performance work
Database, caching, image handling and theme weight. Measured on field data rather than a lab score.
- 04Month 3 onwards
Content and schema rollout
Category content and product improvements, prioritised by revenue rather than by catalogue order.
What you get
Reporting and ownership
- An indexing policy document setting out exactly which URL types are indexable and why.
- A plugin audit naming what to remove, what to replace and what each is costing in performance.
- Before-and-after index coverage and field performance data.
- A written out-of-stock and discontinued policy your team applies without asking.
- Category-level organic revenue reporting rather than store-wide sessions.
Tools and platforms
- Screaming Frog
- Google Search Console
- Query Monitor (WordPress)
- WP-CLI
- Ahrefs or Semrush
- PageSpeed Insights & CrUX
- Schema.org validator
Timeline
How long this actually takes
Index bloat fixes show in coverage reports within two to six weeks, and shrinking the index is the goal — expect indexed URL counts to fall substantially, which looks alarming and is the intended result. Performance work takes four to eight weeks and needs the 28-day field data window before it can be verified. Category content matures over three to six months. One honest constraint: some WooCommerce performance problems are hosting problems, and no amount of plugin configuration fixes shared hosting under load. Where that is the diagnosis, we will say so rather than billing optimisation work that cannot succeed.
Pricing model
Project, then retainer
A fixed-price technical and indexing project first, since that is where the gains are, then an optional retainer for content and ongoing work.
Questions
WooCommerce SEO questions
Why does our indexed URL count keep growing?
Because WooCommerce generates archives for every tag, attribute and filter combination by default, and a store with 400 products across a dozen attributes produces tens of thousands of combinations. Nothing has gone wrong — nobody has made a decision about what should be indexable.
Which SEO plugin should we use?
Any of the major ones does the job. What matters far more is that you use one, not three. Multiple SEO plugins emit conflicting canonicals and duplicate schema, and that conflict causes more damage than the choice between them ever will.
Is WooCommerce slower than Shopify?
It can be, and it is not inherent. Shopify manages hosting and enforces constraints; WooCommerce lets you install thirty plugins on shared hosting. A lean WooCommerce store on decent hosting is fast. The freedom is genuine and so is the responsibility.
Should we disable product tags entirely?
Usually keep them for internal navigation and noindex the archives. Deleting the tags themselves loses internal linking structure that is genuinely useful. The archives are the problem, not the taxonomy.
Our store slows down as orders accumulate. Is that an SEO issue?
It becomes one, because server response time feeds directly into Core Web Vitals. It is usually post meta bloat and unindexed database queries rather than anything on the front end, which is why front-end-only optimisation stops working on older stores.
How many plugins is too many?
It depends entirely on what they do rather than how many there are. One badly written plugin querying the database on every page load costs more than twenty well-behaved ones. The measurable test is profiling queries and load time with each disabled, which is part of the audit.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.