2026 年 WordPress robots.txt 最佳实践（到底该写什么）

一份好的 WordPress robots.txt 大约五行。屏蔽 /wp-admin/、放行 admin-ajax.php、把爬虫指向你的站点地图，然后就停下——论坛上那种动辄 40 行的屏蔽清单，大多要么破坏渲染，要么什么也不做。完整文件如下：

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

把域名换成你自己的；如果你用的 SEO 插件接管了站点地图，就把 Sitemap 那行指向该插件的索引地址。就这么多。如果你的文件比这长，多出来的那些行很可能正在让你付出代价。

WordPress 本来就会生成一份——直到你自己建了真实文件

WordPress 自带一份虚拟 robots.txt。当 /robots.txt 的请求进来、而网站根目录下没有真实文件时，WordPress 会拦截请求并在内存中输出响应。磁盘上什么都不会写。默认输出就是上面那段 wp-admin 屏蔽规则，再加一条指向 wp-sitemap.xml 的 Sitemap: 行——核心从 WordPress 5.5 起就会输出它。

有两件事会改变这个输出。如果设置 → 阅读 → 建议搜索引擎不索引本站点被勾上，WordPress 会把整份内容替换成 Disallow: /，也就是屏蔽一切。这个勾选框是站点上线后从搜索中消失的头号原因。其次，插件和主题可以通过 robots_txt 过滤器修改虚拟输出，SEO 插件就是这样塞进自己的站点地图行和规则的。

接下来是最浪费大家时间的那一点。网站根目录里的物理 robots.txt 文件会静默地覆盖以上全部。 Web 服务器在磁盘上找到真实文件，直接交出去，WordPress 根本不会加载。虚拟生成器不会运行，robots_txt 过滤器也不会触发。你的 SEO 插件的 robots.txt 编辑器可能还显示着漂亮的界面和正确的规则，但这些统统到不了爬虫那里。

规则存放在哪里	能否在 WordPress 后台编辑	真实请求时谁生效
虚拟（磁盘上无文件）	可以，通过 robots_txt 过滤器或插件	仅当不存在物理文件时
网站根目录的物理文件	只有当插件能写磁盘时才可以	始终生效

所以在排查任何问题之前：先在浏览器打开 https://yoursite.com/robots.txt，然后用 SFTP 或主机商的文件管理器，看看 wp-config.php 和 .htaccess 旁边是不是躺着一个真实的 robots.txt。如果有，那个文件就是你的 robots.txt。要么就在那儿改，要么删掉它让 WordPress 接管——但只能二选一。两套并存，正是站点最后留着一个谁也找不到的过期站点地图 URL 的原因。

为什么屏蔽 /wp-admin/ 却放行 admin-ajax.php

/wp-admin/ 放的是后台。这些 URL 出现在搜索结果里毫无用处，抓取它们只是把抓取预算烧在会跳转到登录页的地址上。屏蔽这个目录没有任何争议。

admin-ajax.php 虽然在这个目录里，却不是后台页面。它是插件和主题用来处理前台 AJAX 请求的端点——加载更多按钮、筛选后的商品列表、计算器、表单。如果爬虫抓不到它，就看不到这些功能加载的内容，Google 渲染出来的页面就跟一个访客看到功能坏掉时一样。

Google 是否真的需要在你这个站点上抓取 admin-ajax.php，取决于你的前台用不用它。老实说：在很多现代站点上这完全无关紧要，因为主题改用了 /wp-json/ 上的 REST API。这行 Allow 是针对一种真实故障模式的廉价保险，不是排名因素。留着它，因为它不花任何成本。

不要屏蔽 /wp-content/ 或 /wp-includes/

这是至今仍在流传的最糟糕的一条 robots.txt 建议，它来自 Google 还不会渲染页面的年代。

/wp-content/ 装着你的主题、插件和上传文件——那些让你的页面看起来像页面的样式表、脚本和图片。/wp-includes/ 装着插件依赖的核心 JavaScript。Google 会先用无头浏览器渲染你的页面，然后再评判它。屏蔽这些目录，渲染器拿到的就是一个没有 CSS、没有图片的页面。Google 评估的是一堵没有样式、版式破碎的文字墙，这会影响它对你内容的理解，也会影响它给出的移动端易用性评分。

