Robots.txt is a plain text file placed at the root of a domain (e.g., /robots.txt) that instructs automated crawlers which parts of a site they are permitted to access. It functions as a voluntary crawl control mechanism, not a security measure, using directives like User-agent, Disallow, and Allow to define access rules for specific bots. The protocol is foundational to managing crawl budget and preventing server overload.
Glossary
Robots.txt

What is Robots.txt?
The Robots Exclusion Protocol, implemented via a plain text file at the root of a domain, uses directives to manage polite bot access and control crawl traffic.
While compliant bots respect the directives, malicious scrapers often ignore them. The file supports wildcards and the Sitemap directive to point crawlers to the location of XML sitemaps. For granular control over indexing rather than crawling, developers should use X-Robots-Tag HTTP headers or <meta name='robots'> tags, as robots.txt only prevents crawling, not indexing of linked-to URLs.
Core Directives and Capabilities
The Robots Exclusion Protocol relies on a specific set of directives to manage crawler behavior. Understanding these core commands is essential for precise crawl budget optimization and access control.
User-agent: The Target Selector
The User-agent directive specifies which crawler the subsequent rules apply to. It acts as a case-insensitive substring match against the bot's self-reported token.
- Universal Match: Using
User-agent: *applies rules to all crawlers that do not have a specific block defined. - Specific Bot:
User-agent: Googlebottargets only Google's primary crawler. - Precedence Logic: Bots follow the most specific matching block. If a block for
Googlebot-Newsexists, it ignores the genericGooglebotblock. - Multiple Agents: You can list multiple user-agents on separate lines before a directive set to apply rules to a group.
Disallow: The Access Barrier
The Disallow directive instructs compliant bots not to crawl the specified relative path. It is the primary mechanism for managing crawl budget and hiding non-public resources.
- Path Prefix:
Disallow: /adminblocks/admin,/admin.php, and/admin/login. - Root Block:
Disallow: /blocks the entire site. This is distinct from a missing robots.txt file, which implies permission. - Empty Value:
Disallow:(with no path) allows crawling of everything, equivalent toAllow: /. - Trailing Wildcard: While not standard, major engines treat
Disallow: /*.pdf$as a pattern match for file extensions.
Allow: The Granular Exception
The Allow directive creates exceptions within a broader Disallow rule. It is primarily used by Googlebot to grant access to a specific resource inside a blocked directory.
- Specificity Wins:
Disallow: /blogfollowed byAllow: /blog/publicensures only the public subfolder is crawlable. - Order Agnostic: Google evaluates the most specific path rule regardless of its position in the file.
- Parameter Stripping: Bots generally ignore query strings when matching Allow/Disallow paths unless explicitly handled.
- Non-Standard: While supported by major search engines, Allow is not part of the original 1994 standard.
Sitemap: The Discovery Pointer
The Sitemap directive is a non-blocking instruction that points bots to the absolute URL of an XML sitemap. It decouples discovery from crawling rules.
- Absolute URL:
Sitemap: https://example.com/sitemap.xmlis required. Relative paths are invalid. - Cross-Domain: Sitemaps can point to URLs on other domains if verified via Search Console, enabling cross-domain sitemap hosting.
- Multiple Files: You can list multiple Sitemap directives or point to a Sitemap Index file containing up to 50,000 sitemaps.
- Location: The directive can be placed anywhere in the file and is not bound to a specific User-agent block.
Crawl-delay: The Rate Limiter
The Crawl-delay directive specifies the number of seconds a bot should wait between successive requests. It protects server resources from aggressive crawlers.
- Integer Value:
Crawl-delay: 10requests a 10-second pause between hits. - Google Ignored: Googlebot does not officially support this directive. Use Google Search Console to manage crawl rate.
- Bing/Yahoo Support: Microsoft's crawlers respect this directive for managing load on origin servers.
- Dynamic Alternative: For modern rate limiting, a 429 HTTP status code with a Retry-After header is more reliable than this static file directive.
Wildcards and Pattern Matching
While not part of the original standard, Google and Bing support limited pattern matching to reduce file bloat when blocking dynamic URLs.
- Asterisk (*): Matches any sequence of characters.
Disallow: /search?q=*blocks all search query pages. - Dollar Sign ($): Matches the end of a URL.
Disallow: /*.pdf$blocks PDF files but not/pdf-guide. - Escaping: There is no official escape character. To block a literal
*in a URL path, you must rely on the bot's heuristic parsing. - Regex Limitation: Full regular expressions are not supported. Complex filtering logic should be handled via X-Robots-Tag HTTP headers.
Frequently Asked Questions
Essential questions about the Robots Exclusion Protocol, its directives, and how it governs crawler access to your site.
A robots.txt file is a plain text file placed at the root of a domain (e.g., example.com/robots.txt) that implements the Robots Exclusion Protocol (REP). It works by providing directives to automated crawlers—primarily search engine bots—specifying which parts of a website they are permitted to access and index. When a compliant crawler visits a site, its first action is to request this file. The file uses a syntax of User-agent lines to target specific bots and Disallow or Allow rules to define path-based access controls. It is a voluntary standard; it functions as a polite 'No Entry' sign rather than a security mechanism, relying on the good-faith compliance of legitimate bots like Googlebot and Bingbot.
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.

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.

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.
Related Terms
Mastering robots.txt requires understanding the broader ecosystem of crawl management, indexing directives, and bot behavior analysis. These related concepts form the foundation of technical SEO crawl governance.
Crawl Budget
The approximate number of URLs a search engine bot will crawl on a site within a given timeframe. Crawl budget is determined by two factors: crawl rate limit (how fast bots can fetch without degrading server performance) and crawl demand (URL popularity and freshness).
- A restrictive robots.txt that blocks low-value directories directly preserves crawl budget for critical pages
- Wasted budget on faceted navigation or infinite spaces reduces indexation of revenue-driving content
- Monitoring server logs reveals the crawl health score assigned by Googlebot
X-Robots-Tag
An HTTP header directive that provides crawler indexing instructions at the server level, offering granular control over non-HTML assets like PDFs, images, or video files. Unlike robots.txt which only suggests crawling behavior, the X-Robots-Tag can enforce noindex rules that bots must respect.
- Use for file types that cannot embed HTML meta tags
- Supports the same directives as the meta robots tag:
noindex,nofollow,noarchive - Can be applied conditionally via server configuration (e.g., Apache .htaccess or Nginx)
Log File Analysis
The forensic examination of server access logs to understand exactly how search engine bots interact with a site. Log file analysis reveals whether robots.txt directives are being honored, identifies wasted crawl budget, and surfaces anomalies like bots crawling blocked directories.
- Verify that Googlebot respects
Disallowrules in practice - Detect orphan pages that bots discover through sitemaps but users cannot navigate to
- Identify soft 404s consuming crawl budget despite returning 200 status codes
Canonicalization
The process of selecting the preferred URL when multiple URLs serve identical or highly similar content. While robots.txt blocks crawling, canonicalization consolidates ranking signals through <link rel="canonical"> tags or HTTP headers.
- Blocking duplicate URLs via robots.txt prevents crawling but does not consolidate signals
- A blocked URL cannot pass canonical signals if the bot cannot access it
- Use robots.txt to block parameter-based duplicates, then canonicalize the accessible version

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.
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