346 篇历史文章体检：内链、描述、死链与过时版本号的检修顺序

更新日期：2026-09-18

任何运营三年以上的技术博客都会欠下同一笔债：早期发布的文章当时是对的，但外部依赖变了、自己站内的结构也变了。这些文章不会被删除，它们继续被索引、继续带来搜索流量，也继续以看不见的方式拉低整站质量。

本文不讨论泛泛的"内容要更新"，而是记录一次真实的存量检修：站点有 384 篇已发布文章，其中 346 篇来自一次 WordPress 全站导入。检修前先做了一次量化体检，结果比预期严重——345 篇导入文章里没有任何站内链接，328 篇没有填写描述，外链中占比最高的两个自有域名已经无法访问。这些问题的共同点是：它们都不会让页面报错，因此从外部完全看不出来，只能靠主动体检发现。

站内此前有 WordPress 7.1 生产升级指南 处理过"程序版本升级"，有 CDN 缓存命中率从 60% 到 95% 处理过"访问性能"。本文处理第三个维度：内容资产本身的衰减。如果你也做过站点的技术栈迁移（WordPress 转自研、换域名、换 CDN），站内 零停机 DNS 迁移实战 讲的是迁移当天怎么做，本文讲的是迁移之后那一年该怎么收尾。

适用范围：内容型站点，文章数量在数百篇量级，经历过至少一次平台迁移或多年沉淀，具备数据库读取权限（或能导出内容用于离线分析），并且可以写脚本做批量处理。不适用于：文章总数不足百篇且都在近两年内发布（人工过一遍更快）；也不适用于内容不允许被修改的合规存档类站点。

先看结论

1. 先量化再动手。 体检的成本远低于盲目改写。本文的体检脚本只用了几个聚合查询，就定位出四个优先级完全不同的问题。
2. 修复顺序按投入产出比排：内链 > 描述 > 死链 > 过时版本号。 内链是唯一能立刻改变爬虫与读者行为的一项，而过时版本号的改写成本最高、收益最慢。
3. 内链缺失是最严重也最容易被忽略的问题。 本文抽样站点的 346 篇导入文章里 345 篇零站内链接——它们实际上是孤岛，既无法把权重传递给新文章，也无法把读者留在站内。
4. 描述（description）缺失直接影响搜索结果点击率。 缺失时搜索引擎会自行截取正文片段，通常不如人工撰写准确。本文站点 346 篇中 328 篇缺失。
5. 自有域名的外链会随业务下线而失效。 这是最隐蔽的一类死链：迁移后老论坛、老图床域名停用，但正文里几百条链接还写着它。迁移前必须统计自有域名的外链引用量。
6. http:// 外链在 HTTPS 站点上属于混合内容，除了被浏览器拦载，也会削弱迁移后本应统一的信号。
7. 标签体系会随规模失控。 本文站点 747 个标签里有 549 个只被使用过一次，这类标签不构成聚合页，只制造重复的薄弱页面。
8. 检修必须可复现。 一次性脚本修完，三个月后新导入的内容会重新引入同样的问题。要把检查项固化进导入流程或 CI。

第一步：先体检，别先动手

体检数据全部可以从数据库或内容导出文件中得到，不需要爬虫。核心是回答四个问题：内容厚度如何分布、元数据缺失多少、内链密度如何、外链有多少已失效。

# 思路示意：用聚合查询得到分布，而不是逐篇人工浏览
# 1) 正文字符数分布（分位数比平均值更能暴露"薄内容"）
#    min / p50 / p90 / max
# 2) 缺失字段计数：description 为空、正文过短
# 3) 内链密度：统计每篇正文中指向站内文章的链接数
# 4) 外链主机分布：按域名聚合，找出被引用最多的域名

本文站点的体检结果如下，可以直接作为你自查时的对照基线：

这张表里最值得注意的不是"导入文章更短"——这是迁移的常见结果——而是内链中位数为 0。新写的 38 篇中位数是 2，说明写作规范本身是对的；差距完全来自导入批次没有做链接补全。

外链的体检需要多做一步：按域名聚合后，对引用量最高的域名逐个实测可用性。

# 按域名聚合外链，取出引用量最高的若干个
# 然后对每个域名抽样实测（不要一次性全量请求，容易触发风控）
for u in \
  "https://old-forum.your-site.test/some-post/" \
  "https://old-images.your-site.test/2018/pic.jpg" \
  "https://legacy-cdn.example.net/img/a.jpg" ; do
  printf '%-60s ' "$u"
  curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' -m 20 -L "$u"
