每天上新几百个 SKU，商品页写完、内链挂好，然后就是漫长的等：百度自然收录动辄十五到二十五天，等收齐的时候活动早就结束了。这批页面对电商 SEO 来说恰恰是价值密度 highest 的一块——新促销、新价格、真实的转化意图。这篇把我们站从"等三周"压到"多数页面三天内出索引"的完整改造过程拆开讲，核心是百度搜索资源平台的普通收录 API 推送与快速收录 API 的配额分配问题。

适用读者：负责电商平台网站优化、天天盯收录量的技术同学；手上有商品页批量上新、分类页频繁变动需求的后端开发；正在做站群收录诊断的 SEO 从业者。需要你能登录百度搜索资源平台并改得了服务端代码。

先说结论：收录慢的根因不在内容，在发现路径

很多同学第一反应是"内容质量不够"，跑去加文案、改详情，两周过去收录率没动。后来我们抓了日志才看清：爬虫对我们的新商品页根本没有"及时到达"这回事。

百度蜘蛛发现新页面的常规路径有三条：外链导入、站内链接爬取、主动提交。中小站前两条基本靠运气——外链没有，内链层级深（首页 → 分类页 → 列表第 N 页 → 商品页），蜘蛛两次路过同一分类页的间隔可能长达一周以上。也就是说，你的新页面在站内"被看见"的延迟，就已经把收录时间拖到二十天量级了。

主动提交正是为这个场景设计的。把发现路径从"被动等爬"改成"主动推"，我们站的实际效果是这样的：

数据是我们站九月份为期四周的对照观察，站点规模、内容类型不同会有明显差异，只作参考。但方向是稳定的：主动推送解决的是"发现延迟"，不是"收录标准"，页面本身得先合格。

接入之前：站点验证与 token 获取

推送接口的两个前置条件，一个都不能少。

站点验证。 登录百度搜索资源平台（ziyuan.baidu.com），添加你的域名并完成验证。我们用的是文件验证：下载 baidu_verify_xxx.html 放到站点根目录，保证 https://你的域名/baidu_verify_xxx.html 能 200 返回即可。验证文件别随手删，平台会不定期复查。

获取 token。 在"普通收录"页面能看到推送接口的准入密钥，形如 http://data.zz.baidu.com/urls?site=example.com&token=xxxxx。这条 URL 里 site 必须和验证过的域名完全一致，token 是你站点的身份凭证。

token 泄漏等于把推送额度送人。 任何拿到 token 的第三方都能往你的接口推任意 URL。生产环境里它只该出现在服务端环境变量或配置中心，不要写进前端代码，不要提交进 Git 仓库。我们就见过站群项目把 token 硬编码在公共仓库里，额度被同项目的其他站点挤占的情况。

推送机制拆解：接口背后到底发生了什么

这一节讲原理。很多人把推送理解成"催一下收录"，这个心智模型会导致后面所有的配额策略都做歪。

百度推送接口本质上是一个候选 URL 注册器。你推一条 URL，它做的事情是：校验归属 → 写入待抓队列 → 给这条 URL 一个相对高的抓取优先级。注意关键词是"抓取优先级"而不是"收录保证"——推送只影响蜘蛛多快来到你页面，抓回来之后质量评估、索引筛选走的是同一套流程。

推送后的完整链路可以这样描述：

flowchart LR
    A[业务系统产生新页面] --> B[URL 进入待推送队列]
    B --> C{配额判断}
    C -->|普通收录配额| D[普通推送接口]
    C -->|快速收录配额| E[快速推送接口]
    D --> F[写进待抓队列 提升优先级]
    E --> F
    F --> G[蜘蛛抓取页面]
    G --> H{质量评估}
    H -->|通过| I[建立索引 可被搜索]
    H -->|不通过| J[仅存为已知页 不进索引]

两个推论从这里直接推出来：

• 推送不等价收录。 我们站九月份推送成功率 100% 的那批页面里，最终进索引的约 94%。剩下的页面被判定为低价值（空参数页、重复模板页），推送只是让它们更快地被"看了一眼然后放弃"。所以推送策略的前置动作永远是页面去噪。
• 配额是稀缺的抓取优先级资源。 普通收录每天有推送条数上限，快速收录的额度更低。快速收录的每日配额这两年来整体在收紧，多数中小站点能拿到的额度已经很小，具体剩多少以你平台后台实际显示为准——这也是为什么配额必须省着用在刀刃上，后面单开一节讲。

另外接口返回里有个 remain 字段，表示当日剩余可推送条数，它是配额策略的实时依据，脚本里一定要接住这个值。

普通收录与快速收录：配额怎么分

两个接口共用一套 token 体系，但额度、时效定位完全不同。我们站的分工表：

配额策略只有两条纪律。 其一，新页优先：新页面没有任何内链积累，是推送收益最大的一类；老页面更新靠 sitemap 的 lastmod 提示就够。其二，爆款页优先：从业务数据里筛出来未来两周预计有流量的 SKU，才动用快速收录额度，普通长尾商品页一律走普通推送。

千万别把快速收录额度平均撒给所有新页。额度紧张的现实下，撒胡椒面的结果是要紧的那条大促页没推上，当天额度已经耗尽。

Python 推送脚本：增量页自动推

下面是我们服务端跑的推送脚本，接在商品发布流程的收尾处，每日新增页自动进入推送队列。依赖只有 requests（pip install requests），Python 3.8+ 环境运行。

# -*- coding: utf-8 -*-
# 百度普通收录推送脚本：商品页发布完成后调用
# 依赖：pip install requests，Python 3.8+
import time
import json
import random
import requests

