不要为了SEO直接关闭WordPress REST API。它是WordPress编辑与扩展功能使用的数据接口，关闭整套接口可能让编辑器保存、前台商品加载或自定义应用出问题。应先判断要解决的是未授权数据访问、异常请求，还是页面内容无法被搜索引擎读取，再按具体路由、调用者和权限处理。
看到wp-json公开访问，不等于发现漏洞
WordPress REST API手册说明，公开内容通常也可以通过REST API公开访问，私有或受保护的内容则受身份验证限制，或取决于是否被专门配置为公开。这是数据访问机制的设计。能读取一篇本来就公开的文章，不能单独证明越权。
真正需要排查的是接口是否暴露了本应私有的字段，或是否允许没有权限的人执行写入。不要在工单里粘贴真实令牌、客户记录或完整订单响应；保留字段名称、权限预期与脱敏后的错误证据即可。自定义接口还要核对开发人员配置的权限检查，不能用WordPress核心默认行为为所有插件担保。
原创场景示意：同一套数据接口可能服务编辑、展示与移动应用；画面不是网络拓扑实测，也不代表任何客户系统。
官方为什么不建议整体禁用
REST API官方常见问题直接指出，不应禁用REST API，因为这会破坏依赖接口的WordPress后台功能。该文档也提供了要求身份验证的示例，但“限制匿名访问”同样会影响依赖公开读取的应用，不是一段对任何网站都安全的通用加固代码。
例如一个假设的产品目录，首屏标题由服务器输出，产品卡片却在浏览器里通过公开接口加载。匿名请求一旦被统一拒绝，管理员登录后仍能看到卡片，普通采购者却只见空白。只测试后台账号，是这类改动最容易产生的误判。
因此需要把三个问题分开问：谁在调用，读取或修改什么，当前是否允许该调用者做这件事。以路由和操作为单位确认，比把所有包含wp-json的请求一律拦截更准确。限流、字段权限和认证失败也不能混作同一种故障。
先建立依赖清单，再讨论限制方式
- 在测试副本打开编辑器，观察加载、保存和预览时的网络请求。只记录路径、请求方法、状态码及功能，不保存凭据。
- 退出登录后访问首页、产品页、搜索、筛选和分页。记录哪些内容依赖接口，哪些在初始HTML中已经存在。
- 向集成负责人确认移动应用、同步工具或Headless前端使用的路由及认证方式。不能因为浏览器里没看到请求，就认为外部集成不存在。
- 对每个拟限制路由写出预期：允许哪些公开读取、哪些操作需要认证、哪些角色可以修改。无法解释用途的路由先调查，不先封禁。
浏览器出现403时，还要核对响应来自WordPress、反向代理还是安全服务。有些防护会返回HTML验证页面，前端却按JSON解析，于是显示的只是“数据错误”。保留状态码、内容类型和错误发生的页面，有助于维护人员找到实际拦截层。
SEO核查应看商品内容，不只看接口能否返回JSON
REST接口可访问，并不代表最终页面已经具备可搜索的内容。应直接访问产品URL，检查名称、主要说明、规格和普通导航链接是否呈现；再比较初始HTML与脚本执行后的页面。接口返回正确商品而模板没有渲染出来，仍然是前台故障。
反过来，某个与公开内容无关的受保护接口返回认证失败，也不必被当作SEO错误。Google的JavaScript SEO基础文档解释了抓取和渲染过程。需要验证的是爬虫访问目标页面时能否获取应公开的内容与链接，而非追求全站每个接口都返回200。
使用自定义前端时，可以继续按Headless电商上线检查核对路由与HTML。若只是原生搜索页设置异常，则应回到搜索结果页noindex输出排查，不用关闭API替代索引控制。
把一次接口错误写成能执行的工单
例如一个教学场景：匿名访客打开目录页后标题正常、产品卡片空白，网络记录显示某个公开商品读取路由返回403。记录应包括目录URL、该路由、请求方法、发生身份、期望可公开字段和实际响应类型。不要写成“REST坏了，请打开全部接口”，因为另一些路由可能本来就应该拒绝匿名访问。
如果恢复该路由后前台显示正常，继续检查它是否只返回计划公开的信息，以及正常编辑和外部集成是否仍然工作。工单的完成条件应同时包含功能与权限，而不是“403变200”这一项。对写入接口尤其如此：无权限调用得到拒绝，本身可能正是应该保留的正确结果。
限制生效后，用不同身份复测
至少分别检查匿名访客、日常编辑角色以及已登记的应用调用方式。测试应包括正常读取、允许的写入、明确禁止的操作和出错后的可见反馈，写入测试只在获准的测试环境进行。不要用管理员成功保存一篇文章，证明所有角色都正常。
光算的网站技术优化可按项目核对接口依赖与内容渲染，安全策略、账号权限和集成改造应另行明确负责人。最终选择可能是保留接口并修正某个路由，而不是安装一个“全关”插件。没有实际店铺回归之前，只能称为方案，不能称为已经安全上线。