Skip to content

Glossary Noindex

What Is Noindex?

Manuel Riveiro Rodriguez
Manuel Riveiro Rodriguez

CEO & Digital Strategist

8 min reviewed on 2026-08-08

Definition

Noindex is a directive that tells search engines not to include a specific URL in their index, so that page stops showing up in search results even though the site keeps serving it normally.

A shelf of old books with one turned around, showing its page edges — beside the title Noindex
The book is still on the shelf, turned the wrong way round
On this page 6
  1. What is noindex?
  2. Meta tag or HTTP header: when to use each
  3. Difference from canonical
  4. Difference from robots.txt: the crawling-vs-indexing mix-up
  5. Best practices
  6. Common mistakes
In brief

How noindex is applied through a meta tag or an HTTP header, how it differs from canonical and from robots.txt, and why using it to hide weak content costs more than rewriting that content.

A shelf of old books with one turned around, showing its page edges — beside the title Noindex
The book is still on the shelf, turned the wrong way round

What is noindex?

Noindex is a directive aimed at crawlers that specifies a given URL should not enter the search engine's index. The page keeps existing, stays reachable for anyone with the link, and the server keeps serving it normally, but it disappears from search results because Google, Bing, or any other engine excludes it from its searchable database.

The directive is expressed in two technically equivalent but differently scoped ways: the robots meta tag inside the HTML document's <head>, or the X-Robots-Tag HTTP header sent by the server along with the response. Both accept combinable values: noindex,follow excludes the page from the index but still lets the crawler follow its internal links, while noindex,nofollow blocks both at once.

A detail that gets overlooked often: noindex doesn't delete a page or stop it from loading in a browser. It only instructs the search engine to drop it from the results or never add it in the first place. If the page was already indexed when the directive gets added, Google needs to crawl it again to read the tag and apply the exclusion, a process that can take anywhere from a few days to several weeks depending on how often the site gets crawled.

Google is the reference engine in most audits, but noindex is part of the standard industry protocol for excluding content and works equivalently on Bing, Yandex, or any search engine that honors those conventions. It isn't a proprietary feature of a single provider, it's an industry-wide agreement on how to signal which content shouldn't show up in search results.

Another point that trips people up in practice: noindex offers no protection against careless internal linking. If a page carries noindex but is still linked prominently from the navigation menu or from other pages, users and crawlers will keep running into it regularly; the tag only removes it from the search index, not from the rest of the site.

Meta tag or HTTP header: when to use each

AspectMeta tag (meta name="robots")X-Robots-Tag header
Where it sitsInside the HTML document's <head>In the HTTP response, sent by the server
File types it coversHTML pages onlyAny type: PDF, images, CSV, XML, JSON
Where it's configuredIn the page's template or CMSIn server configuration (Apache, Nginx) or CMS settings at the file-type level

The meta tag only works on HTML documents, because the search engine needs to download and parse the <head> to read it. That makes it useless for files without that structure: a PDF catalog, an image, or an XML feed can't technically carry an HTML tag inside them.

For those cases, the only option is the X-Robots-Tag header, configured at the server or CMS level so it travels with the HTTP response without the file itself containing any code. It's also the most practical way to block an entire file type in bulk, every PDF in a downloads folder, for instance, with a single server rule instead of editing each document individually.

Difference from canonical

Noindex and the canonical tag solve different problems, even though both come up in the same conversations about duplicate content. Canonical tells the search engine which of several similar URLs is the preferred version and where to consolidate ranking signals, but it keeps all those URLs in the index as candidates. Noindex, on the other hand, removes a URL from the index unconditionally: there's no consolidation and no preferred version, that page simply stops competing for rankings.

The choice between the two depends on whether the secondary URL offers something on its own. A product page with filter parameters that shows the same information as the clean version is a canonical candidate: it stays useful for anyone landing directly on that link and doesn't break the shopping experience. An automatically generated internal search results page, by contrast, doesn't represent content worth consolidating under another URL, it's a noindex candidate.

Combining both on the same URL creates a signal conflict. If a page carries noindex and a canonical pointing elsewhere at the same time, the exclusion directive already removes it from the index on its own, so the canonical signal becomes irrelevant for that page. Google treats that combination as contradictory and usually chooses to respect the noindex.

Canonical or noindex: what decides which

Difference from robots.txt: the crawling-vs-indexing mix-up

