页面删除、合并或改 slug 之后，指向它的站内链接必须当场一起改掉，不能指望 301 把点击兜住。重定向是留给外链、书签和广告链接的，站内链接要直接指到最终的 URL。这条规则如果不写进每一次内容变更的流程里，站内 404 和断链就会一直堆下去，而且大部分你根本看不见。
我原来也把内链检查放在一年一次的大盘点里。后来发现这个频率不成立——断链不是慢慢长出来的，是每次动内容的时候当场长出来的。
你看这个顺序。你把两篇同主题的文章合并成一篇，旧的那篇 301 指向新的，表面上很干净。过了几天打开 Search Console 的「页面」报告，「未找到 (404)」那一栏多出几条，URL 不是被你合并掉的那篇，而是另外三篇文章里指向它的链接。Google 重新抓取了那三篇页面，发现链接目标已经不在了，于是报成 404。
这就是内链最别扭的地方：你改的是一个页面，坏掉的是别的页面。
301 会把问题藏起来
很多人觉得反正有重定向兜着，内链晚点改也没事。我不同意，理由有三个，第三个最要命。
第一个是多一跳。站内链接还要绕一次 301，等于每次点击都多一次往返。桌面端你感觉不到，移动端弱网下能看出那一下空白。链路长了更糟，A 指向 B、B 又 301 到 C 的时候，用户得等两次跳转。
第二个是锚文本和落点脱节。合并之后旧链接的锚文本往往还是「某某 App 评测」，可新页面是「记账 App 推荐」，用户点进去发现说的不是一回事，会退出来。
第三个是重定向会让问题在报表里消失。指向 301 的内链，在 GSC 里记成「网页会自动重定向」，不记成 404。也就是说它永远不会出现在 404 报告里，你就永远发现不了它。它安安静静地堆着，直到某天你清理重定向规则，这些内链一次性全断。
四种变更，各自要处理什么
合并。 旧 URL 的所有站内入链改成直指合并后的新 URL，锚文本顺手对齐新页面。301 保留，但那是给外链和书签用的。旧 URL 从 sitemap 里拿掉。
下架。 别急着删链接，先问一句：哪个还活着的页面跟它最近？把旧链接重指到那个页面，读者的路径就还连得上。实在没有相近的，就指到它的上级分类页，或者干脆把这条链接从正文里删掉——删一条链接比留一个死链好。最不该做的是让 404 页面自动跳首页，那是软 404，用户以为自己走错了地方，搜索引擎也会对整站多一层怀疑。
改 slug。 一篇文章发出去之后被别的文章引用过几次，标题改一次，那几条引用就全死了。改完 slug 要拿新 slug 反查一遍，把老路径的引用全部换掉。
目录搬家、分类重构。 这类漏得最多，因为它一次影响一整片。做完要按目录逐个过一遍入链，而不是只给旧目录配一条规则就完事。
找出「谁指向它」，这一步跳不过去
Search Console 的「页面」报告会告诉你哪些 URL 404 了，但它不会告诉你站内是谁在链过去。链接报告里的「内部链接」只列出被链最多的那批页面，长尾基本看不到。
我的做法是拿旧 URL 的路径片段——不是整个 URL，是 slug 那一段——回到 CMS 的内容列表里搜正文，一条一条看。搜出来的是候选，命中率不低，但确实要自己过一遍。站小的时候十分钟能扫完；站大了就得排优先级：主导航、首页、分类页、专题页这些骨架上的链接必须先改，正文长尾可以放到季度复查里一起处理。
这里有个反查的规律值得记：如果一次 404 报告里冒出来的 URL 全都落在同一个目录下，基本可以断定是某次目录重构漏了一整片，而不是零散的内容修改。按目录去查，比按 URL 一条条查快得多。
有些链接就该留在重定向里
不是所有链接都要重指。外链、书签、邮件和广告链接、二维码、已经提交过的旧 sitemap URL，这些你改不了，留着 301 就是它们的正确归宿。
还有一种情况：链接来自你不再维护的模板或者归档页面。这种我一般不动，留着重定向，但在规则上加一行注释，写明它为什么还在。
顺带说一个容易忽略的：重定向链要拉直。A 转到 B、B 又转到 C 的时候，把 A 直接改成指向 C，同时把站内链接也指到 C。链子越短越好。
季度复查是补漏，不是主力
为什么是季度而不是每月？因为 GSC 的 404 报告本身就是滞后的——只有 Google 重新抓取了那个带链接的页面，它才会报出来，而抓取周期不短。你今天改完，报告里不会今天就清零。按季度扫一遍，是给遗漏兜底，不是指望它发现问题。
真正的主力是每次变更时的那张清单。我自己的清单只有三步：
- 这次动到的旧 URL 是什么；
- 在 CMS 里搜这个 URL 的路径片段，列出所有指向它的页面；
- 逐条决定——重指到哪个存活页面并改锚文本，还是删除这条链接。
三步走完再点发布。
说清楚取舍
站大到几万个 URL 的时候，逐条手改不现实。我自己的分档是这样：结构里骨架的部分必须直连最终 URL，这条不打折；正文长尾的链接允许留在重定向后面，但要保证重定向规则不会在某次改版里被顺手清掉。
这个取舍不好看，但它比「等有空了再统一处理」强。后者我等过，结果是那个冬天我花了两个晚上在 GSC 里一条条手动核对 404，而且到现在我也不确定当时清干净了没有。
把内链当成发布流程里的一个勾选项，它就不会变成一件待办。
