最近给这个博客做了一轮 SEO，本以为是「加个 sitemap」这种十分钟的活儿，结果一路排查下来牵出好几个隐藏问题：部署发错了地方、sitemap 的 lastmod 全站失真、新域名迟迟不收录……这篇把整个过程复盘一下，都是真实踩过的坑和验证过的解法。

背景

博客是 Hexo + Butterfly 主题，纯静态站，托管在自己的一台服务器上（nginx 直接托管静态文件）。目标很朴素：让 Google、Bing、百度都能正常抓取收录文章。

一开始只想着「Bing 那边还没提交 sitemap，加一下」，然后就掉进了一连串坑里。

坑一：部署发错了地方

给 Bing 加验证 meta 标签后，Bing 一直报「<meta> tag not found」。反复确认标签明明在本地 public/index.html 里，怎么会找不到？

关键在于先搞清楚线上到底由谁在服务。一条命令就看穿了：

1
2
curl -sI https://your-domain/ | grep -i server
# server: nginx/1.29.7

nginx —— 而不是 GitHub Pages 的 Fastly。再查 DNS：

1
2
dig +short your-domain A
# 指向自己的服务器 IP

真相大白：域名解析到自建服务器，由 nginx 托管；而项目里的 hexo deploy 却在往 GitHub Pages 推。标签推到了 GitHub，但线上根本不看 GitHub。 难怪 Bing 找不到。

教训：排查线上问题前，先用 curl -I + dig 确认线上的真实服务来源，别想当然地以为「部署命令 = 线上」。

修复方式是把发布方式改成实际的路径——把本地 build 出的 public/ 直接 rsync 到 nginx 服务的目录，并彻底移除废弃的 GitHub Pages 部署（删掉 hexo-deployer-git 依赖）：

1
2
npx hexo clean && npx hexo generate
rsync -az --delete public/ user@server:/path/to/nginx/webroot/

坑二：Bing 不需要单独的 sitemap

一度想给 Bing 单独生成一个 bingsitemap.xml（因为百度那边确实有个定制的 baidusitemap.xml）。做完才想明白：Bing 和 Google 用的是完全相同的 sitemap 标准协议，根本不需要独立文件。

更有意思的是 Bing 后台的数据坐实了这一点。提交 bingsitemap.xml 后：

  • 「已发现站点地图：0」
  • 「发现的 URL：3」（其实是索引里 3 个子图链接本身，Bing 没有下钻）

而标准的 sitemap.xml 则正常下钻、爬到了几十个真实 URL。原因很可能是：bingsitemap 的内容和 sitemap.xml 逐字节重复，Bing 识别到重复就不再重复处理了。

所以这个「专属 sitemap」纯属冗余，果断删掉。结论：Bing / Google 直接提交标准 sitemap.xml 即可，不要造重复副本。 百度那份定制版之所以保留，是因为它有真实差异（去掉了百度支持不好的 changefreq/priority 字段），冗余得有理由才值得留。

坑三：IndexNow —— 让 Bing 主动来抓

IndexNow 是微软主推的协议，让你在发布/更新内容时主动 ping 搜索引擎，而不是被动等爬虫。Bing 支持，Google 目前（2026 年）不支持。

接入分两步：

1. 托管 key 文件。 生成一个 key，把内容为该 key 的文本文件放到站点根：

1
https://your-domain/<key>.txt   内容就是 <key> 本身

Hexo 里直接把这个 .txt 丢进 source/ 就会被拷进 public/。注意 key 文件不要进 sitemap，可以在 sitemap 生成逻辑里加一条排除规则。

2. 发布时 POST 推送。 按协议 POST 一段 JSON 给 api.indexnow.org：

1
2
3
4
5
6
{
  "host": "your-domain",
  "key": "<key>",
  "keyLocation": "https://your-domain/<key>.txt",
  "urlList": ["https://your-domain/some-post/"]
}

返回 HTTP 200 / 202 即成功。我把这一步写成脚本，复用了已有的「本轮新增文章 URL 收集」逻辑，接进 CI —— 每次检测到新文章就自动推给 Bing。

一个值得做的验证：反证法

