工具 文档 价格 专栏 更新日志 解锁
English 中文 日本語 Español
GitHub
← 返回专栏
· 5 分钟阅读

如何不花钱修复谷歌索引问题，让页面被收录

如果谷歌不索引你的页面，SEO 就毫无意义。这里有一套实战验证的排查框架，帮你解决“已抓取 - 暂未索引”，让新页面更快被抓取，还能从索引下跌中恢复——全部用免费工具。

我还记得第一次打开 Google Search Console 看到那个数字时的情景。提交了 272 个页面。收录数为零。不是差了几页，也不是“大部分已收录，还有几个待处理”。是零。我写的、优化的、做了内链的每一个页面，Google 都看不见。

这个站不是新站。上线已经好几周了。sitemap 提交了，robots.txt 没问题，内链结构也扎实。然而 Google 的索引里，我的页面一个都没有。

如果你正在读这篇文章，大概率也遇到过同样的情况。你搭好网站、发布内容、提交 sitemap，然后等。一直等。时不时看一下 GSC。然后在 URL 旁边看到 “已抓取 - 当前未收录” 或者 “已发现 - 当前未收录”。更糟的是——之前已经收录的页面，突然就没了。

收录是 SEO 的地基。Google 没收录你的页面，它在搜索结果里就不存在。关键词优化做得再好、外链铺得再多、内容质量再高，只要页面不在索引里，全都白搭。它是最顶层的守门员。

这份指南是一套基于实战经验的排障框架——不是理论。我处理过新站不被抓取、老站一夜之间掉收录、以及各种介于两者之间的状况。这里用到的东西全部免费：Google Search Console、Google Analytics、你的浏览器，再加几个命令行工具。

为什么页面不被收录（以及为什么越来越难）

先讲一些我花了很久才搞明白的背景。

Google 不会收录它抓取的每一个页面。这是设计使然，不是 bug。Google 的索引容量有限，抓取-收录这条流水线成本很高。所以 Google 会做分级判断：对于发现的每一个 URL，它都会问：“这个页面值得收录吗？”如果答案是否——或者哪怕是“以后再说”——页面就会进入一个悬置状态。它被抓取过了，Google 知道它的存在，但它不在正式索引里。

这种分级判断越来越激进。2023-2024 年，Google 的“有用内容”更新和持续的反垃圾措施，把收录的门槛抬得更高了，尤其是那些权重低的新站。独立开发者做新站受的冲击最大，因为你一开始没有任何信任信号——没有外链、没有域名年龄、没有品牌认知度。

以下是页面不被收录的主要原因：

1. 站点质量信号差。 Google 在收录单个页面之前，会先评估整站质量。如果你的站点内容是薄内容、有重复页面、或者看起来像个内容农场，Google 可能会抓取但拒绝收录。这是最常见的原因，也是最难解决的。

2. 抓取预算浪费。 Google 会给每个站点分配有限的抓取预算。如果你的站里有几百个低价值 URL（标签页、筛选组合、分页、带参数的 URL），Google 就把抓取预算浪费在垃圾页面上，反而没精力发现你真正重要的页面。

3. 技术障碍。 robots.txt 拦截、noindex 标签、canonical 链、重定向循环、服务器响应慢、Googlebot 执行不了的 JavaScript 渲染内容——这些任何一个都可能阻止收录。

4. 孤立页面。 如果一个页面没有任何内链指向它，Google 可能永远发现不了它。即使它在你的 sitemap 里，Google 也会把内链当作质量信号来看待。在 sitemap 里但没有任何地方链接它的页面，会被当作低优先级处理。

5. 人工处置或惩罚。 如果你的站点被标记为垃圾内容、非自然链接或违反政策，Google 可能会取消页面甚至整个站点的收录资格。这种情况很少见，但一旦发生就是毁灭性的。

6. 信任赤字。 新域名，尤其是某些特定 TLD，一开始就有信任赤字。Google 在投入索引资源之前需要时间和信号。这不是惩罚——这是一个等待期，你可以通过正确的信号来缩短它。

第一步：在 Google Search Console 里诊断问题

在动手修任何东西之前，你得先搞清楚到底发生了什么。Google Search Console 是你的主诊断工具。

查看页面收录报告

