实测 GEOC 百度普通收录自动推送：API 显示成功，就等于已经收录吗？

一、核心结论：API 接收成功，只完成了“主动告知 URL”

先把结论说清楚：本次日志中的 success: 2 能证明百度普通收录 API 接受了两个 URL；它不能证明百度蜘蛛已经访问页面，不能证明页面已经进入索引，更不能证明用户搜索时能够看到结果。百度搜索资源平台当前公开说明也明确写道，普通收录工具用于缩短爬虫发现链接的时间，可以加快抓取，但无法解决内容是否收录的问题，平台不保证提交的链接一定收录。

这个边界很重要，因为“推送成功”在日常沟通中经常被简化成“百度已收录”。技术团队看到 HTTP 请求成功，内容团队看到工作流变绿，业务团队就可能把三者继续翻译成“页面已经可以搜到”。实际上，接口确认的是提交行为，不是搜索结果。若不拆开链路，后续发现文章还没有展示时，团队容易误判为自动化故障，或者反过来错误宣传收录效果。

我们把本次观察分成五层：页面公开可访问、API 接受 URL、爬虫发现并抓取、搜索系统建立索引、最终查询产生展示。前两层可以从网站响应和工作流日志直接核验；后三层需要百度侧抓取、索引与查询证据。本次没有登录百度搜索资源平台查看抓取或索引量，也没有取得 Baiduspider 服务器日志，因此不会越过证据说“已经抓取”。

在 2026 年 8 月 15 日复查时，本次提交的两个页面均返回 HTTP 200；站点公开 robots.txt 对通用 User-Agent 允许访问并声明 sitemap；sitemap.xml 包含两个 URL。它们共同说明页面具备公开访问和发现基础，但仍然不是索引结果。我们还尝试通过公开百度搜索页查询新文章，返回的是安全验证页面，无法获得可复现的正常结果列表，所以没有据此判断页面是否进入索引。

二、测试对象：GEOC 的自动推送流程具体做了什么

