What a WordPress robots.txt file does (and what it doesn’t)
A robots.txt file gives crawl instructions to well-behaved bots (like Googlebot and Bingbot). It’s mainly about crawling (where bots are allowed to fetch pages), not guaranteed indexing (whether a URL can appear in search results). If a URL is blocked in robots.txt, Google may still index it based on links—but it won’t be able to crawl the content to understand it.
For most WordPress sites, the safest SEO goal is simple: don’t block important content, and make your XML sitemap easy to discover. Google’s documentation explains how robots.txt is interpreted and why precise directives matter; see Google Search Central’s robots.txt introduction.
Before you edit: quick safety checklist
- Back up your site (or at least record your current robots.txt output) before changing anything.
- Know your sitemap URL (common options: /sitemap.xml or /sitemap_index.xml depending on your SEO plugin).
- Decide what you’re trying to achieve: protect private areas, reduce crawler waste on parameter URLs, or just publish a clean sitemap directive.
- Remember: robots.txt does not protect confidential content. Use authentication, permissions, or “noindex” where appropriate.
Step 1: Locate your current robots.txt in WordPress
WordPress can serve a virtual robots.txt even if no physical file exists. Start by checking what bots currently see:
- Open a browser and visit: https://yourdomain.com/robots.txt
- If you see content, copy it into a safe note. If you get a 404, you may not have a virtual file enabled (or something is blocking it).
If you see default WordPress-style rules, it’s often something like:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
That default is common and generally safe: it prevents crawling admin screens while still allowing admin-ajax (needed for some front-end features). Some SEO plugins replace these defaults with a more minimal approach.
Step 2: Choose the best way to create or edit robots.txt
Option A (most controlled): Create a physical robots.txt in your site root
A physical file overrides the virtual one. This is often the most predictable method.
- Open a plain-text editor and create a file named robots.txt.
- Add your rules (use the safe templates below as a starting point).
- Upload it to your WordPress web root (the same folder that contains wp-config.php) using FTP/SFTP or your host’s file manager.
- Recheck /robots.txt in your browser and confirm your changes appear.
Option B: Edit via an SEO plugin file editor (when available)
Some SEO plugins provide a robots.txt editor in the WordPress dashboard. For example, Yoast explains how its robots.txt editor works and what it outputs in its help documentation. If your setup allows it, this can be faster than FTP—but you should still verify the final output at /robots.txt.
Step 3: Use a safe robots.txt baseline for WordPress SEO
On most WordPress sites, less is more. Overblocking can prevent Google from crawling resources it needs (or stop discovery of pages you actually want to rank). A widely used “best-practice” approach is to allow crawling and provide a sitemap location. Yoast has an example of a minimal WordPress robots.txt suitable for many sites in its robots.txt best-practice article.
Here’s a safe baseline you can adapt:
User-agent: *
Disallow:
Sitemap: https://example.com/sitemap_index.xml
- Disallow: with nothing after it means “don’t disallow anything.”
- Sitemap: should point to your real sitemap URL (replace the domain and path).
Important: Only include a sitemap line if the URL is correct and accessible. If your sitemap is at /sitemap.xml, use that instead.

Step 4: Add WordPress-specific directives (only when needed)
If you have a reason to reduce crawl noise, you can add targeted rules. Keep changes minimal and avoid blocking assets (CSS/JS) unless you’re certain it’s harmless for your site.
Commonly safe: block wp-admin, allow admin-ajax
If your baseline is too open for your preferences, this is a common approach:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml
This is about keeping crawlers out of backend paths while letting front-end functionality work.
Be cautious with blocking search and filter URLs
Some sites add rules to reduce crawling of internal site search pages or URL parameters. This can help on large sites, but it can also hide pages you didn’t mean to block—especially if your theme or plugin uses parameters for important content.
- If you block query parameters broadly (like /*?*), you may accidentally block canonical pages that use tracking parameters or pagination.
- For complex setups (eCommerce faceted navigation, heavy filtering), consider handling indexing with canonical tags and “noindex” (where appropriate) rather than aggressive robots.txt blocks.
Step 5: Publish changes and verify the live output
- Save your robots.txt changes (plugin editor or uploaded file).
- Hard refresh your browser at /robots.txt (or test in an incognito window).
- Confirm the output matches what you intended—especially the sitemap URL and any Disallow rules.
If your changes don’t appear, a caching layer or CDN may be serving an older version. Purge cache and try again.
Step 6: Test your robots.txt rules before you rely on them
Testing prevents the most expensive mistake: accidentally blocking your entire site.
- Spot-check key URLs: Make sure your homepage, major categories, and top posts are not disallowed by pattern.
- Validate syntax: robots.txt is sensitive to small formatting issues and unexpected wildcard matches. Google’s documentation explains directive handling and matching behavior in more detail in Search Central.
If you use Google Search Console, you can also confirm Google can fetch important pages and resources and watch for crawl anomalies after changes.

Common robots.txt SEO mistakes (and how to avoid them)
Mistake 1: Blocking the entire site
This line tells crawlers to stay out of everything:
User-agent: *
Disallow: /
Only use that intentionally (for example, on a private staging site). If this appears on your live domain, it can severely hurt crawling.
Mistake 2: Trying to “noindex” in robots.txt
robots.txt is not a reliable place to control indexing. If you need a page not to appear in search results, use a meta robots “noindex” directive (or an equivalent header), and allow Google to crawl the page so it can see that directive.
Mistake 3: Blocking CSS/JS needed for rendering
If Google can’t fetch essential resources, it may not render pages properly, which can affect how content is understood. Avoid broad blocks on /wp-includes/ or theme/plugin asset paths unless you’re certain it won’t break rendering.
Mistake 4: Forgetting to update the sitemap line
If you switch SEO plugins or change sitemap structure, update the Sitemap: directive. A stale sitemap URL wastes crawl attention and can slow down discovery.
A practical workflow for ongoing WordPress SEO control
robots.txt is only one piece of technical SEO. A sustainable workflow usually looks like this:
- Use robots.txt for crawl guidance (keep it minimal unless you have a clear reason).
- Use sitemaps for discovery (ensure they’re accessible and accurate).
- Use on-page controls for indexing (meta robots, canonicals, internal linking).
- Monitor changes after theme/plugin updates to ensure robots.txt and sitemap URLs didn’t shift.
If you want to streamline the broader SEO workflow around your content (beyond robots.txt)—like creating optimized posts, building internal links, and adding FAQ schema directly inside WordPress—SEO Max Suíte is worth exploring as part of an all-in-one publishing process while you keep robots.txt lean and focused.
Example robots.txt files you can copy (with notes)
Example 1: Minimal (recommended for most sites)
User-agent: *
Disallow:
Sitemap: https://example.com/sitemap_index.xml
Use when: You don’t have crawl-bloat issues and you want to avoid accidental blocking.
Example 2: Minimal + block wp-admin
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml
Use when: You want the common WordPress default restriction plus a clear sitemap pointer.
Final checks before you hit publish
- Does /robots.txt load with a 200 status and show your intended content?
- Did you avoid Disallow: / on a live site?
- Is your Sitemap: URL correct and accessible?
- Did you avoid blocking CSS/JS folders that affect rendering?
When in doubt, revert to the minimal file and only add restrictions after you can explain exactly what they do and why you need them.
