Noindex

When noindex is the right choice

• Internal login and account pages — users need to reach them, search engines do not.
• Your own site's search results pages — otherwise endless mini-pages arise as duplicates.
• Filter and tag overviews in shops or blogs without independent value.
• Thin service pages that cannot be omitted but have no value in the index (contact confirmations, cookie overviews).
• Staging and test environments — noindex plus IP restrictions as double protection.

Noindex vs robots.txt disallow

A common confusion: a robots.txt disallow forbids crawling — Google does not see the page but knows it exists (for example through internal links). The consequence: the URL can remain indexed without snippet text. Noindex, by contrast, permits crawling — Google reads the page but does not index it. Anyone who wants to remove a page from the search results needs noindex, not disallow. Anyone who also wants to save crawl budget combines both — but always in this order: first set noindex, wait until the page has left the index, and only then add the disallow.

Common noindex mistakes

• Accidental noindex on live pages after a relaunch (a forgotten staging setting).
• Noindex plus canonical on the same URL — a contradictory signal, both are devalued.
• Blocking a noindex via robots.txt disallow — Google no longer sees the noindex and the page stays indexed.
• Mass noindex in the sitemap — the sitemap signals "please index", the noindex says the opposite. Sitemaps should only contain indexable URLs.