# 推送接口地址：site 必须与验证域名一致，token 从环境变量读取，不落代码
API = "http://data.zz.baidu.com/urls?site=example.com&token={token}"
TOKEN = os.environ["BAIDU_PUSH_TOKEN"]  # 生产环境从配置中心取

def push_urls(urls):
    # 单次请求最多 2000 条，超量会被截断，这里按 1500 一批留余量
    batch = 1500
    # remain 记录当日剩余配额，为 0 时立即停止，避免无效请求
    remain = None
    results = []
    for i in range(0, len(urls), batch):
        # 当日配额耗尽就不再发请求，防止推送全部被拒
        if remain is not None and remain <= 0:
            print("今日配额已用完，剩余 URL 顺延到明天")
            break
        chunk = urls[i:i + batch]
        # 每批之间随机等待 2-5 秒，避免对接口形成突发压力
        time.sleep(random.uniform(2, 5))
        resp = requests.post(
            # 推送正文就是纯文本的 URL 列表，一行一条，不需要 JSON
            API.format(token=TOKEN),
            data="\n".join(chunk).encode("utf-8"),
            headers={"Content-Type": "text/plain"},
            timeout=10,
        )
        # 返回体是 JSON：success 成功条数、remain 剩余额度、not_same_site 域名不符
        data = resp.json()
        remain = data.get("remain", 0)
        # 域名不符的 URL 要单独落日志，通常是混入了别的子域名页面
        if data.get("not_same_site"):
            print("域名不符：", data["not_same_site"][:5])
        # not_valid 是格式非法的 URL，检查是否带了空格或中文未编码
        if data.get("not_valid"):
            print("非法 URL：", data["not_valid"][:5])
        results.append(data)
    return results

if __name__ == "__main__":
    # 实际使用时从数据库取当日新发布且未被推送过的商品页
    urls = ["https://www.example.com/item/10001.html",
            "https://www.example.com/item/10002.html"]
    # 每条 URL 只推一次，重复推送浪费额度（接口会按已推送处理）
    push_urls(urls)

对应的命令行验证方式，上线前先用几条 URL 手工确认接口通：

# 先推一条 URL 验证 token 与 site 配置是否正确
curl -H "Content-Type: text/plain" --data "https://www.example.com/item/10001.html" "http://data.zz.baidu.com/urls?site=example.com&token=你的token"

# 返回里 success 应为 1，remain 显示当日剩余条数
# 如果报 not_same_site，检查 URL 是否带了未验证的子域名或跳转地址

返回码排查：对着报错找原因

推送失败基本不用猜，返回字段直接指明问题类别。整理成排查表：

我们踩得最深的一个坑是 not_same_site：商品页同时挂在 www 和 m 两个域名下，m. 子域没有单独验证。批量推送时混进去的移动端 URL 全部落进这个数组，表面上脚本"跑成功了"，实际有一小半没推上。所以结果判断不能只看 HTTP 200，必须解析返回 JSON 并对 not_same_site 计数告警。

和 sitemap 自动提交的分工

两套提交机制不是二选一，是分工。sitemap 的优势是全量、无人值守、改动自动带出；API 推送的优势是即时、带优先级信号。我们的分层安排：

flowchart TD
    Q[新页面出现] --> R{页面类型}
    R -->|强时效 大促 爆款新SKU| S[快速收录 API 当日额度]
    R -->|常规新商品页 内容页| T[普通收录 API 推送]
    R -->|全站页面 兜底| U[sitemap 自动提交]
    T --> V[URL 写入 sitemap 带更新时间]
    S --> V
    U --> W[每天定时由资源平台抓取]
    V --> W

sitemap 兜底还有个实际好处：推送漏掉的页面（比如脚本停服那一天）最迟一天内也会被 sitemap 覆盖。反过来，sitemap 不该背快速收录的锅——它没有优先抓取的信号强度，大促页指望它就是回到九天起步的老路。

日常维护节奏：sitemap 由发布系统在每日凌晨自动重建，lastmod 用真实的最后修改时间，不要为了"显得新"全量刷成当天——虚假的更新时间会逐渐削弱这条通道的可信度，对网站优化是净伤害。

推送后收录时效对照

把四种路径的实际时效放到一张表里，方便你估算自己的收益：

再强调一次边界：表中"建立索引"前提是页面通过了质量评估。模板雷同、空参页面、无实质信息的筛选页，推得再快也不会进索引——它们会被更快地判死，而不是更快地收录。

收尾：两个常见误区

一个是"推送了就该收录"。推送解决发现，收录看质量，这两个环节的评估体系是分开的，混为一谈会让你在错误的层面找原因。另一个是"配额越多越好"。额度永远追不上页面增长，真正拉开差距的是分配策略：把有限的快速收录额度集中给当周的业务重点页，普通推送覆盖全部新页，sitemap 做全站兜底，三层各干各的活。

快速收录配额收紧这个趋势短期内看不到回头迹象，早一天把分层策略固化成代码，就少一天依赖运气。你们站的新页收录要等几天？欢迎评论区交流各自的推送实践。

参考与延伸

1. 百度搜索资源平台（站点验证、收录工具入口）：https://ziyuan.baidu.com/
2. 普通收录推送接口说明（token 获取与推送示例）：https://ziyuan.baidu.com/linksubmit/index
3. 百度搜索学堂（收录与抓取机制官方内容）：https://ziyuan.baidu.com/college/index
4. sitemap 协议（lastmod 等字段定义）：https://www.sitemaps.org/zh_CN/

关键词：SEO、网站优化、百度收录、API 推送、快速收录、配额管理、收录时效、sitemap