The WooCommerce SEO checklist, plugin by plugin

On WooCommerce, nothing about SEO lives in one place. WordPress owns the URLs, WooCommerce owns the product and category behaviour, an SEO plugin owns titles and sitemaps, a filtering plugin owns the parameters, and a caching stack owns the speed. Each layer is configured separately, and most problems we find on WooCommerce stores are two layers disagreeing. This checklist goes through the stack in the order the layers load.

Layer one: WordPress core settings, before any plugin

Three settings decide the shape of every URL on the store and are painful to change later.

• Settings, Reading. The “discourage search engines” checkbox writes a noindex across the whole site. It is switched on during development on many builds and forgotten at launch. Check it first.
• Settings, Permalinks. Use the post-name structure. Further down, WooCommerce adds its own bases: the product category base (/product-category/ by default), the product tag base and the product permalink. The product permalink can be the default /product/<slug>/, the shop base, the shop base with category, or a custom base. Pick one before the catalogue is imported. A product URL that includes the category breaks whenever a product moves between categories and produces two URLs for anything filed in two of them.
• Settings, General. The site address must be the HTTPS version with the hostname you intend to keep. A mismatch here causes redirect chains on every request.

WooCommerce itself adds a noindex to the cart, checkout and account pages, as long as those pages are assigned correctly under WooCommerce, Settings, Advanced. If someone rebuilt the checkout on a new page and forgot to assign it, the old assignment stays and the new page is indexable.

Layer two: product data settings inside WooCommerce

Under Products, Attributes, each global attribute has an “enable archives” option. Switched on, it creates a public archive page for every attribute term, such as /colour/red/, with a grid and no text. Keep archives off unless you are going to write content for specific terms, and if you switch a few on, treat them the way you would a category.

Product tags create archives too. A store that tags products freely ends up with hundreds of tag pages that compete with its categories. Either restrict tags to a controlled list that maps to real queries, or set tag archives to noindex in the SEO plugin.

Category descriptions render above the product grid in most themes, and only on the first page in the better ones. That is the only native place for category content, so the description field is where the buying guidance goes unless the theme or a page builder provides a block below the grid.

Layer three: the SEO plugin

Whichever SEO plugin the store runs, it should be doing these jobs and nothing else.

• Title and description templates for products, product categories, tags and the shop page. Product templates usually work best as product name plus a short category qualifier plus the brand; category templates as the category name plus the brand.
• Meta robots per taxonomy. Index product categories, decide tag archives case by case, noindex attribute archives you did not opt into, and noindex the internal search results at ?s=.
• Canonicals. The plugin outputs a self-referencing canonical by default. On paginated archives at /page/2/ it must stay self-referencing, not point to page one.
• The XML sitemap. WordPress core produces wp-sitemap.xml; the SEO plugin typically replaces it with one that respects your noindex choices. Only one sitemap should be live, and it should be the one that excludes what you have noindexed. Submit that one in Search Console.
• Breadcrumbs with BreadcrumbList markup, using the primary category for products filed in more than one.

The plugin is not the place for a second Product schema, which brings us to the next layer.

Layer four: schema, and who is allowed to print it

WooCommerce prints Product structured data on single product pages: name, description, SKU, offers with price and availability, and aggregate rating when reviews are on. Recent WooCommerce versions also include a field for a GTIN, UPC, EAN or ISBN on the product, and filling it lets the markup and your Merchant Center feed agree on identifiers. The problems start when a theme, a review plugin and the SEO plugin each add their own Product block. Google expects one Product entity per page. Validate a product page with the Rich Results Test, count the Product objects, and switch off every source but one. What the markup needs to contain is in Google’s Product structured data documentation and our product structured data entry.

Layer five: filters, sorting and the parameters they generate

Layered navigation is where WooCommerce stores generate the most crawlable waste. The default widgets and most filter plugins write URLs such as ?filter_colour=red&min_price=20&orderby=price. Every combination is a URL, and left alone they get discovered through links and end up in the index. The rules we apply:

1. The canonical on any filtered or sorted URL points to the base category. Check this on a live filtered URL, since some filter plugins rewrite the canonical to the filtered version.
2. Filter and sort parameters are disallowed in robots.txt only once the canonicals are right, and never as the sole defence.
3. Filter combinations that match real queries, for instance a brand within a category, are built as proper category pages or landing pages with content rather than left as parameter URLs.
4. AJAX filtering that updates the grid without changing the URL is preferred on categories with many attributes.

A store with a large catalogue and uncontrolled filters can have far more parameter URLs than product pages, and Google’s crawling settles on the parameters. The pattern and its cleanup are described in faceted navigation URLs indexed, with the decision framework in faceted navigation SEO and the vocabulary in the faceted navigation entry.

Layer six: caching, images and everything that affects speed

WooCommerce speed is mostly a hosting and plugin-count question, and the caching plugin comes after both.

• Hosting. PHP workers and database performance decide how fast an uncached page renders. Cart, checkout and account pages are never cached, so the uncached render time is the speed shoppers experience at the moment they are about to pay.
• Page caching. Cache the catalogue, exclude the cart, checkout and account pages and anything carrying a nonce, and confirm the cache is not serving one shopper’s mini-cart to another.
• Object caching. A persistent object cache helps stores with large catalogues and many attribute lookups.
• Images. Serve modern formats, set explicit width and height so nothing shifts, and exclude the first product image from lazy loading so the largest element paints early.
• Plugin count. Every active plugin can enqueue CSS and JavaScript on every page. Review the list quarterly and remove what no longer earns its place.

Measure with the Core Web Vitals checker against product and category templates rather than the homepage, and if the store is failing on mobile, start with WooCommerce site slow. The general case for speed as a ranking and conversion factor is in does site speed affect ecommerce rankings.

Layer seven: redirects

WordPress remembers a changed post slug and redirects the old one, and because products are posts, product slug changes are covered. Category slug changes are not, and neither are deleted products or a change to the permalink structure. A redirect plugin, or rules at the server level, handles those. Log 404s from the moment the store launches and review the log monthly; the top entries are usually old product URLs still linked from somewhere.

Layer eight: languages

A store selling into Quebec or running an English and French site needs one URL per language, translated slugs, and hreflang pairs between them. Multilingual plugins handle the mechanics, and the hreflang entry explains what the tags must contain. Machine-translated product pages published without review are a thin-content problem in the second language, so translate the categories and top sellers properly first.

Working through it

Do the layers in order. A permalink decision made after the SEO plugin is configured undoes the plugin’s work, and a filter cleanup done before the canonicals are right gets nothing indexed correctly. On a mature store the pass surfaces a list of index bloat to remove, a short list of filter combinations to promote, and a handful of speed fixes; the index bloat entry explains how to read the page indexing report to size the first item. For a store wondering whether the platform can carry its catalogue at all, can WooCommerce handle a large catalogue is the honest answer. If manufacturer copy is still on every product, are manufacturer descriptions bad for SEO explains what to rewrite first. The ecommerce SEO and ecommerce development teams run this pass together, because half the fixes are code.

---

Sources

• Google Search Central: SEO best practices for ecommerce sites
• Google Search Central: Robots.txt introduction and guide
• Google Search Central: Intro to Product structured data
• web.dev: Web Vitals