先把四个状态分开

页面提交之后,最容易出现的误判是把“接口返回成功”直接写成“搜索引擎已经收录”。实际上,提交、抓取、索引和 AI 引用是四个不同层次的状态。每一层都要有自己的证据,不能用上一层的结果代替下一层。

状态它回答什么问题可以使用的证据不能直接推出什么
已提交站点是否把 URL 通知给了某个平台?IndexNow、百度主动提交等接口的请求时间、状态和响应。不能推出平台已经请求页面或建立索引。
已抓取平台或机器人是否请求并取得了页面?核验后的服务器日志、平台抓取诊断或官方抓取记录。HTTP 200 不等于页面一定进入索引。
已索引页面是否进入某个搜索系统的可检索数据库?对应平台的 URL 检查、稳定的结果证据或官方索引报告。不能推出有排名、点击或 AI 引用。
被引用某个 AI 产品是否在某次回答中展示并使用了页面?问题、模式、完整回答、来源链接、页面版本和人工核对。不能反推所有搜索引擎都已收录。
复测的最低结论

“截至某时间,某平台接收了 URL 通知”是合格结论;“已经被抓取”“已经收录”“已经被 AI 引用”必须分别取得对应证据。没有证据的状态保留为未知,不要填成否定。

复测前先冻结页面版本

复测不是反复打开页面,而是比较同一页面在不同时间点的状态。开始前应保存规范 URL、页面版本、发布日期、最近修改日期、canonical、meta robots、正文摘要和 sitemap 中的 lastmod。若复测期间页面又被编辑,后面的结果就不再对应同一个样本。

建议为每个页面生成一条最小快照:

url: https://example.com/guide/
content_version: 2026-09-27
snapshot_at: 2026-09-27T09:00:00+08:00
http_status: 200
canonical: https://example.com/guide/
robots: index, follow
sitemap_lastmod: 2026-09-27
submission_status: accepted
submission_at: 2026-09-27T09:05:00+08:00

这里的 content_version 不一定要是 Git commit,也可以是内容修改日期或发布系统生成的版本号,但规则必须稳定。页面正文、标题、来源和关键结构发生变化时,应产生新的版本;仅仅重新打开页面不应产生新版本。

用 T+0、T+1、T+3、T+7 分层复测

不同平台的抓取调度和数据更新速度不同,因此不建议只在发布后马上查询一次。下面是一套适合新教程站的观察窗口。它是站长侧的复测协议,不是搜索平台承诺的处理时限。

窗口主要任务应记录的结果此时仍不能下的结论
T+0:发布后确认线上页面和机器入口没有发布错误,并记录提交响应。页面状态、canonical、robots、sitemap、IndexNow/百度接口结果。不能写成已抓取或已收录。
T+1:约 24 小时查看服务器日志和各平台能提供的发现、抓取或 URL 检查信号。请求时间、路径、身份核验状态、平台检查结果。一次没有机器人请求不等于平台永远不会抓取。
T+3:约 72 小时重复同一检查,观察状态是否从提交或发现进入更强证据层。同一 URL 的状态变化、首次抓取时间、索引工具结论。状态变化不能直接归因于某一次提交,除非证据足够。
T+7:约一周汇总平台状态,并开始固定问题的 AI 检索观察。平台、查询时间、答案、来源链接和内容支持关系。单次 AI 结果不能代表长期引用率。

如果页面是新闻、活动或价格等时效内容,可以缩短窗口;如果是长期教程,T+3 和 T+7 往往比发布后几分钟的查询更有解释价值。重要的是提前写下窗口和判定规则,避免看到结果之后才修改标准。

每个窗口先做页面技术检查

