本文约 3,105 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：存量页面不能用新文章钩子补交
站点接入百度主动提交时，往往已经积累几百甚至几万篇文章。发布钩子只能覆盖以后新发的内容，历史页面仍需从站内链接和 XML 站点地图被发现。迁移 HTTPS、修改固定链接或合并域名后，站长也常希望把当前有效 URL 重新整理并提交。若直接把数据库里的 guid 当作链接，可能提交旧域名；若一次塞入全部地址，又可能超过当天配额或让定时任务超时。
可靠的批量方案应先从 WordPress 生成当前 permalink，过滤不可索引和非 200 页面，再按百度搜索资源平台显示的实际配额分批提交。任务必须可暂停、可追踪、可重复执行，但不能在失败时无限轰击接口。WordPress 迁站 SEO 检查清单
原理分析：历史 URL 队列要处理状态、配额与幂等
百度普通收录 API 接收纯文本 URL 列表，通常每行一个地址，响应中会给出本次成功数量和剩余额度。这里的“成功”表示接口接受，并不等于已抓取或已进入索引。批量脚本的核心不是循环 curl，而是构建一份干净、确定的队列。
WordPress 数据库中的 guid 用于标识内容，迁站后不一定随域名变化，不能作为前台规范 URL 的可靠来源。应使用 get_permalink() 生成当前链接，并只取 post_status=publish 的公开内容。若站点通过 SEO 插件把某些文章设为 noindex，理想做法是进一步读取插件的索引配置；至少先排除密码保护、404、重定向和测试栏目。
定时任务还要避免并发。主机面板可能在上一个任务未结束时启动下一次，导致同一批地址重复提交。可以用 flock 创建进程锁，并将已经处理的批次移动到归档目录。由于推送配额可能调整，批大小不能照搬其他站点，应以自己在百度搜索资源平台看到的额度为准。
保姆级实操
步骤一：准备运行条件。 确认服务器已安装 WP-CLI 和 curl，命令从 WordPress 根目录执行。通过主机环境设置 BAIDU_SITE 与 BAIDU_PUSH_TOKEN，真实令牌不写入脚本、日志或文章。
步骤二：生成当前 URL 清单。 使用 WordPress 函数输出 permalink，而不是查询 guid。首次运行先检查清单中协议、主机名和结尾斜杠是否与 canonical 一致。
步骤三：按额度拆分并提交。 下面脚本每批 50 条，只展示实现方式；上线时应根据自己的配额调整 BATCH_SIZE。响应保存为 JSON，脚本不把含令牌的完整接口地址打印到日志。
#!/usr/bin/env bash
set -euo pipefail
: "${BAIDU_SITE:?缺少 BAIDU_SITE}"
: "${BAIDU_PUSH_TOKEN:?缺少 BAIDU_PUSH_TOKEN}"
BATCH_SIZE=50
WORK_DIR="${TMPDIR:-/tmp}/baidu-url-push"
mkdir -p "$WORK_DIR/pending" "$WORK_DIR/done"
exec 9>"$WORK_DIR/push.lock"
flock -n 9 || exit 0
wp eval 'foreach (get_posts(["post_type"=>"post","post_status"=>"publish","numberposts"=>-1,"fields"=>"ids"]) as $id) { if (!post_password_required($id)) echo get_permalink($id), PHP_EOL; }' \
| sort -u > "$WORK_DIR/urls.txt"
split -l "$BATCH_SIZE" -d "$WORK_DIR/urls.txt" "$WORK_DIR/pending/urls-"
for batch in "$WORK_DIR"/pending/urls-*; do
[ -s "$batch" ] || continue
response=$(curl -fsS -H 'Content-Type: text/plain' \
--data-binary "@$batch" \
"http://data.zz.baidu.com/urls?site=${BAIDU_SITE}&token=${BAIDU_PUSH_TOKEN}")
printf '%s\n' "$response" > "${batch}.response.json"
mv "$batch" "$WORK_DIR/done/"
break
done
脚本每次只处理一个批次，适合由 cron 周期执行；Windows 主机可在 WSL 或兼容 shell 中运行，纯虚拟主机则可改写为 WP-CLI 自定义命令。flock 并非所有系统默认提供，部署前要实际验证。
步骤四：验证队列质量。 随机抽取 URL，用浏览器无痕访问并检查 HTTP 状态、canonical、robots meta 和正文。发现旧域名、附件页或分页参数时，应先修清单生成规则，不要提交后再补救。WordPress canonical URL 规范化
步骤五：安排低频定时任务。 根据额度设置每天或每小时执行，不要把分钟级高频当成收录优化。记录运行时间、批次文件名、提交条数、成功数和剩余额度，不记录令牌。
步骤六：结束后保留审计记录。 全部批次完成后停止定时任务，继续通过 XML 站点地图承载常规发现。存量推送是一次性迁移工作，不应永久重复提交全部文章。
常见踩坑
- 从
wp_posts.guid导出链接，迁站后把旧域名全部提交。 - 不判断发布状态，把草稿、私密文章和附件页纳入队列。
- 一次提交全部 URL，超过配额后仍反复重试。
- 把真实令牌写进 crontab 命令并让其他用户可读取。优先使用受限环境配置。
- 案例： 某站改为 HTTPS 后直接导出数据库
guid，数千条请求仍指向 HTTP 和旧测试域名。清空队列、改用get_permalink()并统一 301 后，才得到干净提交记录。 - 只保存“任务成功”日志，不保存接口响应中的成功数和剩余额度。
- 把批量提交当作站点地图替代品，长期不更新 sitemap 和内链。
总结
批量推送历史文章的关键是队列质量，而不是请求速度。使用 get_permalink() 生成当前规范地址，只保留公开、可访问、允许索引的页面；按本站实际配额拆分，利用锁文件避免并发，并保存不含令牌的响应摘要。完成存量处理后应停止重复任务，让新文章发布钩子、XML 站点地图和自然内链分别承担后续发现工作。百度链接提交效果监控
