网站不被收录原因：临时维护页面恢复后哪些残留信号需要核对
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bf4a655f1d10.html
📄
网站不被收录原因：临时维护页面恢复后哪些残留信号需要核对
临时维护页撤掉后，页面仍可能不被收录，这时最该核对的不是“维护页是否删干净”，而是它留下的可抓取信号是否还在生效。一个可操作的结论是：先核对返回状态码、robots 规则、页面级 noindex 和缓存响应头这四类残留，再决定是继续等待还是主动干预。如果维护期间只返回了 503 且带 Retry-After，恢复后通常只需确认状态码回正；但如果维护页曾用 200 返回并带 noindex，或者 robots.txt 曾被改成全站禁止，残留影响会明显更久。
先区分两类维护方式，残留信号的来源不同
维护页对抓取的影响，取决于当时服务器对外返回什么，而不是页面上写了什么。
- 返回 503 的维护页：这是对爬虫相对友好的做法，表示暂时不可用。恢复后主要核对 503 是否已经变成 200，以及 Retry-After 是否还挂在响应头里。
- 返回 200 的维护页：爬虫会把它当成正常内容。如果这个 200 页面还带 noindex，或者整站被临时替换成同一份维护内容，恢复后可能出现“页面内容回来了，但索引信号仍指向维护态”的情况。
判断依据是响应状态和响应头，不是维护页的视觉样式。用 curl -I 看头部，比在浏览器里看页面更接近爬虫看到的结果。
恢复后必须逐项核对的四类残留
1. 状态码与重定向链
确认目标 URL 现在返回 200，且不再经过维护页的跳转。如果维护期间把全站 302 到单一维护地址，恢复后要检查这条跳转是否彻底移除，避免爬虫仍沿着旧跳转走。跳转链越长，抓取预算消耗越多，恢复判断越慢。
2. robots.txt 的抓取限制
维护时常见的临时操作是 Disallow: /。这里有一个容易被忽略的点：robots.txt 的抓取限制不等于可靠的索引移除。它只阻止抓取，不保证已收录页面被移除；反过来，恢复 robots 允许抓取后，也不代表页面会立刻重新被抓。核对动作是直接请求 /robots.txt，确认禁止规则已删除，而不是只改回本地文件。
3. 页面级 noindex 与 canonical
如果维护页模板带过 <meta name="robots" content="noindex">，要确认它没有跟着模板残留在恢复后的页面上。同时核对 canonical 是否指回自身，而不是仍指向维护地址。这两个信号冲突时，爬虫会优先处理更明确的排除指令。
4. 缓存与 CDN 响应头
源站恢复了，边缘缓存可能还在返回维护页。核对 Cache-Control、Age 和 CDN 缓存状态，确认用户和爬虫拿到的是同一份恢复后内容。若缓存 TTL 较长，残留时间会超出预期。
一个会让上述结论失效的反例
上面四类核对成立的前提是：维护只影响了一段时间内的响应，站点本身结构没变。如果维护期间同时做了 URL 结构调整、域名切换或模板大改，那么“恢复后仍不被收录”可能来自新的结构问题，而不是维护残留。此时继续清理维护信号不会有结果，需要转而核对新 URL 的可访问性和内部链接。
另一个反例是：抓取量在恢复后短暂归零，并不单独证明处理正确或错误。它也可能是爬虫调度周期、日志采集延迟或缓存未刷新造成的。把抓取量变化当作唯一证据，容易误判。
按证据决定下一步动作
建议按以下顺序执行，每一步的结果决定下一步：
- 对目标 URL 发一次头部请求，记录状态码和响应头。若仍是 503 或跳转，先修服务端，不要进入下一步。
- 请求
/robots.txt，确认禁止规则已移除。若仍禁止，先改规则，再等待下一次抓取。 - 查看页面源码中的 robots meta 和 canonical。若存在 noindex 残留，先移除，再考虑用站点地图提交。
- 确认缓存已刷新，用户与爬虫拿到同一版本。
- 以上都正常后，再提交站点地图。注意站点地图不保证收录，它只是提供发现路径，不能替代前面的信号清理。
如果四类信号都已干净，页面仍长时间不被收录，此时应转向内容质量、重复度和内部链接的核查，而不是反复修改维护相关设置。假设某站维护期间用了 200 加 noindex，恢复后只删了维护页却没删 meta，那么无论提交多少次站点地图都不会改变结果；先移除 meta，再观察下一次抓取日志，才是有效动作。
