A store owner sends me a screenshot of their own checkout page ranking in Google, usually with no description under it, and asks how to noindex it. The answer is almost never “add a noindex”, because WooCommerce has been adding one automatically for years. Something on the site is stopping it from applying, and until you find out what, adding another one will not help.
Every article I found on this tells you to block cart and checkout in robots.txt. On a page that is already indexed, that is the one move that guarantees it stays there.
WooCommerce already noindexes those pages
This is not a claim, it is in core. The function wc_page_no_robots hooks into WordPress’s wp_robots filter and returns a no-robots response when the current page is the cart, the checkout, or my account. It has been there since WooCommerce 5.0, and an earlier version of the same guard has existed since 3.2.0. The docblock says exactly what it is for: “Disable search engines indexing core, dynamic, cart/checkout pages.”
There is a second guard for endpoints. wc_prevent_endpoint_indexing, in core since 2.5.3, sends an X-Robots-Tag: noindex header on WooCommerce endpoint URLs and on download links. Its docblock reads “No index our endpoints. Prevent indexing pages like order-received.”
Worth knowing what your SEO plugin is and is not doing here. Yoast WooCommerce SEO removes cart, checkout and my account from your XML sitemap precisely because WooCommerce already noindexes them. It does not add the noindex. Rank Math treats them the same way. So if you disable the SEO plugin looking for the culprit, the noindex should still be there.
Also worth noting: WooCommerce’s own documentation page on WooCommerce Pages explains how to assign the cart, checkout and my account pages and says nothing at all about robots, noindex or SEO. The behaviour is real, it is just undocumented.
So why is yours indexed?
Both guards key off the assigned page. The check is effectively “is this the page whose ID is stored as the cart page”, not “does this page contain a cart”.
That is the whole failure, and I have not seen it written anywhere. If your store serves checkout from a page that is not the assigned checkout page, no guard fires and there is no noindex on it at all.
The cases I run into:
A checkout plugin such as CheckoutWC or a funnel builder that serves its own checkout at its own URL.
A duplicated cart page from a redesign, where the old one is still published and still linked from somewhere.
Block based cart and checkout blocks dropped onto a page that was never assigned in settings.
A staging or landing page rebuild that quietly took over while the setting still points at the original.
The audit takes a minute. Open WooCommerce settings, Advanced, and read the four page assignments. Then open the page that actually serves your checkout in a browser and check whether they are the same page. If they are not, that is your answer.
Then verify rather than trust. View source on the live cart page and look for the robots meta tag. Run a header check on an order received URL and look for X-Robots-Tag. Do not read this off a plugin settings screen, because that tells you what was configured, not what was served.
Source: WooCommerce core source and Google's noindex documentation.
Why robots.txt is the wrong first move
Google states it directly: “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file. If the page is blocked by a robots.txt file or the crawler can’t access the page, the crawler will never see the noindex rule, and the page can still appear in search results.”
And separately: “Specifying the noindex rule in the robots.txt file is not supported by Google.”
Robots.txt prevents crawling. Noindex removes from the index. They are not two strengths of the same tool. Disallowing an already-indexed cart page freezes it in the results permanently, usually as a bare URL with no description, which is the indexed though blocked by robots.txt status. I have written the full comparison in noindex vs robots.txt.
Robots.txt is a prevention tool for URLs Google has never indexed. That is a real use, and it comes last, not first.
The order I work in
Remove any robots.txt disallow covering the cart, checkout, my account or their parameters.
Confirm the noindex actually renders, in view source and in the response headers, on the URL that is really serving the page.
Take those URLs out of the XML sitemap. A noindexed URL in a sitemap produces a “Submitted URL marked noindex” warning, which is noise you do not need.
Kill the internal links pointing at them. Nothing on your site should link to the cart page as a crawlable link.
Use the Removals tool only if you need the result gone from view while the rest works. It is cosmetic and it expires: Google says “Requests made in the Removals tool last for about 6 months.”
Only after the URLs have dropped out, add robots.txt rules for the parameter patterns, to stop them coming back.
The parameter problem underneath it
Cart and checkout are usually a handful of URLs. The volume problem is the parameters.
Five hundred products with an add-to-cart link on the archive gives you five hundred extra crawlable URLs. Layer four sort values across forty category pages and half a dozen filter attributes and a store with five hundred real pages is presenting tens of thousands of crawlable URLs.
Google describes this exactly, in its faceted navigation documentation: “Because the URLs created for the faceted navigation seem to be novel and crawlers can’t determine whether the URLs are going to be useful without crawling first, the crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless.” And then, plainly, “if crawling is spent on useless URLs, the crawlers have less time to spend on new, useful URLs.”
On ?add-to-cart= specifically, there is a WooCommerce issue on record. It was opened in July 2025, argued that the parameter “creates a huge number of low-value, thin-content URLs that can dilute crawl budget”, and was closed as not planned. So this is yours to handle at the theme and robots.txt level. It is not getting fixed upstream.
The old URL Parameters tool is not coming back either. Google retired it in April 2022 and said “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.”
My write-up on faceted navigation SEO covers the filter and sort side in full, and the complete list of Search Console indexing statuses covers each status in the table above.
Sources
- Block Search indexing with noindex, Google Search Central.
- Crawling and indexing faceted navigation URLs, Google Search Central, last updated 18 December 2025.
- URL Parameters tool deprecated, Google Search Central blog, 28 March 2022.
- Remove information from Google, Google Search Central.
- WooCommerce issue 59627, closed as not planned.
- Configuration guide for Yoast WooCommerce SEO, Yoast.