Blog · 2026-08-30

新站一页都没被索引？先查 canonical 跟 sitemap 有没有打架

收录挂零先别急著改内容：用 URL 检查 API 看 lastCrawlTime，全空代表讯号在打架——把 canonical、og:url、JSON-LD、sitemap 四个位置对齐、逐笔验到 200、重送 sitemap，通常就解了。

站上线好几个星期，sitemap 交了、内容也不是薄页，Search Console 的收录数还是 0。最常见的反应是回头改文章、换标题，或安慰自己「新网域就是要等」。先停一下：一页都没被索引，通常不是品质问题，而是网站对搜寻引擎讲了两套互相矛盾的话——这种问题改内容改不好，查对地方才修得掉。

先看 lastCrawlTime：全空＝Google 根本没来，不是来了嫌烂

用 Search Console 的 URL 检查 API（urlInspection().index().inspect()）把全站网址扫一遍，重点看两个栏位：coverageState 跟 lastCrawlTime。这两个栏位把「没被收录」拆成两种完全不同的病：

• lastCrawlTime 有值、状态是「已检索 - 目前尚未建立索引」：Google 来过、看完、决定先不收。这时才轮得到内容品质、样板重复度的问题。
• lastCrawlTime 全空、状态卡在「已找到 - 目前尚未建立索引」甚至「Google 无法辨识的网址」：Google 连抓都没抓。内容写得再好它也没看过，问题在技术讯号，不在文章。

我们处理过的「整站挂零」新站，扫下来 lastCrawlTime 清一色是空的。这个栏位一空，就可以跳过内容焦虑，直接查讯号。

真凶长这样：sitemap 说 A、canonical 说 B、B 又被 308 转回 A

去识别化后的实际案例，三行就能看懂：

sitemap 的 <loc>  →  https://example.com/reviews/foo        （无副档名）
页面的 canonical  →  https://example.com/reviews/foo.html   （带 .html）
实测 foo.html     →  回 308，转回无副档名的 /reviews/foo

站在 Google 的角度走一遍：照 sitemap 来抓 A，A 页上的 canonical 说「正式版是 B」，去抓 B，又被 308 丢回 A。两个讯号来回踢皮球，Google 不会帮你猜哪个算数，它的做法是延后处理，或干脆放弃建立索引。

这个雷在静态托管平台上特别好踩：例如 Cloudflare Pages 会自动把 /foo.html 308 转到 /foo——文件系统上放的是 foo.html，对外正式网址却是无副档名的 /foo。产生器照档名输出带 .html 的 canonical，sitemap 又输出无副档名的 loc，两段程序各自看都「没错」，错在不一致。

要对齐的四个位置，少一个都还在打架

一页的正式网址在站上不只出现一次，以下四个位置必须逐字元一致：

1. <link rel="canonical">
2. <meta property="og:url">
3. JSON-LD 里 WebPage / Article 这类节点的 "url"
4. sitemap.xml 的 <loc>

修法不是开四个文件各改一次，而是在产生器里定义唯一的「正式网址」函式，四个位置全部从同一个值输出。靠人工同步四份字串，迟早再打架一次。

顺带一个常见的邻居问题：sitemap 的 loc 混进建置目录的路径前缀，线上直接 404。我们踩过更阴的版本——验证脚本里一行「好心」的 fallback 自动把前缀剥掉再比对，写错的 loc 因此每轮检查都过，连续绿了非常多轮都没人发现。教训：fallback 只能吸收已知且正确的形式差异（例如平台的无副档名网址），不能拿来吸收错误。写每行 fallback 前先问一句：这是在容错，还是在掩盖 bug？

验收只有一条标准：每笔 loc 直接回 200

改完不能只看「页面打得开」。浏览器跟带 -L 的 curl 都会自动跟转址，308 根本看不到，所以要关掉自动跟随来量：

# 不带 -L，才看得到真实状态码
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"

标准：sitemap 里每一笔 <loc> 直接请求都要回 200。回 308 算失败——代表 loc 写的不是正式形式；404 更不用说。另外抽几页确认三位一体：实际请求的网址、页面 canonical、og:url 三者完全相同。

最后一步最多人漏：回 Search Console 重新提交 sitemap。不重送，Google 手上还是旧文件，矛盾讯号会继续留在它的排程里，前面全部白改。

对齐之后还是卡「已找到」？换查内链

四处对齐解决的是「讯号矛盾所以不抓」。如果讯号干净了，页面还是长期卡在「已找到 - 目前尚未建立索引」，下一个常见凶手是内部连结太稀：页面只挂在 sitemap 里，站内几乎没有别页引用它，Google 判定它不重要，就不排队来抓。

我们在一个高竞争产业的内容站做过内链配平：配平前有 49 页只有 1 条入链，补到全站 116 页每页入链都 ≥ 4 之后，该站收录率达 153/173 页（约 88%）。做法一样走自动化——把「每页被引用次数」当成建置时的守门指标，输出前先算一遍，不足的页面自动从相关页补连结，而不是靠编辑记得互连。

结语：把这套检查写成脚本，挂进部署管线

整理一下查案顺序：URL 检查 API 看 lastCrawlTime → 全空就对齐 canonical / og:url / JSON-LD url / sitemap loc 四处 → 逐笔 loc 验 200（关掉转址跟随）→ 重送 sitemap → 还卡就查内链。每一步都是可程序化的检查，值得写成脚本挂进部署流程，每次上线自动跑，别靠上线后人工想起来。如果你的新站也卡在收录挂零，或想把这类检查自动化省下反复排查的时间，可以找我们聊聊——把 URL 检查 API 的实际回应拉出来看，通常很快就能定位是哪一层在打架。

新站上线这一段，我们做成了服务

canonical 与 sitemap 打架只是其中一种死法。新站不被索引的原因通常不只一个，要一条一条排除。

• 站台架构与技术 SEO：canonical、sitemap、robots、结构化资料一次对齐
• 索引监控：逐页查收录状态，没进去的找出原因再送一次
• 内容产出：有原创内容才有被索引的理由，这是最常被跳过的一步

四周交付，周周有产出。规格在 iGaming SEO 建站服务。