noindex vs nosnippet: two ways to disappear from an answer

The rules, as Google states them

noindex means: do not show this page, media, or resource in search results. nosnippet means: do not show a text snippet or video preview in the search results for this page. That is the entire distinction at the level of intent. One removes the entry, the other removes the description beneath it.

Where they differ in practice

Google's guidance on noindex is unusually absolute. When Googlebot crawls the page and extracts the tag or header, Google will drop that page entirely from Google Search results, regardless of whether other sites link to it. That last clause is the important one. Inbound links normally keep a page discoverable even when the site owner would rather they did not; noindex overrides them.

nosnippet leaves the listing in place. The page can still rank, still be clicked, still send traffic. What disappears is the preview text, which for many results is the part that actually earns the click.

There are two more members of the snippet family that have no counterpart on the noindex side. max-snippet limits a result to a stated maximum number of characters of textual snippet. data-nosnippet is an HTML attribute that designates textual parts of a page not to be used as a snippet — a scalpel where nosnippet is a switch. If a single licensed paragraph is the problem, data-nosnippet solves it without touching the rest of the page.

Implementation, and the mistake almost everyone makes

noindex has two documented forms, a meta tag and an HTTP response header, and Google says they have the same effect. The header form is what you use for PDFs, images and anything that is not HTML.

Then comes the failure mode that generates more support threads than any other rule in this area. For the noindex rule to be effective, the page must not be blocked by robots.txt and must otherwise be accessible to the crawler. If the page is blocked, the crawler never sees the rule, and the page can still appear in search results[^noindex-robots-conflict].

Read that carefully, because the intuition is exactly backwards. Blocking a page more aggressively makes it harder to suppress, not easier. robots.txt governs fetching; noindex and nosnippet are instructions inside the thing being fetched. A site that disallows a directory and adds noindex to the pages inside it has built a configuration where neither control does what was intended.

The correct sequence is: allow the crawl, serve the rule, wait for it to be recrawled, and only then, if you still want to, block the path.

The part that matters for AI answers

Google's documentation on its AI features names the prerequisite plainly: a page must be indexed and eligible to be shown in Google Search with a snippet. It also lists the controls for limiting content in those features — nosnippet, data-nosnippet, max-snippet and noindex — and explains that these are managed through the ordinary robots directives because AI is built into Search.

That means the two sides of this comparison converge on the outcome that most readers actually care about. noindex makes a page ineligible because it is not indexed. nosnippet makes it ineligible because it is not snippet-eligible. Different mechanisms, same result: absent from AI Overviews and AI Mode.

This is the single most under-appreciated fact in this pairing. A team that added nosnippet years ago to protect syndicated content, or to stop competitors reading their answers off the results page, made a choice about AI search visibility years before AI search existed. Nobody revisits a robots meta tag, and nothing in an analytics dashboard flags it.

Why teams reach for the wrong one

Three patterns account for most of the misapplied rules in this pair, and each has a better answer.

"We do not want competitors reading our answers off the results page." This is the classic reason a nosnippet ends up on a knowledge base or a support site. It works, in the narrow sense that the preview disappears. It also removes the page from the pool for Google's AI features, which are increasingly where those same answers get read. The content was public the whole time; suppressing the preview only stopped it being useful to the people who would have clicked.

"This page is thin, so we noindexed it." Sometimes correct, often a way of avoiding the actual decision. A thin page that serves a real user need should be made substantial or merged into a page that is. A thin page that serves no need should be deleted and redirected, not preserved in a state where it is fetched, crawled and permanently hidden.

"Legal asked us to stop AI companies using our content." Neither rule is addressed to AI companies. Both are addressed to Google, and Google has folded its AI features into the same controls. Using them satisfies the letter of the request by removing you from ordinary Google results as well, which is almost never what the request meant. Crawler-level controls aimed at named user agents express that intent without the collateral damage, and they are the right conversation to have instead.

What each control does not do

Neither rule stops a page being fetched. Both are read out of the response, which means the crawl happened. If your concern is bandwidth, request volume or a crawler you do not want touching the server at all, these are the wrong layer entirely.

Neither rule is retroactive in any useful sense. A page has to be recrawled for a newly added rule to take effect, and Google's guidance on how long changes take to be reflected applies here as much as anywhere: hours in the best case, considerably longer in ordinary ones. Adding noindex the morning of a launch does not clear a page from results by the afternoon.

And neither rule travels. They govern one page on one origin. A copy of the same text on a syndication partner, a documentation mirror or a scraper carries none of your directives, and if a system is retrieving from the copy rather than the original, your suppression achieves nothing except removing the version you control from the answer.

An audit worth running this week

Crawl your own site and list every URL carrying a robots meta tag or an X-Robots-Tag header. For each one, answer three questions.

Was this deliberate? Staging leftovers and CMS defaults account for a depressing share of production noindex tags. A page you want found that carries noindex is not a ranking problem, it is a configuration bug, and no amount of content work will move it.

Is it still justified? A nosnippet added to protect a paywall, an embargo or a syndication agreement may have outlived the arrangement it protected. If the commercial reason is gone, the control should go with it.

Could it be narrower? This is where data-nosnippet earns its place. If one quoted passage is the sensitive part, exclude the passage, not the page. A page with one excluded element remains snippet-eligible and remains in the pool for Google's AI features; a page with a blanket nosnippet does not.

Then check the interaction with robots.txt for every URL on the list, because a suppression rule sitting behind a disallow is doing nothing at all while looking like it is doing its job.

A worked example

A B2B software company runs a large help centre. Two years ago a competitor was observed lifting answers verbatim, so the team added a site-wide nosnippet to the help subdomain. Rankings were unaffected. Traffic dipped slightly and was blamed on a seasonal pattern. Nobody revisited it.

Today the same company cannot understand why assistants describe its onboarding process incorrectly while citing a three-year-old third-party blog post. The help centre pages, which contain the correct answer, are indexed and rank well. They are also, by the company's own configuration, not snippet-eligible, and snippet eligibility is the prerequisite Google names for its AI features.

The fix costs one deploy. Remove the blanket rule, apply data-nosnippet to the handful of passages that were actually sensitive, and let the rest of the corpus become eligible again. The competitor concern was never solved by the rule anyway, because the pages were public and a competitor with a browser could always read them.

This pattern is common enough to be worth checking for by default. Any site-wide snippet restriction added before AI answers existed was, in effect, a decision about AI answers made in advance and without the information.

Choosing deliberately

If the goal is that nobody finds the page, noindex is the honest instrument. It is documented, it is absolute, and it overrides inbound links.

If the goal is that a specific passage is not reproduced, data-nosnippet is the honest instrument, and it costs you almost nothing.

If the goal is to keep AI systems from using your content, neither of these is aimed at the right target. They are instructions to Google about crawling and display, and Google has folded its AI features into the same controls, so using them removes you from ordinary results too. Crawler-level rules express that intent with far less collateral damage, because they let you keep the surfaces you still want while declining the ones you do not.

The worst outcome is the accidental one: a rule added for a reason nobody remembers, quietly holding a page out of the answers your buyers are reading. That is not a policy. It is an artefact, and the only fix is to go and look.