The most common mistake with noindex is confusing it with blocking through robots.txt. The robots.txt file sits at the domain root and tells crawlers which paths not to visit, that's a crawling instruction. Noindex, by contrast, is an indexing instruction: it doesn't stop the search engine from visiting the page, it stops the engine from storing the page in its index after visiting it.

The practical consequence of that difference surprises a lot of people: blocking a URL in robots.txt doesn't guarantee it disappears from search results. If that URL receives links from other pages, internal or external, Google can still index it based on those external signals, without ever having crawled its actual content. The usual result is a visible search listing showing the URL but no generated title or description, along the lines of "no information is available for this page."

That mix-up leads to a second, more serious mistake in practice: blocking in robots.txt a page that also carries the noindex tag. If the crawler is barred from accessing it via robots.txt, it never downloads the HTML and therefore never reads that tag, so the exclusion directive never takes effect. For a URL to reliably drop out of the index, the crawler needs to be able to visit it and read the noindex, which requires exactly the opposite: robots.txt has to allow access to that path, not block it.

Search Console itself reflects this distinction in its coverage report: a URL blocked by robots.txt shows up as "blocked by robots.txt," while a URL whose noindex tag got read correctly shows up as "excluded by noindex tag." Checking that report is the fastest way to spot a URL stuck in the worst of both scenarios, blocked and noindex'd at once, with neither directive actually taking effect.

Best practices

  • Apply noindex to a site's own internal search results pages; they offer no value to someone arriving from an external search engine and tend to multiply uncontrollably based on whatever each visitor types.
  • Use noindex on thank-you or confirmation pages after a conversion, a submitted form, a purchase, a resource download; there's no reason for these to compete for organic traffic.
  • Pair noindex with follow, not nofollow, when the excluded page still links to relevant content on the site; that way the crawler still follows those links even though the page itself doesn't get indexed.
  • Check Search Console for which URLs with filter parameters, color, size, sort order, create duplicates, and decide case by case between noindex and canonical based on whether that variant offers value of its own.
  • Always leave robots.txt open to URLs carrying noindex, so the crawler can download them and read the tag.
  • Before every launch, verify that no noindex tag inherited from a staging environment made it onto the production site.

Common mistakes

  • Using noindex as a patch for a page with thin or poor content instead of improving it. The page stops competing entirely and gives up any chance at organic traffic, while a content revision keeps that chance alive and can turn the same URL into a real traffic source. Removing a page from the index doesn't solve the underlying problem, it just moves it out of sight.
  • Leaving a noindex tag inherited from a staging environment in place after the page goes live, which pulls content that should be ranking out of the index, sometimes affecting an entire site unnoticed for weeks.
  • Blocking in robots.txt a URL that also carries noindex, so the crawler never reads the tag and the exclusion never applies.
  • Confusing noindex with nofollow: the first controls whether the page enters the index, the second controls whether a specific link gets followed; they're independent directives that can be combined but don't mean the same thing.
  • Keeping noindex on pages for years without checking whether they still receive valuable internal links or whether the exclusion is still necessary; Google tends to crawl long-excluded content less often, which can weaken the flow of authority to the rest of the site.
Manuel Riveiro Rodriguez CEO & Digital Strategist

A technical audit covers this and everything else in one pass.

Request an audit

Frequently asked

Does noindex affect the ranking of the rest of the site?

Not directly. Each noindex'd URL gets excluded individually and doesn't drag other pages on the domain down with it. The indirect risk shows up when that page received internal links that helped distribute authority; once it stops being crawled as often, that distribution can weaken over time.

How long does it take Google to apply a noindex?

It depends on how often Google crawls that URL. If the page was already indexed, the search engine needs to visit it again to read the directive, which can take anywhere from a couple of days on frequently crawled sites to several weeks on pages the crawler rarely visits.

Can I use noindex and robots.txt together on the same URL?

Better not to. If robots.txt blocks access to that path, the crawler never downloads the HTML and never reads the noindex tag, so the exclusion never applies. For noindex to work, robots.txt has to allow access to that URL.

Is noindex the same as removing a URL through Search Console?

No. Search Console's removal tool hides a URL from results temporarily, for a few months, while the underlying issue gets fixed. Noindex is the permanent solution: as long as the tag stays in place and the crawler can read it, the URL stays out of the index.

Does noindex fix duplicate or low-quality content?

As a temporary fix for pages that are genuinely dispensable, internal search results, filters with no value of their own, yes. As a substitute for improving the content, no: excluding a page leaves that URL with zero chance at organic traffic, while rewriting it keeps the chance to rank.