📍 WDQWDWQD987AAAAA:216.73.216.219
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0ebbbd77d0e9.html
📄

WordPress搬家：历史地址没有一一对应新页时怎样设计映射

当旧站一批地址在新站找不到同名页面时，正确做法不是给每一条旧地址都硬找一个新页，而是先把旧地址按内容意图分组，再为每组指定一个最接近的新落点，剩余无对应内容的地址用合适的状态码收口。判断依据是旧地址是否仍有搜索需求、是否还有外部链接指向、以及新站是否真的存在同主题页面。

先拿一份旧地址清单，按内容意图分组

打开旧站的地址清单，逐条看它的主题，而不是只看网址里的词。把地址分成三类：第一类，新站有同主题页面，只是网址变了；第二类，旧地址的内容已被合并进某个更大的新页面；第三类，旧地址对应的内容已经不再提供。

这个分组动作会直接决定后面的处理方式。第一类做一对一映射，第二类做多对一映射，第三类不映射到具体页面。如果不先分组就批量做重定向，很容易把一批不相关的旧地址全部指向首页，用户和搜索引擎都无法判断落点是否相关。

一对一映射成立的条件：新页承接同一主题

只有新页确实在讲同一件事时，才适合把旧地址直接指向它。判断标准不是标题相似，而是用户带着旧地址的预期进入新页后，能否找到他原本要的内容。

• 旧地址是产品详情，新站有同一产品的详情页，只是分类层级变了，可以一对一。
• 旧地址是某篇教程，新站把它拆成了两篇，这时应指向覆盖原主题最完整的那一篇，而不是两篇都指。
• 旧地址是标签聚合页，新站取消了标签体系，就不属于一对一，应归入合并或收口。

假设旧站有一批地址形如 /guide/a、/guide/b，新站改成 /docs/a、/docs/b，且内容主题完全对应，这种情况可以用规则批量映射。规则写好后，先抽几条实际访问，确认落点页面能正常打开、内容主题一致，再放开全量。如果抽查发现落点页面是空分类或列表页，说明这条规则的前提不成立，应回到分组阶段重新判断，而不是继续扩大规则范围。

多对一映射：合并页要能承接所有旧主题

当旧站多个地址的内容被合并进一个新页面时，映射目标是同一个新页。这里的关键是确认合并页是否真的覆盖了这些旧地址的主题。如果合并页只讲了其中一部分，剩下的旧地址指向它，用户会认为落点不相关。

实际操作中，可以先列出每个旧地址的核心主题词，再看合并页的标题和正文是否覆盖这些主题。覆盖得住的，统一指向合并页；覆盖不住的，说明这次合并不彻底，要么补充合并页内容，要么把这条旧地址单独处理。这一步的动作结果会改变下一步：覆盖得住就可以批量写规则，覆盖不住就先改内容，不要先写规则。

没有对应新页时，用状态码收口而不是全指首页

第三类旧地址没有合适落点，常见处理有两种：返回 410 表示内容已永久移除，或返回 404 让系统自然处理。选择哪一种，取决于这些地址是否还有外部链接和搜索需求。

如果旧地址仍有外部链接指向，直接让它 404 会浪费这些链接带来的访问；此时更稳妥的做法是找一个主题最接近的上级页面承接，并在该页面上给出相关内容的入口。如果旧地址既无外链也无搜索需求，用 410 或 404 收口即可，不必强行映射。

把全部无对应地址统一指向首页是一种省事但代价高的做法。它会让大量不同主题的旧地址落到同一个页面，用户找不到预期内容，也无法判断哪个页面才是替代品。只有在旧地址本身就是首页或全站入口时，指向首页才成立。

用一份映射表驱动规则，并留出回退空间

把分组结果整理成一张映射表，每行包含旧地址、处理方式、目标地址、判断依据。处理方式只有几种：一对一、多对一、收口。目标地址栏为空时，表示这条不映射到具体页面。

映射表写完后，不要一次性全部生效。先选一小批有代表性的地址上线，观察访问日志中这些旧地址的请求是否落到了预期目标，以及落点页面是否被正常访问。如果发现某条规则把用户带到了不相关页面，只需修改这一条，不影响其他规则。这个先小批后全量的顺序，能让错误停留在可控范围内，也方便在映射表上直接定位问题行。

对于规则无法覆盖的特殊地址，保留手工映射条目，不要为了追求全自动而把它们塞进不合适的批量规则。映射表本身就是后续复查的依据：当业务内容再次调整时，可以回到这张表，判断哪些旧地址需要重新指定落点。