WooCommerce SEO: the structural decisions you cannot cheaply undo

Most SEO advice for WooCommerce is about words: keywords in titles, longer descriptions, more blog posts. None of it survives a store whose structure is wrong. We have audited stores with three years of content work sitting on top of a permalink change that was never redirected, and stores emitting two different prices for every product in structured data because a theme and a plugin both thought schema was their job. Better copy fixes neither.

This guide covers the structural decisions: the ones taken in the first week, usually by whoever installed the plugins, that get baked into indexed URLs and are painful to reverse.

The permalink base is the decision you make once

WooCommerce puts products at /product/slug/ and categories at /product-category/slug/ by default. Both bases are editable under Settings, Permalinks, along with the tag and attribute bases, and there is an option to build product URLs from the shop base or from the shop base plus category. Each choice changes every product URL on the site. Change it after launch and every indexed product URL becomes a 404 unless you write the redirects yourself. WordPress may rescue some by guessing from the slug when it hits a 404. Treat that as luck, and write the rule.

The shop-base-with-category option is the one that looks attractive and bites later. A product in two categories can only have one URL, so WooCommerce picks a category by its own ordering rule, and recategorising the product later changes its URL. The flat default keeps a product's URL stable however the category tree is reorganised, and growing stores reorganise. Removing the /product/ base entirely takes rewrite hacks and produces slug collisions with pages. We leave it in.

Slugs are generated from the product name: lowercase, hyphens, stable once indexed. Renaming a product does not change its slug, which is correct. Set the slug you want before publishing.

Category pages are usually your best ranking pages, so keep them indexable

A category page targets the query a shopper types before they know which product they want, and it collects internal links from every product in it. That makes it the natural page to rank for the head term. Keep categories indexable and give each one a real description, in the category description field so it survives a theme change. Give subcategories the same treatment or fold them into the parent. A subcategory with two products and no text is a thin page competing with its own parent.

Tags are different. A tag archive is an unordered list with no text and a handful of products, and a store with a tag per colour, material and occasion has hundreds of them. Noindex the tag archives. The same goes for attribute archives, which are off by default and should stay off. WooCommerce itself already noindexes the cart, checkout and account pages and marks add-to-cart links nofollow, so those need nothing from you.

Product schema has three possible owners, and exactly one should emit it

WooCommerce core outputs Product structured data as JSON-LD on every single product page: name, image, description, SKU, an Offer with price, currency and availability, or an AggregateOffer with a low and high price for a variable product, plus review data where reviews exist. A plain store needs nothing more.

The trouble starts when a second thing also emits Product markup. An SEO plugin's WooCommerce module will, and the good ones remove the core output when they take over. A theme built before JSON-LD was common may emit microdata in the template. A dedicated schema plugin adds a third. The page now carries two or three Product entities, often disagreeing: one with the sale price, one with the regular price. Google asks for one Product per product page, and Search Console reports the conflict under merchant listings. We open the page source, count occurrences of the Product type across JSON-LD blocks and microdata, and switch off every emitter but one.

The price in the schema has to be the price on the page. Core follows the store's tax display setting, so an Indian store showing GST-inclusive prices emits GST-inclusive prices with priceCurrency INR. A Merchant Center feed built from an ex-GST export then disagrees with the landing page, and price mismatch is a standard reason for a disapproved listing. One price, on the page, in the schema and in the feed.

Filtered and paginated category URLs need a policy, not a plugin default

Layered navigation appends query parameters: filter_colour, min_price, max_price, orderby, rating_filter. Every combination is a distinct URL, and a category with five filters can generate thousands of them, each a subset of the same products. Left alone, a crawler spends its budget there and reaches your new products late.

• Filtered URLs should carry a canonical pointing at the unfiltered category URL, and a noindex where the filter set is large. Check what your SEO plugin does with query strings by fetching a filtered URL and reading the canonical it serves. The SEO Analyzer reports that for any live URL.
• Sort and add-to-cart parameters create no unique content. Disallow them in robots.txt so they are never fetched.
• Paginated pages, /page/2/ onward, are different. They hold products that appear nowhere else, so keep them indexable and self-canonical. A canonical from page 2 back to page 1 hides every product past the first page from the crawler, and so does a load-more button that never changes the URL.
• Pick the one filter axis that deserves an indexable page, colour for apparel say, and build it as a category with a clean URL and text. Let the rest stay filters.

Out-of-stock and discontinued products are two different cases

The setting that hides out-of-stock items from the catalog removes them from listings and leaves the product URL returning 200. For a product that will be restocked that is right: the page keeps its rankings, the schema reports OutOfStock, and the customer sees the truth. For a discontinued product it is a page that will never sell again holding a position a live product could hold. Redirect it to its replacement, or to its category if there is none. Retired products left at 200 with no stock are the slow leak we find in older stores.

What an SEO plugin covers, and what it leaves to you

A plugin handles the per-page mechanics well: title and description templates, a canonical on every page, per-taxonomy robots settings, an XML sitemap of products and categories, breadcrumbs, and product schema once its commerce module is on. Validate the sitemap with a sitemap checker after any change to which taxonomies are indexable, because that setting silently changes what the sitemap lists. Check the title template in a SERP preview so a long product name plus the site name does not truncate at the point where the size or colour was.

What a plugin does not do is any of the above. It does not choose the permalink base, write category descriptions, decide which filter deserves a page, notice a theme emitting a second Product schema, or redirect a discontinued product. And it has no opinion on the supplier description pasted into two hundred products and every competitor's store, the largest content problem we see on reseller catalogs and one no setting fixes.

Should WooCommerce category pages be indexed?

Yes. Category pages target the broad queries shoppers type before choosing a product and collect internal links from every product they hold, so they are usually a store's strongest ranking pages. Keep them indexable with a real description each, and noindex the thin archives instead: tags, attribute terms and large filtered URL sets.