WooCommerce SEO Services

WooCommerce generates more URLs than any other platform we work on

Products, categories and tags each get archives. Attributes — size, colour, material — get their own archive pages. Add filtering and pagination and a modest catalogue becomes tens of thousands of crawlable URLs, the large majority of them thin or duplicated.

None of this is a fault. It is flexibility with no opinion attached, which means somebody has to supply the opinion. That decision — index, canonicalise or block, taken per URL type rather than globally — is the single highest-impact piece of WooCommerce work.

Attribute archives

A page listing every product available in blue is rarely something anyone searches for, and it competes with the category page that is. Most stores should not index attribute archives. The exception is where the attribute genuinely matches demand — "waterproof walking boots" behaves like a category, not a filter, and deserves a real page.

Out-of-stock and discontinued products

The instinct is to delete. That returns a 404 for a URL that may have ranked for years and accumulated links, and throws all of it away.

Better options, in order: keep the page live with clear stock status and alternatives if the product is returning; redirect to the closest equivalent if it is not; and only delete if the page never earned anything. This decision compounds — a store that has deleted five years of discontinued products has usually thrown away a meaningful share of its authority.

Category pages are where the traffic is

Category-level queries carry most of the commercial search volume in UK retail. WooCommerce category pages ship as a product grid with a title and nothing else, which gives a search engine almost no reason to rank them.

What works is genuinely useful buying guidance — the questions a customer asks before choosing, sizing or compatibility notes, and internal links to related categories. Not 500 words of keyword repetition below the fold, which is both obvious and ineffective.

Performance at scale

WooCommerce slows down in specific, predictable places: uncached category pages with heavy filtering, product queries that scale badly past a few thousand SKUs, and the plugin stack most stores accumulate. Cart and checkout cannot be page-cached, so those need a different approach entirely.

We diagnose rather than prescribe. "Install a caching plugin" is not advice; knowing which queries are slow on your catalogue is.

What we do

• URL inventory and an index/canonicalise/block decision per type
• Category page strategy and content structure
• Attribute and filter handling
• Stock and discontinued product policy that retains authority
• Product and Offer schema with correct price and availability
• Performance work targeting the queries that are actually slow
• Internal linking between categories, products and content

What we usually find

Six audits out of ten surface the same items, which is worth knowing before you commission one.

• Product tags used like keywords. Someone tagged products with every term they could think of, generating hundreds of thin archives.
• Category pages with no content at all — competing against guides and listicles that answer the question the searcher asked.
• Redirect chains from a previous migration, three or four hops deep, each one leaking a little.
• Duplicate products created as separate listings instead of variations, splitting authority across near-identical pages.
• Checkout scripts loading site-wide, so every category page carries JavaScript only two pages need.

Moving to or from WooCommerce

The same rule as any replatform: the risk is URLs, not the platform. Every product, category and content URL that earned traffic or links needs a mapped 301 to its specific equivalent. Bulk-redirecting to the homepage is treated as a soft 404 and discards everything those pages built.

Crawl the staging site and compare it against live before the DNS changes. Finding the gaps after launch means finding them at the same time as Google does.

What we need from you

Search Console and analytics access, a WordPress account that can see the plugin list, and ideally a staging site. Where no staging exists, setting one up is usually the first recommendation — a live store is not the place to test structural changes.