done

本文站点实测发现的三个典型失效形态，值得对照检查你自己的站点：

• 自有论坛域名已下线：正文中引用 200 次，实测无法连接。这类链接同时伤害读者体验和信任度。
• 自有图床域名超时：引用 30 次，请求 20 秒仍无响应。比直接 404 更糟——它会让页面加载被拖住。
• 第三方老图床 HTTPS 不可用、HTTP 可用：引用量最大的图片主机只能走明文 HTTP 访问。

一份可直接运行的体检清单

把上面的体检指标落成 SQL，你就能在自己的库上跑出同一组数字。下面这些查询只读、不改数据，可以安全地在生产库上执行。字段名按常见的内容表结构给出，实际使用时替换成你自己的列名即可。

-- 1) 内容厚度分布：用分位数而不是平均值，平均值会被少数长文拉高
SELECT
  COUNT(*)                                        AS total,
  MIN(length(content))                            AS min_len,
  percentile_disc(0.5) WITHIN GROUP (ORDER BY length(content)) AS p50_len,
  percentile_disc(0.9) WITHIN GROUP (ORDER BY length(content)) AS p90_len,
  MAX(length(content))                            AS max_len
FROM posts
WHERE status = 'published';

-- 2) 元数据缺失：描述为空、正文过短
SELECT
  COUNT(*) FILTER (WHERE description IS NULL OR description = '') AS missing_description,
  COUNT(*) FILTER (WHERE length(content) < 1500)                  AS thin_content
FROM posts
WHERE status = 'published';

-- 3) 完全没有站内链接的文章（把 /blogs/ 换成你自己的路径前缀）
SELECT COUNT(*) AS no_internal_link
FROM posts
WHERE status = 'published'
  AND content NOT LIKE '%](/blogs/%';

-- 4) 含明文 HTTP 链接的文章数
SELECT COUNT(*) AS has_http_link
FROM posts
WHERE status = 'published'
  AND content ~ '\]\(http://';

-- 5) 只被使用一次的标签：这些标签页是典型的薄内容
SELECT COUNT(*) AS single_use_tags
FROM (
  SELECT tag_id FROM post_tags GROUP BY tag_id HAVING COUNT(*) = 1
) t;

跑完之后把结果和本文的对照表比一下。如果你的站点同样存在大面积缺失描述，不必惊慌——这是迁移站点的常态，重要的是先知道规模，再决定投多少精力。

外链失效的检查无法只靠 SQL 完成，需要把域名提取出来后逐个实测。提取可以用 SQL，实测建议抽样：

-- 提取外链域名并统计引用次数，取前 20 个做实测
SELECT
  substring(url FROM 'https?://([^/]+)') AS host,
  COUNT(*) AS refs
FROM (
  SELECT unnest(regexp_matches(content, 'https?://[^\s)"\]]+', 'g')) AS url
  FROM posts WHERE status = 'published'
) links
GROUP BY host
ORDER BY refs DESC
LIMIT 20;

拿到这张表后，优先实测其中属于你自己的域名。第三方域名的失效你无法控制，但自有域名的失效是自己迁移决策的直接后果，也是最容易被读者注意到的破绽。

第二步：判断每篇文章该"修、并、还是退"

不是所有历史文章都值得投入。先做分类，再分配精力。判断标准要写下来，避免每次靠感觉：

这里要强调第三项的一个常见误区：下线的正确方式是让它从索引中消失，而不是屏蔽抓取。 按 Google 的 robots.txt 规范，Disallow 只阻止抓取，被屏蔽的 URL 仍可能被索引（只是没有摘要）——因为爬虫没抓取页面，也就读不到页面里的 noindex 标签。所以：

• 想让它彻底不出现 → 返回 404/410，或允许抓取并输出 noindex；
• 只想省抓取预算 → 用 Disallow。

对历史内容做去索引化时，用错这两个会产生"搜得到标题、点进去没内容"的结果，对站点信任度的伤害比留着原文更大。

第三步：补内链（投入产出比最高）

内链是这次检修里唯一能同时改善三件事的动作：爬虫发现路径、权重分配、读者停留。345 篇零内链的文章等于 345 个孤岛。