GEOC 的推送流程位于仓库 .github/workflows/baidu-push.yml。触发条件是 main 分支发生 push，并且变更路径命中 public/blog/**。这意味着新增文章会触发，修改旧文章、分类页或同一目录下其他内容也可能触发；它不是一个只在“新建文件”时运行的任务。

工作流先以深度为二检出仓库，再用本次提交前后的 SHA 做文件差异。脚本只保留符合 public/blog/(basics|methodology|tests)/.+/index.html 的文件，将仓库路径转换成 https://geoc.ai/ 下的公开目录 URL，去重后写入提交列表。这一规则排除了内容中心首页和三个分类首页，但会同时选中新增文章与被修改的旧文章。

接下来，任务检查 GitHub Secret 中是否存在百度推送 token，然后把 URL 列表以请求正文提交给百度普通收录接口。接口返回 JSON 后，脚本读取 success 字段；若它不是正整数，任务失败。token 在日志中被屏蔽，我们没有读取或展示凭证。本次实测只使用工作流源码、公开 URL 和 GitHub 运行日志。

这套流程的优点是提交动作与内容发布绑定：作者不需要复制 URL 到控制台，URL 由实际文件差异生成，不容易漏掉当天的新文章。风险也来自同一个设计：只要旧文章为了补内链、更新日期或统一品牌名而改动，它也会进入提交列表；一次大范围机械修改可能瞬间消耗当日额度。

日志时间以 UTC 保存，本文统一换算为北京时间叙述，并保留运行编号与提交 SHA 作为复核入口。时间换算只帮助阅读，不改变接口响应本身。

三、成功样本：两个 URL 为什么都被提交

成功样本对应提交 3ded81c6228be22a86beb2772b99902094b5f34c。这次发布新增了《GEO 品牌实体一致性怎么检查？》文章，同时给既有的《品牌事实底稿怎么做？》补充一条自然双向内链。由于两个文章页面都发生了变更，差异脚本生成了两个公开 URL，而不是只有新文章一个。

2026 年 8 月 14 日北京时间约 09:10，GitHub Actions 日志列出两个待提交地址：新文章 /blog/methodology/brand-entity-consistency-audit-guide/，以及更新后的 /blog/methodology/brand-fact-sheet-guide/。随后百度接口返回 {"remain":8,"success":2}，工作流步骤和整个任务都以 success 结束。

百度公开课程给出的成功响应示例同时包含 remain、success、not_same_site 和 not_valid 等字段。结合字段语义，本次 success: 2 与实际提交的两个 URL 数量相等，可判断两个提交都被接口接受；remain: 8 表示当时剩余配额，不是“还有八个 URL 等待处理”，也不是“八次抓取机会”。

本次没有收到不属于本站或 URL 不合法的列表，也没有错误状态。工作流的绿色结果与接口响应相互一致。因此，“提交层”可以判定通过。文章发布后的公开复查也确认两个地址返回 200，sitemap 中存在对应 loc 与 2026-08-14 的 lastmod。到这里，我们有了页面层和提交层的完整证据。

但从日志中看不到 Baiduspider 何时访问，也看不到百度索引库是否建立文档。即使几分钟后搜索可见，也需要额外记录查询、地区、时间和结果 URL，不能反向把 API success 当作索引凭证。成功样本的价值，是证明自动化正确生成了目标 URL 并获得平台接收，而不是证明 GEO 已经产生搜索展示。

四、失败样本：为什么一次品牌名称统一会触发“超过每日配额”

失败样本对应 2026 年 8 月 13 日的一次全站品牌名称统一。该提交修改了当时所有文章页面，因此工作流从文件差异中提取出十五个文章 URL。它们包括基础知识、方法论与平台实测三个目录，日志明确列出了全部地址。随后 API 返回 {"error":400,"message":"over quota"}，脚本读取不到正数 success，输出“百度未确认接收 URL”，任务以退出码一失败。

百度官方普通收录课程把 over quota 解释为超过每日配额，并说明超出配额后的继续提交无效。这与本次日志一致：失败发生在调用 API 步骤，而不是检出仓库、生成 URL 或读取 token 阶段。它不是站点 404、域名不匹配，也没有证据表明 token 失效。

这次失败揭示了“变更 URL”与“新增 URL”之间的差别。工作流名称写的是提交新增文章，但实现筛选的是所有发生变化的文章 index.html。品牌名称统一属于大范围内容维护，并没有新增十五篇文章，却产生了十五个提交对象。在额度较小的情况下，这种批量修订会与真正的新文章竞争配额。

失败也说明，不应把工作流红色直接解释为页面发布失败。品牌名称统一的页面可以正常部署，错误只发生在百度推送步骤。相反，工作流绿色也不代表页面内容质量合格；它只反映脚本设定的技术条件。运维报告应把“网站发布状态”和“外部推送状态”分开，避免为了让推送变绿而回滚正确内容。

五、五层状态怎样分别验证

第一层是页面可访问。对最终公开 URL 发起请求，记录状态码、最终跳转地址、Content-Type、canonical、是否存在 noindex，以及页面主要正文。页面返回 200 是推送前提；如果 API 接受了一个 404、登录页或错误 canonical，提交动作仍然不能修复页面本身。

第二层是 API 接受。保存提交时间、请求 URL 数量、工作流 run、接口状态码和 JSON 响应。success 应与预期提交数对照，not_same_site 与 not_valid 应单独记录。只判断“success 大于零”会漏掉部分接受：例如提交五个、成功一个，现有脚本仍可能变绿。本文没有观察到这种情况，但检查规则应覆盖它。

第三层是实际抓取。最直接的证据来自服务器或边缘访问日志中经过适当核验的 Baiduspider 请求，以及搜索资源平台的抓取诊断或抓取记录。仅把 User-Agent 写成 Baiduspider 发起请求，最多测试服务器是否按字符串区别响应，不能证明真实百度爬虫到访。robots 允许也只是授权条件，不是访问记录。

第四层是索引。应使用百度搜索资源平台可用的索引量、抓取诊断、URL 相关工具或其他平台提供的站长数据，并记录观察日期。site 查询可以作为辅助线索，但会受到缓存、地区、查询改写和结果限制影响；单个 URL 没出现不能直接证明未索引，出现摘要也要打开最终地址核验。

第五层是展示与使用。搜索结果出现页面、用户通过查询访问，或生成式回答引用该页面，属于更靠后的结果。它取决于查询匹配、内容质量、时效、站点信号和平台策略，不由 URL 推送单独决定。GEO 报告应把“技术发现链路”与“答案中被采用”分开，不能用前者代替后者。

六、现有自动化做对了什么

第一，它从 Git 差异生成 URL，而不是让发布者手工复制。路径转换规则稳定，能避免少写斜杠、提交预览地址或遗漏双向内链更新页。新文章与实际修改过的旧文章同时进入列表，也符合“重要内容更新可重新通知平台”的基本逻辑。

第二，它对文章目录做白名单匹配。只有 basics、methodology 和 tests 下的具体文章 index.html 会被转换，分类页与内容中心不会因为每次列表更新而反复占用额度。URL 在提交前排序去重，可以避免同一文件通过多个路径重复出现。

第三，它对错误进行显式失败。token 缺失、接口没有返回正数 success 或请求失败时，任务不会伪装成功。最近一次 over quota 因此留下了清晰的红色运行和原始响应，后续可以区分配置、网络、额度与 URL 质量问题。

第四，凭证通过 Secret 注入，日志显示为掩码，没有被写入仓库。公开文章只需要引用响应中的非敏感字段和运行结论，不应复制含 token 的接口地址。任何复盘都要避免把方便调试变成凭证泄露。

七、还可以怎样改进：重点不是“多推”，而是让结果可核验

第一项改进是区分新增与修改。新增文件可优先提交；旧文章仅在正文、canonical、日期或重要事实发生变化时重新提交；只改页头品牌、样式或全站模板时，可以选择不占用普通收录额度。实现上可以同时检查 Git 状态和差异类型，而不是把所有 index.html 变化视为同一优先级。

第二项是做数量一致性校验。脚本应记录 submitted、success、not_same_site 和 not_valid，并要求成功数加拒绝数能够解释提交总数。若 success 只覆盖部分 URL，任务可以标记为失败或警告，同时输出需要重试的具体地址。现有“success 至少为一”适合判断接口可用，不足以证明批次完整。

第三项是配额感知。接口成功响应提供 remain，自动化可以保存或输出剩余额度；当预计提交量超过额度时，优先新文章和高风险事实修正，其他 URL 延后。遇到 over quota 不应循环重试同一大批次，因为官方说明已表明超配额后继续提交无效；更合理的是等待下一额度周期，并保留队列。

第四项是加入发布前健康检查。提交前确认 URL 返回 200、canonical 指向自身、没有 noindex、正文存在且 sitemap 已同步。这样可以避免把配额用在尚未部署、重定向错误或内容不完整的地址上。检查失败应阻止推送，但不应把未完成页面写入 main。

第五项是把“推送状态”与“索引状态”分开存档。前者来自工作流与 API，后者来自百度搜索资源平台或后续可复查证据。报表可以写“已提交并被接口接受，索引状态待观察”，不要把两个字段合并成一个绿色勾。若未来获得后台数据，再补充抓取和索引日期。

第六项是降低无关提交。当前只要 public/blog 下任何路径变化就启动任务，随后可能因为没有文章 URL 而跳过。这个设计并不错误，但大规模样式调整会频繁占用运行资源。可以将公共样式变更与内容 URL 提交通知拆开，或者保留现状但明确“无 URL 时正常跳过”，避免把跳过误判为故障。

八、旧 URL 什么时候值得重新提交

旧文章发生变化并不自动等于应该占用推送额度。最值得重新通知平台的是会改变页面主题或用户判断的更新：正文补充新的核心结论，错误事实被更正，产品状态、服务范围或政策发生变化，canonical 从错误地址修复为当前地址，页面由不可访问恢复为正常公开。这些变化可能影响搜索系统理解页面的当前版本，适合进入较高优先级。

第二类是发现链路修复。文章过去遗漏 sitemap、内部入口或结构化数据，修正后页面身份和关系更清楚；旧 URL 合并或重定向后，权威地址已经改变。这类更新也可以重新提交，但提交前要先确认线上响应已经部署，避免平台先抓到变更前缓存。

优先级较低的是不改变文章事实的全站页头、Logo、页脚、颜色、通用脚本和轻微错别字。它们当然可以正常发布，却不必让每篇文章都竞争有限额度。当前失败样本正是一个提醒：品牌名称统一同时修改了所有文章 HTML，文件差异很大，但对于 URL 发现任务而言并不等同于十五个新页面。

双向内链更新位于两者之间。它能改善站内发现与上下文关系，但旧文章是否需要重新提交，应取决于额度和业务重要性。本次成功样本额度足够，因此新文章和补链旧文同时获得接收；若额度紧张，更合理的顺序是先提交新 URL，让 sitemap 和内部链接自然承担旧页更新发现。

团队可以为变更建立简单优先级：新 URL 与可访问性修复为 P0，重要事实和 canonical 变化为 P1，结构化关系与内链为 P2，纯样式和模板为 P3。优先级不是百度官方规则，而是站点自己的额度管理方法；它必须结合真实业务风险，不能为了减少提交而推迟纠正错误信息。

九、常见误判与反例

误判一：“工作流绿色，所以百度已经收录。”绿色只表示脚本满足了自己的成功条件。本次条件是 success 至少为一；它连“全部 URL 均成功”都不必然保证，更不能跨越到索引层。

误判二：“remain 是还有多少页面等待百度处理。”remain 是接口返回的剩余额度。等待抓取或索引的队列属于平台内部状态，本次日志没有提供。

误判三：“重复提交会强制刷新索引。”普通收录是链接提交通道，不是内容刷新命令。重要页面更新后可以重新通知，但重复提交无法保证更快抓取，也可能浪费有限额度。

误判四：“over quota 说明 token 坏了。”本次失败响应明确是配额超限，且第二天同一自动化成功提交两个 URL，说明不能把该错误归因于 token。token 无效通常应根据平台返回的对应错误判断。

误判五：“site 搜不到就是没有索引。”公开查询只是辅助观察。搜索结果会受到查询表达、地区、时间与平台限制影响，本次自动请求还遇到百度安全验证。没有稳定结果时，应如实写“无法判断”，而不是把验证页当成零结果。

误判六：“为了节省额度，不更新旧文章。”内容正确性优先于推送便利。事实错误、失效链接和双向内链仍应修正；自动化应学会排序和排队，不能为了保持工作流绿色而保留错误内容。

十、边界与局限

本文只分析 GEOC 私有仓库中已经授权可读的工作流源码、两次 GitHub Actions 日志、百度公开文档与站点公开响应。没有读取百度账号中的索引量、抓取频次、配额配置或 URL 详情，也没有访问服务器原始日志，因此不能说明真实 Baiduspider 是否在某时刻访问。

成功样本与失败样本来自两个不同变更规模，不能据此推导百度每天固定给 GEOC 十个额度。remain: 8 只是那次成功响应的当时值；每日额度可能由平台和站点状态决定。本文不会把一次响应扩展成长期配额规则。

批量失败样本列出的十五个 URL 在后续是否通过其他方式提交、被 sitemap 发现或进入索引，本次没有逐一追踪。后续一次 success: 2 只确认那两个 URL，不能证明此前批次已经自动补齐。工作流当前也没有持久重试队列。

百度公开页面与接口行为可能更新。本文观察截止 2026 年 8 月 15 日，使用时应重新查看搜索资源平台当前说明。对于其他搜索引擎或生成式平台，也不能照搬百度字段含义；每个平台的提交、抓取和采用链路应分别核验。

十一、发布与排查检查清单

• 新文章 URL 是否已经公开返回 200，而不是预览、登录或错误页？
• canonical 是否指向稳定正式 URL，页面是否不存在 noindex？
• sitemap、内容中心、分类页、llms.txt 和 feed 是否在同次发布中同步？
• 工作流识别的 URL 数量是否与本次新增或重要修改的文章数量一致？
• 提交日志是否保存 submitted、success、remain、not_same_site、not_valid 与错误信息？
• success 是否覆盖全部提交 URL，而不是只判断至少成功一个？
• 遇到 over quota 时是否停止无效重试，并保留下一周期待提交队列？
• 是否把新增文章优先于纯模板或页头改动？
• 百度 token 是否只存于 Secret，日志和文章中均未泄露？
• 报告是否把 API 接受、真实抓取、建立索引和搜索展示分开？
• 索引结论是否来自有日期的后台或可复查证据，而非一次模糊 site 查询？
• 修改旧文章后，是否同步 dateModified、sitemap lastmod 与 feed updated？

十二、下一步阅读与可复用判断

如果网站还没有建立基本发现链路，先阅读GEOC 官网 AI 可读性审计，区分公开访问、robots、sitemap、结构化数据、llms 与 feed 的各自责任。只有页面本身稳定可达，主动推送才有意义。

若自动发布涉及多份索引文件，可以继续参考最近文章结构化数据一致性抽查，检查可见标题、Article JSON-LD、sitemap 和 feed 是否描述同一个版本。推送一个内部已经互相冲突的页面，只会更快暴露维护问题。

对团队而言，最有用的记录不是“百度推送已完成”这一句话，而是一组分层状态：页面已发布、接口已接受、抓取待核验、索引待观察、展示按查询记录。每一层附上时间、证据和责任人，后续变化才能解释。这个方法同样适用于其他搜索和 AI 平台，只是证据字段必须按平台重新定义。

资料来源与实测记录

实测窗口为 2026 年 8 月 13 日至 15 日。GitHub Actions 日志来自 GEOC 仓库自身的百度推送工作流；公开页面状态在 2026 年 8 月 15 日复查。以下百度资料用于解释普通收录的产品边界、接口返回与错误含义。

• 百度搜索资源平台：普通收录使用说明与“不保证收录”边界
• 百度搜索资源平台：普通收录 API 返回字段、成功示例与错误说明
• 百度搜索资源平台：普通收录 API 接口地址统一公告
• GEOC：2026-08-14 两个 URL 提交成功的工作流记录（私有仓库，需相应权限）
• GEOC：2026-08-13 配额超限的工作流记录（私有仓库，需相应权限）