URL 出现在 sitemap.xml 里，但站内没有任何页面链向它——这就是”孤儿页”。Google 通过 sitemap 知道它存在，但孤儿页拿不到任何内链给的”重要性投票”，于是被压在抓取队列最底部，通常会在 Discovered - currently not indexed 卡上几周甚至几个月。
最快的修法： 从已经被收录、且话题相关的页面，给这个孤儿页补至少 2 条正文内链，然后在 Search Console 里 Request indexing 一次。下面所有内容背后只有一个心智模型:sitemap 是发现信号,内链才是重要性信号。 这两者不能互相替代。
症状
- URL 在
sitemap.xml里,但一直卡在Discovered - currently not indexed - 内链审计显示这个页 0 条入站内链
- 这个页可能有外部反链也可能没有——不管有没有,收录都很慢
- 在 Google 搜
site:yourdomain.com/the-url什么都搜不到
你属于哪一种”未收录”?
Search Console 里这两种状态看着像,但修法完全相反。先用 URL Inspection 查清楚:
| 状态 | 含义 | 根因 | 修法方向 |
|---|---|---|---|
Discovered - currently not indexed | Google 发现了这个 URL,但还没抓取 | 抓取优先级太低——通常是内链弱或没有 | 补内链、降低点击深度(本文) |
Crawled - currently not indexed | Google 抓过了,但选择不收录 | 内容薄 / 重复 / 质量低 | 改页面内容本身 |
孤儿页几乎都落在第一行。如果你看到的是 Crawled - currently not indexed,光补内链没用——问题出在页面内容上。
常见原因
1. 页面建好后,没被任何列表、分类或相关文章组件链过
新写的文章没被加进首页”最新”区,没出现在任何分类列表,也不在其他文章的”相关阅读”模块里。
如何确认(在仓库根目录运行):
rg -l 'href="/your-orphan-url/?"' src/ | wc -l
# 0 = 孤儿2. 只有直接输入 URL 才能到达
从首页出发,能不能在 3 次点击以内到达这个页?不能的话,就当它是孤儿。截至 2026 年 6 月,距首页 3 次点击以内的页面会得到优先抓取、更快收录;更深的页面只能去抢剩下的抓取预算。
3. 只被很旧、低权重的 URL 链接
内链是有,但链它的那些来源页本身就是 0 流量、低权重的孤儿,传过去的权重几乎为 0。
如何确认: 用 Screaming Frog 或 Ahrefs 看那些来源页的点击深度和页面权重。
4. 只通过 nofollow 或 JS 渲染的组件被链
内链存在,但全是 rel="nofollow",或者只有客户端 React useEffect 跑完后才渲染出来。nofollow 链接 Google 可能不计入抓取发现,JS 注入的链接也比原始 HTML 里的链接抓取得更不可靠。把真正的 <a href> 标签放进服务端渲染的 HTML 里。
5. URL 路径改了,但旧内链没更新
页面最早叫 /blog/old-slug,后来挪到了 /articles/new-slug。301 redirect 设好了,但所有内链还指向旧 URL,新 URL 从没收到一条直链,于是一直是孤儿。链向被重定向 URL 的链接,是一个更弱、更间接的信号,远不如直接链向最终 URL。
6. 分页 / Tag / 归档结构把深层文章孤立掉
/blog/page/15 里的文章只能靠翻归档才能到。几周后新文章把它顶到爬虫懒得去翻的位置,它就成了事实上的孤儿。
最短修复路径
Step 1:找出每一个孤儿页
可靠的做法:爬整站抓出所有内链,再和 sitemap 对比。差集(在 sitemap 里、但爬不到的)就是你的孤儿清单。
# 用 wget 镜像爬整站
wget --spider --recursive --no-verbose --no-directories \
--output-file=crawl.log https://yourdomain.com/
# 提取爬到的所有 URL
grep "http" crawl.log | awk '{print $3}' | sort -u > crawled.txt
# 提取 sitemap 里的 URL
curl -s https://yourdomain.com/sitemap.xml \
| grep -oE '<loc>[^<]+</loc>' | sed 's/<\/\?loc>//g' > sitemap.txt
# 差集 = 只在 sitemap 里出现的 URL = 孤儿
sort sitemap.txt crawled.txt crawled.txt | uniq -u > orphans.txt更全面的工具:Screaming Frog(免费版可爬 500 URL,它的 Sitemaps -> Orphan URLs 报告会直接拿爬取结果对比 sitemap)或 Sitebulb(报告更直观)。在 Search Console 里,Pages(Indexing)报告中 Discovered - currently not indexed 下列出的 URL,本身就是一份很好的孤儿候选名单。
Step 2:逐条判断这个孤儿该不该存在
打开 orphans.txt,逐条分流:
- 该存在的(真有价值的页面):补内链(见 Step 3)
- 不该存在的(测试页、重复、过期):从 sitemap 里删掉,并返回
410 Gone或加noindex。别把死 URL 留在 sitemap 里,那是在白白浪费抓取预算。
Step 3:从相关的、已收录的页面补 2 条以上正文内链
对每个值得保留的孤儿页:
# 找出话题最相关的 3-5 篇老文
rg -l "相关关键词" src/ | head -5在这几篇里,各加一条写在句子里的正文内链(放在正文里,不要塞进通用页脚),锚文本里包含目标 query。目标是至少 2 个不同的来源页,最好 3-5 个,并且优先选那些本身已被收录、有流量的来源页。来自相关、已收录页面的正文内链,传递的价值远高于页脚或侧边栏链接。
Step 4:把孤儿页变成一个自动、结构性的问题
一次性补链会反弹,要从源头堵住缺口。对 Astro 内容站,在每篇文章末尾自动渲染一个相关阅读块:
---
import { getCollection } from 'astro:content';
const allPosts = await getCollection('posts');
const related = allPosts
.filter(p => p.data.tags?.some(t => Astro.props.tags.includes(t)))
.filter(p => p.slug !== Astro.props.slug)
.slice(0, 5);
---
<aside>
<h2>相关阅读</h2>
<ul>
{related.map(p => <li><a href={`/articles/${p.slug}/`}>{p.data.title}</a></li>)}
</ul>
</aside>同时确保有一个枢纽页(首页、/articles/ 索引页,或各分类索引页)链向每一篇文章,而不是只列最新 5 篇。一个完整、可抓取的索引页,是防孤儿最有效的单项措施。
Step 5:重交 sitemap,触发重新发现
老的 https://www.google.com/ping?sitemap=... 接口已在 2023 年 6 月废弃,现在返回 404——别再用了。改在 Search Console 里重交:
- Search Console -> Sitemaps -> 先删掉 sitemap,再重新添加并提交一次。
- 确认 sitemap 里这些更新过的 URL 带有准确的
<lastmod>日期。自从 ping 接口下线后,Google 更依赖<lastmod>来判断该重抓什么,所以它必须反映真实的最后修改时间(不要每次构建都写成”现在”)。 - 挑 1-2 个修过的孤儿页,用 URL Inspection -> Request indexing 推一下。
如果你还想让 Bing、Yandex 等支持 IndexNow 的引擎立刻收到变更,可以 ping IndexNow。注意:截至 2026 年 6 月,Google 不支持 IndexNow,它仍然依赖 sitemap、内链和 Search Console——所以 IndexNow 帮的是 Bing,不是 Google 收录。
Step 6:等 2-4 周,盯对的信号
- 约 2 周: Search Console 的 Crawl Stats(Settings -> Crawl stats)里,这些 URL 开始出现新的抓取记录。
- 约 4 周: URL Inspection 状态从
Discovered - currently not indexed翻成URL is on Google。
如果 4 周后某个 URL 还卡在 Discovered,说明内链信号还是太弱——从更权威、更高流量的页面再补链,并降低它距首页的点击深度。
如何确认已修好
- 重跑 Step 1 的孤儿差集:这个 URL 不再出现在
orphans.txt里。 - URL Inspection 在 “Discovery” 下显示至少有一个 referring page,状态是
URL is on Google。 - 在 Google 搜
site:yourdomain.com/the-url,终于能搜到这个页。
提醒:有几个孤儿是正常的
大站点在改版或调整分类时,总会冒出几个孤儿页。这很正常——放到下一次月度审计里收掉就行,别把每一个都当成紧急事故。
容易误判的情况
- 反复把孤儿页塞进 sitemap: Google 早就知道它存在,sitemap 从来不是缺的那一环。
- 把 “Request indexing” 当解药: 它有配额(截至 2026 年 6 月,每个 property 大约每天 10-12 个 URL,超了按钮会灰掉 24 小时),而且修不了底层的内链信号。
- 以为加 1 条内链就够: 单条内链很难把孤儿顶出队列;用 2 条以上、来自不同已收录页面的链接。
- 以为 tag 页能解决: 只有当 tag 页本身被收录、内链完整、不薄时才有用。
- 混淆这两种状态:
Crawled - currently not indexed是内容质量问题,不是链接问题(见上面的表)。
预防建议
- 发文前,先从至少 2 篇相关老文补内链,并把这个页加进首页或某个分类索引页。
- “相关文章”组件要触达更深的存档,不只是最新 5 篇。
- 每月做一次轻量孤儿审计(用 Screaming Frog,或上面那段 wget 差集)——10 分钟的活儿。
- 改 URL 结构时,同步更新每一条内链,不要只靠 301。
- sitemap 里的
lastmod要写真实值,让重抓按真实变更来调度。
FAQ
Q:孤儿页到底需要多少条内链? A:至少 2 条来自不同、且已被收录页面的正文内链,最好 3-5 条。来源页的质量(已收录、相关、有流量)比纯数量更重要。
Q:tag 页或分类页能解决孤儿文章吗? A:只有当这些 tag / 分类页本身可索引、内链完整、不薄时才行。一个又薄又 noindex 的 tag 页几乎传不出任何权重。
Q:在 sitemap 里加 <priority> 有帮助吗?
A:没有。Google 忽略 <priority> 和 <changefreq>。只有 <loc> 和 <lastmod> 有用,而 lastmod 也只有在准确时才算数。
Q:用 404 删掉孤儿页,会伤站点权威吗?
A:删掉真正薄的页面是正向的——少了一个拖累抓取预算的低价值 URL。如果你确定一个页面要永久下线,用 410 Gone 比 404 更好,它是更明确的”别再来”信号。
Q:我已经 Request indexing 了,为什么还是没收录? A:“Request indexing” 只是把抓取重新排队,它压不过重要性信号。如果内链还是弱,Google 重抓后还会把它重新压回去。先修内链,再 Request indexing。