摘要：说明企业文章页返回200却未被正常收录时，如何检查页面索引标签、响应头、重定向、规范地址和缓存，定位误加noindex的来源，并在保留必要屏蔽页面的前提下完成修正与复核。
内容人员发布了一篇设备选型文章，浏览器打开正常，销售也能把链接发给客户，但搜索检查一直看不到收录。技术人员查看源码后发现，页面头部的robots元标签保留了测试阶段的noindex指令。HTTP状态码200只说明页面可以访问，noindex却在告诉搜索系统不要把它放进结果。排查时要同时检查页面标签、响应头和模板来源。
页面返回200为什么仍然不能正常收录
抓取和收录不是同一个环节。搜索程序可以访问页面、读取正文，随后仍会按照robots元标签决定是否建立索引。页面若含有noindex，日志里可能留下多次抓取记录，站点地图也能提交成功，但这两件事都不会覆盖页面自己的禁止索引指令。
同一指令还可能出现在HTTP响应头中。服务器返回X-Robots-Tag: noindex时，源码里即使没有robots标签，结果也一样。排查要记录最终URL、状态码、响应头和渲染后的head内容。只用浏览器肉眼看正文，容易漏掉响应层的限制。
重定向会让判断更复杂。旧地址先返回301，新地址返回200，但新页面带noindex，最终仍不能正常进入结果。若跳转中间经过登录页、地区判断或移动端地址，还要沿每一跳检查Location，确认用户与搜索程序到达的是同一个公开页面。
noindex通常从哪些发布环节被带到正式页面
常见来源是测试环境模板。项目上线时只替换域名，没有移除全局noindex；也可能是后台给栏目设置了“不允许索引”，文章继承了栏目规则。若只有部分页面异常，应对比同栏目正常页与异常页的模板、内容状态和缓存文件，而不是直接修改全站head。
有些系统按内容状态输出指令。草稿、定时发布、需要密码或缺少栏目归属时，模板会自动加入noindex。文章后来改为公开，页面缓存却仍保存旧head。此时数据库状态已经是已发布，公网源码仍是旧指令，需要清理对应页面缓存并重新请求，不能只在后台反复保存。
插件和服务器规则也会叠加。页面源码可能输出index,follow，Nginx却给某个目录统一添加X-Robots-Tag。检查时可建立一张记录：URL、内容ID、栏目、页面robots、响应头指令、canonical、HTTP状态和检查时间。型号文章、资料下载页与搜索结果页应分别核对，不要用首页结果代替全站判断。
同一个页面还要分别用普通浏览器与命令行请求核对。若两次结果不同，可能存在设备识别、登录Cookie或缓存节点差异。记录Server、Cache-Control和Age等响应字段，能帮助技术人员判断旧指令来自源站还是中间缓存。
canonical需要一并查看。页面允许索引，但canonical指向另一篇内容时，搜索系统可能把信号合并到目标地址；页面同时存在noindex和跨页canonical，意图更含混。每篇独立文章应使用自引用canonical，只有确实重复的地址才指向主版本。
移除指令后怎样完成发布与复核
修正前先找到指令来源。若来自栏目设置，就在后台调整对应栏目；若来自模板条件，核对判断字段；若来自响应头，修改具体目录规则。不要用脚本直接删除所有页面里的noindex，因为登录页、站内搜索页或临时结果页可能本来就不应进入索引。
修改后按最终公开地址重新检查：状态码应为200，页面head中没有noindex，响应头也没有禁止指令，canonical指向自身。正文标题、型号和主要段落应能在渲染结果中读取。页面若引用图片，图片URL也要返回200，alt说明图片内容，不用关键词列表代替。
站点地图应保留这条可索引URL，lastmod使用本次实质修正日期。若旧地址已经301到新地址，地图只放最终地址。随后清理页面缓存，从外部网络再次请求，避免服务器本地看到新页面，CDN节点仍返回旧响应头。
复核记录可保存修正前后的响应头、源码片段、修改位置、发布时间和负责人。后续模板升级或栏目复制时，抽查一篇新文章和一篇旧文章，确认索引指令没有被重新带回。能打开只是可访问的起点；状态、索引指令、规范地址和正文同时一致，页面才具备正常参与搜索的条件。
