为什么搜索引擎抓到了你的站，却「不收录」

很多个人站长都遇到过这种困惑：在 Google 或 Bing 里搜 site:mysite.com，结果显示「未找到」；去服务器日志里一看，Googlebot 明明来过，甚至来了很多次，爬取量也不低。爬了却不收录，是最让人抓狂的一类 SEO 问题，因为「网站能打开、内容也写了、爬虫也来了」，外面看不出任何毛病，问题全藏在细节里。

本质原因只有一个：抓取（crawl）和收录（index）是两件事。爬虫访问你的页面，只是把 HTML 取回去；是否收录，取决于索引器（indexer）对这份内容的一系列判断——页面是不是重复的、是不是低质量、有没有被 noindex 挡住、是不是需要渲染 JS 才能看到内容、canonical 指向哪里。任何一环出问题，都会导致「爬了但不收」。本文按「先诊断、再逐项排查、最后验证」的顺序，给你一套可执行、可验证的收录问题排查方法，尤其针对个人站长最常踩的几个坑：robots/meta 误挡、canonical 冲突、JS 渲染内容、重复内容、以及新站的「沙盒」观望期。

第一步：先搞清楚「不收录」到底卡在哪一层

不要一上来就猜。先用几个免费工具把问题定位到具体环节，否则你会花大量时间在错误的方向上优化。

# 1. 确认 robots.txt 是否放行了爬虫（浏览器或 curl 均可）
curl -s https://mysite.com/robots.txt
# 关键检查：有没有 Disallow: / 之类的全站封禁，或误封了 Googlebot/Bingbot

# 2. 确认某个具体 URL 返回的是 200 而不是重定向/软 404
curl -sI https://mysite.com/some-post.html | head -5
# 期望 HTTP/2 200；如果是 301/302 连环跳，爬虫可能跟丢

# 3. 确认页面里有 index 信号（没有 noindex）
curl -s https://mysite.com/ | grep -i 'meta name="robots"'
# 如果出现 noindex —— 这就是根因，收录被自己挡住了

# 4. 确认 canonical 指向自己
curl -s https://mysite.com/some-post.html | grep -i 'rel="canonical"'
# 期望指向该页自身；若指向别人/首页，等于告诉搜索引擎「别收这页」

这四个命令能在两分钟内排除掉一半的常见问题。robots.txt 全封、noindex 误加、canonical 串味，这三样占了「爬了不收录」的绝大多数。如果这几项都正常，再看下面更深的原因。

坑一：noindex 与 robots 的「双重误伤」

最常见的自杀式配置，是测试时为了让站点不被搜到，加了 noindex，上线后忘了删。更隐蔽的是缓存：你改了模板去掉了 noindex，但 CDN 或页面缓存还留着旧版本 HTML，爬虫拿到的仍是带 noindex 的页面。

# 检查站点是否在模板层面残留 noindex
grep -rn 'noindex' /var/www/mysite/ --include="*.html" | head
# 检查 CDN/缓存是否还吐旧页面（对比源站与 CDN）
curl -s https://mysite.com/ | grep -i noindex       # 经 CDN
curl -s -H "Host: mysite.com" http://源站IP/ | grep -i noindex  # 直连源站

另一类误伤在 robots.txt。有人为了屏蔽后台，写了 Disallow: /admin，结果把路径里含 admin 的正常页面也挡了；或者更糟，用了 User-agent: * Disallow: / 只在本机测试、忘了改就推送上线。Robots 规则是「前缀匹配」，Disallow: /p 会挡住所有以 /p 开头的路径（包括 /post/）。写完后务必用 Google Search Console 的 robots.txt 测试工具逐条验证，别凭感觉。

坑二：canonical 与「重复内容」自相残杀

canonical 标签是告诉搜索引擎「这个内容的正版在这里」。用错了会适得其反。三种典型翻车：

1. 所有页面 canonical 都指向首页：常见于模板变量写错，把 canonical 硬编码成了站点首页。后果是内页全部被判为首页的重复，索引器只收首页，内页全掉。
2. http 与 https、www 与非 www 混用：页面实际在 https://www，canonical 却写 http:// 早期版本，两个 URL 被当两份内容，权重分裂。
3. 带参数与不带参数的页面互相 canonical：如 ?utm_source=x 的页面如果 canonical 指向自己，会被当成独立重复页；正确做法是 canonical 一律指向「干净的规范 URL」。

# 批量检查站内 canonical 是否都指向自身（Hugo/Astro 产物扫描）
cd /var/www/mysite/current
for f in $(find . -name "*.html" | head -50); do
  url=$(grep -o '<link rel="canonical" href="[^"]*"' "$f" | head -1)
  printf "%-40s %s\n" "$f" "$url"
done | grep -v "canonical" && echo "以上页面缺 canonical"

规范 URL 的黄金法则：在服务器层面就把所有变体 301 到唯一的规范形式（选 https + 一个 www 或非 www，另一个 301 过去），然后在页面里 canonical 指向自己。不要靠 canonical 去处理大量重复——canonical 是「建议」，301 才是「强制」。把 www/非 www、http/https 用 301 收口，比在页面里声明 canonical 可靠得多。

# Nginx：把非规范域名统一 301 到规范域名（示例：统一到 https://www）
server {
    listen 80;
    server_name mysite.com www.mysite.com;
    return 301 https://www.mysite.com$request_uri;
}
server {
    listen 443 ssl;
    server_name mysite.com;      # 非 www 的 https 也 301 到 www
    return 301 https://www.mysite.com$request_uri;
}

坑三：JS 渲染的内容，爬虫可能「看不见」