如果你接手的文件里有下面这些行，删掉它们：

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

你可以在 Google Search Console 的网址检查工具里亲自确认这种损害。对任意页面运行一次实时测试，查看渲染后的截图，再看页面资源列表里有没有被屏蔽的项。如果你的 CSS 显示为被屏蔽，那就是原因。

Sitemap 指令

一行，绝对 URL，而且可以放在文件任意位置——它不属于任何 User-agent 分组。

Sitemap: https://example.com/wp-sitemap.xml

用那个真正能打开的 URL。WordPress 核心提供的是 wp-sitemap.xml。多数 SEO 插件会关掉核心站点地图，改在另一个路径提供自己的索引，通常是 sitemap_index.xml。写进去之前先在浏览器里加载一遍——一条指向 404 的 Sitemap 行比没有这行更糟，因为它在审计时看起来是对的。

列多个站点地图也没问题，一行一个。在 Search Console 里单独提交站点地图仍然值得做；robots.txt 里的这条指令，是那些永远看不到你 Search Console 账户的爬虫找到它们的方式。

robots.txt 不是 noindex，也不是安全措施

这两个误解造成了 robots.txt 的大部分破坏。

屏蔽一个 URL 并不能把它从 Google 里删掉。 robots.txt 管的是抓取。如果别的网站链接到了被屏蔽的 URL，Google 仍可以收录这个网址本身——你会得到一条只有裸地址、并注明无可用信息的结果。还有一个更阴的陷阱：如果某个页面已经带了 noindex meta 标签，你随后又在 robots.txt 里屏蔽了它，Google 就抓不到它，也就看不到那个 noindex，这个页面可能会无限期地留在索引里。要移除一个页面，就允许抓取，并在页面头部输出 noindex 的 meta robots 标签，或者输出 X-Robots-Tag HTTP 响应头。Google 从 2019 年起就不再支持 robots.txt 里的 noindex 指令了。

屏蔽一个路径并不能保护它。 你的 robots.txt 按定义就是公开的。把 /private-client-files/ 列出来，等于告诉每个访客和每个扫描器该去哪儿找，而遵守与否全靠自觉——Google 会遵守，敌意机器人不会。任何需要保护的东西，需要的是身份验证、IP 限制，或者 .htaccess 里的服务器层规则，而不是一行把目标公之于众的文本。

值得加的规则，和该跳过的规则

有两条补充在很多站点上确实有用。屏蔽搜索结果路径，可以避免爬虫从你的站内搜索里生成无穷无尽的低价值 URL。在 WooCommerce 上屏蔽购物车或结账路径，可以让带会话参数的 URL 不进入抓取。

Disallow: /?s=
Disallow: /search/

这些跳过：

• Crawl-delay——Google 完全忽略它。如果你真有服务器负载问题，用 Search Console 里的抓取频率控制。
• 屏蔽 /feed/ 或 /trackback/——这些是无害的 URL，而且订阅源是有用的。
• 一长串具体的机器人名称——大家想屏蔽的那些机器人，多数本来就不会诚实地表明身份。
• 屏蔽 /wp-json/——你的主题可能正靠它来渲染内容。

用 WordPress robots.txt 生成器来构建这个文件，它会生成最简的正确版本，并让你在不用手写语法的情况下加上搜索和电商相关的规则。

改完之后

直接加载 https://yoursite.com/robots.txt，确认服务器实际交出的内容就是你期望的——而不是插件编辑器显示给你的内容。然后在 Search Console 里对一个普通页面跑一次实时网址检查，确认没有任何 CSS 或 JavaScript 资源返回”被屏蔽”。Google 对 robots.txt 的缓存大约是一天，所以修复不会立刻生效，出错也不会立刻显现。正是这个延迟，才让”认真验证”比”直接改上线然后干等”更值得。