平台状态异常时,先排除站点自身问题。用正式 HTTPS URL 检查页面,不能只检查本地开发地址,也不能只看浏览器渲染后的视觉效果。搜索系统通常需要取得原始 HTML、响应头和可访问的资源。

  1. 规范 URL。确认 HTTP、www、尾斜杠和带参数版本会归一到同一个正式地址。
  2. 响应状态。公开页面应稳定返回 200;301/308 只能说明发生了重定向,不能把跳转入口当成正文页面。
  3. canonical。检查 canonical 存在、可解析、指向正式页面,并与 sitemap 和内部链接使用同一版本。
  4. 索引指令。检查 meta robots、X-Robots-Tag 和 robots.txt 没有意外阻止页面或关键资源。
  5. 正文可读。标题、H1、核心答案、来源和更新时间应直接出现在 HTML 中,不应只依赖登录态或客户端脚本。
  6. 发现路径。确认页面出现在栏目页、相关内链、sitemap、RSS 或适用的主动提交台账中。

一个简单的公开检查可以帮助发现最明显的问题:

curl -sS -D headers.txt -o page.html \
  https://example.com/guide/

grep -iE 'HTTP/|content-type|location|x-robots-tag' headers.txt
grep -iE 'canonical|robots|<title>|<h1' page.html

命令输出只能说明这次请求看到的响应。它不能模拟所有搜索平台的抓取环境,也不能代替平台自己的 URL 检查。检查时还应记录请求时间、请求主机、是否经过 CDN、是否登录以及是否携带了特殊 User-Agent。

服务器日志如何判断“有蜘蛛来过”

日志是观察抓取的重要材料,但“日志里有一个自称蜘蛛的 User-Agent”并不等于身份已经核验。User-Agent 可以被伪造,代理、共享网络、平台基础设施和用户触发的预取也可能让来源解释变复杂。

建议每条候选请求至少保存这些字段:

字段用途公开报告是否需要脱敏
时间与时区与平台提交、发布和 DNS 核验对齐。可以公开日期和时间窗口;不必公开精确个人访问时间。
Host 与路径确认请求确实命中了目标站点和目标页面。公开路径通常可以;后台、参数和敏感路径应谨慎处理。
方法与状态区分 GET、HEAD、重定向、限流和错误。可以公开方法与状态码。
IP 与 User-Agent进行来源候选分析和平台身份核验。公开样本应删除或聚合 IP,必要时截断 User-Agent。
反向与正向 DNS 结果验证主机名是否符合平台规则,避免只相信 PTR。保留核验时间和结论即可,原始地址按隐私政策处理。
核验状态明确区分自报、待核验、已核验、已知人工测试和排除。必须公开状态含义,不能把候选写成确认。

对 Google 等平台,官方建议通过反向 DNS 后再做正向解析确认;其他平台也应遵循其当前官方核验规则。一次通过的身份核验只能支持这一次或这一组请求的来源判断,不能把同一 User-Agent 的所有请求永久标记为真实蜘蛛。

百度、Bing 和 Google 的状态如何分别看

复测表必须带有 platform 字段。不同平台的工具、字段和更新节奏不同,不能把“发现”“已查询”“提交成功”和“已索引”统一翻译为一个绿色状态。

平台优先证据建议写法需要保留的未知
百度搜索资源平台的提交、抓取诊断、索引工具和服务器日志。“百度普通收录接口已接收”;“本次抓取诊断取得预期正文”。提交是否转化为索引、单 URL 是否稳定展示。
BingWebmaster 工具、URL 状态、IndexNow 响应和经过核验的日志。“Bing 返回 discovered”;“IndexNow 接口返回 200”。discovered 是否已经建立索引,是否有排名或点击。
GoogleURL Inspection API、Search Console 页面和 Google 抓取日志。记录 verdict、indexingState、lastCrawlTime 和检查时间。未配置、接口不可达和未检查不能填成未收录。

百度普通收录页面明确区分了提交和收录;IndexNow 官方文档也说明成功响应只表示搜索引擎收到 URL。Google 的 AI 功能文档则要求页面先满足搜索技术资格才能作为支持链接出现,但这仍不是某个问题下必然被引用的保证。把这些边界写入台账,后续才不会因为平台字段名称不同而误算。