批量补内链不能靠随机插入。可行的方法是基于关键词与标题的匹配生成候选，再人工确认：

# 思路示意：为每篇待补链文章，找出标题/标签高度相关的其他文章
# 1) 从数据库导出 (slug, title, tags) 三列
# 2) 对每篇文章，用其标题与标签中的技术词去匹配其他文章的标题
# 3) 输出候选对，人工确认后再写入
#
# 关键约束：必须人工确认。自动插入的相关性噪声会直接损害阅读体验，
# 而内链的价值恰恰来自"读者真的会点"。

补链时遵循三条实践规则：

1. 锚文本用目标文章的真实主题，不要用"点击这里"或裸 URL。
2. 每篇新增 2–4 条即可，不要为了指标堆砌。本文新文章的站内链接中位数是 2，这个量级足够。
3. 优先链接到"支柱内容"：把老文章链向新写的深度文章，比老文章之间互链更有价值——新文章才是你希望被索引和引用的对象。

第四步：补 description

描述缺失的直接影响是搜索结果摘要不可控。搜索引擎会自行截取，通常截在句子中间，且可能包含导航文字。

批量补全的正确做法是基于正文生成草稿，再人工校对，而不是让模型直接写入生产库：

# 需要补描述的篇数
# 本文站点：346 篇中 328 篇缺失
# 补全流程建议：
#   1) 导出缺失描述的 (slug, title, 正文前若干字符)
#   2) 生成 60–180 字符的描述草稿
#   3) 人工抽查（重点看是否包含具体信息，而不是"本文介绍了……"式空话）
#   4) 以 dry-run 方式先跑一遍，确认将要更新的行数
#   5) 确认后再写入

关键约束：批量更新必须默认 dry-run。 这是所有内容运维脚本的通用要求——先打印将要修改的行数与样例，加显式参数才真正写入。本文涉及的站内内容脚本都遵循这一约定。

描述的质量判据很简单：它应该回答"读完能获得什么具体结论"，而不是"这篇文章讲了什么主题"。 前者如"对比就地升级与逻辑复制两条路线，给出停机窗口与回滚方案"，后者如"本文介绍了数据库升级的相关内容"。

第五步：修死链与混合内容

按失效形态分别处理，不要一刀切删除：

• 自有域名已下线：优先找回资源。若图片还在备份或对象存储里，迁移到当前在用的域名；确实找不到的，删除该图并补一句文字说明，而不是留一个坏图。
• 自有域名超时：先确认是否只是 DNS 或证书问题。超时的图床往往资源还在，修好解析比删图便宜得多。
• 第三方 HTTP 图床：能换 HTTPS 地址就换；只能走 HTTP 的，考虑下载后转存到自有存储。把关键图片放在自己控制不到的第三方主机上，本身就是这次检修暴露出的架构问题。

图片引用的修复要特别注意区分 Markdown 语法与 HTML 语法：

# 统计两种图片写法的数量，它们的替换逻辑不同
# Markdown 图片：  ![alt](url)
# HTML 图片：      <img src="url">
#
# 本文站点：Markdown 图片 1126 处，HTML 图片 5 处，
# 含图片的文章 192 篇。以 Markdown 为主，替换可按 markdown 语法处理。

HTML 图片数量很少时不要写复杂解析器，单独处理即可。反过来，如果两种写法混杂且量都很大，应该先统一语法再批量替换，否则正则会互相干扰。

第六步：清理标签体系

标签失控的表现是数量膨胀与语义重复。本文站点的体检结果：

三个问题依次是：一次性标签不构成有效聚合页（只有一篇文章的标签页是典型的薄内容）；中英文标签混用导致同一主题分裂成两个聚合页；大小写不统一（如 WordPress 与 Wordpress 并存）同样造成分裂。

处理顺序：

1. 先合并同义标签（大小写、单复数、中英对照），这一步纯收益、无争议；
2. 再把使用次数低于阈值的标签归并到上位标签，阈值建议 3–5；
3. 删除从未使用的标签；
4. 把合并规则写进导入流程的映射表，避免下次导入重新产生。

标签聚合页是否该被索引，取决于你是否能给它提供足够的独特性内容。只有一两篇文章的标签页，建议不要索引。

第七步：过时版本号的正确改法

