SEO 内容更新与文章合并实战：用 Python 识别内容衰退、关键词冲突与重复页面

很多站点在文章数量增加后都会遇到同一个问题：旧文章还在，但内容已经过时；新文章又不断覆盖相同的搜索意图。此时直接批量删除，或者只把发布日期改成今天，并不能解决收录、排名和用户体验问题。更稳妥的做法是先建立内容台账，再判断每个 URL 应该保留、更新、合并，还是下线。

本文给出一套可以落地的维护流程，并用 Python 生成“相似内容候选清单”。脚本只负责缩小人工检查范围，最终决定仍然要结合搜索意图、事实有效性、内链和业务价值来做。

一、先明确四种处理结果

同一主题的文章不一定要合成一篇。先为每个 URL 选择处理结果，后续的重定向、canonical 和内链才不会互相矛盾。

“没有收录”不是单独的下线理由。新页面可能只是尚未抓取，旧页面也可能承担外部链接或品牌查询入口。先查抓取、收录、访问和引用情况，再做处理。

二、建立一份内容台账

不要只在后台按标题浏览。可以从数据库、Sitemap、访问日志和搜索平台导出一份表格，每行对应一个 URL，至少保留以下字段：

• URL、标题、文章 ID、分类和标签；
• 首次发布时间、最近一次实质更新时间、内容适用的版本或日期；
• 最近 28 天和 90 天的展现、点击、点击率、平均排名（没有数据时标记为“未知”）；
• 访问日志中的请求数、状态码、主要来源、爬虫请求和最近抓取时间；
• 站内入口数、正文内链数、外部引用（如果能够获得）；
• 当前 canonical、是否在 Sitemap/RSS 中、是否存在图片和图片 alt；
• 事实来源、作者、审核人、是否包含个人信息或过期代码；
• 可能重复的 URL、候选主 URL、处理建议和复核日期。

台账中的“未知”要和“为零”区分开。例如没有接入某个搜索平台时，展现量是未知，不应被当成零展现页面。这样可以避免因为数据缺失而误删内容。

三、怎样判断内容已经衰退

浏览量下降只是一个信号，不能单独证明文章失效。建议按下面的顺序排查：

1. 先排除技术原因。 检查是否返回 4xx/5xx、被 noindex、canonical 指向了别的页面、移动端加载失败，或者 Sitemap 和正文仍然引用了错误 URL。
2. 再看搜索需求。 比较近 28 天和 90 天的展现、点击、排名以及查询词。展现稳定但点击下降，可能是标题和摘要不再匹配；展现和排名一起下降，可能是内容过时、意图变化或竞争加剧。
3. 核对事实有效性。 API、框架版本、后台路径、价格、政策和截图都可能变化。无法验证的数字、测试结果和“最新”表述应当删除或改成有时间范围的描述。
4. 检查页面关系。 没有入口的孤立页面，即使内容不错，也很难被发现。反过来，多个页面都链接到同一个主题时，重复页面可能在争夺相同意图。
5. 区分季节性和真正衰退。 以周或月为周期的主题要和去年同期比较，短期下降不能直接触发合并或下线。

如果还没有足够数据，可以把这些条件写成“候选信号”，而不是直接得出“低质量”的结论。候选清单需要人工复核，尤其是涉及医疗、财务、法律、隐私和安全的内容。

四、用 Python 找出相似内容候选

下面的脚本读取一个 UTF-8 JSON 文件。文件是对象数组，每个对象至少包含 id、url、title 和 content 字段。脚本对中文使用二字片段，对英文和数字使用单词，分别计算标题重叠度、正文 Jaccard 相似度，并输出排序后的候选对。

将以下内容保存为 detect_similarity.py：

#!/usr/bin/env python3
"""Generate candidate pairs for a human content-merge review."""
from __future__ import annotations

import argparse
import csv
import json
import re
from pathlib import Path

CJK = re.compile(r"[\u4e00-\u9fff]")
LATIN = re.compile(r"[a-z0-9]+", re.I)


