先把四个状态分开
页面提交之后,最容易出现的误判是把“接口返回成功”直接写成“搜索引擎已经收录”。实际上,提交、抓取、索引和 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、响应头和可访问的资源。
- 规范 URL。确认 HTTP、www、尾斜杠和带参数版本会归一到同一个正式地址。
- 响应状态。公开页面应稳定返回 200;301/308 只能说明发生了重定向,不能把跳转入口当成正文页面。
- canonical。检查 canonical 存在、可解析、指向正式页面,并与 sitemap 和内部链接使用同一版本。
- 索引指令。检查 meta robots、X-Robots-Tag 和 robots.txt 没有意外阻止页面或关键资源。
- 正文可读。标题、H1、核心答案、来源和更新时间应直接出现在 HTML 中,不应只依赖登录态或客户端脚本。
- 发现路径。确认页面出现在栏目页、相关内链、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 是否稳定展示。 |
| Bing | Webmaster 工具、URL 状态、IndexNow 响应和经过核验的日志。 | “Bing 返回 discovered”;“IndexNow 接口返回 200”。 | discovered 是否已经建立索引,是否有排名或点击。 |
| URL 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 或品牌提及写成完整收录或引用。