这是最容易做错的一步。历史文章里的版本号往往是当时事实的准确记录，直接改成最新版本会让文章的叙述失真（例如"在 CentOS 7 上实测……"改成 CentOS 8 就变成虚构）。

正确做法是区分三种情况：

本文站点的体检数据显示这类痕迹分布如下（按篇统计）：涉及 PHP 7.x 的 38 篇、PHP 5.x 的 23 篇、http:// 链接的 95 篇、Ubuntu 1x 的 27 篇、CentOS 6/7 的 17 篇、MySQL 5.x 的 12 篇。

值得注意的是 PHP 这条线：站内 28 篇 PHP 相关文章最新一篇发布于 2020 年，全部围绕 PHP 7.x，而 PHP 8.x 的内容此前完全缺失。这正是"保留旧文 + 另写新文 + 双向互链"策略的典型场景，而不是把旧文里的 7 改成 8。

第八步：把检查固化，避免重复欠债

一次性修复的收益会随时间衰减，因为新导入的内容会重新引入同样的问题。要固化的是检查项，而不是修复脚本：

• 导入流程默认校验：正文字符数下限、是否含站内链接、是否含 http:// 链接
• 导入时自动补 description 草稿，进人工复核队列
• 外链主机白名单：出现未登记域名时告警，防止再次指向已下线的自有域名
• 标签映射表随导入流程维护，新标签需人工确认
• 每月跑一次体检脚本，把本文的表格作为趋势记录，观察是否恶化
• 迁移或下线任何自有域名之前，先统计该域名在历史正文中的引用量

最后一条尤其重要。本文站点的两个失效自有域名，一个被引用 200 次、一个被引用 30 次——如果在下线前统计过引用量，这些链接本可以在下线时一并处理。

第八步：外链与内链之外，还要看抓取侧

内容侧的检修做完，还要回到搜索引擎看到的结果上验证。有两个容易脱节的地方值得单独检查。

一是规范化与重复内容。 历史文章常见同一主题存在多篇近似内容，或者同一篇文章因参数、语言前缀、斜杠差异产生多个可访问地址。这类问题不会报错，但会让权重分散。检查方式是确认每篇文章都有明确的规范地址，并且该地址返回 200：

# 抽查页面的 canonical 是否指向自身，且该地址可访问
curl -s "https://your-site.test/some-legacy-post" \
  | grep -oE '<link[^>]*rel="canonical"[^>]*>' | head -2

二是站点地图与实际内容的偏差。 站点地图应只包含希望被收录、且确实返回 200 的地址。历史检修中经常会发现站点地图里仍列着已经合并或下线的内容，这会浪费抓取预算并制造"已提交但未收录"的噪音：

# 统计站点地图条目数，与数据库中已发布文章数对照
curl -s https://your-site.test/sitemap.xml | grep -c '<loc>'

本次站点的站点地图包含 5229 条地址，而数据库中的已发布文章只有 384 篇——差额来自分类、标签、产品等聚合页。这个比例本身不一定是问题，但必须是你有意为之的结果，而不是历史遗留的自动生成产物。标签聚合页尤其需要检查：如果一个标签只有一篇文章，它的聚合页几乎没有独立价值。

第九步：把体检结果变成趋势记录

单次体检的结论会过期。真正有价值的是把同一组指标按周期记录下来，观察趋势。建议每月固定跑一次，记录以下数字：

这张表的作用不是好看，而是让"欠债"可见。存量治理最怕的不是工作量大，而是看不见进度——当无描述篇数从 328 降到 0 的过程中，你需要一个数字来证明方向是对的。

官方资料与继续阅读

• Google 搜索：robots.txt 规范（Disallow 与索引的关系）
• Google 搜索：阻止索引的正确方式
• Google 搜索：链接与内链最佳实践
• Google 搜索：内容质量与薄内容判定
• MDN：混合内容（Mixed Content）的浏览器处理规则
• W3C：重定向与 410 语义说明

站内相关文章：

• WordPress 7.1 生产升级指南：新功能、兼容性检查与安全回滚
• 零停机 DNS 迁移实战：TTL 策略、DNSSEC 与邮件记录切换检查表
• CDN 缓存命中率从 60% 到 95%：缓存规则、Cache Key 与回源治理
• MDX 里的一行 HTML 属性导致文章返回 500：589 条 5xx 的排查记录
• Google AI Search 与 GEO/AEO 实战