进入 GSC > 网页（以前叫“覆盖范围”）。这个报告会显示 Google 知道的每一个 URL 的收录状态。关键分类：

  • 已收录：正常。页面在 Google 的索引里。
  • 已抓取 - 当前未收录：Google 抓取了页面但选择不收录。这通常意味着质量问题——Google 觉得这个页面还不值得收录。这是最让人抓狂的状态，因为页面技术上是可以访问的，Google 也看到了，但它还是说“不”。
  • 已发现 - 当前未收录：Google 知道这个 URL 存在（从 sitemap 或内链发现），但还没抓取它。这通常意味着抓取预算问题或者优先级非常低。
  • 因 ‘noindex’ 标签排除：noindex 标签阻止了收录。检查你的 meta 标签和 HTTP 响应头。
  • 因 robots.txt 排除：你的 robots.txt 拦截了这个页面。
  • 重复内容，未设置用户指定的 canonical：Google 发现了重复页面，并且选择了一个和你指定的不同的 canonical URL。
  • 重复内容，Google 选择的 canonical 与用户不同：Google 认为这个页面是另一个 URL 的副本，所以选择收录那个。

对于每一种状态，GSC 都会显示受影响的 URL。点进任何分类就能看到列表。

我首先做的事： 导出完整的“未收录”URL 列表。按分类排序。“已抓取 - 当前未收录”是我重点关注的地方，因为这些页面是被看到了但被拒绝了。解决办法通常涉及提升内容质量、改善内链，或者删掉重复内容。

使用网址检查工具

对于单个页面，网址检查工具（GSC 顶部的搜索框）会给你详细的诊断信息。输入任何 URL，GSC 会告诉你：

  • 是否已收录
  • 最近一次抓取时间
  • 任何收录错误
  • Google 选择的 canonical URL
  • 是否为移动端友好
  • 页面是否符合富媒体搜索结果的条件

这里最有用的操作是 “请求编入索引”。点击之后，Google 会把这个 URL 放进新的抓取队列。对于新页面或更新过的页面，这可以把收录时间从几周缩短到几天。Google 对这个功能有限流——每天大概 10-25 次请求——所以要策略性地用在你最重要的页面上。

我的工作流： 发布新页面或对页面做重大更新之后，我立刻通过网址检查工具请求收录。我会用表格记录哪些页面请求过、什么时候请求的，这样就能追踪 Google 的响应时间。

查看 Sitemap 报告

进入 GSC > Sitemap。这里会显示每个已提交 sitemap 的状态：

  • 成功：Google 已经处理了 sitemap 并发现了里面的 URL。
  • 有错误：出了问题——XML 格式错误、URL 返回错误状态码、或者 URL 被 robots.txt 拦截了。

如果 sitemap 显示有错误，点进去看具体信息。常见问题包括返回 404 的 URL、重定向链、或者不该被 robots.txt 拦截的 URL。

关键检查： 对比 sitemap 里的 URL 数量和 GSC 报告的“已发现”数量。如果你的 sitemap 有 200 个 URL，但 GSC 只发现了 50 个，那说明 sitemap 格式有解析问题，或者有 robots.txt 冲突。

第二步：修复技术障碍

技术问题最容易修，应该先排除掉。以下是一套系统性的检查。

确认 robots.txt 没有拦截重要页面

听起来像废话，但我不止一次见过这种情况。一条写得太狠的 robots.txt 规则把整个站点区块都拦掉了。

在浏览器里访问 https://yoursite.com/robots.txt 检查你的 robots.txt。看看有没有 Disallow 规则误伤了不该拦的页面。

