百度不收录怎么排查：从发现、抓取到索引的完整清单

先给现象分层，避免把所有问题都叫作不收录

同一个 site: 查询无结果，可能代表页面尚未进入索引，也可能只是该查询口径没有展示。先在百度搜索资源平台核对站点与资源提交状态，再取得生产 URL 的 HTTP 响应、HTML 源码和服务器访问日志。

URL 未被发现时，日志中通常没有相应抓取；已发现未抓取时，可在平台反馈或站内发现路径中找到线索；抓取后没有索引，则要继续检查规范化、重复内容和页面价值。

按优先级执行技术检查

第一优先级是阻断性问题：DNS、TLS、持续 5xx、robots 误拦截、noindex、错误 canonical 和需要登录。第二优先级是发现与规范化：孤立页、Sitemap 中的重定向地址、参数重复页。第三优先级才是内容重写。

用 curl -I 查看最终状态码和 Location；直接查看页面源代码确认 title、description、H1、正文和 canonical 已存在；robots.txt 只能控制抓取，不能作为权限控制或可靠的移除索引工具。

curl -I https://example.com/article
curl -s https://example.com/article | grep -E '<title|canonical|<h1'
curl -s https://example.com/robots.txt

用服务器日志判断是否抓取

按目标 URL、时间、状态码、响应耗时和已核验的爬虫身份查询日志。不要只相信 User-Agent，因为它可以伪造。先看目标页面是否被访问，再看访问是否稳定返回 200，以及抓取后是否持续出现重定向或服务器错误。

没有抓取记录不等于被惩罚；它更常说明发现路径、观察窗口或身份验证尚不足。抓取频繁也不等于一定会索引。

完整示例：新教程发布七天仍无可见结果

某教程在栏目中可见，但日志显示请求一直访问带追踪参数的旧地址，旧地址 302 到新页，而 Sitemap 又列出另一个尾斜杠版本。处理结论不是增加关键词，而是统一内链、canonical 与 Sitemap 到一个 200 URL，删除追踪参数入口，并保留旧地址单跳重定向。

修复后第 1 天复查状态码、robots、HTML 与 canonical；第 2—3 天观察日志是否抓取规范 URL；第 4—7 天核对平台反馈和目标 URL 的实际搜索表现。若已抓取仍未索引，再比较页面是否与既有文章重复、是否提供独立答案和来源。

七天复查清单

每天记录事实，不写“预计已收录”。同一表保存检查时间、URL版本、HTTP状态、抓取记录、平台反馈和下一动作。

• 第1天：技术阻断与规范URL
• 第2天：站内入口和Sitemap
• 第3天：日志中的抓取与响应
• 第4天：重复页与canonical一致性
• 第5天：正文独立价值与来源
• 第6天：内部链接和移动端HTML
• 第7天：汇总证据并决定继续观察、合并或修复

百度搜索资源平台里的检查入口怎么用

先完成站点验证，再查看资源提交、抓取异常、robots和站点属性相关入口。平台名称与字段可能调整，因此操作时以当前界面为准；台账中记录检查日期、入口名称和截图编号，不把“已提交”写成“已收录”。

URL提交用于帮助发现；抓取异常用于定位服务器或访问问题；robots工具用于验证路径匹配。平台反馈与服务器日志应互相印证：平台报抓取失败时，日志要找到对应时间和状态；日志无访问时，不应凭猜测归因内容质量。

内容价值与站点质量如何判断

技术检查全部通过后，再比较该页与站内已有页面：是否回答独立问题、是否提供原始证据、是否只是同义改写、标题承诺是否在正文完成。一个有用页面应让读者能够完成任务，而不是为搜索引擎重复定义。

站点层面还要查看大量薄页、重复模板、失效链接和服务器不稳定是否降低整体可用性。不要因为单页暂未索引就批量改标题；先用抽样检查确认问题发生在单页、模板还是全站。

证据台账、复现方式与升级条件

建立按URL逐行记录的诊断台账：规范URL、发现入口、Sitemap最后修改时间、robots判定、HTTP最终状态、重定向链、canonical、首屏正文长度、抓取时间、已核验爬虫地址、平台反馈、实际查询和负责人。每次检查写UTC时间与工具版本，原始响应保存为附件。这样可以区分“从未抓取”“抓取失败”和“抓取成功但未进入可见索引”，也能避免不同同事重复提交却没有新证据。日志保留周期必须覆盖观察窗口，并按隐私策略去除查询参数中的个人信息。

复现时从未登录环境访问，分别请求桌面和移动常见User-Agent，确认服务器在不执行客户端脚本时已经返回标题、唯一H1、直接答案、主体和规范链接。检查缓存节点是否一致，连续请求不应在200、403和5xx间波动。若HTML仅返回骨架、关键内容依赖接口、canonical指向其他页面或Sitemap仍列旧URL，应先修技术问题。修复必须从首页或栏目真实点击到页面，再重跑抓取，不用地址栏直达代替信息架构验证。

技术与内容检查均完成后仍长期没有明确解释，可通过百度资源平台反馈，提交规范URL、首次发现时间、最近一次抓取证据、服务器状态摘要和已完成动作。不要发送后台密码、日志中的IP或用户数据。升级后保持页面与URL稳定，在合理观察期内避免每天改标题和日期。是否收录、何时收录与排名均由线上系统决定；没有平台证据时状态只能记为UNKNOWN，而不能写成已恢复。

多URL与改版场景的额外检查

站点改版或协议、主机、路径变化时，先列出旧新URL映射，保证旧地址单跳到最相关的新地址，新地址返回200且自指canonical。导航、正文、Sitemap、hreflang及结构化数据统一使用新地址，旧Sitemap可短期保留用于发现迁移但要记录策略。分页、筛选、打印版和追踪参数若生成近似内容，应明确哪些允许抓取、哪些合并。迁移期间分别监控旧新URL日志与错误，不能因site命令短期波动立刻撤销重定向。若无法取得搜索平台或真实日志证据，迁移效果保持待验证。