怎么确认 key 校验真的生效、而不是 Bing 无脑收下？故意推一个不属于本站的 URL：

1
2
# 推本站 URL → HTTP 200（接受）
# 推 example.com 的 URL → HTTP 422（拒收）

拿到 422 就说明：Bing 真的在校验域名所有权，只接受属于你的 URL。这比单看一个 200 有说服力得多——200 可能是任何原因，422 才证明校验逻辑在工作。

坑四：sitemap 的 lastmod 全站塌缩成同一天

这个最隐蔽。检查生成的 sitemap，发现几十个 URL 的 <lastmod> 全是同一天（部署当天），但文章真实发布日期跨越好几年。

根因链条：

  1. 文章 front-matter 里普遍没有 updated 字段；
  2. Hexo 默认 updated_option: 'mtime'，即用文件修改时间当 updated；
  3. 文章是通过 rsync / 对象存储同步部署的，所有 .md 文件的 mtime 都变成了同步那一刻；
  4. sitemap 的 lastmod 取了这个失真的 updated → 全站同一天。

危害： 搜索引擎看到「整站几十篇文章同一天更新」，容易判定为批量迁移 / 批量生成的站点，从而降低信任度和抓取优先级。对新站是雪上加霜。

修复： 一行配置治本。Hexo 官方专门为「Git / 同步工作流下 mtime 不可信」提供了这个选项：

1
2
# _config.yml
updated_option: 'date'

改成 'date' 后，没有手写 updated 的文章会回退到真实发布日期 date，sitemap 的 lastmod 立刻恢复了跨年份的真实分布。

如果你的 sitemap 是自定义生成的，也建议把取值逻辑显式改成「以 date 为基准，仅当有真实且更晚的 updated 时才用 updated」，双保险。

那么，一周多零收录到底正不正常？

做完上面这些，三大引擎一周多还是没收录任何文章。是不是哪里还有问题？

我把所有可能「拦截收录」的技术因素挨个查了一遍：

检查项 结果
robots.txt 是否拦爬虫 放行
文章页有无 noindex / X-Robots-Tag 无
canonical 自指正确
Googlebot / Baiduspider / bingbot UA 访问 全部 200
正文是否直出 HTML（不靠 JS 渲染） 直出
HTTPS / 证书 / 首页 正常

技术上没有任何障碍。 那答案只剩一个：域名太新。

whois 一查，域名实际注册至今才几个月，博客上线也就三个多月，认真做 SEO 更是最近的事。而按 2026 年的行业经验：

  • 新域名有 3–9 个月的「信任评估期」（俗称 Google Sandbox），期间收录慢、排名被压制，这是对所有新域名的普遍待遇；
  • 廉价 TLD（比如 .site）的评估期往往更长；
  • Bing 即使配了 IndexNow，小站完整收录也要 2–4 周；
  • 百度对新站更保守。

所以一周多零收录，完全在正常窗口内，不是故障。 这一步的价值在于：先用技术清单排除掉真正的问题，剩下的就是耐心。

能加速的正经手段

  • Google Search Console 的「URL 检查 → 请求编入索引」：手动提交重点文章，新站最快的收录方式，往往 24–48 小时；
  • IndexNow（已配）：Bing 1–3 天来抓；
  • 别反复重提 sitemap、别频繁大改：新站最忌讳「看起来不稳定」。

小结

一次「加个 sitemap」的小任务，最后收获了几条能复用的经验：

  1. 排查线上先确认服务来源（curl -I 看 server 头、dig 看解析），别假设「部署命令 = 线上」；
  2. Bing / Google 共用标准 sitemap，不要造重复副本，冗余要有理由；
  3. IndexNow 用反证法验证（推一个非本站 URL 看是否 422），比单看 200 可靠；
  4. 同步部署会污染文件 mtime，Hexo 用 updated_option: 'date' 让 sitemap 的 lastmod 回归真实；
  5. 新域名零收录先别慌，用技术清单排除真问题，剩下的交给时间。

SEO 里很多「看起来出问题了」的现象，其实只是还没到时候。先把技术做干净，然后耐心等信任积累——这大概是这次复盘最实在的一条。