Site search and cart pages that ended up in Google
Somebody searches for your brand and lands on your empty cart. Or on a search results page for a term nobody sold anything with. Or on the order confirmation that thanks them for a purchase they never made. None of those pages is broken — they are all working exactly as built — and every one of them is a bad first impression that you did not choose.
Which pages this is about
The utility pages every site has and nobody writes: internal search results, the cart, login and account screens, wishlists, and order or enquiry confirmations. They carry almost no content because content is not what they are for.
Internal search results are the sharpest case, and the one Google asks site owners to keep out of the index by name. A search page can generate an unlimited number of URLs — one per query anybody ever types, including the ones typed by bots — and each looks like a real page to a crawler.
Why it survives review
Because there is nothing to find. Open any of these pages and it looks right, because it is right. A content audit that judges pages on their merits passes them. A thin-content report flags them and gets waved away, correctly, because nobody is going to write five hundred words onto a login form.
The fault is not in the page. It is in the page being available to a search engine, and that is a property you have to go looking for.
What it costs
- A dead end for a real searcher. Someone looking for your brand gets a page with nothing on it and no reason to stay.
- A confirmation page found by strangers. At best it is confusing. If your analytics counts that page as a conversion, your conversion data now includes people who arrived from a search result.
- Crawl spent on nothing. An unbounded set of search URLs is an unbounded amount of fetching that could have gone to pages you wrote.
The fix, and the wrong version of it
Add a robots meta tag to those pages, and keep follow:
<meta name="robots" content="noindex, follow">
noindex takes the page out. follow means the links on it are still
crawled, which matters on a cart or account page that links onwards into the site.
Do not reach for robots.txt instead. Disallowing a path stops the crawler
fetching the page — which also stops it seeing the noindex you put there.
A URL that is linked from somewhere can still end up listed on the strength of the link alone,
and now there is no way to tell the engine to drop it. Blocking the crawler and asking it to
forget the page are different requests, and only one of them needs the page to be readable.
Finding yours
Ask the engine what it has:
site:example.com inurl:search
site:example.com inurl:cart
site:example.com inurl:checkout
Then check the pages themselves for the tag. If your search URLs use a query string rather than a path, search for the parameter instead — the shape varies by platform and the fault does not.
What this does not cover
Whether these pages should exist, or how faceted navigation ought to be handled, are design questions with real trade-offs. This is narrower and more boring: pages that are already right are telling search engines to list them, and one directive stops it.
Common questions
Should internal search results be indexed?
No. Google asks site owners to keep them out of the index, and a search page can generate an unlimited number of URLs — one per query anyone ever types, including bots. Each looks like a real page to a crawler.
What is the fix for indexable cart and login pages?
A robots meta tag with noindex and follow. The noindex takes the page out of the index; keeping follow means the links on it are still crawled, which matters on pages that link onwards into the site.
Can I just block them in robots.txt?
That is the common wrong answer. Disallowing the path stops the crawler fetching the page, which also stops it seeing the noindex. A linked URL can still be listed on the strength of the link, and you have removed your own way to ask for it to be dropped.
Why do these pages survive a content audit?
Because nothing is wrong with them. They look right because they are right, and nobody is going to write five hundred words onto a login form. The fault is that they are available to a search engine, which is a property you have to look for rather than something visible on the page.
Does an indexed confirmation page affect analytics?
It can. If the page counts as a conversion, people arriving from a search result are counted alongside people who actually bought.