常见 HTTP 状态码怎么解释

状态当前请求说明复测动作不要写成
200这次请求取得了正常响应。检查正文、canonical、robots 和内容版本。搜索引擎已经收录。
301/308请求被永久归一到另一个 URL。跟随并检查目标页面,同时确认 sitemap 使用目标地址。重定向入口就是已收录页面。
403这次请求被权限或防护策略拒绝。确认是否误伤真实平台、验证文件或公开教程。平台一定被拦截,或一定不是平台。
404/410资源不存在或已明确删除。检查 URL 是否写错;删除页面则维护重定向、内链和 sitemap。页面只是暂时没有被收录。
429请求过多,触发限流或访问控制。降低频率,读取 Retry-After,并核对是否为敏感路径扫描。百度蜘蛛已经被永久拦截。
5xx服务器或上游在这次请求中发生错误。检查应用日志、反向代理、资源压力和重试结果。搜索引擎已经放弃这个页面。

状态码只描述一次 HTTP 请求。要判断它是否影响某个平台,必须结合请求时间、来源核验、路径类型、平台规则和后续重复观察。尤其是 429:对敏感探测路径限流可能是正确的安全策略,但对已核验的公开教程页面长期返回 429 就需要单独排查。

按症状排查,而不是反复提交

观察到的现象优先排查下一步记录
接口成功,日志没有平台请求平台抓取调度、服务器是否可达、Host/HTTPS 归一和日志采集范围。提交时间、接口响应、公开页面健康状态,抓取保持未知。
日志有请求,身份无法核验IP、DNS、代理、User-Agent 和是否为人工测试。标为候选或待核验,不把它写成真实蜘蛛。
平台发现 URL,但索引状态未知平台工具是否只报告发现、缓存是否过期、是否需要更长观察窗口。保存原始字段和检查时间,保留未知。
页面可访问,平台仍不建立索引重复内容、canonical、noindex、正文质量、主版本和平台反馈。记录具体证据,不通过重复提交制造成功信号。
搜索中出现 URL,AI 没有引用AI 产品是否联网、问题相关性、来源选择和答案模式。另建 AI 观察,保存问题、回答、来源和支持关系。
AI 提及品牌但没有页面链接回答中的事实是否独有,是否能与页面正文逐句对应。分别记录品牌提及、页面引用、内容采用和引用准确性。

后台应该保存哪些字段

后台的复测记录最好采用“一个页面、一个平台、一个窗口、一条结果”的粒度。页面版本和平台观察不要覆盖写入;同一 URL 的 T+1 和 T+3 应该是两条记录,才能看出状态何时变化。

url: https://example.com/guide/
content_version: 2026-09-27
platform: bing
window: T+3
tested_at: 2026-09-30T09:00:00+08:00
technical_status: pass
submission_status: accepted
crawl_status: unknown
index_status: discovered
index_source: webmaster-api
evidence_url: https://example.com/guide/
notes: discovered is not confirmed indexed

对抓取日志还应增加 request_id、状态码、核验状态和响应摘要;对 AI 观察则增加问题原文、产品模式、联网开关、完整回答、来源链接、页面版本和人工审核结论。null 或 unknown 表示尚未取得证据,不表示结果为 0 或没有发生。

公开展示时应删除 IP、凭证、登录信息和不适合公开的完整对话;后台内部可以在权限和保留期限范围内保存更细的安全审计字段。公开报告要让读者能复核方法,却不应把访问者或平台账号暴露出来。

复测结果怎样服务 GEO

复测的价值不是证明“提交次数越多越容易被 AI 引用”,而是找出内容链路中断在哪一层。如果页面无法稳定访问,先修技术;如果页面被抓取但没有进入相关检索结果,检查标题、实体、问题匹配和答案结构;如果页面进入候选但答案引用不准确,检查声明、条件和证据是否靠近;如果页面被准确引用但没有点击,再研究来源展示和落地页承接。

