索引请求发了，为什么收录还是不涨
过去两年，Google 的 Indexing API、百度的普通收录接口、Bing 的 IndexNow，成了站长圈里最常被提起的三个"加速收录"手段。很多人照着教程配好接口，提交了几百个 URL，都在后台看到"提交成功"，然后满怀期待地等——结果一周过去，site 查询还是那几条。
问题在于："提交成功"和"被收录"之间没有任何因果关系。接口只是把一个 URL 塞进待抓取队列，最终抓不抓、抓了收不收，完全是搜索引擎自己决定。这篇文章不讲怎么申请 API，而是讲提交之后该怎么判断"到底卡在哪一环"，以及哪几种情况下接口是完全无效的。
先搞清楚三个接口的真实定位
这三个接口经常被混为一谈，但适用范围完全不同，用错了就是纯浪费配额。
Google Indexing API：不是给普通网页用的
这是最容易踩的坑。Google 官方文档写得很清楚：Indexing API 目前官方支持的类型只有 JobPosting 和 BroadcastEvent（直播）结构化数据页面。对普通文章页、商品页，Google 明确表示"不保证有效果"。
现实中的情况是：很多站长提交普通文章，确实偶尔会看到收录变快，但这更可能是巧合，或者是因为提交动作触发了对站点其他信号的重新评估。把收录希望押在 Indexing API 上是不可靠的。
它真正有价值的场景是：招工信息、直播活动页这类时效性极强、需要分钟级收录的页面。如果你做的是招聘站或直播聚合站，那它非常有用；如果是普通博客，别指望它。
IndexNow：Bing 系效率最高，但对 Google 无效
IndexNow 是 Bing 和 Yandex 联合推的协议，实现成本极低——放一个 key 文件到根目录，然后 GET 请求提交 URL 即可。它对新站的收录速度确实有明显提升，通常几小时到一天内就会看到 Bing 蜘蛛来抓。
但要注意：Google 明确不支持 IndexNow。很多人以为提交了 IndexNow，Google 也能收到通知，这是误解。
百度普通收录：配额制，且对低权重站极不友好
百度的普通收录接口每天有配额限制，新站往往只有几条到几十条。更关键的是，百度对新站和低质量站的收录意愿本来就很低，配额再多也只进去一小部分。
百度的核心问题不是接口，而是站点权重和内容质量。同样的接口，权重 5 的老站提交 10 条能收 8 条，新站提交 100 条可能只收 2 条——而且这 2 条通常还是首页和栏目页，不是内容页。
判断卡在哪一环：用日志看蜘蛛到底来没来
提交之后收录不涨，有两种可能，必须先区分开：蜘蛛压根没来，还是来了但没收。这两种情况的解决方案完全不同。
方法是从访问日志里筛选各家爬虫的 UA，统计每天对不同路径的抓取次数：
# 统计各搜索引擎蜘蛛今天的抓取次数
grep "$(date +%d/%b/%Y)" /var/log/nginx/access.log \
| grep -iE 'googlebot|bingbot|baiduspider' \
| awk '{print $NF}' | sort | uniq -c | sort -rn
# 看具体抓了哪些 URL（Googlebot）
grep "$(date +%d/%b/%Y)" /var/log/nginx/access.log \
| grep -i 'googlebot' | awk '{print $7}' | sort | uniq -c | sort -rn | head -30更规范的做法是给日志加一个结构化字段，用 Nginx 的 map 把 UA 归类，写进单独的日志，这样统计起来更清爽。大致思路是在 http 块里定义：
map $http_user_agent $spider {
default -;
~*googlebot google;
~*bingbot bing;
~*baiduspider baidu;
}
log_format spider '$remote_addr - [$time_local] "$request" $status $spider';
access_log /var/log/nginx/spider.log spider;然后 awk '{print $NF}' /var/log/nginx/spider.log | sort | uniq -c 就能一眼看出三家各来了多少次。
判断标准：
- 提交后 0 次抓取：接口层面就失败了，或者蜘蛛池判定你的站不值得抓。检查 robots.txt 有没有误封、站点是否被 noindex、服务器有没有对蜘蛛返回 403/503。
- 有抓取但状态码不是 200：从日志里
awk '$9 != 200'看非 200 的比例。大量 301 跳转、429 限流、500 错误都会让搜索引擎放弃这个 URL。 - 抓了 200 但不收录：这才是最常见的情况，问题在内容层面，跟接口无关。
抓了 200 却不收录，问题在哪
蜘蛛来了、拿到 200、页面正常返回内容，但就是不进索引。这种"抓而不收"有四个高频原因：
第一，内容与站内已有页面高度重复。搜索引擎做去重时，会选一个"代表页"收录，其他的归为重复内容不单独建索引。如果你的站是采集站或者模板化生成的，几百个页面只有标题不同，那被大量丢弃是必然的。检查方法：把页面正文前 200 字做哈希，看有多少页面哈希相同。
第二，页面主体内容在 HTML 里占比太低。如果一篇文章正文只有 300 字，而导航、侧栏、推荐位、广告占了大半屏幕，搜索引擎评估"内容稀薄"时会放弃收录。这是很多采用了重型主题的 WordPress 站的通病——渲染出来的 HTML 里，正文被大量样板内容淹没。
第三，canonical 标签指向错误。如果每个页面的 canonical 都指向首页，或者带参 URL 和主 URL 的 canonical 互相打架，搜索引擎就不知道该收哪个，最后可能一个都不收。用 curl 检查每个新页面的 canonical 是否是自身 URL：
curl -s "https://example.com/post/123?_=$(date +%s)" \
| grep -oP 'rel="canonical" href="\K[^"]+'第四，站点整体抓取预算被浪费。抓取预算是个有限资源。如果你的站有大量筛选页、分页、标签页、带参 URL 对蜘蛛开放，蜘蛛的时间会大量消耗在这些无价值页面上，真正的内容页反而排不上队。解决方案是在 robots.txt 里屏蔽掉这些模式（比如 Disallow: /*?sort=、Disallow: /tag/），把预算集中到内容页。
一个可执行的收录加速组合
把上面这些串起来，一套对绝大多数站长站都有效的做法是：
- 先修基础，再谈提交。确认 robots.txt 不误封、sitemap.xml 覆盖所有内容页且能正常返回、每个页面 canonical 指向自身、正文 HTML 占比合理。基础不修，提交再多也是白提交。
- sitemap 挂到 Search Console 和百度搜索资源平台。这是最基础也最稳定的一环，比任何主动推送接口都重要。
- IndexNow 用于 Bing。成本低、效果好，值得配。每次发布新文章后自动提交。
- 普通博客不必强上 Google Indexing API。收益不确定，还要维护服务账号密钥，性价比低。真要加速 Google 收录，更有效的做法是保证站点的内容更新频率和外部链接。
- 百度重在养权重。持续更新原创内容、做好移动端体验、确保百度统计能跑起来，比研究推送接口有用得多。
这几步里，只有第 3 步是"技术上要写代码"的，其他都是配置和内容工作。这也说明一个事实：收录问题的本质从来不是接口问题，而是站点质量和结构问题。接口只是微波炉上的"加速"按钮，它不能把生米变成熟饭。
别把收录当成 KPI
最后一个容易被忽视的点：收录数从来不是目的，流量才是。有些站长为了让收录数字好看，批量生成几十万个低质量页面去碰运气，短期内收录数确实涨了，但这些页面没有排名、没有流量，反而拖累了整站的权重评估——搜索引擎会把"这个站有大量低质页面"作为一个负面信号。
一个健康的节奏是：每周稳定更新几篇真正有价值的原创内容，保证技术面（robots、sitemap、canonical、状态码）没有硬伤，然后用 IndexNow 和 sitemap 提交保证新内容被及时感知。剩下的交给时间。收录会跟着内容质量和站点权重自然长起来，这比任何"黑科技"都可靠。