def tokens(text: str) -> set[str]:
    """Use CJK bigrams plus Latin/number words as a simple baseline."""
    text = (text or "").lower()
    han = "".join(CJK.findall(text))
    cjk_bigrams = {han[i : i + 2] for i in range(len(han) - 1)}
    words = set(LATIN.findall(text))
    return cjk_bigrams | words


def jaccard(left: set[str], right: set[str]) -> float:
    union = left | right
    return len(left & right) / len(union) if union else 0.0


def title_overlap(left: set[str], right: set[str]) -> float:
    # The smaller title being mostly covered is more useful than a raw count.
    return len(left & right) / min(len(left), len(right)) if left and right else 0.0


def main() -> None:
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("input", type=Path, help="JSON array of posts")
    parser.add_argument("--output", type=Path, default=Path("candidates.csv"))
    parser.add_argument("--threshold", type=float, default=0.42)
    args = parser.parse_args()

    posts = json.loads(args.input.read_text(encoding="utf-8"))
    prepared = []
    for post in posts:
        prepared.append(
            {
                "id": post.get("id", ""),
                "url": post.get("url", ""),
                "title": post.get("title", ""),
                "title_tokens": tokens(post.get("title", "")),
                "body_tokens": tokens(post.get("content", "")),
            }
        )

    rows = []
    for index, left in enumerate(prepared):
        for right in prepared[index + 1 :]:
            title_score = title_overlap(left["title_tokens"], right["title_tokens"])
            body_score = jaccard(left["body_tokens"], right["body_tokens"])
            score = 0.45 * title_score + 0.55 * body_score
            if score < args.threshold:
                continue
            rows.append(
                {
                    "score": f"{score:.3f}",
                    "title_overlap": f"{title_score:.3f}",
                    "body_jaccard": f"{body_score:.3f}",
                    "left_id": left["id"],
                    "left_url": left["url"],
                    "left_title": left["title"],
                    "right_id": right["id"],
                    "right_url": right["url"],
                    "right_title": right["title"],
                }
            )

    rows.sort(key=lambda row: float(row["score"]), reverse=True)
    fields = [
        "score",
        "title_overlap",
        "body_jaccard",
        "left_id",
        "left_url",
        "left_title",
        "right_id",
        "right_url",
        "right_title",
    ]
    with args.output.open("w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=fields)
        writer.writeheader()
        writer.writerows(rows)
    print(f"wrote {len(rows)} candidate pairs to {args.output}")


if __name__ == "__main__":
    main()

运行示例：

python detect_similarity.py posts.json --threshold 0.42 --output candidates.csv

阈值 0.42 只是一个起点，不是搜索引擎规则。中文二字片段会把相邻词拆开，同义词、代码片段和相同模板也会影响分数。文章数量较大时，可以先按语言、分类或年份分组，再做两两比较。生产环境还可以加入标题中的主实体、文章长度差、共同标签和搜索查询词，但不要把脚本输出直接接到删除接口上。

让候选清单变成可解释的决定

拿到 candidates.csv 后，可以给每对页面建立一张人工复核卡。卡片至少回答：两个页面分别服务谁？读者进入页面后要完成什么任务？哪一篇有更完整的事实、示例和外部引用？哪一篇拥有稳定的入口或转化路径？如果把内容合并，是否能用一个主 URL 清楚回答所有问题？

例如，一篇文章讲“Django 页面为什么没有被收录”，另一篇讲“Django 发布前如何检查 canonical、Sitemap 和状态码”。它们都会出现“Django”和“收录”，但前者是故障排查，后者是上线检查，搜索意图并不相同。此时更适合互相链接，并在首段明确差异，而不是因为相似度超过阈值就合并。相反，如果两篇文章都在逐步解释同一个错误、使用同一组截图，而且用户看完其中一篇还需要打开另一篇才能得到答案，就应该考虑选择一个主页面。

可以用四个维度帮助排序，但不要把分数当成自动决策：搜索意图重合度、事实过期风险、页面价值（入口、链接、转化）和维护成本。意图重合高且事实风险高的页面优先人工处理；意图不同但都具有价值的页面优先补充摘要、目录和内链；没有入口且没有可验证内容的页面才进入下线候选。每一项都写下证据，例如查询词截图、日志时间范围、版本文档链接或编辑记录，这样另一个人能够复核你的结论。

专门排查孤立页面

孤立页面是没有任何可发现的站内入口的 URL。它可能仍出现在 Sitemap，却不在导航、分类、专题、相关文章或正文链接中。检查时先从 Sitemap 列出全部 URL，再统计每个 URL 被站内页面引用的次数；只在 Sitemap 中出现、引用次数为零的页面进入人工清单。还要排除登录后页面、分页末页和有意隐藏的落地页，不能把所有零入链页面都视为错误。

修复孤立页面时，优先添加一个语义准确的上游入口：分类页适合稳定的主题，专题页适合连续教程，正文内链适合解释某个具体概念。锚文本应该描述目标页面真正解决的问题，不能为了增加关键词而重复堆叠。补入口后在 7 天复核抓取日志和 30 天复核搜索表现；如果页面本身仍无明确读者和事实依据，再考虑重写或下线。

五、识别关键词蚕食，而不是只看标题相似

两篇文章包含相同关键词，不代表一定冲突。判断是否蚕食，要比较四件事：

• 搜索意图： 用户是在找教程、排错清单、定义解释，还是在找产品或服务？
• 主问题： 两个页面能否用同一句话回答？如果一个讲原理、一个讲实操，可能应该保留两个入口。
• 目标读者： 初学者、开发者、管理员和决策者的需求不同，内容深度也不同。
• 结果页形态： 查看同一查询的结果页，确认搜索引擎展示的是教程、文档、列表还是交易页面。

确认冲突后，先选一个主 URL。主 URL 应该具备更完整的证据、更稳定的外部链接、更清晰的意图和更好的维护能力，而不是简单选择 ID 较大的文章。另一篇文章中的独有案例、代码和问题边界要迁移到主页面，并在编辑记录中写明来源和迁移日期。

六、安全合并一组文章

合并前先建立映射表，例如 旧 URL -> 主 URL -> 原因 -> 上线日期 -> 验证人。执行时按以下顺序进行：

1. 备份数据库和媒体文件，保留可以回滚的版本。
2. 选择主 URL，合并内容并重写摘要、目录、标题层级和图片说明。删除重复段落时保留能够解释结论的上下文。
3. 旧 URL 返回永久重定向（通常是 301），直接指向最终主 URL，避免 A→B→C 的重定向链。若 URL 带有无意义的跟踪参数，先在服务器规则中统一处理。
4. 主页面使用自指向 canonical；旧页面一旦 301，就不要继续输出旧页面的 canonical。canonical 是提示，不是重定向的替代品。
5. 从 Sitemap、RSS、分类页、专题页、相关文章组件和正文内链中移除旧 URL，替换为主 URL。检查导航、面包屑和分页是否仍然产生旧链接。
6. 保留必要的评论、访问统计或编辑历史，并记录数据归属。不要因为合并页面就无依据地把旧文章的全部指标相加。
7. 在线验证状态码、Location、canonical、标题、H1、结构化数据和所有关键内链。

合并过程可以分成“内容迁移”和“URL 迁移”两次提交。先在草稿或预发布环境完成内容迁移，逐段对照旧页面，确认代码、表格、引用和图片没有丢失；上线后再启用 301，并同步更新 Sitemap 与内部入口。这样出现错误时，可以快速判断是正文缺失还是 URL 路由问题。变更记录中保留旧页面快照、主页面版本和映射表，不要只保存最终结果。

可用下面的检查方式确认重定向没有链路：

curl -I https://blog.zenleak.cn/post/旧文章/
curl -IL https://blog.zenleak.cn/post/旧文章/

第一条应能看到 301 和最终地址，第二条应在合理次数内到达主 URL，并且主 URL 返回 200。若页面仍有访问价值但只是主题重新定位，也可以保留旧页面并改写内容；不要为了减少数量而强行重定向。

七、更新旧文章时要有实质变化

只修改 updated_at 或把“2025 年最新”替换成“2026 年最新”，不会让内容变得可靠。一次合格的更新至少应完成其中几项：

• 重新运行代码和命令，核对版本号、参数、返回结果与截图；
• 删除已经失效的 API、配置路径和第三方服务说明；
• 在开头注明适用版本、最后核验日期、作者和审核人；
• 用可复现的数据替换没有来源的结论，给出采集时间、样本范围和限制；
• 更新摘要、目录、代码块语言标记、图片尺寸和 alt 文本；
• 增加一到两个能够帮助读者继续阅读的相关页面，而不是堆很多泛相关链接；
• 在编辑记录中写出“改了什么、为什么改、如何验证”。

本网站的发布后监控可参考 SEO 发布后监控实战，链接结构可参考 站内链接审计实战，发布前的页面检查可参考 Django SEO 发布前检查。这些页面应该互相补充，避免每篇都复制相同的清单。

八、下线、404 和 410 的边界

有明确替代页面时使用 301，并确保替代页面真正回答了旧页面的主要问题。没有替代内容、也不再需要保留时，可以返回 410 或 404；具体选择要和站点的日志、缓存及监控策略一致。noindex 只能阻止页面继续作为搜索结果候选，不能替代错误的重定向，也不能修复站内仍然存在的错误链接。

不要按“未收录”“访问量低”或“发布时间久”批量下线。先检查 网站页面不被收录排查清单 中的抓取和索引问题，再决定是否值得重写。访问来源和爬虫请求的判断可结合 SEO 访问日志分析实战；没有访问数据时，应在台账中保留不确定性。

九、让内容对 GEO 和搜索引擎都可核验

面向生成式搜索的内容维护，核心仍然是可验证性，不是增加一段“AI 推荐”式的宣传语。文章开头先直接回答主问题，再说明范围、前提和例外。涉及数字、版本、政策、实验或对比时，标明日期、样本和来源。作者、组织、产品和术语要保持统一写法，来源链接应能打开并支持结论。

可以参考 GEO 内容组织方法 检查首段、实体关系和问答结构，但不要伪造作者、引用或测试结果。结构化数据中的 dateModified、作者和图片必须与正文一致；不能因为模板字段方便就填入不存在的作者或日期。

事实边界也要写进编辑流程：无法通过官方文档、可重复测试或公开原始数据验证的内容，改成假设、经验或待验证项，并明确说明限制。引用第三方文章时，区分原文事实和自己的推断；引用日志样本时，写出采集时间、脱敏方式和样本量。这样读者、搜索引擎和后续编辑都能判断结论适用到哪里。

十、发布后的 7 天和 30 天复核

合并或大幅更新上线后，至少安排两次复核。7 天复核关注技术和抓取：

• 主 URL、旧 URL 的状态码和重定向是否符合映射表；
• canonical、Sitemap、RSS、面包屑和正文内链是否都指向主 URL；
• 移动端是否有溢出、图片是否加载、alt 是否描述了图片内容；
• 日志中是否出现循环重定向、404 峰值、异常爬虫请求或服务器错误；
• 百度主动推送和 IndexNow 是否只提交最终可访问的 URL。提交机制可参考 百度主动推送与 IndexNow。

30 天复核关注结果和下一步：

• 比较主 URL 与旧 URL 合并前后的展现、点击、查询词和排名；
• 查看新页面是否获得了原来分散在多个页面上的长尾查询；
• 检查是否仍有两个页面针对同一意图，或出现新的孤立页面；
• 记录用户停留、退出、站内搜索和转化变化，区分内容问题与流量季节性；
• 把结论写回内容台账，决定继续更新、重新定位或恢复原结构。

更长期的指标设计可以参考 SEO 进阶测量与验证 和 SEO 数据监控实战指南。指标的作用是帮助做下一次判断，而不是给一次合并行动贴上“成功”或“失败”的标签。

结语

内容维护是一组持续的判断：先确认用户问题和事实是否仍然有效，再决定 URL 的去留。相似度脚本适合发现候选，人工复核负责理解意图；301、canonical、Sitemap 和内链负责把变更清楚地传递给用户和搜索引擎。只要保留台账、备份、映射表和 7/30 天复核记录，旧文章就能从“数量负担”变成可持续更新的知识资产。