Noindex
Noindex is a directive, delivered as a meta robots tag or an X-Robots-Tag HTTP header, that tells search engines to keep a page out of their index. Google must be able to crawl the page to see it.
Noindex is the only directive that reliably keeps a specific page out of Google's search index while leaving it accessible to users. It ships in two equivalent forms: a meta robots tag in the HTML head (<meta name="robots" content="noindex">) and an X-Robots-Tag: noindex HTTP response header — the header form also covers non-HTML resources like PDFs and images.
The directive works only when Google can fetch the page. Noindex is read at crawl time, so a page blocked in robots.txt never has its noindex seen — the two directives cancel each other, and the URL can stay indexed on link signals alone. Correct removal is always the same sequence: allow the crawl, serve noindex, wait for Googlebot to refetch.
Noindex takes effect on the next recrawl, not at deployment — hours for frequently-crawled pages, weeks for rarely-visited ones. Left in place long-term, it changes crawl behavior: Google recrawls noindexed pages progressively less often and eventually treats the links on them as nofollow, so a permanently noindexed page stops passing signals to the pages it links to.
Quick facts
How do you implement noindex?
Noindex is implemented in one of two equivalent forms — one is enough:
- Meta robots tag, in the HTML
<head>:<meta name="robots" content="noindex"> - X-Robots-Tag header, in the HTTP response:
X-Robots-Tag: noindex— the only option for PDFs, images, and other non-HTML files
The rule can target one crawler (name="googlebot") and combine with other directives in the same value (noindex, nofollow). Verify what the live page actually serves with the Meta Tag Analyzer and the HTTP Header Checker — CMS plugins, CDN rules, and copied staging configs are the usual sources of accidental noindex.
Why must a noindexed page stay crawlable?
Because noindex is content, not configuration: the directive lives in the page's HTML or response headers, and Google reads it only when Googlebot fetches the URL. Block the URL in robots.txt and the directive goes unread — the page can remain indexed indefinitely, surfacing in Search Console as "Indexed, though blocked by robots.txt" while the noindex sits invisible.
The division of labor: robots.txt manages crawling, noindex manages indexing, and the two must never be applied to the same URL while the goal is removal. If crawl savings also matter, sequence them — noindex first, wait for the page to drop out of the index, then disallow.
What happens after you deploy noindex?
The page drops out of the index on the first recrawl that sees the directive — hours on frequently-crawled sites, several weeks on rarely-crawled ones. Requesting a crawl through the URL Inspection tool compresses the wait for individual URLs.
Over the long term Google demotes noindexed URLs in its crawl scheduling: refetches become rarer, and Google eventually treats the page's outgoing links as nofollow. Reserve noindex for pages that genuinely should stay out of search — thin utility pages, faceted result sets, cart and account pages, untranslated fallback pages — not as temporary parking for content you intend to rank later.
Frequently Asked Questions
How long does noindex take to work?+
One recrawl. Frequently-crawled pages drop out within days; rarely-crawled ones can take weeks. Requesting a crawl in the URL Inspection tool compresses the timeline for individual URLs.
Can I combine robots.txt Disallow with noindex?+
Not while removing a page. Disallow prevents Google from fetching the page, so the noindex is never read and the URL can stay indexed. Apply noindex first, let Google recrawl and deindex the page, then add the disallow if you also want to stop the fetches.
Does noindex block crawling?+
No. Noindexed pages remain crawlable and Googlebot keeps fetching them — just less and less often over time. Stopping the fetches themselves is robots.txt's job.