WooCommerce filter URLs indexed in Google: ?orderby, ?filter_ and add-to-cart addresses, and what to do

The addresses with question marks in your page indexing report are your shop and category pages, sorted or filtered. WooCommerce makes them from parameters: orderby for the sort order, names that begin filter_ and query_type_ for attribute filters, min_price and max_price, rating_filter, and add-to-cart. Each one answers with status 200 and the same products in another order, or fewer of them. On a store with no SEO plugin, none of them carries a canonical link or a noindex.

For most stores the report is describing something that works as intended, and nothing needs fixing. When the addresses run to thousands, or crawlers spend the server's time on them, the remedy Google names first is a robots.txt rule that keeps crawlers out. This page lists the addresses, shows what each one tells a search engine, and gives the rules.

The addresses one list of products answers at

These were read from a test store with twenty products, one category named Mugs and one attribute named Color, on WordPress's default theme. The plain addresses are /shop/ and /product-category/mugs/.

Every one of them works on a category page too: /product-category/mugs/?orderby=price is the category, sorted. A product's own page has a further family, the attribute_ parameters that choose a variation, and WooCommerce variations and search covers those.

Which of them a fresh store prints as links

Almost none. On the default theme, the only links on the shop page that carry a parameter or a page number are the page links. The sort control is a drop-down inside a form. The add to cart control is a button with no address in it. There is no filter on the page until someone adds one.

That matters because of how Google finds addresses. Its documentation on pagination says it generally crawls the addresses found in the href of <a> elements, and that its crawlers do not click buttons.

Filters come in two kinds, and only the older kind prints links:

• The classic widgets. "Filter Products by Attribute" prints each value as a link, and marks each link rel="nofollow". "Filter Products by Rating" prints each rating as a link with no rel at all. "Filter Products by Price" is a form. "Active Product Filters" prints a link for removing each filter, marked rel="nofollow".
• The Product Filters block. It prints checkboxes and buttons, and changes the address with a script when one is pressed. Its choices are not links in the page.

The add to cart control becomes a link in two cases: a theme or a shortcode that uses WooCommerce's classic product list, and a store where "Enable AJAX add to cart buttons on archives" is unticked under WooCommerce, then Settings, then Products. In both, the link is ?add-to-cart= and the product's ID, marked rel="nofollow".

One parameter leads to more

WordPress's page links keep whatever follows the question mark. On /shop/?orderby=price-desc, the link to the second page is /shop/page/2/?orderby=price-desc, and it carries no rel="nofollow".

That holds for a parameter WooCommerce has never heard of. /shop/?anything=1 answers 200 with the full list, and links to /shop/page/2/?anything=1. So a crawler that meets one such address, on your site or in a link from someone else's, is handed more of them. Google's documentation on link attributes makes the same point from the other side: a page behind a nofollow link may still be found through other means, such as a link from another site.

What each address tells a search engine

This is what WooCommerce and WordPress print by themselves, with no SEO plugin, as read from the test store.

Four things to take from it:

• The robots tag blocks nothing. max-image-preview:large is on every WordPress page and allows large image previews. The word that keeps a page out of search is noindex, and no sorted or filtered address has it. WordPress itself puts it on search results, which is why a product search does.
• A list has no canonical link. WordPress prints one for a single post, page or product: its rel_canonical() function stops at once for anything else. A shop page and a category page are lists, so neither gets one, with a parameter or without, and WooCommerce adds none. A product does, which is why an add-to-cart address on a product page points back at the plain product.
• A filter that matches nothing is still a page. It answers 200 and says "No results found". A page number past the end answers 404.
• An add-to-cart address is not a view of a page. Each request makes a cart: WooCommerce sets its cart cookies and saves a session in the database. It is the one address here that changes something on the server every time a crawler asks for it.

A theme, an SEO plugin or a filter plugin changes this table, so read your own store's. This prints the canonical link and the robots tag of one address, as a crawler receives them:

On the test store it prints one line, the robots tag, and no canonical link:

An SEO plugin can fill the canonical column. Yoast SEO's published specification, for one, says a canonical link belongs on list pages as well, with sorting and filtering queries taken off it and the page number kept. On a store like that, a sorted address points at the plain one.

The cart, checkout and account pages

WooCommerce puts noindex on the cart, checkout and my-account pages on purpose: its function wc_page_no_robots adds the word through WordPress's own robots tag, and the table shows it on all three. When Search Console lists them under a noindex status, the store is working as designed and there is nothing to fix.

What Google says about filter addresses

Google documents this under the name faceted navigation. Its account of the problem is that filters built on URL parameters can make a near-endless number of addresses. A crawler cannot tell whether one is useful without fetching it, so it fetches a very large number of them before it works out that they are not. That leaves less time for the new addresses that are useful.

It then sorts sites into two. A site that does not need its filter addresses in search should prevent them being crawled. A site that does need them should follow a short list of practices, and accept the cost in server resources.

To prevent crawling, it gives these ways, in this order:

