先给结论：把百度推送当作有额度的通知队列
百度主动推送适合通知百度发现已发布或实质更新的公开 URL。稳定的做法是先完成页面检查，再规范化和去重 URL，优先提交当天新文章，剩余额度用于尚未提交或版本已变化的有效页面；每次保留请求数量、百度响应和剩余配额。接口接收只代表提交这一层完成，不代表百度已经抓取或收录。
这套流程解决的是“哪些页面现在值得通知、额度怎么安排、失败后下一步是什么”。它不能通过重复请求代替页面质量、内部链接、sitemap 或索引状态检查。百度普通收录平台把提交作为加快链接发现和抓取的入口，同时明确不保证提交链接一定被收录。
新发布页面优先；其余名额补给状态有效、尚未提交或内容版本发生变化的页面；已经按当前版本接收的 URL 不重复占用额度。
先把提交、抓取和收录分成不同状态
后台应该让每条状态都能回答一个具体问题。不要把“提交成功”写成“已收录”，也不要把“没有看到蜘蛛请求”写成平台没有发现页面。
| 状态 | 它能说明什么 | 对应证据 | 不能推出什么 |
|---|---|---|---|
| 页面已发布 | 正式地址在公开环境可以取得页面。 | 线上 URL、HTTP 状态、正文、canonical 和索引指令。 | 不说明百度已经知道该地址。 |
| 提交已接收 | 百度接口接受了本次 URL 通知。 | 请求时间、成功数量、拒绝列表、响应正文和剩余额度。 | 不说明百度已请求页面或建立索引。 |
| 已抓取 | 百度爬虫请求过该地址并取得响应。 | 平台抓取诊断或来源已核验的服务器日志。 | HTTP 200 不等于已收录。 |
| 已收录 | 某个时间点的平台证据显示页面进入索引。 | 百度搜索资源平台对应的索引工具或报告。 | 不保证稳定排名、点击或 AI 引用。 |
提交前先过页面验收
推送队列只应接收已经可以公开访问、适合索引的页面。将明显有问题的 URL 发送得更快，并不会修复问题，反而会让后台把配置故障和页面状态混在一起。
- 检查正式地址。使用 HTTPS 规范主机和页面的正式路径。确认 HTTP、www、尾斜杠和追踪参数最终都归到同一个 canonical。
- 检查响应与正文。页面应公开返回预期内容。登录页、软 404、维护页或空壳响应都不应进入新文章队列。
- 检查索引资格。确认 meta robots、X-Robots-Tag、robots.txt 和权限设置没有阻止目标页面。
- 检查页面版本。保存发布日期、实质修改日期和内容版本。只改无关格式、访问时间或统计字段，不应自动制造新的内容版本。
- 检查发现路径。页面应加入适当的栏目或语义内链、sitemap 和站点更新入口。主动提交是补充通知，不能代替可持续的发现路径。
正式发布和推送应按顺序连接：部署完成，线上 URL 验收通过，sitemap 或栏目入口已更新，再把规范 URL 放入待提交队列。若部署失败，任务应保持待发布或阻塞，不能提前标记成已提交。
规范化 URL，再做去重
同一个页面可能以 HTTP、HTTPS、www、带参数、不带尾斜杠等形式出现。队列应在入库时统一主机和路径，剥除追踪参数和片段标识，并将文章版本与规范 URL 绑定。
| 输入情况 | 队列处理 | 理由 |
|---|---|---|
| 同一正文带不同 UTM 参数 | 归一到不带追踪参数的 canonical。 | 追踪参数通常不代表另一份内容。 |
| 同一地址只有片段不同 | 去掉片段，按页面 URL 去重。 | 片段通常指向正文位置，不是独立页面。 |
| HTTP 或 www 变体 | 归到站点配置的正式 HTTPS 主机。 | 避免将重定向入口当作正文版本重复提交。 |
| 目标主机不属于已验证站点 | 拒绝入队并提示检查站点资源。 | 错误站点参数会造成站点初始化或 URL 校验失败。 |
去重键至少应包含规范 URL 和内容版本。若 URL 和版本都与最近一次已接收记录相同，状态维持“已提交”；若页面确实发生了影响正文、标题、来源或结构的实质更新，则生成新版本，进入“待更新”队列。
设计最小队列状态
队列要能区分新文章、已经提交过的旧页面、发生实质更新的页面和提交失败项。每一项只记录当前状态不够，还要保留历史运行记录，便于解释配额为什么减少、某个 URL 为什么被拒绝。
| 队列状态 | 进入条件 | 下一步 |
|---|---|---|
| 待提交（新） | 正式页面已发布，本站没有当前 URL 的成功记录。 | 优先检查并提交。 |
| 待提交（更新） | URL 已有记录，但内容版本发生实质变化。 | 检查版本差异后纳入剩余额度。 |
| 已接收 | 百度响应的成功数量和逐条拒绝结果相符。 | 不重复提交同一版本，进入后续抓取和收录观察。 |
| 部分接收 | 一批中部分 URL 被接收，部分被拒绝。 | 只更新确认成功的 URL；逐条修复被拒绝项。 |
| 响应不明 | 超时、响应无法解析或计数不一致。 | 保留未知并复核记录，避免误标成功或马上重复请求。 |
| 配置阻塞 | 站点、token 或接口参数错误。 | 修正配置后再重试，不把失败 URL 当作已提交。 |
成功提交记录建议至少保存规范 URL、内容版本、提交时间和响应运行 ID；运行记录则保存请求时间、请求数量、接收数、拒绝数、百度返回的 remain、错误类别和触发来源。不要在公开页面或日志中写出 token。
把“百度额度”和“本站每日上限”分别计算
日常可用数量通常受两套上限共同约束：百度接口返回的当前剩余额度，以及网站应用自己配置的每日提交上限。某一轮最多可处理的数量，不能超过这两个数中较小的一项，也不能超过批次大小和有效待提交数量。
本轮可提交数 = min(
百度当前剩余额度（未知时按保守配置处理），
本站今日剩余上限，
单批大小，
符合条件的待提交 URL 数
)百度响应中的 remain 是接口返回的剩余额度；应用配置中的“每天最多提交几条”是站点自己的节奏和成本控制。两者不能互相替代。额度数据跨日后应标成过期或未知，不能拿昨天的剩余值假装今天仍有效。
新文章优先，剩余名额补位
如果每天会发布新文章，队列应先保护新页面名额，再将其他名额用于尚未提交或已更新的公开 URL。这样既能保证新内容不会一直排在历史积压之后，也能让有限额度持续消化有效待办。
- 先算当天还可用多少。应用每日上限减去当天已经确认接收的数量，再与百度最新剩余额度和批次大小取较小值。
- 优先放入当天新发布文章。按“已发布且线上验收完成”的新页面排序，不按文章草稿或本地文件时间排序。
- 检查新文章预留名额。若当天还没有新文章可提交，保留配置的名额，避免历史积压提前占满；新文章到达后优先处理。
- 用剩余容量补位。继续选择未提交或版本变化的公开页面，排除已经按当前版本接收、URL 无效、已删除、禁止索引或尚未发布的页面。
- 按接口真实结果更新。只把响应确认接收的 URL 标成已提交；拒绝和响应不明的 URL 保留原状态或标为待核。
本站应用配置为每日最多 2 条、每批最多 2 条，并为当天新发布的文章预留 1 个名额；自动提交已开启。百度接口返回的剩余额度可能进一步降低本轮数量。这是 ZenLeak 当前的应用层设置，不是百度向所有站点公布的统一每日配额。查看不含密钥的配置快照。
例如本站当天可用上限为 2 条、百度返回剩余 8 条，且有一篇新文章和多篇有效积压页面：本轮最多提交 2 条，先提交新文章，再用另一条容量补入符合条件的旧 URL。若百度只返回剩余 1 条，则本轮最多提交 1 条；若接口剩余为 0，则保留待办，不能因为应用配置还有名额就继续发送。
按响应结果分类处理
一个可靠的后台不能只显示绿色“成功”。应同时看 HTTP 状态、百度 JSON 字段和响应里的 URL 列表，并校验成功数、拒绝数与请求数是否一致。
| 响应情况 | 含义与处理 | 是否立即重试 |
|---|---|---|
| 返回成功数量与拒绝列表一致 | 仅将确认接收的 URL 标记为当前版本已接收；记录 remain。 | 不重发已接收 URL。 |
not_same_site 或 not_valid | 逐条记录主机不匹配或 URL 无效，检查站点资源、协议、路径和 URL 格式。 | 先修复，不能原样循环发送。 |
site init fail 或 token 无效 | 检查已验证站点与 API 的 site 参数、token 所属资源和接口参数格式。 | 配置正确前停止。 |
over quota 或 remain 为 0 | 额度已用完，保留待提交项并等待平台额度恢复。 | 不重试，避免重复失败。 |
please retry later、超时或暂时无法连接 | 视为暂时性失败，记录运行并按退避间隔稍后复核。 | 可以有限重试；遵守本地冷却和平台提示。 |
| 响应无法解析或计数不一致 | 标记为“响应不明”，保留原始安全摘要并人工核对。 | 确认接口是否已处理后再决定。 |
失败重试应有限、有间隔、可停止。token、站点参数和 URL 校验错误需要配置修复；网络暂时失败才适合退避后重试。不要将每分钟定时重试当作自动化，也不要因失败就清空历史记录。
新文章发布当天的执行步骤
| 步骤 | 要做什么 | 完成证据 |
|---|---|---|
| 1. 发布 | 部署到正式站点，确认 URL 公开可访问。 | 最终 URL、HTTP 状态、正文和 canonical。 |
| 2. 更新发现入口 | 确认栏目内链、sitemap、RSS 或站点索引已包含新内容。 | 入口中能找到规范 URL。 |
| 3. 入队与去重 | 规范化 URL，绑定内容版本，排除参数重复和已提交同版本页面。 | 后台待提交条目及其状态。 |
| 4. 计算配额并发送 | 先顾新文章，再按剩余容量补有效待提交 URL。 | 请求数、成功数、拒绝数、remain 和运行时间。 |
| 5. 安排复测 | 按 T+1、T+3、T+7 查看日志和站长平台可提供的状态。 | 每个窗口独立记录，未知仍保持未知。 |
T+1、T+3 和 T+7 是便于重复执行的观察窗口，不是百度承诺的抓取或收录时间。提交台账与之后的抓取日志、索引报告应通过规范 URL 关联，但不要把它们写进同一个“已收录”字段。
自动化应该做什么，人工仍要看什么
| 适合自动化 | 需要人工判断 |
|---|---|
| 规范 URL、识别重复参数、按页面版本去重。 | 页面是否真的发布完成，正文是否独立且值得公开。 |
| 计算今日已接收数量、应用剩余量和百度返回额度。 | 遇到配置错误、配额异常或响应计数不一致时如何处置。 |
| 按优先级排序、批量发送并保存运行记录。 | 某个页面是否应保留索引资格，是否已撤稿或改为 noindex。 |
| 失败分类、冷却、有限重试和逾期提示。 | 日志中的蜘蛛身份、页面抓取情况和平台索引结果。 |
自动化的价值是让规则可重复，而不是将结论自动变真。尤其是搜索蜘蛛身份不能只看 User-Agent；平台收录状态也不能从提交次数推算。百度提交、爬虫日志核验和索引复测应由不同证据支持。
常见问题
每日额度没用完，可以提交其他 URL 吗？
可以，但只提交已发布、规范、允许索引、本站尚未按当前版本成功提交的页面。先满足当天新文章的优先级和预留规则，再用剩余数量补历史待办。不要重复提交当前版本已接收的 URL。
提交接口接收了 2 条，是否表示有 2 条已收录？
不是。它说明接口接收了对应数量的 URL 通知。抓取和索引需要通过百度搜索资源平台、核验后的日志等后续证据分别确认。
百度返回的剩余配额和后台每日上限不一样，按哪个？
两者都要遵守，本轮可用量取更小值。后台每日上限是本站应用策略，百度返回 remain 才是接口当前提供的剩余额度信号。
同一篇文章更新后能再提交吗？
如果内容发生实质更新，页面版本变化且仍是公开的规范 URL，可以进入“待更新”。只刷新访问时间、格式或无实质变化的日期，不应制造重复推送。
百度接口失败后应该马上再点一次吗？
先按错误分类。站点或 token 配置错误要先修复；额度用完就等待恢复；暂时性网络失败可以在冷却后有限重试；响应不明时先查运行记录，避免重复消耗额度。
接入自动推送后还要提交 sitemap 吗？
需要维护 sitemap 和语义内链。主动提交是变化通知入口，sitemap 和站内链接则持续表达页面集合及其关系。
可直接使用的推送前检查清单
- 页面已经部署到正式站点，并通过公开 HTTP 与正文检查。
- canonical、robots、正式主机和提交 URL 一致。
- URL 已去除追踪参数、片段和重复版本。
- 同一 URL 的当前内容版本没有已接收记录。
- 当天新文章优先级和保留名额已经纳入计算。
- 百度 remain、本地每日上限、批次大小和当天已接收数均已检查。
- 请求只发送本站已验证资源下的有效公开 URL。
- 响应中的 success、remain、not_same_site 和 not_valid 已合理校验。
- 失败类型、重试间隔和人工处理项已写入运行历史。
- 提交状态没有被写成抓取、收录、排名或 AI 引用结论。
结果边界与延伸阅读
队列规则能提高每日名额的使用效率，让新内容和有效积压都有清楚的处理顺序；它不能保证页面被抓取、收录、排名或被 AI 引用。若搜索状态长期没有变化，应分别检查页面访问、canonical、内容独立性、站内发现路径、抓取日志和站长平台反馈，而不是不断重复提交。
可以接着阅读IndexNow 自动提交教程了解变化通知协议，阅读搜索收录复测教程分开记录提交、抓取和索引，阅读百度蜘蛛身份核验判断日志来源，并参考GEO 内容优先级方法安排下一轮内容。