If you have a WordPress site in 2026, robots.txt is no longer just an SEO housekeeping file. It is one of the first places AI crawlers look when they decide whether to fetch your content, and it is one of the simplest places to tell them what you want. That sounds easy, but most site owners get it wrong. They either block too much, block nothing, or assume robots.txt is a security feature when it is really more of a signal than a lock.
If you have been following the recent wave of crawler changes, this matters even more. Cloudflare is now surfacing AI traffic controls in a much more visible way, and WordPress owners are suddenly making decisions about bots they had never heard of a year ago. If you want the broader context first, start with our guides on Cloudflare blocking AI crawlers and whether you should block AI scrapers at all. This tutorial is the hands-on version. By the end, you will know how to update robots.txt for AI crawlers, when that is enough, and when you need something stronger than robots.txt. Before you edit anything, it helps to see the current state: an AI crawler access checker shows which bots can already read your pages.
1. Start With the Right Question: Block, Allow, or Narrow?
Before you touch robots.txt, decide what you actually want AI crawlers to do. There are three common goals.
Block most AI crawlers
This is the right choice if you publish original work and do not want large language model crawlers harvesting it for training or indexing. It is also the simplest option for smaller sites that do not want to waste crawl budget on low-value bots.
Allow selected crawlers
If you want visibility in AI search products, you may choose to allow some bots while blocking others. That is the middle ground. It is not perfect, because different companies name and behave differently, but it gives you a more controlled stance than a blanket block.
Allow everything but monitor traffic
This makes sense for publishers who care more about reach than control. If you are trying to get found in Perplexity, ChatGPT Search, or other AI-driven discovery tools, you may want to keep access open and focus on making the content easy to understand. Our guide on getting your WordPress site found by AI search is the better companion if that is your goal.
The important part is to choose intentionally. Robots.txt should support your strategy, not define it for you.
2. Know What robots.txt Can and Cannot Do
robots.txt is a publicly accessible text file at the root of your domain. It tells compliant crawlers which paths they should avoid. For example:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
That is the basic shape, but the limitations matter just as much as the syntax.
First, robots.txt is voluntary. Good bots tend to respect it. Bad bots often ignore it. Second, it is path-based, not content-aware. If you block a crawler from your whole site, you are blocking the whole site, not just certain posts. Third, robots.txt does not remove content already indexed elsewhere. If your content is already in a search engine or training set, changing robots.txt today does not erase the past.
This is why I treat robots.txt as the first layer, not the only layer. If you need harder enforcement, you should pair it with Cloudflare rules, server rules, or bot management. Our post on Cloudflare and blocking AI crawlers is useful if you want that stronger layer.
3. Add Clear Rules for the Crawlers You Actually Care About
Most WordPress owners do not need a giant ruleset. Start small and only add the crawlers that matter to you. The common names you will see include GPTBot, ClaudeBot, PerplexityBot, CCBot, Bytespider, and other AI-related user agents. The exact list changes, so do not treat any one list as permanent. The point is to be explicit.
If you want to block all AI crawlers while keeping normal search bots in play, a simple file might look like this:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: PerplexityBot
Disallow: /
User-agent: CCBot
Disallow: /
If you want a more selective approach, you can keep your main WordPress assets crawlable and only restrict parts of the site that are low value for AI indexing. For example, some publishers block tag archives, internal search pages, and thin utility pages while leaving articles open. That is not about secrecy, it is about reducing noise.
Here is the practical rule I use: if a page is not useful to a human reader, it is usually not useful to a crawler either. That does not mean block everything. It means keep the crawl surface clean.
For WordPress users, the easiest way to edit robots.txt is often through a SEO plugin, hosting panel, or a host-level tool. If your host gives you a built-in file editor, use that carefully. A stronger managed host gives you more room to experiment without worrying about sudden traffic spikes.
4. Match robots.txt to Your Actual WordPress Setup
A robots.txt file that looks good on paper can still be wrong for your site. The rules should reflect how your WordPress site is structured.
If you run WooCommerce, for example, you may want to avoid blocking product pages that drive revenue. If you publish tutorials, you probably want article pages open but might want to trim crawl access to feed archives or low-value taxonomies. If you use page builders like Elementor, check that important landing pages are not accidentally tucked behind a rule that also blocks assets the page needs to render correctly.
On the WordPress side, make sure your permalink structure is stable, your XML sitemap is current, and your important pages are linked internally. robots.txt does not replace those basics. It works alongside them.
And if your real goal is discoverability in AI search, do not confuse “blocked for training” with “hidden from answers.” Some AI tools will still cite or summarize content from places you did not expect. That is why it helps to read both sides of the story, especially the articles on Google AI Overview traffic drops and AI search discovery.
5. Test, Monitor, and Adjust After You Publish
Once you update robots.txt, do not assume the job is done. Test it.
First, open the file in a browser and confirm the rules are live. If you changed it through a plugin or host panel, make sure the file at your root domain actually reflects the update. Then use your browser, server logs, or Cloudflare analytics to see whether the bots you care about are still showing up.
Second, watch for side effects. A too-aggressive robots.txt file can reduce crawl coverage, make content harder to surface, or create confusion if you later decide you want AI search visibility. A too-loose file can leave you with wasted crawl activity and less control over where your content goes.
Third, revisit the file when your strategy changes. If you start a new content cluster, launch a product, or shift toward monetizing traffic from AI referrals, your crawler policy should change with it.
If you want a practical testing loop, use this checklist:
- Confirm the robots.txt file is live at the root domain.
- Check that your essential pages are still accessible to normal search bots.
- Verify the AI crawlers you want blocked are listed explicitly.
- Watch logs for a few days to see whether traffic changes.
- Adjust if you accidentally block something useful.
Common Mistakes
Blocking everything by default. This is the fastest way to create a file that is easy to write and hard to live with. Be specific.
Using robots.txt as security. It is not a lock. If you need real access control, use Cloudflare, server rules, login gates, or paywalls.
Forgetting that rules change. AI crawler names and behavior are moving targets. Revisit your file regularly.
Blocking useful pages by accident. A bad rule can hide product pages, category pages, or assets that support rendering.
Never checking logs. If you do not inspect traffic after the change, you are guessing.
Check out our Kinsta comparison, it is the fastest way to see why solid hosting matters when your site is dealing with more crawlers, more content, and more traffic swings.
Only if that matches your content strategy. If you care more about control than reach, blocking specific AI crawlers in robots.txt is a good first step. If you want AI search visibility, you may want to allow some crawlers instead.
No. It only stops compliant crawlers. Some bots ignore robots.txt, which is why important sites often pair it with Cloudflare rules or server-level blocking.
Start with the bots that matter most to you, such as GPTBot, ClaudeBot, PerplexityBot, and CCBot. The exact list can change, so review it periodically instead of copying an old file forever.
Not directly. Google Search and AI crawlers are not the same thing. But if you accidentally block normal search bots or important site assets, you can create SEO problems, so test carefully.
Use a plugin or host-level editor, make one change at a time, confirm the live file, and then check server or Cloudflare logs for a few days. Small, testable edits are safer than rewriting the file all at once.
Final Thoughts
robots.txt is simple, but the strategy behind it is not. In 2026, AI crawlers are part of the normal traffic mix, and WordPress site owners need to decide whether they want to block them, allow them, or split the difference. You just need a clear policy, a clean file, and a quick test cycle after the update.
If your site is important to your business, do not leave this by accident. Pick the crawlers you want to allow or block, write the rules carefully, and then verify that your site still behaves the way you expect. That is the whole game. A small file can protect a lot of value, as long as you treat it like a real decision instead of a checkbox.


If I block GPTBot in robots.txt, will that affect normal Google indexing too, or is it completely separate?
No, GPTBot and Google indexing are separate. robots.txt rules are crawler-specific, so blocking one does not automatically block the other. The main thing to watch is that you do not accidentally block assets or paths that normal search bots need.
This helped me a lot. I finally understand the difference between robots.txt and real blocking.