WooCommerce SEO: The URLs Your Plugin Cannot Fix

Install Yoast or Rank Math on a WooCommerce store, fill in every field the plugin asks for, and you will have done roughly a third of the job. The other two thirds are URLs. Your store generates them by itself, every time a visitor sorts the shop page by price or ticks a colour in a filter widget, and no SEO plugin creates them, counts them, or decides what Google should do with them.

We pulled the United States search results for "woocommerce seo" on 2026-10-19 and read the pages that rank. They are competent. They are also, between them, 7,700 words that never once print the name of a single URL parameter WooCommerce emits.

This article does that part. What your store generates, what Google's current documentation says to do with it, where the common advice is pointed at the wrong tool, and how to measure the whole thing in a report you already have access to.

What ranks for "woocommerce seo", and what the pages leave out

The SERP, measured with Ahrefs on 2026-10-19 (United States, top 10 positions):

Two things stand out before any content analysis.

The first is that none of the three sources cited in the AI Overview appear in the organic top ten. Two of them are woocommerce.com's own posts and one is Rank Math's guide. Whatever Google's generative layer selects on for this query, it is not the organic ranking underneath it. If you are thinking about how assistants and AI Overviews pick their sources, that gap is a measurement rather than an opinion.

The second is the traffic column. DR 97 at position ten earns 39 visits. DR 39 at position three earns 186. Domain rating orders nothing here, which is the normal state of affairs and the reason we keep printing the column.

Credit where it is due before the gap table. The page at position two is a real guide: 3,932 words, a dedicated section on what to index, noindex and canonicalise, a code example for canonical tags, and a section on AI search that most of its competitors skip entirely. Rank Math's guide, cited in the AI Overview, is about 3,800 words and goes deeper on schema than anything else on the page.

Here is what both of them never say.

The position three result returned HTTP 403 to every fetch we tried, so it is absent from this table rather than scored at zero. That is the fifth consecutive SERP we have audited with at least one unreadable page in the top ten.

Read the two rows that matter most. Both pages discuss canonical tags, 21 times between them. Neither names one URL that WooCommerce actually produces. And "Search Console", the only place you can see whether any of this worked, gets four mentions across 7,700 words.

Your store generates URLs you never wrote

A WooCommerce store ships with several URL generators turned on. Here is the inventory, with what produces each one.

The price and attribute parameters are read straight out of the query string. WooCommerce's own WC_Query::price_filter_post_clauses, added in WooCommerce 3.6.0, takes min_price and max_price from $_GET and turns them into a range condition against the product lookup table. The attribute widget works the same way, with filter_ plus the attribute slug and a matching query_type_ pair.

None of that is a bug. It is how a filter widget has to work. The problem is combinatorial: three attributes with five terms each, crossed with four sort orders and a price range, is already thousands of distinct URLs that all serve subsets of the same catalogue.

You do not have to take our word for the count. Open Search Console, go to the Page indexing report, and look at the list of discovered URLs. Then run the same check from the other side:

# What does Google actually know about your store?
site:yourstore.com inurl:orderby
site:yourstore.com inurl:min_price
site:yourstore.com inurl:product-tag

If the last one returns forty tag archives for a catalogue of sixty products, you have found your first job. The same arithmetic applies on every platform with a tagging system, and we counted it in detail for Shopify tags and what they do to a store's index.

Where the permalinks themselves are decided

WooCommerce puts product URL structure under Settings then Permalinks, and offers four product bases: Default (an ID-based URL such as example.com/?product=111), Shop base, Shop base with category, and Custom base. The optional section below sets the base for categories, tags and attributes, defaulting to product-category, product-tag, and an empty string for attributes.

WooCommerce's documentation gives one piece of advice here, and it is good advice: "Keep permalink structures as short as possible and include keywords that relate to the content they categorize."

It also carries a warning worth more than most SEO tips, because changing this setting on a live store changes every product URL: "previously shared links or search engine indexes pointing to the old URLs will return 404 errors unless you set up redirects." Decide the structure once, early, then leave it alone. We walked through the same decision for Shopify's URL structure and what it locks in.

"Noindex your filtered URLs" is the wrong tool

The guide at position two tells its readers to "Keep most filtered and faceted URLs out of the index". That is the right goal pointed at the wrong instrument, and Google's own documentation says so in two separate places.

Start with the page Google wrote for exactly this problem, "Improve crawling of faceted navigation URLs", last updated 2025-12-18. Its first recommendation:

If you don't need the faceted navigation URLs potentially indexed, prevent crawling of these URLs.

And the method it names:

Use robots.txt to disallow crawling of faceted navigation URLs.

The word noindex does not appear on that page at all. Not as an alternative, not as a caveat. Google's faceted navigation guidance is about crawling, because crawling is the resource the filter URLs consume. As the same page puts it, "if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs."

