robots.txt generator_
Build a robots.txt file visually — add rules per bot, set allow/disallow paths, sitemaps and crawl delays.
Live preview updates as you type. Copy and paste directly into your site root. 100% client-side.
Build a robots.txt file visually — add rules per bot, set allow/disallow paths, sitemaps and crawl delays.
Live preview updates as you type. Copy and paste directly into your site root. 100% client-side.
A plain-text file placed at the root of your domain that tells web crawlers which parts of your site they're allowed to request. It's the first thing most well-behaved crawlers check before fetching any other page.
At the root of your domain, exactly at yoursite.com/robots.txt — not in a subfolder. A file at yoursite.com/blog/robots.txt is ignored, and each subdomain needs its own copy at its own root.
No. robots.txt only asks crawlers not to fetch certain paths — it doesn't stop a page from appearing in search results if it was already discovered some other way. To actually keep a page out of the index, use a <meta name="robots" content="noindex"> tag or the X-Robots-Tag HTTP header, and don't Disallow that page — or the crawler can't fetch it to see the noindex instruction in the first place.
It targets every crawler that doesn't have its own more specific User-agent block elsewhere in the file. Use a specific name, like User-agent: Googlebot, to write rules for one crawler only — major search engines use the most specific matching block instead of the wildcard one.
Yes, completely free — and everything runs client-side in your browser. The rules you build, and anything you paste into the import box, never leave your machine; there's no server involved in generating your robots.txt.
Disallow tells the matched crawler not to request the given path. Disallow: /admin/ blocks that one folder; Disallow: / blocks the entire site for that crawler.
Allow explicitly permits a path, which matters when it sits inside a broader Disallow. For example, Disallow: /private/ followed by Allow: /private/public-file.pdf lets that one file through even though its parent folder is blocked.
The longer, more specific path wins, regardless of which directive appears first in the file. If an Allow and a Disallow match with exactly the same length, Allow wins — this is documented behavior for Google and most major crawlers, and it's exactly how the URL tester on this page evaluates a match.
* matches any sequence of characters, so Disallow: /*.pdf$ blocks any path ending in .pdf. $ anchors the match to the end of the URL — without it, Disallow: /page also matches /page2 and /page/anything. Both are a widely supported extension beyond the original robots.txt spec.
It means no restriction at all for that block. Disallow: with nothing after the colon is equivalent to not having a Disallow rule for that crawler.
Crawl-delay asks a crawler to wait a number of seconds between requests. Bing, Yandex and several others honor it — Google does not and ignores Crawl-delay entirely; use the crawl rate settings in Google Search Console instead.
Sitemap points crawlers to your sitemap.xml so they can discover pages more efficiently. You can list as many as you need, one per line, and unlike other directives a Sitemap line applies to every crawler regardless of which User-agent block it appears near.
Host was a Yandex-specific directive for stating a preferred domain when a site was mirrored under multiple hostnames. Yandex deprecated it in 2018 and no major crawler relies on it today — leave it blank unless you have a specific legacy reason to set it.
Not within a single block — Google and most major crawlers always compare the longest matching Allow vs Disallow path, not which line came first. Order does matter between blocks though: a specific User-agent block is used instead of the wildcard block entirely for that crawler, not merged with it.
Each preset replaces your current rules with a ready-made set for a common situation — allowing or blocking every bot, a standard SEO-friendly setup, blocking known AI-training crawlers, blocking known low-value SEO/scraper bots, or starter rules for e-commerce and blog sites. Applying one overwrites what's currently in the builder, so copy or export your existing rules first if you want to keep them.
It adds a new rule block pre-filled with that bot's exact user-agent string and a Disallow: / directive, ready for you to edit or delete. If a rule for that bot already exists, it won't add a duplicate — you'll get a notice instead.
Both produce Disallow: / blocks for different bot lists. "Block AI crawlers" targets bots used to gather AI training data — GPTBot, CCBot, Google-Extended and similar — while still allowing normal search crawlers. "Block bad bots" instead targets third-party SEO/scraper tools like SemrushBot, AhrefsBot, MJ12bot and DotBot, which many sites block to save crawl bandwidth rather than because they're malicious.
Not necessarily. GPTBot and CCBot are generally used for training-data collection, not for the separate crawler some AI products use to fetch a page while answering a live user question — those often use a different user-agent string. Check each provider's current documentation for their live-browsing crawler's name if you want to block that separately.
Yes. robots.txt relies on voluntary compliance — reputable crawlers honor it, but nothing technically stops a scraper from ignoring it. Treat robots.txt as guidance for well-behaved bots, not a security or access-control mechanism; use authentication or server-side blocking for anything that actually needs to be kept out.
You give it a path and a user-agent (default *), and it tells you whether your current rules would allow or block that exact combination — including which specific Allow or Disallow line decided it. It re-evaluates live as you edit your rules.
They flag common mistakes as you build: a red ✗ is a rule that fully blocks a major search engine (or all crawlers) from your whole site; a yellow ⚠ is something worth double-checking, like a Crawl-delay Google ignores, a path missing its leading /, or no sitemap declared; a green ✓ means no issues were found.
Yes — paste it into the import box (or upload the .txt file) and click "import parsed rules." It reads User-agent, Allow, Disallow, Crawl-delay, Sitemap and Host lines and rebuilds them as editable rule blocks, replacing whatever is currently in the builder.
Consecutive User-agent lines are treated as sharing the same block, per the robots.txt spec — so User-agent: A / User-agent: B / Disallow: /x is imported as two separate rule blocks, one for A and one for B, each starting with an identical copy of that Disallow rule, which you can then edit independently.
This tool checks your logic client-side and doesn't fetch your live site. For a definitive read on how Google specifically sees your actual deployed file, use the robots.txt report in Google Search Console, which tests against Google's real parser.
Yes. Your rules, sitemaps and host are saved to your browser's local storage as you edit, and a resume banner offers to restore them the next time you open this page on the same browser. Nothing is sent anywhere — it never leaves your device.
Yes — clicking download saves an actual robots.txt file, not a renamed .txt, ready to upload to your site's root exactly as generated.
The interface is available in English, Dutch, Spanish, Arabic, Indonesian, French, Portuguese, Russian, Japanese and German — switch via the 🌐 globe icon in the top bar.