WooCommerce SEO

Which URLs WooCommerce creates and which belong in Google

WooCommerce creates separate URLs for products, categories, tags, attribute archives and paginated pages, plus one for every filter, sort order and add-to-cart action. Only some of them should be indexed. So the first step of an audit is to give every URL type one decision: index it, keep it out of the index, or keep it out of the crawl altogether.

According to the WooCommerce documentation, the default structure is: products under /product/name/, categories under /product-category/name/, tags under /product-tag/name/, and attribute archives with no base at all, e.g. /size/medium/. The product path can be changed under Settings → Permalinks to one of four options:

I don't change the URL structure of a live store just to make URLs prettier. The WooCommerce documentation warns that changing permalinks updates the URLs of existing products, and that shared links and search engine indexes pointing to the old URLs will return 404 errors unless you set up redirects. When a change does make sense, I run it like a migration: with a 301 map for every URL and monitoring after launch.

The good news: WooCommerce keeps the cart, checkout and account pages out of the index by itself. In the plugin code, a function hooked into the wp_robots filter adds noindex to these three pages, and endpoints such as the order confirmation get an X-Robots-Tag: noindex header. There is nothing to fix here, but I check that the theme or SEO plugin doesn't override it.

WooCommerce filters – the parameters that eat crawl budget

Classic WooCommerce filters add filter_ (attribute), query_type_ (how values combine), min_price and max_price (price) and rating_filter (rating) parameters to the URL, and sorting adds orderby. Every combination is a new URL with the same or nearly the same product list. With a few attributes of a dozen values each, that means tens of thousands of URLs, and filter plugins (for example AJAX filters with their own parameters or paths) can multiply that number further.

In its faceted navigation documentation Google recommends that filter URLs which don't need to appear in search results should not be crawled at all, and it points to robots.txt for that. It adds that rel=canonical may reduce crawling of such URLs over time, and that nofollow is generally less effective. So in WooCommerce I split filters into two groups:

