Noarchive is a value for the robots meta tag or X-Robots-Tag HTTP header that instructs compliant search engines not to store a locally cached copy of the page. Unlike noindex, which prevents indexing entirely, noarchive allows the page to appear in search results but disables the 'Cached' link, ensuring users must fetch the live version directly from the origin server.
Glossary
Noarchive
A directive value used in a Robots Meta Tag or X-Robots-Tag that prevents a search engine from storing a cached copy of the page on its servers.
CACHE CONTROL DIRECTIVE
What is Noarchive?
A directive value used in a Robots Meta Tag or X-Robots-Tag that prevents a search engine from storing a cached copy of the page on its servers.
This directive is critical for content that changes rapidly or is monetized behind a paywall, where a stale cached version undermines the business model. It is distinct from nosnippet, which controls the text preview. Implementing <meta name='robots' content='noarchive'> in the <head> section provides page-level control over cache retention without affecting crawlability or indexation status.
CACHE CONTROL DIRECTIVE
Key Characteristics of Noarchive
The noarchive directive is a critical tool for controlling how search engines and archiving services store and display cached copies of web content. It operates at the page level to prevent outdated or sensitive information from persisting in search engine caches.
01
Prevents Cached Copy Storage
The primary function of the noarchive directive is to instruct compliant search engines not to store a cached copy of the page on their servers. When a user clicks a 'Cached' link in search results, they will receive an error instead of a stored snapshot. This is crucial for content that changes rapidly or contains time-sensitive information where an outdated cache could be misleading.
- Implementation: Applied via the Robots Meta Tag (
<meta name="robots" content="noarchive">) or the X-Robots-Tag HTTP header. - Scope: Affects only the specific page it is applied to, not the entire site.
- Compliance: Supported by major search engines including Google, Bing, and Yandex.
Page-Level
Granularity
02
Distinct from Noindex
A common point of confusion is the difference between noarchive and noindex. These directives control entirely separate functions. Noindex instructs a bot not to include the page in its search index at all, meaning it will not appear in any search results. Noarchive allows the page to be indexed and ranked, but prevents the search engine from keeping a cached snapshot.
- Noindex: Removes the page from search results entirely.
- Noarchive: Keeps the page in search results but disables the 'Cached' link.
- Combined Use: They can be used together (
noindex, noarchive) to both hide a page from search and prevent any residual cache.
03
X-Robots-Tag for Non-HTML Resources
While the Robots Meta Tag works only for HTML pages, the X-Robots-Tag HTTP header extends the noarchive directive to any file type served over HTTP. This is essential for preventing search engines from caching PDFs, images, videos, or other binary files that lack an HTML <head> section.
- PDF Protection:
X-Robots-Tag: noarchivein the server response for a.pdffile prevents Google from displaying a cached 'View as HTML' version. - Pattern Matching: Server configurations like Apache's
.htaccessor Nginx'slocationblocks can apply the header to entire directories of files using regex.
04
Use Cases for Enterprise Content
The noarchive directive is vital for managing proprietary or regulated enterprise content. It ensures that even if a page is publicly accessible for indexing, a search engine cannot serve a stale copy that might violate compliance standards or display outdated pricing and terms.
- Paywalled Content: Allows a snippet to appear in search results for discovery, but prevents users from accessing the full text via a cached copy.
- Dynamic Pricing Pages: Prevents a cached version of yesterday's price from appearing in search results today.
- Legal & Compliance: Ensures that outdated terms of service or privacy policies are not accidentally disseminated through search engine caches.
05
Interaction with Wayback Machine
It is critical to understand that the noarchive directive is a convention for search engines and is not a legally binding access control mechanism. The Internet Archive's Wayback Machine, for example, does not consistently respect the noarchive robots meta tag. If a page must be absolutely excluded from archival services, explicit blocking via robots.txt (using a Disallow directive for ia_archiver) is a more robust, though still voluntary, method.
- Search Engines: Generally respect
noarchive. - Web Archives: May ignore
noarchive; require specificrobots.txtrules. - Best Practice: Use
noarchivefor cache control, not as a primary security or privacy barrier.
06
Syntax and Validation
The syntax for noarchive is strict. In a meta tag, it must be placed within the <head> section and the content attribute must be a comma-separated string. A common mistake is using multiple meta tags, which can cause unpredictable behavior. The correct approach is a single tag with all directives.
- Correct:
<meta name="robots" content="noarchive, nofollow"> - Incorrect:
<meta name="robots" content="noarchive"><meta name="robots" content="nofollow"> - Validation: Use the URL Inspection tool in Google Search Console to see the rendered HTML and confirm the directive is being parsed correctly.
NOARCHIVE DIRECTIVE
Frequently Asked Questions
Clarifying the technical function, implementation, and strategic implications of the noarchive directive for controlling cached content in search engines and AI retrieval systems.
The noarchive directive is a value used in a Robots Meta Tag or X-Robots-Tag that instructs compliant search engines not to store a cached copy of the page on their servers. When a crawler processes a page with this directive, it may still index the content and display a snippet in search results, but it will not provide a 'Cached' link to a stored snapshot. The directive operates at the HTTP response level, meaning it is processed as the page is served, preventing the search engine from saving the rendered HTML, associated assets, or text content to its cache infrastructure. This is distinct from noindex, which prevents indexing entirely. The mechanism relies on the crawler's adherence to the Robots Exclusion Protocol (REP) as formalized in RFC 9309, though compliance is voluntary and not all crawlers, particularly those operated by AI training pipelines, respect it.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.
Enterprise searchRAGPermissions
Read more
Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.
AI agentsWorkflow automationGovernance
Read more
Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
AI integrationDecision supportModel routing
Read moreCACHE AND SNIPPET CONTROL COMPARISON
Noarchive vs. Related Directives
A comparison of page-level REP directives that control how search engines store and display cached copies versus content snippets in search results.
| Feature | Noarchive | Nosnippet | Noindex |
|---|---|---|---|
Prevents cached copy storage | |||
Prevents text snippet display | |||
Prevents video preview display | |||
Allows page indexing | |||
Allows link following | |||
Applied via HTML meta tag | |||
Applied via X-Robots-Tag HTTP header | |||
Typical use case | Prevent stale cached versions | Hide paywalled content previews | Remove page from index entirely |
About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
LinkedIn
Limited slotsGet a Free AI Consultation
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us