常见错误： 在测试环境或预览环境里用 Disallow: /，然后忘了在生产环境改回来。或者用 Disallow: /*? 去拦带参数的 URL，结果把带查询字符串的合法页面也一起拦了。

免费验证工具： Google 的 robots.txt 测试工具（在 GSC 的旧版工具里，或者用任何在线 robots.txt 检查器）。输入一个 URL，它会告诉你这个地址是被允许还是被拦截。

检查 noindex 标签

noindex meta 标签是告诉 Google 不要收录某个页面。这东西对感谢页面、搜索结果页和筛选视图很有用——但一旦误加到重要页面上，就是灾难。

在两个地方检查 noindex 标签：

  1. Meta 标签： HTML 的 <head> 里的 <meta name="robots" content="noindex">。
  2. HTTP 响应头： 响应头里的 X-Robots-Tag: noindex。

免费检查： 在 Chrome 里打开页面，右键“查看网页源代码”，然后 Ctrl+F 搜 “noindex”。或者用 GSC 的网址检查工具，它会标记 noindex 问题。

框架相关的坑： 很多框架在特定模式下默认设置 noindex。Astro 在预览部署时会设置 noindex。Next.js 在某些配置下也会。WordPress 在“设置 > 阅读”里勾选了“阻止搜索引擎索引本站”的话，整站都会设置。查一下你用的框架的默认行为。

修复 Canonical 标签问题

Canonical 标签（<link rel="canonical" href="...">）告诉 Google 当存在重复版本时，应该收录哪个 URL。如果你的 canonical 标签写错了，Google 可能会收录错误的 URL，或者干脆不收录。

常见问题：

  1. 非 canonical URL 上写了自引用 canonical： 如果页面 A canonical 到页面 B，但页面 B 又 canonical 回页面 A，Google 会直接懵掉。每个页面要么 canonical 到自身（如果它本来就是 canonical 版本），要么指向正确的 canonical URL（单向，不能有循环）。

  2. Canonical 指向一个返回 404 或重定向的 URL： 如果你的 canonical URL 指向一个不存在的页面或者会跳转到别处的地址，Google 会忽略这个 canonical，可能就会收录错误的版本。

  3. 信号冲突： 如果你的 canonical 标签写的是 A，但你的 sitemap 列的是 B，内链又指向 C 的变体，Google 收到的信号是混乱的，最后可能自己做一个决定。

免费检查： 用网址检查工具。它会显示“Google 选择的 canonical”和“用户声明的 canonical”。如果两者不一致，说明有冲突需要解决。

我的规则： 每个页面只有一个 canonical URL。Canonical URL 和浏览器地址栏里的 URL 一致。Sitemap 里只列 canonical URL。内链只指向 canonical URL。斜杠结尾的格式要统一（选带斜杠或不带斜杠的其中一种，然后在所有地方保持一致）。

确保服务器响应时间够快

Googlebot 有超时时间。如果你的服务器响应太慢，Googlebot 会放弃然后去抓别的页面。持续超时的页面根本不会被抓取，更别说收录了。

免费检查： Google PageSpeed Insights 会测量服务器响应时间（首字节时间，TTFB）。超过 2 秒就会影响抓取。超过 5 秒，Googlebot 可能直接停止抓取你的整站。

对于部署在 Cloudflare Pages、Vercel 或 Netlify 上的静态站点，这基本不是问题。对于有数据库查询或服务端渲染的动态站点，检查一下 TTFB，需要的话就优化。

命令行检查：

curl -o /dev/null -s -w "Time to First Byte: %{time_starttransfer}s\nTotal: %{time_total}s\nHTTP Status: %{http_code}\n" https://yoursite.com/page-url

拿几个页面跑一下。如果 TTFB 持续超过 2 秒，这就是一个抓取问题。

第三步：修复抓取预算问题

抓取预算就是 Googlebot 在给定时间范围内会抓取你站点的页面数量。对于小站点（1 万页以下），抓取预算很少成为问题。但如果你把预算浪费在垃圾 URL 上，它仍然会有影响。

找出抓取预算浪费的地方

免费方法： 查看 GSC > 设置 > 抓取统计信息。这个报告会显示：

  • 每日抓取请求总数
  • 平均响应时间
  • 按用途分类的明细（Googlebot 类型）
  • 按主机名和文件类型分类的明细

如果 Googlebot 花了大量时间在抓取带参数的 URL、分面导航页面或重复内容上，你就是在浪费抓取预算。

另一个免费方法： 查看服务器日志。如果你能访问 access log，用 grep 过滤 Googlebot：

grep "Googlebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

这会显示 Googlebot 请求最多的前 30 个 URL 以及每个 URL 被抓取了多少次。如果你在这个列表的顶部看到参数 URL、标签页或其他低价值页面，说明你在浪费抓取预算。

拦截低价值 URL 的抓取

用 robots.txt 阻止 Googlebot 把抓取预算浪费在那些永远不应该被收录的 URL 上：

User-agent: *
Disallow: /*?sort=
Disallow: /*?filter=
Disallow: /*?page=
Disallow: /search?
Disallow: /tag/
Disallow: /author/

注意不要拦截有搜索价值的 URL。部署之前，把每条规则都放到 robots.txt 测试工具里验证一遍。

清理重定向链

重定向链会浪费抓取预算。如果 URL A 重定向到 B，B 重定向到 C，C 再重定向到 D，Googlebot 就要顺着这条链走，用掉四次请求而不是一次。

免费检查： 用 curl 检查重定向链：

curl -L -o /dev/null -s -w "Final URL: %{url_effective}\nRedirects: %{num_redirects}\n" https://yoursite.com/old-page

如果 num_redirects 大于 1，说明有重定向链。把第一跳直接改成指向最终目标地址。

移除孤立页面

孤立页面就是 sitemap 里有、但没有任何内链指向它的 URL。Google 会从 sitemap 里发现它，但由于站点上没有其他页面认为它重要到值得链接，Google 就会把它当作低优先级来处理。

免费检查： 对于 sitemap 里的每一个 URL，在站内链接里搜索它。最简单的方式是用一个免费爬虫工具，比如 Screaming Frog（免费版限制 500 个 URL），然后看 “Inlinks” 列。内链数为零的页面就是孤立页面。

修复方法： 给每个重要页面添加至少 2-3 个来自其他相关页面的内链。这向 Google 传递了“这个页面很重要”的信号，同时也有助于分发 PageRank。

第四步：提升内容质量信号

如果你已经排除了技术问题和抓取预算浪费，剩下的问题大概率是内容质量。Google 的收录决策本质上就是一个质量评估。以下是我学到的关于 Google 认为“值得收录”的标准。

确保每个页面都有实质性、独特的内容

Google 不太愿意收录薄内容页面。什么是“薄”因情况而异，但根据我的经验，正文少于 300 个独特词汇的页面，被“已抓取但未收录”的风险很高。有 800 个词以上真正有用内容的页面，收录速度快得多。

“独特”这个维度和字数一样重要。 如果你的页面大部分是样板内容——导航、页脚、侧边栏——中间夹一小段实际内容，Google 会觉得这就是薄内容，即便整个 HTML 文件体积不小。

我之前有个站，40% 的页面是简短的标签归档页，只有两三句话加一个链接列表。Google 把每一页都抓了，一个都没收录。后来我给每个标签页加了 200 多字的描述性内容，两周内 70% 都被收录了。那些内容算不上精彩——就是对这个标签涵盖了什么、为什么相关文章值得阅读的实用描述。但这足以传递“这个页面有价值”的信号了。

删除或合并重复内容

Google 不会收录内容实质相同的多个页面。如果你有同一页面的细微变体（打印版、移动版、排序版），Google 会选一个，忽略其余。

免费检查： 从每个页面里挑一段随机文字，加引号在 Google 里搜。如果多个页面出现在同一段文字的搜索结果里，说明有重复内容。

修复方法： 要么删掉重复页面（重定向到 canonical 版本），要么添加足够多的独特内容来区分它们。用 canonical 标签指定哪个版本应该被收录。

通过内容簇构建主题权威

当页面属于一个主题簇时，Google 会更积极地收录它。一篇孤立的“关键词研究”文章可能很难被收录。但如果你有五篇关于关键词研究且互相链接的文章——一篇主指南，加上几个具体子话题——Google 就会看到你的主题深度，更有可能把整个簇都收录。

机制： 当 Google 抓取一篇文章，发现里面有指向同主题相关文章的内链时，它会认为这个站点对这个主题有深入覆盖。这是一个质量信号，能提高簇内所有页面的收录概率。

实操方法： 不要发布孤立的单篇文章，按 3-7 篇相关的组合来规划内容。做一个支柱页面，链接到所有子文章。让每篇子文章都链接回支柱页，并且至少链接到簇里的另外 2 篇文章。这种内链结构一石二鸟：既帮助 Google 理解你的主题权威，又能确保没有页面成为孤岛。

更新过时内容

一个几个月都不更新的页面，会向 Google 暗示这个站点可能已经废弃了。Googlebot 对不定期更新的站点会降低抓取频率。

我的节奏： 我每个月至少更新一次我最重要的 10 个页面。“更新”不一定是重写——新增一节内容、更新统计数据、修复一个死链、或者扩写某一段都算。关键是页面最后修改时间会变化，向 Google 传递新鲜的信号。

第五步：让页面更快被发现

对于新站或新页面，你希望 Google 尽快发现并抓取它们。以下这些免费方法确实有效。

提交一份干净的 Sitemap

你的 XML sitemap 是最重要的发现信号。确保它：

  1. 只包含 canonical URL——没有重定向、没有重复项、没有带参数的 URL。
  2. 在可预测的位置可访问——/sitemap.xml 或 /sitemap-index.xml。
  3. 已在 GSC 中提交——进入 Sitemap，输入 URL，点击提交。
  4. 在 robots.txt 中被引用——添加 Sitemap: https://yoursite.com/sitemap.xml，这样爬虫能自动找到它。

Astro 专属提示： Astro 通过 @astrojs/sitemap 集成自动生成 sitemap。但如果你有 sitemap 索引文件（sitemap-index.xml），提交索引文件而不是各个独立的 sitemap 文件。Google 原生支持索引文件。

使用 IndexNow 做即时通知

IndexNow 是一个免费协议，可以让你即时通知搜索引擎（Bing、Yandex、Naver、Seznam）有新页面或更新过的页面。Google 目前还不支持 IndexNow，但 Bing 支持——而 Bing 带来的流量也是流量。

工作原理：

  1. 生成一个密钥（任何 UUID 都行）。
  2. 在 https://yoursite.com/{key}.txt 放一个文本文件，内容就是密钥本身。
  3. 向 https://api.indexnow.org/indexnow 发送一个 POST 请求，带上你的 URL 列表。

免费提交脚本：

import urllib.request, json

SITE = "yoursite.com"
KEY = "your-uuid-here"
urls = ["https://yoursite.com/new-page", "https://yoursite.com/updated-page"]

payload = json.dumps({
    "host": SITE,
    "key": KEY,
    "keyLocation": f"https://{SITE}/{KEY}.txt",
    "urlList": urls
}).encode()

req = urllib.request.Request(
    "https://api.indexnow.org/indexnow",
    data=payload,
    headers={"Content-Type": "application/json"},
    method="POST"
)
resp = urllib.request.urlopen(req, timeout=15)
print(f"IndexNow: {resp.status}")

这个设置只需要 2 分钟，Bing 会在几分钟内收到通知，而不是等上几周。

从已收录的页面构建内链

让新页面被快速抓取的最快方式，是从一个 Google 已经在定期抓取的页面链接到它。Googlebot 会顺着链接走——如果它每天都抓页面 A，而页面 A 链接到页面 B，页面 B 很快就会被发现。

免费检查： 在 GSC 里查看抓取最频繁的页面（网页报告，按展示次数排序）。这些是 Google 访问频率最高的页面。从这些高流量页面加链接到你新发布的页面。

我的方法： 每次发布新文章，我都会从至少 2 篇已被收录有流量的旧文章里加链接到新文章。这不仅对 SEO 有好处——对想深入了解相关主题的读者来说也确实有用。

获取外链（哪怕只有几条）

一条来自已收录页面的外链，往往就足以触发发现机制。Google 通过跟踪已知页面上的链接来发现新 URL。

有效的免费方法：

  • 在社交媒体上分享你的 URL（Twitter/X、LinkedIn、Reddit）——Google 会抓取社交平台并跟踪链接。
  • 在允许链接回你网站的平台上发布内容（Dev.to、Medium、Hashnode、GitHub README）。
  • 参与相关的线上社群，分享真正有用的内容。
  • 把站点提交到真正有编辑筛选的免费目录（避免垃圾目录列表）。

一条来自相关、已收录页面的高质量外链，抵得上 100 条来自低质量目录的链接。我见过有些页面在获得一条来自中等权威站点的链接后，24 小时内就被收录了。

第六步：从收录下降中恢复

如果你的页面之前已收录，然后突然消失了，这和“从未收录”是不同的两个问题。以下是诊断和恢复的方法。

检查人工处置

进入 GSC > 安全性与人工处置 > 人工处置。如果 Google 施加了人工惩罚，这里会列出触发原因和解决办法。

人工处置很严重，但可以修复。独立开发者站点最常见的类型：

  • 垃圾内容： 单薄、采集或自动生成的内容。修复方式是删除或大幅改进内容，然后提交重新审核请求。
  • 非自然链接： 购买或操纵性的外链。修复方式是使用 disavow 工具拒绝这些坏链接，并记录你的清理过程。
  • 社会工程 / 钓鱼： 如果站点被标记为具有欺骗性。修复方式是移除任何 Google 认为有误导性的元素，然后提交重新审核请求。

重新审核请求流程： 写一份详细、诚实的说明，讲清楚发生了什么、你修复了什么、未来如何避免。Google 的审核员是人，他们会对真诚的努力做出回应，而不是借口。附上你修复过的具体 URL，相关的话也可以附上截图。典型的响应时间是 2-4 周。

检查核心算法更新

有时候收录下降不是你的错——是 Google 某个算法更新的结果。查看 SEO 新闻网站或 Google 的搜索状态面板，看最近有没有可能影响你站点的更新。

如果算法更新导致你的收录下降，解决办法就是提升整体站点质量——算法变化没有快速恢复之道。聚焦基本盘：更好的内容、更好的用户体验、更好的技术 SEO。

检查服务器或托管问题

如果 Googlebot 抓取期间你的服务器宕机了或者 SSL 证书过期了，Google 可能会暂时取消受影响页面的收录资格。服务器恢复在线后，这些页面通常会在几天内自动恢复，但你可以通过网址检查工具请求收录来加速这个过程。

用 Google Search Console 警报监控

GSC 会对关键问题发送邮件警报：人工处置、流量骤降、收录错误和安全问题。确保你的邮箱已验证，并且在 GSC 设置里开启了通知。

我的做法： 我每周至少检查一次 GSC——不只是网页报告，还包括安全问题、人工处置和 Core Web Vitals。每周花 5 分钟检查，就能在问题恶化之前发现问题。

第七步：建立一个可持续的收录工作流

预防比恢复容易。以下是我用来确保持续收录的工作流。

每个新页面都要：

  1. 写实质性内容（800 词以上真正有用、独特的内容）。
  2. 设置正确的 canonical 标签（如果它是唯一的版本就自引用）。
  3. 从已收录页面添加 2-3 个内链。
  4. 确保页面在 sitemap 里（用 CMS 或静态站点生成器的话是自动的）。
  5. 通过 GSC 网址检查工具请求收录。
  6. 通过 IndexNow 提交给 Bing。
  7. 至少在一个外部平台分享 URL，以获得外链信号。

每周维护：

  1. 检查 GSC 网页报告——监控“未收录”分类的变化。
  2. 对重要但“已抓取未收录”的页面请求收录。
  3. 更新 1-2 个现有页面，传递新鲜度信号。
  4. 在网页报告里检查新的抓取错误。

每月审计：

  1. 审查完整的“未收录”列表——有没有规律？（全都是标签页？全都是短内容？全都来自某个特定板块？）
  2. 用上面的 curl 方法检查重定向链。
  3. 确认 robots.txt 没有意外变化。
  4. 审查内链——有没有新的孤立页面？
  5. 检查 sitemap 健康状态——所有 URL 都返回 200 且与 canonical 一致吗？

我犯过的常见错误（希望你别踩）

错误 1：恐慌乱改。 第一次看到 0 个页面被收录时，我立刻重写了一半内容、改了 URL 结构、提交了重新审核请求。实际上，这个站只是需要更多时间。新域名可能需要 4-8 周才会有第一批页面被收录。这个时期做激进改动，反而会重置 Google 的质量评估，拖慢进度。

错误 2：反复提交 sitemap。 重复提交同一个 sitemap 并不会加速收录。Google 会处理 sitemap 一次，然后按自己的节奏抓取。只有在添加了新 URL 或修复了错误之后重新提交才有意义。

错误 3：每天都在每个页面上请求收录。 Google 对收录请求有限流，频繁请求可能被当作垃圾处理。我会把每天的配额用在那 2-3 个最重要、最新或更新过的页面上，其余页面的收录顺其自然。

错误 4：忽视 Bing 和其他搜索引擎。 Bing 有 3-5% 的搜索市场份额——不大，但不是零。更重要的是，Bing 收录新站的速度比 Google 快得多。先在 Bing 上被收录，能提供早期的流量信号，最终对 Google 也有帮助。IndexNow 让 Bing 提交变得即时且免费。

错误 5：以为“已抓取”就是“已收录”。 这是两个不同的阶段。已抓取意味着 Googlebot 拿到了页面。已收录意味着 Google 决定把它放进搜索结果。很多页面被抓取了，但永远不会被收录。别在日志里看到抓取活动就庆祝——要等 GSC 显示页面已收录再庆祝。

错误 6：拦截了 JavaScript 渲染的内容。 如果你的站点用客户端渲染（React、Vue 等），而且重要内容是通过 JavaScript 加载的，Googlebot 可能看不到。Google 渲染 JavaScript 的能力变强了，但仍然有延迟且不完美。如果关键内容不在初始 HTML 响应里，就使用服务端渲染或预渲染。我在一个 Next.js 站点上栽过跟头——所有内容都是客户端渲染的，Google 连续几周收录的都是空白页。

错误 7：创建了几百个低质量页面。 我的一个站有 400 多个页面，但大多数是薄内容（不到 200 字）。Google 抓了整站，但只收录了 30 个页面。后来我把这些薄页面整合成 50 个内容全面的页面，一个月内收录数跳到了 45。少而精的页面，胜过一堆肤浅页面。

工具总结：你需要的一切都是免费的

工具用途费用
Google Search Console收录状态、网址检查、sitemap 提交、人工处置免费
网址检查工具检查单个页面的收录状态、请求收录免费
Bing Webmaster ToolsBing 收录状态、向 Bing 提交 URL免费
IndexNow 协议向 Bing、Yandex、Naver 即时提交 URL免费
Google PageSpeed InsightsTTFB、Core Web Vitals、移动端友好度免费
Chrome DevTools查看页面源代码、检查 meta 标签、检查 HTML免费
Screaming Frog（免费版）像 Googlebot 一样爬你的站，找出孤立页面和错误免费（500 个 URL）
curl检查重定向、响应头、响应时间免费

总费用：0 元。总工具数：8 个。核心观点是：光 GSC 就能给你 80% 的诊断能力。其他工具用来填补特定缺口。

结论

收录问题是可以解决的。框架很清晰：

  1. 诊断——用 GSC 的网页报告和网址检查工具。
  2. 修复技术障碍——robots.txt、noindex 标签、canonical 问题、响应慢。
  3. 优化抓取预算——拦截垃圾 URL、修复重定向链、消灭孤立页面。
  4. 提升质量信号——实质性独特内容、主题簇、新鲜更新。
  5. 加速发现——干净的 sitemap、IndexNow、来自已收录页面的内链、外链。
  6. 从下降中恢复——检查人工处置、算法更新、服务器问题。
  7. 建立可持续工作流——页面清单、每周维护、每月审计。

收录最难的部分不是技术工作，而是耐心。新站需要时间赢得 Google 的信任。今天“已抓取但未收录”的页面，随着站点权重的积累，可能下周或下个月就被收录了。恐慌然后激进改动的诱惑力很强——要忍住。修复基础问题，提交页面，构建优质内容和链接，然后让 Google 按自己的节奏来。

如果我们就坐在同一个房间里，我会告诉你：挑出你最重要的 5 个页面。确保每个都有 800 词以上的真正有用内容、正确的 canonical 标签、来自现有页面的 3 个以上内链、并且没有技术问题。通过 GSC 对这 5 个页面请求收录。通过 IndexNow 提交给 Bing。然后等两周再看。

如果它们被收录了，就扩展到 10 个页面。如果没有，回头重新读一遍上面的诊断步骤，找找你漏掉的东西。答案永远在 GSC 里——你只需要知道去哪里找，以及这些状态意味着什么。

修复收录问题不是什么光鲜的活儿，但它是 SEO 里一切其他工作的地基。没有收录，就没有流量。先把这件事做对。

想给自己的站点做同样的分析？

ZensInk Pro 把这个流程自动化了。一条命令，从种子词到内容计划。

查看 Pro →