搜索复测结果GEO 内容动作
页面无法访问或被误限流修复公开访问、代理、缓存和防护规则,不先改写正文。
页面可抓取但主题不清补充实体定义、问题场景、页面角色和明确的 H1/H2。
页面被检索但答案未采用把结论、条件、证据和边界写成独立可理解的答案单元。
答案采用但来源不准确核对引用上下文、日期、适用条件和页面版本,必要时修正声明。
引用准确但没有稳定重复冻结问题和环境,扩大观察窗口,不把单次结果写成长期排名。

这条链路也解释了为什么“搜索引擎收录少”不能直接等于“GEO 不可能”。搜索索引是重要发现渠道,但 AI 产品的搜索源、缓存、联网模式和来源展示并不完全相同。任何平台结果都应带平台、模式、时间、问题和证据链接。

ZenLeak 的复测安排

ZenLeak 当前把 IndexNow 提交台账、百度主动提交、服务器爬虫活动、页面健康检查、搜索平台收录查询和国内 AI 基准观察放在不同模块中。它们可以在同一个后台查看,但状态不会被合并成一个“收录成功率”。

对新发布教程,建议先在后台保存 T+0 页面健康与提交结果;之后由人工在 T+1、T+3 和 T+7 复测同一正式 URL。后台应保留每轮的版本和时间,即使结果没有变化也要记录“已复测,状态保持未知”或“已复测,仍为 discovered”。

现有实验已经采用这种边界:机器入口返回 200 只证明检查时能取得响应,Bing 返回 discovered 只证明平台报告了发现,百度提交台账只证明接口接收;搜索收录、AI 检索和显式引用继续等待各自证据。后续新增数据必须补齐完整问题、回答、来源和核验条件,不能用缺失样本填充成功率。

常见问题

提交后多久应该复测?

没有适用于所有平台的统一时间。教程站可以采用 T+0、T+1、T+3、T+7 的观察窗口;这是一套可重复的记录节奏,不是平台承诺的收录时限。

页面返回 200,为什么还没有收录?

200 只说明本次请求取得正常响应。搜索系统还要判断是否抓取、是否选择 canonical、是否建立索引以及是否在结果中展示。

看到 Baiduspider 的 User-Agent 就算百度蜘蛛吗?

不算。User-Agent 可以被伪造,应结合 IP、反向与正向 DNS、访问行为和官方规则核验,并把候选、人工测试和已核验请求分开。

IndexNow 已经返回 200,还要重复提交吗?

通常不需要对同一版本反复提交。应先等待并复测页面、日志和平台状态;重复提交不能修复正文、canonical、限流或索引质量问题。

Google 没有数据时应该记为未收录吗?

不应该。要区分 Google 检查关闭、服务不可达、尚未检查、接口失败和明确的索引状态;没有取得证据时保持未知。

搜索结果出现页面,是否代表 AI 会引用?

不代表。搜索可见性、AI 检索、答案采用、显式来源和引用准确性是不同指标,必须用固定问题和对应平台证据单独复测。

发布后复测清单

  • 冻结正式 URL、内容版本、发布时间、修改时间和复测时区。
  • 记录页面 200/301/404/429/5xx 状态,并核对最终 URL。
  • 检查 canonical、meta robots、X-Robots-Tag、robots.txt 和 sitemap。
  • 确认正文、H1、来源、更新时间和核心答案在公开 HTML 中可读。
  • 保存 IndexNow 或百度主动提交的请求时间、响应状态和批次。
  • 把 User-Agent 候选与真实身份核验分开,保存 IP/DNS 核验时间和结论。
  • 分别记录百度、Bing、Google 的平台、工具、状态和检查时间。
  • 在 T+0、T+1、T+3、T+7 复测同一版本,不用新版本覆盖旧结果。
  • AI 复测保存问题、模式、联网状态、回答、来源链接和页面支持关系。
  • 未知保持未知,不把提交成功、200、discovered 或品牌提及写成完整收录或引用。

延伸阅读