<head> section of an HTML document and applies to the individual page where it appears.
For most public webpages, the default behavior is appropriate: search engines may crawl the page, consider it for indexing, follow its links, and generate search-result previews. A robots meta element becomes useful when a specific page requires different treatment.Robots directives are communication tools, not access controls. They can guide compliant search engines, but they do not make a page private or prevent people from visiting it.
What the robots meta element does
The robots meta element provides instructions for search engine crawlers that successfully access and process a webpage. Depending on the directive, it can indicate whether the page should be included in a search index, whether links on the page may be followed, and how much content may appear in search-result previews.
These instructions operate at the page level. A directive included on one URL does not automatically apply to the rest of the website.
The element is part of the document metadata described in HTML document anatomy. It should be placed inside the document’s <head>, alongside elements such as the page title, character encoding declaration, canonical reference, and other metadata.
Basic syntax and placement
A robots meta element uses the name attribute to identify the crawler audience and the content attribute to provide one or more directives.
<head>
<meta name="robots" content="noindex, follow">
</head>
In this example:
robotsaddresses crawlers that recognize the general robots meta convention.noindexasks those crawlers not to include the page in search results.followallows links on the page to be followed, although following links is normally the default behavior.
Directives can also be addressed to a particular crawler. For example:
<meta name="googlebot" content="noindex">
A crawler-specific directive should be used only when there is a clear reason for different treatment. General directives are easier to maintain and less likely to produce inconsistent indexing behavior.
Robots meta elements and HTTP response headers
Equivalent instructions can be delivered through the X-Robots-Tag HTTP response header:
X-Robots-Tag: noindex
The HTTP header is particularly useful for resources that do not contain an HTML <head>, including PDF documents, image files, and other non-HTML resources. It may also be useful when indexing rules are managed at the server or application level.
Both methods can communicate robots directives. The important distinction is where the instruction is delivered: the meta element appears in HTML, while the X-Robots-Tag is part of the HTTP response.
Common robots directives
Search engine support varies, so directives should be checked against the current documentation for the search engines that matter to the website. The following directives are widely encountered.
index- Allows the page to be considered for inclusion in a search index. This is generally the default and usually does not need to be declared.
noindex- Requests that the page not appear in the search engine’s index. The crawler must be able to access the page to discover this directive.
follow- Allows the crawler to follow links found on the page. This is normally the default behavior.
nofollow- Requests that the crawler not follow links from the page. It applies broadly to links on the page and should not be used as a substitute for careful link decisions.
noarchive- Historically requested that a search engine not provide a cached copy of the page. Cache features and support for this directive have changed among search providers, so it should not be treated as a privacy mechanism.
nosnippet- Requests that no text snippet or video preview be shown for the page in search results. Search engines may still display basic information such as the title and URL.
max-snippet:[number]- Sets a maximum number of characters that may be used in a text snippet. For example,
max-snippet:150requests a snippet of no more than 150 characters. The exact presentation remains under the search engine’s control. max-image-preview:[setting]- Controls the permitted size of image previews. Common values include
none,standard, andlarge. max-video-preview:[number]- Sets the maximum duration, in seconds, of a video preview. Support and implementation can differ between search engines.
Multiple directives can be placed in one content attribute and separated by commas:
<meta name="robots" content="index, follow, max-image-preview:large">
Because index and follow are generally defaults, explicitly declaring them is often unnecessary. Including them is not an indexing advantage.
Robots meta element vs. robots.txt
The robots meta element and the robots.txt file address different stages of crawler behavior.
| Control | Primary purpose | When it is encountered |
|---|---|---|
| Robots meta element | Communicates page-level indexing, link-following, and preview preferences | After the crawler requests and processes the HTML page |
X-Robots-Tag |
Communicates similar directives through an HTTP response header | When the server returns the requested resource |
robots.txt |
Communicates which URL paths designated crawlers may request | Before the crawler requests a covered URL |
A page blocked by robots.txt may not be crawled. If it is not crawled, the search engine cannot reliably discover a noindex directive inside its HTML.
This can create an unintended result: the URL may still be known through links or other discovery mechanisms, but the crawler is prevented from accessing the page-level instruction that asks for its removal from the index.
When the goal is to remove a public page from search results, the usual sequence is:
- Allow the crawler to request the URL.
- Return a successful and accessible response containing
noindex. - Allow time for the search engine to recrawl and process the directive.
robots.txt is more appropriate when the goal is to manage crawler access to URL patterns or reduce unnecessary crawling. The broader technical context is explored in Crawl Budget Explained.
When noindex makes sense
A noindex directive is appropriate when a page may remain available to visitors but has little reason to appear as an independent search result.
Common examples include:
- Internal search-result pages: These pages may produce large numbers of thin, variable, or repetitive URLs.
- Form confirmation and thank-you pages: The page supports a completed action but usually provides little value as an entry point from search.
- Temporary campaign pages: Some short-lived pages are not intended for long-term discovery. Others are useful search destinations, so the decision should depend on their purpose.
- Duplicate utility pages: Printer-friendly versions, filtered views, or alternate interfaces may not need separate indexing.
- Public administrative pages: Login screens and other functional pages may be accessible without being useful search results.
- Staging or development pages: If these environments are publicly reachable,
noindexcan provide an additional signal, but authentication remains the appropriate access control.
The decision should be based on the page’s long-term search value and purpose, not simply whether it currently receives traffic. A useful page may have little traffic because it is new, difficult to find, poorly linked, or not yet understood by search systems.
Noindex is not a canonicalization method
If several URLs contain substantially similar content, a canonical reference may help indicate the preferred version. A noindex directive removes a page from index consideration instead of identifying another page as its preferred equivalent.
These mechanisms should not be treated as interchangeable. See Duplicate Content and Canonicalization for a broader explanation.
Pages that should usually remain indexed
Pages intended to answer public questions, explain services, document expertise, or provide durable educational value are generally meant to remain indexable.
These may include:
- Core service and product pages
- Educational articles and guides
- Evergreen reference material
- Location pages containing substantial, location-specific information
- Important category and topic pages
- Original research, documentation, and case studies
An accidental noindex directive can prevent a well-written page from appearing in search results regardless of its content quality, metadata, or internal links. This is why robots directives should be reviewed during launches, redesigns, migrations, and changes to content management systems.
Indexability is only one part of discoverability. Clear website taxonomy, useful internal links, descriptive metadata, and meaningful semantic HTML relationships help people and retrieval systems understand how a page fits within the larger website.
Common implementation mistakes
Leaving development directives on production pages
A staging environment may use a sitewide noindex directive. If that configuration is copied to production, important pages can disappear from search results after they are recrawled.
Blocking a page while expecting noindex to be read
If robots.txt prevents crawling, a search engine may not see the noindex directive in the page. Crawler access and indexing eligibility are related but distinct controls.
Applying nofollow across an entire website
Sitewide nofollow can interfere with link discovery and obscure meaningful relationships among pages. Internal links help establish website structure and should generally remain available to crawlers.
Using noindex to repair weak information architecture
Robots directives can manage specific indexing decisions, but they cannot replace coherent navigation, taxonomy, URL design, or content governance. If many low-value pages are being generated, the underlying publishing system may need attention.
Assuming noindex takes effect immediately
A search engine usually needs to revisit the URL before it can process a new directive. Removal may therefore take time. The page should remain crawlable while the search engine discovers the instruction.
Using robots directives as privacy controls
A page with noindex remains publicly accessible to anyone who knows or discovers its URL. Sensitive information should be protected through authentication, authorization, server configuration, and appropriate data-handling practices.
Sending conflicting directives
Conflicts can occur when a template, plugin, HTTP header, and content management system each produce separate instructions. Search engines commonly apply the more restrictive recognized directive, but relying on conflict resolution creates unnecessary uncertainty.
Robots meta best practices
- Use directives intentionally. Every restrictive directive should have a clear page-level reason.
- Keep important pages crawlable. Search engines need access to process content, canonical references, and robots meta instructions.
- Avoid unnecessary declarations. Adding
index, followto every page does not improve rankings. - Review templates and plugins. Robots directives are often generated by content management systems rather than written directly into each page.
- Check both HTML and HTTP headers. An unexpected
X-Robots-Tagcan override assumptions based only on the visible source. - Audit after migrations and launches. Development settings can persist when a new website moves into production.
- Inspect representative page types. Review articles, services, archives, categories, filtered pages, and other templates separately.
- Keep XML sitemaps focused. URLs intentionally marked
noindexgenerally should not remain in an XML sitemap intended to identify indexable canonical pages. See the technical SEO guidelines for XML sitemaps. - Document important decisions. A brief record of why a page type is indexed or excluded can prevent accidental reversals later.
A practical review process
- Request the page and confirm its HTTP status code.
- Check whether
robots.txtpermits the relevant crawler to access it. - Inspect the rendered document’s
<head>for robots meta elements. - Inspect the HTTP response for an
X-Robots-Tag. - Check the canonical reference and confirm that it reflects the intended preferred URL.
- Verify that important pages appear in navigation, internal links, and the appropriate sitemap.
- Use search engine inspection tools to compare the intended state with the state last observed by the search engine.
Relationship to modern search and retrieval
The robots meta element remains a precise way to communicate page intent to compliant search engines. It helps distinguish content intended for public search discovery from pages that serve a functional purpose without needing their own search presence.
Preview directives such as nosnippet, max-snippet, and max-image-preview can also influence how supporting content is presented in search interfaces. Some search providers connect these controls to certain AI-assisted search features, but implementation is provider-specific and continues to evolve.
Robots directives should not be assumed to govern every crawler, AI system, or retrieval service. Different systems publish different crawler identities and usage policies. A directive is effective only when the receiving system recognizes and honors it.
Clear retrieval depends on more than crawler instructions. Search and AI-assisted systems still benefit from accessible pages, coherent context, descriptive headings, stable URLs, meaningful relationships, and content written for real situations. The relationship between page structure and context is discussed further in Designing Web Content for Situational Context.
Frequently asked questions
Does a webpage need an index, follow meta element?
Usually not. Indexing and following links are generally the default behaviors when a page is accessible and no restrictive directive is present. Adding index, follow does not provide a ranking benefit.
Will noindex make a page private?
No. It asks compliant search engines not to include the page in their indexes. The page can still be visited directly and may be accessed by systems that do not honor the directive. Private content requires appropriate access controls.
Can a page be noindexed if robots.txt blocks it?
A noindex directive may exist on the page, but a blocked crawler may be unable to retrieve and process it. If removal from search is the goal, the crawler generally needs temporary or continuing access to discover the directive.
How quickly does noindex remove a page from search results?
There is no universal timeframe. The search engine must recrawl the page and process the updated instruction. Frequently crawled pages may change sooner than URLs visited infrequently.
Should noindex pages appear in an XML sitemap?
Generally no. An XML sitemap used for search discovery should normally contain canonical URLs intended for indexing. Including a URL in the sitemap while marking it noindex sends inconsistent signals about the page’s intended role.