WooCommerce SEO is the work on the categories, product pages, structured data, URLs and robots.txt of a WordPress shop running WooCommerce that gets it found on Google: the SEO plugin handles the sitemap, canonicals and meta tags, and nothing else. In our test on 15 UK WooCommerce shops on page one of Google (10 October 2026), 14 had an SEO plugin, but only 1 declared shipping in its structured data, none declared a returns policy and 8 had product page titles over 60 characters.
On WooCommerce the first thing everyone does is install Yoast or Rank Math.
Fair enough.
The problem is that people stop there. In the test 14 shops out of 15 had an SEO plugin running: 9 Yoast, 3 Rank Math, 1 All in One SEO, 1 SEOPress. The gaps were all in the places a plugin doesn't reach on its own:
- robots.txt, which in 3 shops didn't contain the rules WooCommerce adds by itself;
- the data for Google's product listings, almost always without shipping and returns;
- the theme, which got the H1 wrong on 5 categories out of 15.
The guides on page one of Google UK for "woocommerce seo" are lists of general tips (keywords, titles, alt text, speed) or, like MonsterInsights', start from the plugin their publisher recommends. None of the ones we read looked at what actually happens on real shops. So we went and read the code of 15 UK ones.
An honest disclaimer: for the two ecommerce projects in our case studies, both in Italy, we chose Shopify. Scovaventi had a shop with visits but no sales; rebuilt from scratch, it closed twelve months with more than €77,000 in sales and an average order value of €190. Bosatta sells spare parts in four markets and made €240,000 in a year.
So why a guide to WooCommerce?
Because the catalogue decides the platform, not our preferences. WooCommerce runs 47.6% of ecommerce systems detected by W3Techs (7.9% of all websites, figures for 10 October 2026), and in our sample 16 of the 103 shop domains we checked returned a WooCommerce catalogue. We've already run the same test on Shopify, in our guide to Shopify SEO: at the end of this article we put the two results side by side.
Here you'll find:
- what WooCommerce and the plugin do on their own and what's left to you;
- the test on 15 UK shops, with the method so you can repeat it;
- the four places where WooCommerce goes wrong without telling you: robots.txt, structured data, URLs and categories;
- when to choose WooCommerce and when Shopify, based on the two tests.
Let's start.
What WooCommerce and the SEO plugin do on their own (and what they leave to you)
Out of the box WooCommerce creates the URLs for products and categories, writes Product structured data on product pages and adds a few rules to robots.txt. Titles, meta descriptions, the XML sitemap and canonicals are handled by the SEO plugin. What's left to you is the copy, the URL decisions, the filters, the data for Google's product listings and the theme.
| Element | Who handles it | What's left to you |
|---|---|---|
| Product and category URLs | WooCommerce: "product" and "product-category" bases | Choosing them before launch: changing them later creates 404s unless you add redirects |
| robots.txt | WooCommerce adds 5 rules to the file WordPress generates | Checking they're actually there and deciding what to do with filters and sort orders |
| Canonical | SEO plugin | Checking that internal links point to the canonical version |
| XML sitemap | SEO plugin | Removing tags and pages with no content |
| Title and meta description | SEO plugin, with automatic templates | Writing them by hand for the main categories and products |
| Product structured data | WooCommerce or the SEO plugin | Adding shipping, returns, GTIN and brand |
| Category H1 and copy | Theme | One H1 and real copy above or below the grid |
That's the main difference from Shopify: on WooCommerce everything can be changed, so everything can also break. The five robots.txt rules, for example, are written into WooCommerce's code (the robots_txt function in the plugin's main class, on GitHub): they block the log and temporary file folders and the ?add-to-cart= addresses. But they only exist as long as nobody overrides them.
The test: 15 UK WooCommerce shops on page one (method and results)
On 15 UK WooCommerce shops that appear on page one of Google, the part left to the SEO plugin was nearly always in order: in 14 categories out of 15 the version sorted by price had its canonical on the main category. The gaps were in robots.txt, in the structured data and in the theme.
Here's the method, so you can repeat it.
On 10 October 2026 we used DataForSEO to read Google UK mobile organic results for sixteen searches: buy extra virgin olive oil online, raw honey online, vegetable seeds online, handmade natural soap, handmade scented candles, coffee beans online, loose leaf tea online, handmade ceramics online, artisan cheese online, craft gin online, natural skincare products uk, herbal tea online, handmade chocolates online, dried flowers online, organic dog treats online and buy english wine online. We checked 103 shop and brand domains (marketplaces, price comparison sites and magazines excluded). 41 refused our requests (403, 429 or a bot challenge), so we couldn't classify them; of the 62 that answered, 16 ran on WooCommerce, recognised because the public endpoint /wp-json/wc/store/v1/products returned the catalogue. We dropped one whose pages sat behind a bot challenge. For the other 15 we downloaded robots.txt and the sitemap, one category (also in the ?orderby=price version) and one product page, then read the canonical, meta robots, title, H1 and JSON-LD structured data.
| Check | Result | Shops checked |
|---|---|---|
| SEO plugin running | 14 out of 15 (Yoast 9, Rank Math 3, AIOSEO 1, SEOPress 1) | 15 |
| Sorted category (?orderby=price) with a canonical to the category | 14 out of 15 (the 15th, with no SEO plugin, had no canonical at all) | 15 |
| robots.txt with WooCommerce's ?add-to-cart= rules | 12 out of 15 | 15 |
| robots.txt blocking sort orders or filters (orderby, filter_) | 2 out of 15 | 15 |
| Product page with no Product structured data | 2 out of 15 | 15 |
| Page describing the product twice | 0 out of 15 | 15 |
| Shipping declared in the structured data | 1 out of 15 | 15 |
| Returns policy declared in the structured data | 0 out of 15 | 15 |
| GTIN or MPN in the Product | 0 out of 15 | 15 |
| Product page title over 60 characters | 8 out of 15 (from 62 to 83) | 15 |
| Category with no meta description | 6 out of 15 | 15 |
| Category with no H1 or more than one H1 | 5 out of 15 (1 with none, 4 with more than one) | 15 |
| Products outside the default /product/ base | 4 out of 15 (2 under /shop/, 1 under /products/, 1 with no base) | 15 |
| Product tags included in the sitemap | 7 out of 13 | 13 with a sitemap in robots.txt |
What does this table tell us?
That the plugin, the thing everyone has, isn't where ground is lost. It's lost in the rows no plugin fills in on its own.
We don't name the shops one by one: they're public sites, but the point isn't who gets it wrong. It's that the same gaps come back from olive oil to dog treats, because they stem from the same default settings. We ran the same test in Italy, on 22 shops, and found the same pattern.
WooCommerce's robots.txt: the rules that disappear without warning (3 shops out of 15)
In WooCommerce product grids the "Add to basket" button for simple products is a link with ?add-to-cart= followed by the product ID. To a crawler it's an address like any other: it follows it, and every visit puts a product in a basket instead of reading a page. That's why WooCommerce adds two lines to robots.txt, Disallow: /*?add-to-cart= and Disallow: /*?*add-to-cart=.
In the test 12 shops out of 15 had them.
The other 3 didn't, and not by choice.
WooCommerce writes its rules into the virtual robots.txt, the one WordPress generates when there's no real file on the server. If someone uploads a physical robots.txt (a previous developer, a security plugin, the hosting company), the server serves that one and WooCommerce's rules stop existing. In one of the shops the file contained nothing but a comment and the line User-agent: *. In another it had one Disallow for a /dev/ folder and a Crawl-delay, a directive Google doesn't support.
The fix takes two minutes: open yourdomain.co.uk/robots.txt, look for add-to-cart and, if it isn't there, add the two lines by hand. How to write the file is explained in our guide to robots.txt.
What about sort orders and filters?
Here the picture is different. URLs with ?orderby= were handled well by the canonical in 14 categories out of 15, but only 2 shops out of 15 blocked sort orders or filters in robots.txt. In its page on faceted navigation (updated in December 2025), Google writes that the canonical may, over time, reduce crawling of the filtered versions, but that in the long term a robots.txt block is more effective. And in its guide to URL structure it warns that when filters can be combined, the number of URLs "explodes".
The rule we use:
- small catalogue, sort orders only → the canonical the plugin already adds is enough;
- filters that can be combined (the filter_colour, filter_size and min_price parameters of layered navigation) → block them in robots.txt;
- a filter that matches a real search, such as "heather honey" → make it a category, with its own URL, title and copy.
The last point matters more than the other two. In our analysis of category pages, across seven UK queries 67% of page one was a category page: that's where demand is concentrated, not in filters.
Structured data: the Product is there, shipping and returns almost never (1 shop out of 15)
WooCommerce writes a JSON-LD block of type Product on product pages, with price and availability, and SEO plugins extend or replace it. In the test it was there in 13 shops out of 15. In the other two it was missing from all three product pages we opened: Google saw a generic web page, not a product. One ran All in One SEO, the other Yoast, so it isn't a question of which plugin you pick.
No UK shop in the sample described the same product twice, once from WooCommerce and once from the plugin; in the Italian version of the test it happened on 2 shops out of 22. Two UK shops used a ProductGroup with one Product per size, which is the structure Google documents for product variants, not a duplicate. It's the same conflict we found on Shopify between theme and apps, and we explain how to avoid it in our guide to adding structured data on WordPress without duplicating it.
Then there's the part almost nobody fills in.
In its documentation on merchant listings, Google lists shipping (shippingDetails) and the returns policy (hasMerchantReturnPolicy) among the recommended properties of the offer, and suggests declaring them once for the whole shop in the Organization markup.
In the test, looking at both the product page and the home page:
- shipping declared: 1 shop out of 15;
- returns policy declared: 0 shops out of 15;
- GTIN or MPN: 0 out of 15;
- brand: 3 out of 15.
These are shops selling honey, tea, seeds, soap and dog food: products where the delivery cost is often the first thing a buyer wants to know. Several of them even show in the Google snippet the order value above which delivery costs nothing. The information already exists, written on each shop's "Delivery" page. It's only missing in the form Google reads.
The fix: an Organization block with hasMerchantReturnPolicy and the shipping rules for the UK, written once (by the plugin, if it supports it, or by code in the theme), plus GTIN and brand in the product fields. If you also run Shopping campaigns, the same data is needed in the feed: we explain it in our guide to Google Ads for ecommerce. The overall picture is in our guide to schema markup.
Does your shop tell Google what delivery costs?
You've just seen that 14 shops out of 15 don't declare shipping in their structured data and none declares returns, even though the information is already written on their pages. We'll check your WooCommerce shop on the same points as the test, robots.txt included, and tell you which fixes are worth your developer's time.
Book a strategy consultationURLs: /product/, /shop/ or nothing? (and why not to change them on a shop that's selling)
In its documentation on permalinks, WooCommerce uses "product" as the default base for products and "product-category" for categories. The alternatives are the shop base (/shop/), the shop base with the category, or a custom base.
In the sample:
- products under /product/ in 11 shops, under /shop/ in 2, under /products/ in 1, with no base in 1;
- categories under /product-category/ in 12, with a custom base (or none) in 3;
- one shop uses /products/ and /collections/, the same prefixes as Shopify.
Google recommends using readable words in your audience's language in URLs (guide to URL structure). On a UK shop the default bases are already in English, so the only question is whether you want a base at all, or a shorter one. Decide before launch.
And if the shop is already live with /product-category/?
Leave it as it is.
The same WooCommerce documentation warns that changing permalinks changes the URLs of all existing products and that the old addresses return 404 unless you set up redirects. The benefit of a shorter URL is small; the risk of losing rankings on hundreds of product pages is real. If you have to do it anyway, for example as part of a rebuild, follow the 301 redirect map and our guide to SEO when you redesign your website.
A warning about the shop base with category (/shop/category-name/product-name/): if you move a product to another category, its address changes too.
Categories, tags and titles: the pages the theme decides for you
The category is the page that brings in the most traffic on WooCommerce, and it's also the one the plugin controls least: the H1, the copy and the layout depend on the theme.
In the test:
- 6 categories out of 15 with no meta description, so with a snippet chosen by Google;
- 1 with no H1 and 4 with more than one, in one case 9, because the theme marks the menu and filter headings as H1;
- 2 categories with a title over 60 characters, one of them 111.
On product pages the title went over 60 characters in 8 shops out of 15, peaking at 73 and 83. The plugin offers an automatic template (product name, separator, site name): with long product names, or with a template that adds "Buy ... Online" on top, the count goes over.
What about product tags?
They're the most common case of a page created by accident. Every tag generates an archive with a grid of products, almost always the same ones as a category. In 7 sitemaps out of 13 product tags were included, in other words put forward to Google as pages to index.
Rank Math, in its WooCommerce guide, gives a rule of thumb: index tags only if the shop has more than 100 products. We use a different test: a tag stays indexed only if it matches a search that no category already covers. Otherwise it gets noindex and comes out of the sitemap. How to work out which searches deserve a page is explained in our guide to ecommerce keyword research.
WooCommerce or Shopify for SEO? (what the two tests say)
Put next to our test on 24 UK Shopify stores, the picture is a mirror image.
| Point | Shopify (24 stores) | WooCommerce (15 shops) |
|---|---|---|
| robots.txt | Fixed at the base, editable only through the template | Open: WooCommerce's rules were missing on 3 shops |
| Canonical | Correct on 24 collections out of 24 | Correct on 14 categories out of 15, thanks to the plugin |
| URLs | Fixed prefixes (/products/, /collections/) | Bases that can be changed, even later, at the risk of 404s |
| Where the mistakes come from | Theme and Markets settings | robots.txt, structured data and theme |
Shopify takes away freedom and with it mistakes. WooCommerce leaves everything in your hands, including the things you didn't know you had to check. If the shop is small and nobody in the business touches code, Shopify starts out cleaner. If you already have a WordPress site with traffic, a blog that brings in visits or a catalogue with unusual logic, WooCommerce saves you a migration and gives you more control. Which plugins to use is covered in our guide to WordPress SEO plugins.
Summary
Everyone has an SEO plugin: it isn't an advantage.
Check that add-to-cart is in your robots.txt.
Declare shipping and returns once, in the Organization.
One H1 per category, and real copy.
URL bases are chosen before launch, not after.
There's a detail in the test that the industry rarely notices. To recognise the WooCommerce shops we didn't have to read the HTML: 16 of the domains we checked returned their catalogue as JSON (names, prices, categories, URLs) to anyone who called /wp-json/wc/store/v1/products, with no login. That's WooCommerce's Store API, built for the basket and the theme's blocks. But it's also the door through which an AI agent can read the shop without going through the page, and today nobody does SEO on that door: what counts there are the names, prices and categories you enter in the catalogue, not the titles and meta descriptions you polish in the plugin. What it means for merchants is in our guide to agentic commerce.
If you'd like us to check your shop on the same points as the test, start with our SEO service; if the theme or the shop needs rebuilding, we handle that too as part of website development. The overall picture for online shops, from categories to filters, is in our guide to ecommerce SEO.
Until next time!
Frequently asked questions
It depends on how you set it up. The technical basics are there: editable URLs, Product structured data and, with an SEO plugin, a correct sitemap and canonicals (in our test on 15 UK shops the canonical on categories sorted by price was right in 14 cases out of 15). The mistakes come from robots.txt, the data for Google's product listings and the theme, which no plugin fixes on its own.
It depends on what you already use on the site. Yoast, Rank Math, All in One SEO and SEOPress all handle titles, sitemaps and canonicals. In our test on 15 UK shops 9 used Yoast and 3 Rank Math, and the problems we found didn't depend on the plugin chosen. What matters more is using only one, so the product's structured data isn't written twice.
No, not on a shop that's already live. Changing permalinks changes the address of every product and, as WooCommerce's documentation warns, the old URLs return 404 unless you set up redirects. On a new shop, choose short bases before launch.
Only if the tag matches a search that no category already covers. Otherwise it's a product grid that duplicates a category, and it should get noindex and come out of the sitemap. In our test 7 sitemaps out of 13 included product tags.
Yes. WooCommerce adds the rules Disallow: /*?add-to-cart= and Disallow: /*?*add-to-cart= to the robots.txt WordPress generates, but if there's a physical robots.txt file on the server those rules aren't served. In our test they were missing on 3 shops out of 15.
It depends on how new the domain is and how much competition there is on the categories you want to rank, not on the platform. Technical fixes such as robots.txt and structured data show up in crawling within a few weeks; traffic to categories takes months.