如果你用的是纯前端框架（Vue/React 的客户端渲染 SPA），那么初始 HTML 里往往只有一个空的 <div id="app">，真正的内容靠 JS 执行后才有。Google 能做 JS 渲染（有延迟、有配额），但 Bing、百度以及很多二线搜索引擎对 JS 渲染支持很弱，甚至完全不做。结果就是：Google 可能勉强收录，其他引擎一律「内容为空，不收」。

# 检查「不执行 JS 时」页面里到底有什么内容
curl -s https://mysite.com/some-page | sed 's/<[^>]*>//g' | tr -s ' \n' | head -20
# 如果剥掉标签后几乎没文字 —— 你的内容全靠 JS，收录会很难

# 对比「渲染后」内容（用 Chrome 无头模式）
google-chrome --headless --dump-dom https://mysite.com/some-page 2>/dev/null \
  | sed 's/<[^>]*>//g' | tr -s ' \n' | head -20

如果两者差异巨大，解决方案有二：其一，改用预渲染（prerender）或 SSR/SSG，让初始 HTML 就含完整内容——这也是为什么静态站（Hugo/Astro/Next 静态导出）在收录上天然占优；其二，如果必须用 SPA，至少给关键页面加预渲染服务（如自建 Prerender，或在构建时用 puppeteer 把关键页导出成静态 HTML 交给爬虫）。对个人站长，最省心的选择是：内容页用静态生成，交互才用 JS。

坑四：新站的「观望期」不是 bug，是常态

如果你确认上面所有技术项都正常，站点也确实是新上线的，那么很可能只是处于新站的信任建立期。新域名没有任何历史信号，搜索引擎会先给一个很低的抓取/索引配额，慢慢观察内容质量与稳定性，几周到几个月都是正常的。

这个阶段该做的是「持续输出 + 主动提交」，而不是焦虑地反复改站：

# 1. 提交 sitemap 到各大搜索平台（Google/Bing 都有 Webmaster 工具）
curl -s https://mysite.com/sitemap.xml | head -20
# 确认 sitemap 格式正确、含真实 URL、且 URL 可访问（200）

# 2. 用 IndexNow 协议主动推送 URL（Bing/Yandex/Seznam 支持，一次推送多引擎生效）
curl -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json" \
  -d '{
    "host": "mysite.com",
    "key": "你的IndexNow密钥",
    "keyLocation": "https://mysite.com/你的IndexNow密钥.txt",
    "urlList": ["https://mysite.com/post-1.html", "https://mysite.com/post-2.html"]
  }'
# HTTP 200/202 表示已接收；GET 单条也可，无需账号，非常适合个人站

IndexNow 是被很多站长忽视的免费利器：在站点根放一个「密钥.txt」（内容就是密钥本身），然后任何新增/更新页面都可以 POST 推送通知。它不保证收录，但能显著加快「被发现」的速度，尤其对新内容首日收录有帮助。配合 sitemap 自动提交，能做到「新文章一发，多引擎当天知晓」。

坑五：内容层面的「不收录」信号

技术项全对，内容本身也可能被判为不值得收录。索引器的判断标准里，这几条对个人站尤其致命：

注意最后一条：搜索引擎对「影响使用的侵扰性广告」有明确降权。个人站的 AdSense 位置要克制，别一进文章就插屏、别做成遮挡内容的悬浮层，文章内的 in-article 流式广告是安全的，但如果一屏里塞三四个，也可能被判为低质量。

验证：怎么确认「已经收录了」

排查完、改完后，不要凭感觉认为「应该好了」。用这几招确认：

# 1. site: 语法看收录量（各引擎语法一致）
#    在 Google/Bing 搜索框输入：site:mysite.com

# 2. 精确查某个 URL 是否被收录（Google 搜索完整 URL，看是否直接命中）
#    https://mysite.com/exact-post-url.html

# 3. Google Search Console → URL Inspection，输入 URL
#    查看 "Coverage" 状态，能看到 "Discovered - currently not indexed"
#    或 "Crawled - currently not indexed" 这类精确状态

# 4. 检查服务器日志里 Googlebot 的抓取与返回码
grep -i "googlebot" /var/log/nginx/access.log | tail -20 | awk '{print $7, $9}'
# 关注是否有大量 5xx（爬虫遇到错误会降低抓取频率）
grep -i "googlebot" /var/log/nginx/access.log | awk '$9 ~ /5../' | wc -l

Crawled - currently not indexed 这个状态特别值得记住：它明确告诉你「爬了但没收」，把问题锁定在「内容/质量」而非「技术可达性」上——遇到它，就该回到上面「坑五」去审视内容质量，而不是继续折腾 robots 和 sitemap。反之如果是 Discovered - currently not indexed，说明还没爬到，问题在抓取预算或站点结构。

排查清单（照着做一遍）

1. robots.txt 没全封、没误封目标路径；
2. 页面无 noindex，且 CDN/缓存没有残留旧 noindex；
3. canonical 指向页面自身，规范域名唯一；
4. www/非 www、http/https 用 301 统一收口；
5. 不执行 JS 时页面仍有实质内容（或已预渲染）；
6. sitemap 正确且已提交，新页面用 IndexNow 主动推送；
7. 每篇文章有信息增量、有内链、不是模板灌水；
8. 服务器对爬虫返回 200，5xx 比例低；
9. 用 GSC 的 URL Inspection 看精确覆盖状态再决定下一步。

「抓了不收录」从来不是玄学，它是可以被逐层拆解、逐项验证的工程问题。先诊断再动手，把上面的清单过一遍，你会发现绝大多数「不收录」都源于一个具体的、可以修的错误配置，而不是搜索引擎在针对你。修好之后给它一点时间——内容站是长跑，收录是结果，不是命令。