搜索结果里显示的排名,追到最底层就是两件事。爬取,Google 派自动程序到你的网站,把页面内容下载回去。索引,Google 把下载回来的内容分析一遍,存进自己的数据库,等有人搜索时从里面挑相关的页面返回。
这两个概念是 SEO 领域里面非常基本的两个观念。在了解 SEO 之前一定要理解它们,后面所有的优化动作,最终都是在影响这两个环节。这篇文章由浅入深,先讲清楚它们分别是什么,再讲 Google 具体怎么运作,最后落到常见状态和排查顺序。
这篇文章的事实口径主要来自 Google 官方文档,动笔前我把 Search Central 和 Search Console 帮助里的相关页面重新过了一遍,下文引用到的地方会标出来。有个别结论来自 IndexNow 官方站点,写到那里再说明。
爬取是什么,索引是什么
Google 把搜索的运作分成三个阶段,爬取、索引、提供搜索结果。
爬取,Google 用自动程序从网页上下载文字、图片和视频,这个程序统称 Googlebot。索引,Google 分析页面的内容和关键标签,把信息存进 Google 索引这个大型数据库。提供搜索结果,用户搜索时,Google 从索引里挑出相关页面返回。
三个阶段,每个页面不一定能走完。官方文档在讲这三段之前先写了一句提醒,即使页面完全符合 Google Search Essentials,Google 也不保证会爬取、索引或提供这个页面。
把收录当 KPI 的团队都应该把这句话记下来。收录没有配额、没有承诺,Google 对页面的取舍基于它自己的评估。好消息是,机制本身是透明的,照着做能显著提高被收录的概率,也能在没被收录时知道卡在哪一步。
Google 怎么发现你的页面
Google 必须先知道页面存在,这一步官方叫 URL 发现,入口只有三类。
第一类,Google 之前已经访问过这个 URL。老页面改版、内容更新都属于这类。
第二类,链接。Google 爬取已知页面时,从 HTML 里的链接发现新 URL。首页链到新发布的文章,其他网站链到你的页面,都算。
第三类,sitemap。你在 Search Console 提交 sitemap,或在 robots.txt 里声明它的位置,Google 会定期读取。
知道 URL 存在,不等于马上爬取。Googlebot 用自己的算法决定爬哪些站、多久爬一次、一次爬多少页,同时会控制速度避免把网站压垮。服务器持续返回 500 错误,Google 会放慢节奏。
Googlebot 爬取时的几个硬限制
Googlebot 是两类爬虫的统称。Googlebot Smartphone 模拟手机用户,Googlebot Desktop 模拟桌面用户。多数网站现在以移动版内容为主进行索引,所以绝大多数爬取请求来自移动爬虫,桌面爬虫只占少数。
几个容易踩坑的硬参数。Googlebot 抓取支持的文件类型时只下载前 2MB,PDF 例外,是前 64MB。页面引用的 CSS 和 JS 各自单独抓取,每个资源同样受 2MB 上限约束。超出的部分不会送进索引评估,页面关键内容放在很靠后的位置,或者把正文整个塞进一个巨型脚本文件,都可能让 Google 看不到。
爬取频率方面,官方口径是 Googlebot 对多数网站平均每几秒最多爬一次。服务器扛不住时,可以在 Search Console 里调低爬取速率。如果服务器持续返回 5xx 或 429,Google 也会自动降低爬取频率。
想确认访问者到底是不是 Googlebot,别只看 user-agent,那个太容易被伪造。官方推荐的做法是对来源 IP 做反向 DNS 查询,或者对照 Google 公布的 IP 段。
robots.txt 只管爬取,管不了收录
robots.txt 的作用是管理爬虫流量。官方文档讲得很直接,它主要用来避免站点被请求压垮。让页面离开 Google 要靠 noindex 标签或密码保护。
robots.txt 对不同文件类型的效果还不一样。网页被屏蔽后,URL 仍可能出现在搜索结果里。图片、视频这类媒体文件被屏蔽后,则不会再出现在 Google 图片和视频结果中。所以想挡住图片被 Google 收录,robots.txt 是有效手段;想挡住网页,它靠不住。另一个限制是语法兼容,robots.txt 的指令依赖爬虫自愿遵守,不同爬虫对语法的解释也可能不同。它没有强制力,只是一套礼貌约定。
这段话后面还有一层更反直觉的事实。一个被 robots.txt 屏蔽的页面,如果其他地方有链接指向它,Google 仍然可能收录这个 URL。搜索结果里会出现这个地址,只是没有描述文字,因为 Google 没有读页面内容,但它知道这个 URL 存在,也知道别人怎么描述它。GSC 里 “URL blocked by robots.txt” 状态的官方说明也写了同样的话,这个状态不保证页面不会被其他途径收录。
还有个更隐蔽的坑。页面被 robots.txt 挡住,Google 就读不到页面上的 noindex 标签。想屏蔽页面的人以为自己做得彻底,结果 Google 看不到 noindex,反而可能把 URL 收进去。Google 的帮助文档明确说,用 robots.txt 屏蔽页面是不推荐的做法,它实际上会阻止 Google 看到 noindex。
到这里结论就很清楚。想控制爬取,用 robots.txt。想控制收录,用 noindex 或登录保护。两者别混用。
JS 页面多走一步渲染
现代页面很多靠 JavaScript 生成内容。Google 处理这类页面时,在爬取和索引之间插进一个渲染步骤,顺序是爬取、渲染、索引。
渲染器是一个无头浏览器,跑的是常青版 Chromium,也就是持续更新到最新版本的 Chrome 内核。所有返回 200 的页面都会进入渲染队列,不管页面上有没有 JS。队列有多长不固定,页面可能在队列里等几秒,也可能更久。JS 生成的内容进索引,天然比纯 HTML 慢半拍。
两条实用结论。JS 注入的链接 Google 能发现,前提是链接用标准的 a 标签和 href 属性。用 hash 路由切换内容的单页应用,Google 解析 URL 不可靠,改用 History API 会好很多。canonical 声明也有讲究,官方建议放在原始 HTML 里,用 JS 写入只是次选,而且 JS 写入的值必须与 HTML 里的一致。
SSR 和预渲染仍然值得做。用户访问更快,Googlebot 处理更快,而且不是所有爬虫都支持执行 JS。
爬取预算只对多大的站有意义
爬取预算指 Google 愿意且能够爬取的 URL 数量。官方定义由两部分组成,爬取容量限制加爬取需求。容量限制来自服务器承受力,Google 给每个站一个保守的初始值,站点响应稳定就上调,出现 5xx 或 429 就下调。需求来自页面热度、更新频率和内容质量。
这个概念只对特定规模的站点重要。官方给出的参考线,一百万个以上唯一页面且内容每周更新,或者一万个以上页面且内容每天变化,或者 GSC 里有大量 “Discovered - currently not indexed”。官方同时说明这些数字只是粗估。中小站基本不用管,保持 sitemap 更新、定期看页面索引报告就够了。
对大站来说,最容易自己控制的因素是 URL 库存。重复页面、参数筛选页、无限滚动页都会消耗爬取名额。官方建议用 robots.txt 屏蔽这类页面,注意这里是屏蔽爬取,不是加 noindex,因为 noindex 页面 Google 仍然会爬,爬完再丢弃,同样浪费预算。已删除的页面返回 404 或 410,比用 robots.txt 挡着更干净,Google 对这类 URL 会逐渐减少爬取,但不会立刻忘掉。官方文档里还有一条口径,Google 会持续重爬返回 4xx 的已知 URL,唯一能让 Google 停止爬取的情况,是页面返回 noindex。
GSC 状态逐个读
页面索引报告把 URL 分成两类,已索引和未索引。官方提醒过一句,别指望站点所有 URL 都被收录,目标应该是让每个重要页面的 canonical 版本进索引。重复页和替代页不被收录通常是好事,说明 Google 找到了 canonical 并已收录。
报告里还有一列容易忽略,Source。它标注问题来自网站还是 Google。标 Website 的,通常自己可以修;标 Google 的,往往与站点本身无关,不用处理。判断一个状态要不要动手之前,先看这一列。
几个最常见状态。
Crawled - currently not indexed,页面爬过了,Google 没把它收进索引。将来可能收录,也可能不收录,官方明确说不用重复提交这个 URL。这类页面多半要回到内容本身找原因,页面质量、重复程度、站点整体评估。
Discovered - currently not indexed,页面被发现了,还没爬。官方解释里最典型的原因,Google 想爬,但这个站当时已经过载,所以推迟了。中小站上这个状态最常见的原因其实是 URL 数量太大,页面排在爬取队列后面,一直轮不到。
Alternate page with proper canonical tag 和两类 Duplicate 状态,都属于正常运转。重复页、AMP 版、移动版正确指向 canonical 页面,canonical 已收录,这些不用处理。Duplicate 状态还说明 Google 替你选了 canonical,如果不认同,去检查页面上声明的 canonical 是否合理。
URL marked noindex,noindex 标签生效了。不想要收录就没事,想要收录就移除标签。
Page with redirect 本身不是错误,跳转目标才可能被收录。
Soft 404,页面返回 200,但内容是”没找到”。Google 认为是软 404,该返回 404 的页面就返回 404。
URL blocked by robots.txt 前面讲过,多半是故意屏蔽,不是错误。要确认这些页面确实不想被 Google 读,否则放开屏蔽,改 noindex。
服务端问题会显示成 5xx 和各类 4xx。这些是真错误,需要修服务器、查防火墙和 DNS。
排查顺序与能做的动作
碰到收录问题,建议的顺序是由宽到窄。
先看状态本身。Duplicate、Alternate、noindex、robots.txt 屏蔽,常常是设计使然,不用动。
再看数量比例。Not indexed 里绝大多数是筛选页、参数页、归档页,说明站点运转正常。接下来只确认一件事,重要页面有没有进索引。
然后挑一个具体 URL,用检查工具跑一遍。它会告诉你爬取是否成功、渲染有没有问题、Google 选的 canonical 是哪个。修完可以点请求编入索引,官方说这能缩短新内容的收录延迟,但收录从不是即时的,即使直接提交爬取请求也一样,新内容可能需要几天才会被处理。
日常动作就几条。sitemap 保持更新,有更新的内容加 lastmod 标签。删除页面返回 404 或 410。重复内容做整合。服务器保持稳定,少出 5xx。这些做完,剩下的就是内容质量和时间。
新建的站点还要多一层预期管理。官方文档说,Google 知道 URL 存在之后,可能要过几周才会爬取站点的部分或全部页面。新站上线一两周没什么收录,多半是正常的,先把 sitemap 提交好,把首页和内链做扎实。
验证修复的时间预期也摆在这里。GSC 里点验证修复,官方说通常需要两周左右,有时更长,期间 Google 会重爬受影响页面,用邮件通知进度。收录问题没有一键修复。
关于 IndexNow 和 Indexing API
IndexNow 是一个让站长主动通知搜索引擎内容变化的协议,一个简单的 ping,告诉搜索引擎某个 URL 新增、更新或删除了。它的支持名单包括 Bing、Naver、Seznam、Yandex 和 Yep,Google 不在里面。
Google 官方的快速收录工具叫 Indexing API,使用范围很窄,只支持两类页面,带 JobPosting 结构化数据的职位页,和把 BroadcastEvent 嵌在 VideoObject 里的直播页。普通内容页面用不了。
对出海站主来说,指望 IndexNow 或 API 加速 Google 收录,方向就错了。Google 这边通用的入口只有两个,sitemap 和请求编入索引。
爬取和索引分开看,GSC 状态当线索不当判决,时间预期拉长到几周。这几条做到,收录问题大半会自己消失,剩下的小半,才是真正需要修的地方。