• Filters with search demand (e.g. “women's running shoes”, “grey corner sofa”) get their own stable URL: a subcategory or an attribute archive, with an H1, a short description and a place in the navigation. I don't leave them as ?filter_color=grey.
• All other filter and sort combinations are kept out of the crawl in robots.txt, and I make sure the template doesn't link to them with plain links where it doesn't need to.
• Empty combinations shouldn't return a page with a 200 status. Google recommends a 404 when a filter combination returns no results.

User-agent: *
# sorting and action parameters
Disallow: /*?*orderby=
Disallow: /*?*add-to-cart=
# classic WooCommerce filters
Disallow: /*?*filter_
Disallow: /*?*query_type_
Disallow: /*?*min_price=
Disallow: /*?*max_price=
Disallow: /*?*rating_filter=

Attribute archives and product tags – hidden potential and hidden duplicates

In WooCommerce, attribute archives are the simplest way to give a popular filter its own indexable URL without parameters. When you tick “Enable archives” on a global attribute, WooCommerce creates a page listing all products with a given value, e.g. /color/black/ or /brand/brand-name/. The WooCommerce documentation describes this option in its guide to managing attributes.

Such a page only makes sense if people search for that value and the page has its own content: a heading, a description, links to categories. So I enable archives selectively, e.g. for brand, material or use case, and not for size or colour in a store where nobody searches for “all red products”.

I decide whether a value deserves its own page based on demand data, not gut feeling. I describe how to assign keywords to categories, filters and products in detail in the article on ecommerce keyword research, and the rules for filters in ecommerce faceted navigation and SEO.

Product pages and variants in WooCommerce

A variable product in WooCommerce has one URL, and a specific variation is selected with attribute_ parameters in the URL or the form. For most stores that is a good setup: one strong page instead of a dozen near-identical ones. The problem starts when a variation has its own search demand, such as a specific colour or capacity that people search for by name.

In its variants documentation Google recommends that each variant can be identified by a separate URL (a path or a parameter) and that the group is described with ProductGroup and the hasVariant, variesBy and productGroupID properties. With optional variant parameters, Google recommends the URL without the parameter as the canonical. WooCommerce core doesn't do this: for a variable product it outputs a Product with an AggregateOffer (lowest and highest price and the number of offers), and a single variation offer only when all of its attributes are in the URL.

What I check on a product page

• One product URL in internal links, whichever category the visitor came from, and consistent with the canonical.
• Variants with demand get a URL that selects the variant and ProductGroup data; the rest stay within one product.
• Original copy instead of the manufacturer's description on the products with the most potential, with specifications, use cases and answers to buyers' questions.
• The GTIN, UPC, EAN or ISBN field filled in for products that have a code. WooCommerce passes it into structured data, but only when the code has 8, 12, 13 or 14 digits.
• Images in a modern format, with dimensions and descriptive alt text, without gallery plugins that load everything at once.

WooCommerce structured data – what core provides and what's missing

WooCommerce outputs Product structured data on its own, but it isn't complete for Google's product results. I read the class that generates JSON-LD in the WooCommerce code and compared it with Google's merchant listing requirements:

The most common problem, though, isn't what's missing but what's duplicated. An SEO plugin, a reviews plugin and the theme can each add a separate Product block to the same page, with different prices or ratings. So I settle on one source of product data and switch the rest off. I describe how I build the data itself, with an ID graph, on the Schema.org implementation page.

Google Merchant Center in WooCommerce

Google's free product listings require a Merchant Center account with a product feed. The simplest route is the official Google for WooCommerce plugin (over 800,000 active installs according to its listing), which syncs products to Merchant Center and keeps prices and stock up to date. Syncing alone isn't enough: I check product titles, Google product categories, GTIN codes, images and whether the feed says the same thing as the page.

WooCommerce store speed – server, plugins and theme

WooCommerce stores score clearly worse on Core Web Vitals than Shopify stores, and the main reason is server response time. According to the CartHacker dataset based on HTTP Archive and the Chrome UX Report (August 2026), 39.5% of WooCommerce stores pass all three metrics on mobile, compared with 76.5% of Shopify stores and 53% of all websites. Only 12.7% of WooCommerce stores have a good server response time.

That isn't a verdict on the platform but on the typical setup: cheap shared hosting, dozens of plugins and a page-builder theme. In a WooCommerce speed audit I check, in order:

1. Server and TTFB: the PHP version, memory limit, database and object cache (e.g. Redis), because without them every category page is rebuilt from dozens of queries.
2. Page cache: full caching of categories and products, with cart, checkout and account excluded.
3. Plugins: the plugin list and which plugins load scripts and styles on every page when they're only needed on one.
4. Cart fragments: since version 7.8 WooCommerce no longer loads the cart fragments script on every page, only where the cart widget is shown. Older themes can still force it and trigger an extra AJAX request on every page.
5. Template and INP: heavy sliders, filters that reload the list with JavaScript and page builders that slow down the response to clicks.
6. Images and LCP: the largest image on the product page and in the category list, its format, dimensions and loading priority.

I cover this in detail in the technical SEO audit and Core Web Vitals service and in the article on improving LCP, INP and CLS.

An SEO plugin in WooCommerce – what to set and what not to expect

Yoast SEO, Rank Math or SEOPress help you set titles, descriptions, the sitemap and noindex, but they won't design the store's architecture. They won't decide which filters have demand, fix a template that links to products through parameters, or speed up the server. Which plugin you choose matters less than how it's configured.

• One SEO plugin, not two. Two plugins usually mean duplicate titles, canonicals and structured data blocks.
• Title templates for products and categories that start with the name, not with the store name.
• noindex for tags and search results if they aren't landing pages, and their removal from the sitemap.
• A sitemap without noindexed, redirected or parameter URLs.
• A product data check after installing the plugin: whether a second Product block appeared next to the WooCommerce one.

Out-of-stock and discontinued products in WooCommerce

The inventory option to hide out-of-stock products removes them from store listings, but it doesn't remove their pages. In the WooCommerce code this option excludes out-of-stock products from product list queries, i.e. from categories, the shop page and search. The product page still works, has external links and can be indexed, so it needs its own decision.

For stores with high stock turnover I implement this logic in code, so it doesn't depend on someone remembering to add a redirect when deleting a product.

WooCommerce and product visibility in AI Mode and ChatGPT

Shopping assistants use the same data as search engines: product feeds, structured data and the content of pages their crawlers can fetch. So I prepare a WooCommerce store for AI as carefully as for Google, with a few extra steps:

• Merchant Center and the Shopping Graph: products synced to Merchant Center go into the database Google also uses in AI Mode.
• Access for AI search crawlers: I check that robots.txt, the firewall or a security plugin don't block, for example, OAI-SearchBot, the crawler used by ChatGPT search.
• Content visible without JavaScript: name, price, availability and description must be in the HTML, not only after a script loads.
• Complete product attributes: brand, GTIN, material, dimensions and use case. Assistants compare products on these attributes.
• MCP in WooCommerce: WooCommerce exposes its functions to AI agents through MCP (Model Context Protocol) with the help of the MCP Adapter plugin. According to the documentation it is still a developer preview, so I treat it as an experiment, not a foundation for visibility.

I write more about AI shopping in the articles on SEO and GEO for e-commerce and agentic commerce.

When to fix WooCommerce and when to change platforms

In most stores, WooCommerce SEO problems can be fixed without changing platforms. Replatforming only makes sense when the limits come from the architecture itself, not from the configuration. Before an audit I say plainly which situation applies to your store.

If a platform change is settled, I run it as part of the SEO migration service.

How much WooCommerce SEO costs

WooCommerce SEO starts from €850, the same as for any store. The scope depends not on the platform itself but on the state of the specific installation. I prepare a quote after a free consultation and a short review of the store.

The overall scope of store SEO, with the order of work and reporting, is described on the e-commerce SEO page. If you want to check the technical state first, you can order a technical SEO audit on its own.