内链审计显示 80 页 0 入链。它们存在——sitemap 里、磁盘上、技术上可达——但你站上没别的页面引用它们。用户只能输 URL 进。Google 看到这种当低重要性：站点自己都不链，凭什么让别人？
孤儿不只是「索引债」——是给 Google 的内容质量信号：不链自己内容的站缺话题结构。修法是每个孤儿二选一：整合（加入链 + 确认值得）或清除（410 / noindex）。下面：怎么找孤儿、按页决定、防新孤儿产生。
常见原因
按命中率从高到低：
1. “多发”思路没 cluster 策略
你两年来每月排 5 篇——编辑流程没问「现有哪些文章该 link 到这个？」每篇孤儿落地、积压。
如何判断：孤儿文章按批量发布日聚集——很多孤儿同一周发——就是发布管道造的。
2. 老 syndicate 或客座作者文章没整合进来
老同步协议或客座作者 import。「加了」但没整合——没人写已有内容到它们的内链。
如何判断：孤儿文章有不同作者或来自不匹配你现在发布的日期段——import 没整合。
3. 前任 / 前方向留下的页面
站点转向（从”通用 tech”到”AI 提效”）。旧的不相关话题文章还在但不够相关、现内容不会 link——它们靠话题转向把自己孤立。
如何判断：孤儿文章在你站不再覆盖的话题——「残余」内容。
4. 文章在已经缩水的分类里
你启动了一个分类发 5 篇、想扩没扩——分类页本身薄、入链少——分类里文章被垂死的父孤立。
如何判断：孤儿文章聚集在某分类——那分类页自己入链也低——枯枝。
5. URL 改名没更新内链
你把 getting-started-with-x 改成 x-quickstart。新 URL 存在，没东西链因为所有内链还指旧——301 redirect 对用户 work、但新页面在 Google 视角是孤儿。
如何判断：301 redirect URL 入链多，但最终目的地 URL 入链 0——内链要指 canonical 目的地。
6. tag 页 / 归档页 / 「仅分类」页
只通过 tag / 归档导航出现、正文从不链。tag 页能在正文链方面孤儿、尽管它们自动生成。
如何判断：tag / 归档页正文引用 0——靠自动 nav 存在但没东西刻意指。
最短修复路径
按收益从高到低。Step 1 探测，Step 2 按页决定。
Step 1：爬一遍找真孤儿
用 Screaming Frog / Sitebulb 或自写：
# scripts/find-orphans.mjs
import fs from "node:fs";
import path from "node:path";
import matter from "gray-matter";
// 1. 收集所有文章 URL
const articles = collectArticleUrls();
// 2. 收集文章正文里所有内链
const linkedTo = new Set();
for (const f of fs.readdirSync("src/content/articles/en/...")) {
const content = fs.readFileSync(f, "utf8");
const matches = content.matchAll(/\/en\/articles\/([^/\s)]+)\//g);
for (const m of matches) linkedTo.add(m[1]);
}
// 3. 入链为 0 = 孤儿
const orphans = articles.filter(a => !linkedTo.has(a.slug));
console.log("Orphans:", orphans.length);
console.log(orphans.map(o => o.slug).join("\n"));输出干净的孤儿列表。过滤掉刻意的 landing 页（付费广告目标等）——它们就是要做孤儿。
Step 2：每个孤儿决定整合 or 清除
| 孤儿类型 | 动作 |
|---|---|
| 近 6 月、对话题、质量过得去 | 整合：加 2-5 条内链 |
| 对话题但老 / 薄 | 先升级内容再整合 |
| 偏话题 / 前方向残余 | 410 或 noindex |
| 转向残余 | 话题完全弃了就 410 |
| tag / 归档页无正文引用 | nav-only 可接受，否则 noindex |
不要全整合——有些孤儿就该清。
Step 3：整合时每个孤儿加 2-5 条内链
每个要保留的孤儿：
1. 找 5-10 篇相关话题已有文章
2. 在其中 2-5 篇里加正文 link 到孤儿
3. 描述性 anchor（孤儿的标题或主题）
4. 确认 link 在正文里，不只是生成的 widget每孤儿 ~5 条来自不同源的入链——这轮后无孤儿。
Step 4：清除时刻意选 410 / noindex
- 410 Gone——页面不该存在（legacy、偏话题、重复）
- Google 去 index 比 404 快
- hosting 配 410 响应
- Astro：删文件 + firebase.json 加 410 条目
- noindex——想 URL 内部可达但搜不可见
- 页面加 `<meta name="robots" content="noindex">`
- 文件留，不让 Google 排
- 301 redirect——有明确后继文章
- 重定向到最近话题替代
- 不要全重定向到首页（被当成软 404）Step 5：「相关文章」widget 暴露孤儿
你 widget 多半 surface 高入链文章（网络效应）。调整算法加权低入链孤儿：
function relatedScore(current, candidate) {
return sharedTags(current, candidate) * 3
+ sameCategory(current, candidate) * 5
+ (candidate.inboundCount < 3 ? 4 : 0); // 孤儿加分
}孤儿在相关性高时占「related」widget 一个额外位——分布自然再平衡。
Step 6：每月重爬抓新孤儿
加日历提醒或 CI job：
# 每月重跑孤儿探测，输出到 dashboard
pnpm audit:orphans > reports/orphans-$(date +%Y-%m).txt数在涨——发布工作流没在整合新文章——加一步整合。
预防建议
- 编辑管道：每篇新文章发前要”找 3 篇已有文章 link 到它”
- 每月孤儿审计，60 天以上孤儿要么整合要么清
- related widget 给低入链页加分，时间上分散
- 话题转向时刻意 deindex 残余、不要留作孤儿
- URL 改名时搜并更新所有内部引用，不要靠 301 掩盖
- 280 篇好连接的胜过 500 篇里 80 个孤立