For a site that wants its filter addresses in search, Google asks that a filter combination with no results answer 404, and a page number that does not exist too. WooCommerce does the second and not the first, as the table above shows.

What you can do

Leave it alone when the numbers are small

Google's guide to crawl budget says who it is written for: sites with more than a million pages that change weekly, sites with more than ten thousand that change daily, and sites where a large share of all addresses sit under "Discovered - currently not indexed". It calls those figures rough estimates. It also says that if your pages are crawled the day they are published, you do not need the guide.

Its documentation on canonical addresses says a site will likely do fine without stating a preference, because Google then chooses the version to show. Its help for the Page indexing report says not to expect every address on a site to be indexed, only the canonical ones.

So a store with a few hundred products, whose report lists a few hundred sorted and filtered addresses under the statuses in the table further down, is in the state Google describes as normal. Act when one of these is true: a large share of the store's addresses are "Discovered - currently not indexed", new products wait a long time to be crawled, or the server's logs show crawlers spending their visits on filter addresses.

See what your robots.txt already says

On the test store, with nothing added, the answer is this:

The five lines after User-agent: * are WooCommerce's. It adds them to the answer WordPress writes when the site has no robots.txt file, and two of them ask crawlers to leave every add-to-cart address alone. Nothing in this answer mentions orderby or a filter.

If your store's answer has no add-to-cart lines, a real robots.txt file or a plugin's editor has replaced WordPress's answer, and WooCommerce's lines went with it. Where robots.txt is in WordPress explains which of the two you have.

Add rules for the sort and filter parameters

A filter on WordPress's robots.txt answer keeps WordPress's lines and WooCommerce's, and adds yours. The smallest place for it is a must-use plugin: one PHP file in wp-content/mu-plugins/, which WordPress loads on every request with nothing to activate.

In Google's reading of robots.txt, * stands for any run of characters. /*?*orderby= therefore matches any address that has orderby= somewhere after its question mark, whatever comes before it. Google's own example for faceted navigation is written the same way. filter_ and query_type_ have no = because the attribute's name follows them, and filter_ also covers filter_stock_status.

The rules leave three of the block's parameters out: categories, tags and brands. Those words are common enough in other plugins' addresses that a rule for them should be a decision. Add a line in the same form if your report shows them.

The file is listed on the Plugins screen under "Must-Use" and cannot be switched off there. To undo the change, delete the file.

If the site has a real robots.txt file

The filter does nothing then, because WordPress is never asked. Put the rules in the file itself, with the lines WordPress and WooCommerce would have written, since the file is the whole answer.

What a block does, and what it does not

• It stops the crawling. Google's crawl budget guide says a robots.txt block prevents Google from crawling an address, and significantly decreases the chance of it being indexed.
• It does not take an address out of the index. Google's introduction to robots.txt says a blocked address can still be listed if other pages link to it, with no description under it. Search Console has a status for exactly that.
• Nothing on a blocked page is read. That includes a noindex and a canonical link.
• It is not instant. Google says it generally keeps a copy of robots.txt for up to 24 hours.

What a canonical link does here

A canonical link answers a different question from a robots.txt rule. A rule decides whether an address is fetched. A canonical link, on a page that was fetched, says which of several similar addresses you would like shown. Google calls it a strong signal for that, and says in its faceted navigation page that it may reduce crawling of the other versions only over time.

The two do not combine on one address, because a blocked page's canonical link is never read. So choose per kind of address. Where the crawling is the problem, block. Where the only question is which address shows in results, a canonical link to the plain address is enough, and so is doing nothing: Google then picks.

If you add canonical links to lists, with a plugin or with code, give each page of a list its own. Google's pagination documentation says not to make the first page the canonical of the pages after it.

How to read the statuses in Search Console

The names below are the ones Google's help for the Page indexing report uses.

What not to do

• Do not combine noindex with a robots.txt block on the same address. The block stops Google fetching the page, so the noindex is never read. Google's noindex documentation says so directly. Pick one: a block to stop the crawling, or a noindex to keep a crawled page out of results.
• Do not put noindex in robots.txt. Google's documentation says a noindex rule inside robots.txt is not supported.
• Do not redirect sorted and filtered addresses to the plain one. A redirect acts on visitors as well as crawlers, so the sort order and the filters stop working for the people using them. Google's canonical documentation keeps redirects for one case, getting rid of a duplicate page for good, and a filtered list is a page you still serve.
• Do not block the cart, checkout or account pages, for the reason in the warning above.
• Do not use the removals tool to tidy the report. Google's canonical documentation says not to use URL removal for this, because it hides every version of an address from Search.
• Do not point page 2 at page 1 with a canonical link. Each page of a list is its own page to Google.

When to get help

• Ask the host if you cannot reach wp-content or the site's root to add a file.
• Hand it over if the report grows after the rules are in, or the store's own output does not match this page and you cannot tell which plugin changes it. A WordPress SEO audit from WP Ministry is a written report of what stands between the store and a search engine, each finding with the documentation it rests on, with the fixes on the WordPress side done and tested again.

What a product page itself tells Google is a separate subject, covered in WooCommerce schema markup.