The noarchive directive tells search engines and AI systems not to store or show a cached copy of your page. Your content stays indexed and can still rank and be cited — but consumers are directed to your live page rather than a saved snapshot. If you publish content that changes often, sits behind time-sensitive pricing, or should never be read in an outdated form, noarchive is the control you want, and it is frequently confused with directives that do something entirely different.

What noarchive does and does not do

It is easy to over-read this directive, so let us be precise. noarchive only affects whether a stored copy of the page is kept and shown. It does not remove you from the index, it does not stop ranking, and it does not hide your snippet in results. Compare the neighbors:

These are separate levers for separate goals. If your aim is to keep the page out of results, that is a job for the meta robots noindex and nofollow directives, not noarchive. If your aim is to limit how much of your text can be quoted, that is the territory of nosnippet, max-snippet and data-nosnippet. Reaching for noarchive when you actually meant one of those is a common and costly mix-up.

How to apply noarchive

There are two delivery methods, and which you use depends on the file type:

The header route is the more flexible one because it works on any response your server sends. If you already control indexing of documents and media, you are likely using the same mechanism described in the X-Robots-Tag guide for PDFs, images and non-HTML files. You can combine directives in a single header — for example noarchive together with a snippet limit — as long as the values do not contradict each other.

A critical rule: do not block the page in robots.txt

This trips people up constantly. A directive like noarchive lives inside the page or its HTTP response, which means a crawler has to fetch the page to read it. If you also disallow that URL in robots.txt, the crawler never fetches the page, never sees the directive, and cannot honor it. The two mechanisms work at different layers: robots.txt controls whether a bot may request the URL, while robots directives control what it may do with the content once it has it. If you want noarchive respected, the page must remain crawlable.

When noarchive is worth using

Most sites never need it, and that is fine — a cached copy is usually harmless. But there are clear cases where it earns its place:

Notice the theme: noarchive is about preventing an outdated version from circulating, not about secrecy. If a page is genuinely private, it should be behind authentication, not merely marked noarchive.

What this means for AI answers

AI assistants increasingly reason over whatever version of your content they can hold onto. If a stale snapshot is what gets referenced, an assistant might repeat pricing or facts you have already changed — and get your brand wrong in the process. Using noarchive on volatile pages nudges systems toward your live content, and pairs naturally with practices that keep AI reasoning from drifting on stale copies, the same concern behind serving fresh HTML in CDN caching and AI bot access. Use it deliberately, only where staleness is a real risk, and never as a blanket setting.

If you are unsure which robots directives your pages are sending — or whether a stale cached version could be misrepresenting you to AI assistants — run the CheckMy.site scanner to see exactly what crawlers read and store from your site.