Now the part that makes the two instruments actively incompatible. From Google's page on blocking indexing, last updated 2025-12-10:

the crawler will never see the noindex rule

That is what happens when a URL is both disallowed in robots.txt and tagged noindex. The crawler stops at the robots.txt rule and never loads the page, so the meta tag it would have found is irrelevant. Google adds that such a page can still appear in results if other pages link to it.

The two pieces of advice therefore cancel each other. Pick one per URL pattern:

• Disallow in robots.txt when you never want the pattern crawled. This is the right default for sort parameters, add-to-cart links and filter combinations.
• Serve noindex when you want the page crawled and its links followed, but kept out of the index. This is the right tool for thin tag archives you still want Google to walk through. Google notes it has two forms with the same effect: a meta tag and an X-Robots-Tag HTTP response header.

A starting point for a WooCommerce store, to adapt to what your own filters actually emit:

# robots.txt
User-agent: *
Disallow: /*?orderby=
Disallow: /*?add-to-cart=
Disallow: /*?min_price=
Disallow: /*?filter_
Disallow: /*?query_type_

Two cautions. Check these patterns against real URLs from your own store before deploying them, because a plugin can rename any of these parameters. And Google's faceted navigation page adds a rule most stores get wrong in the other direction: "Return an HTTP 404 status code when a filter combination doesn't return results." An empty filter result that returns 200 with a "nothing found" message is a soft 404 waiting to be logged.

The tool that used to do this, and why it is gone

If you read older WooCommerce SEO advice you will find references to Search Console's URL Parameters tool. It is gone. Google announced its deprecation on 28 March 2022, in a post by Gary Illyes, with a number worth remembering:

only about 1% of the parameter configurations currently specified in the URL Parameters tool are useful for crawling

The replacement is not another setting. It is Google's crawlers guessing, plus your robots.txt:

Going forward you don't need to do anything to specify the function of URL parameters on your site, Google's crawlers will learn how to deal with URL parameters automatically. If you need more control, you can use robots.txt rules

That is the whole reason robots.txt carries the weight in the section above. It is the last lever Google left in place for parameter crawling.

Crawl budget, honestly

Most WooCommerce SEO advice invokes crawl budget without checking who Google says it applies to. Here is the check, from Google's crawl budget guide, last updated 2026-07-22. It is written for:

• "Large sites (1 million+ unique pages) with content that changes moderately often (once a week)"
• "Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)"
• "Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed"

Google adds that "These are not exact thresholds."

If your store has 200 products, the first two bullets are not about you, and anyone telling you otherwise is selling something. Say so plainly.

The third bullet is the one that catches WooCommerce stores, and it has nothing to do with catalogue size. A store with 200 products and three filter widgets can manufacture tens of thousands of crawlable URLs, and the symptom shows up precisely as a large share of URLs sitting in "Discovered - currently not indexed". Google's position on that case is direct: "If many of these URLs are duplicates, this wastes a lot of Google crawling time on your site."

So the honest version of the crawl budget argument for a small store is not "Google will run out of patience with your catalogue". It is "your filter widgets can bury your sixty product pages under forty thousand near-duplicates, and the report will tell you whether they have".

Pagination, and the canonical mistake that comes with it

Shop and category archives paginate. Two rules from Google's ecommerce pagination guidance, last updated 2025-12-10, settle most of what people argue about.

First, rel="next" and rel="prev" are not a Google signal any more:

Google no longer uses these tags, although these links may still be used by other search engines

Second, and this is the one that gets implemented backwards:

Don't use the first page of a paginated sequence as the canonical page

Pointing page two of your shop at the shop root is a popular "fix" for duplicate content, and it tells Google that page two does not exist. The products that only appear on page two then have one fewer internal path to them. Google's instruction is to give each page in the sequence its own canonical URL, pointing at itself.

Google also says not to put page numbers in URL fragments, because "Google Search generally doesn't support URL fragments in crawling and indexing". WooCommerce's default /page/2/ structure is already correct on that count. Leave it.

Categories rank, products convert

The practical consequence of everything above is an ordering question: which WooCommerce pages are worth the crawl you are protecting?

For most stores the answer is category archives, not individual products. A category page matches the plural, research-stage query a buyer types first, and it is the page that can carry explanatory copy without looking strange. A product page matches a query that names the product, which usually means the visitor already knows what they want.

That ordering is not a reason to neglect product pages, and the fields that matter there are the same ones we broke down in what actually belongs on a product page. It is a reason to stop expecting a product page to rank for a category query.

Tag archives sit at the bottom of this hierarchy, and WooCommerce makes them trivially easy to create. A tag that exists because one product needed one extra label produces an archive page with one product on it. That is a thin page by any definition. Either build the tag into a page with a reason to exist, or serve it noindex and move on.

The broader audit, platform-independent, is the one we laid out in the ecommerce SEO checklist.

Schema: what Google asks for, and what it promises

WooCommerce and the major SEO plugins emit Product structured data without being asked. The useful question is which of Google's two product experiences you are eligible for, because they are not the same thing. From Google's product structured data documentation, last updated 2025-12-10:

• Product snippets: "For product pages where people can't directly purchase the product."
• Merchant listings: "For pages where customers can purchase products from you."

A WooCommerce store is in the second category. Adding the merchant listing properties also makes the page eligible for product snippets, so there is no trade-off to agonise over.

What there is, is a limit worth repeating to anyone who promises you rich results. Google's own wording:

Search result enhancements are shown at the discretion of each experience, and may change over time

Valid markup makes you eligible. It does not buy you the display. Validate what your store emits with the Rich Results Test, fix the errors it reports, then stop treating the markup as a lever you can keep pulling.

Measuring it, status by status

Every change described above is visible in one report: Page indexing in Search Console. These are the statuses that matter for a WooCommerce store, in Google's exact wording, with what each one usually means once filters are involved.

That last pair is the honest trade-off of the robots.txt approach, stated by Google rather than by us: a blocked URL can still be indexed from links alone, and you cannot fix that with noindex because the crawler will not see it. The fix is to stop linking to the pattern, usually by making the filter widget emit links the crawler is not asked to follow. Google is specific about that last point too: "every anchor pointing to a specific URL must have the rel="nofollow" attribute in order for it to be effective."

Set a baseline before you change anything. Note the count in each status, make one change, and compare a fortnight later. Index changes do not resolve on a schedule, and how long any of this takes to show up is the question nobody can answer precisely. No one can guarantee a position in Google, and any report that claims to is reading its own hopes.

If your store is missing from results entirely rather than ranking badly, the diagnostic path is different and we wrote it out separately in why a site does not show up on Google.

The part WooCommerce does not generate

Everything above is defensive. It stops your store from competing with itself and it protects the crawl for pages that deserve it. None of it creates a page that answers a question a buyer asks before they know your product exists.

That is the ceiling on technical WooCommerce SEO. Clean up every parameter, fix every canonical, and your catalogue still only matches queries that name products or categories. The queries above those, the comparisons and the how-tos and the "which one do I need", have no page in your store to match them.

A blog on the store's own domain is the usual answer, and it is a different kind of work: deciding what to write, writing it, and keeping it going. We covered what to write and why most plans stall, and the production side in content marketing for a store. If you are weighing WooCommerce against another platform for exactly this reason, the comparison we ran is Webflow against WordPress.

FAQ

Can a beginner do WooCommerce SEO?

Yes, for the parts that matter most. The parameter inventory in this article is a reading exercise, not a coding one: open your store, click every filter, and write down what appears in the address bar. The robots.txt rules are five lines. Structured data is already emitted by your plugin. The parts that genuinely need experience are judgement calls about which categories deserve a page and what to write on them, and no plugin setting substitutes for those.

Which SEO plugin is best for WordPress and WooCommerce?

They are close enough that the choice rarely decides anything. Yoast, Rank Math and AIOSEO all write titles, descriptions, canonicals and Product schema, and all of them generate an XML sitemap. Pick one, configure it fully, and do not run two at once, because duplicate meta tags and duplicate schema cause real problems. Every decision in this article sits outside all of them.

What are the downsides of WooCommerce for SEO?

The main one is the subject of this article: it generates a large number of crawlable URL variations by default, through sorting, filtering and tagging, and it gives you no built-in way to see how many. The second is that performance depends on your hosting and theme rather than on the platform. Neither downside is unfixable, and both are invisible until you open Search Console.

Should I noindex my WooCommerce product tags?

Usually yes, unless a tag archive has a genuine reason to exist as a landing page with its own copy and more than a handful of products. A tag with one or two products attached is a thin page. Note that noindex is the right tool here, unlike for filter URLs, because you want Google to crawl the archive and follow its links while keeping the archive itself out of the index.

Do I need to worry about crawl budget on a small store?

Not by catalogue size. Google's crawl budget guidance targets sites with a million or more pages, or ten thousand or more with daily changes. But its third criterion is about symptoms rather than size: sites with a large share of URLs classified as "Discovered - currently not indexed". Filter widgets put small stores into that category regularly. Check the report rather than guessing from your product count.

Where do I see whether any of this worked?

The Page indexing report in Search Console, read status by status as in the table above. Record the counts before you change anything, because the only honest way to judge a technical fix is against a baseline. Search results alone do not tell you what Google did with a change, and the report does.