一年后我应该删除旧的重定向吗？

许多迁移团队至少保留一年。在此之后，只要旧 URL 仍然获得外部链接或流量，就保留它们。重定向服务的成本几乎为零，因此很少有必要过早删除它们。

只重定向已索引的页面可以吗？

如果未索引的页面携带链接，则不行。索引状态对外部权重的说明很少。重定向每一个有链接域名的 URL，然后根据流量决定其余部分。

永久移动使用 302 或 307 可以吗？

永久移动请使用 301 或 308。长期保留的 302 可能会被当作永久重定向处理，但结果取决于运气，且重定向的其他客户端可能不会做出相同的猜测。

我可以将旧站点的 404 重定向到新站点吗？

只有在存在接近匹配时才可以。重定向到不相关页面在 Google 看来是软 404。如果内容已消失，返回真实的 404 或 410。

重定向映射表制作指南：根据外链对旧 URL 进行排序

重定向映射表是一个优先级列表，而不是包含所有 URL 的电子表格。从其他网站链接的页面开始，其余的映射工作就会变得更容易。

ArchiLinks 研究团队 · 更新于 2026-10-29

为什么按链接排序

团队通常从爬取数据构建映射表。虽然完整，但它会将一个被遗忘的 2014 年新闻页面与首页同等对待。

当你检查指向我站的外链并按链接域名数量对页面进行排序时，在大多数迁移中会出现一种模式：少数几十个 URL 承载了大部分外部权重。这些 URL 需要人工匹配、双重审核并优先测试。

其余内容遵循规则。文件夹按模式映射，参数被剥离，没有链接也没有流量的孤立 URL 如果决定可以返回 410 状态码。将输出结果与迁移检查清单配合使用，以便在上线前进行测试并在第 45 天重新检查，并与API 脚本配合使用以安排每月抓取。

步骤 1：抓取被链接的页面

一次调用最多返回 1,000 行数据，无论行数多少，费用均为 2 个积分。下面的字段名仅为示例；查看一次真实响应并调整键名。

python

import csv, requests

BASE = "https://archilinks.com/api.php"
KEY = "sk_live_..."

def call(action, **params):
    r = requests.get(BASE, params={"action": action, "key": KEY, **params}, timeout=30)
    r.raise_for_status()
    return r.json()

data = call("toppages", q="old-shop.com", per=1000)
rows = next(v for v in data.values() if isinstance(v, list))

with open("linked-pages.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow(["old_url", "links", "new_url"])
    for row in rows:
        w.writerow([row.get("url"), row.get("backlinks"), ""])

步骤 2：填充第三列

按语义匹配

产品页应跳转到相同的产品，或者如果产品已下架则跳转到其分类页。除非该页面本身就是首页，否则不要跳转到首页。

让第二个人检查前 50 名

下午 6 点疲惫的人可能会将关于规范化的指南映射到博客索引页。审核者可以发现这个问题。

长尾部分的规则

为文件夹编写模式并剥离跟踪参数。将每条规则保留在版本控制中，并附上解释原因的注释。

步骤 3：生成服务器规则

nginx 能很好地读取映射文件，并且可以扩展到数万行。

nginx

# /etc/nginx/redirects.map  (generated from the csv)
/old/guide-canonicals    /guides/canonical-tags;
/products/blue-widget    /shop/widgets/blue;

# in nginx.conf, http context
map $request_uri $new_uri {
    default "";
    include /etc/nginx/redirects.map;
}

# in the server block of the old host
if ($new_uri) {
    return 301 https://new-shop.com$new_uri;
}

步骤 4：测试每一次跳转

如果任何结果不是指向 200 状态码的单个 301 重定向，则使流水线失败。

bash

while IFS=, read -r old new; do
  out=$(curl -s -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}" -L "https://old-shop.com$old")
  echo "$old -> $out"
done < redirect-pairs.csv | grep -v "^.* -> 200 1 " && echo "FIX ABOVE"

我们会首先检查的错误

症状	可能原因	修复方法
两到三次跳转的链	新旧规则堆叠	将旧规则直接指向最终 URL
所有内容都跳转到首页	懒惰的通配符规则	按主题匹配；Google 可能会将大规模首页重定向视为软 404
查询字符串丢失	规则丢弃了参数	保留改变内容的参数；剥离其余参数
上线后顶级 URL 返回 404	遗漏在 CSV 中	重新运行抓取并与实时映射表进行差异比较

哪些 URL 值得人工匹配

并非每个 URL 都值得人工处理。按链接域名进行区分是一个有用的方法：任何有多个外部站点指向的 URL 都应手动匹配，其余的遵循规则集。假设你有 4,000 个旧 URL，其中 60 个承载了大部分外部链接。这六十个 URL 需要一下午的审核，而其他 3,940 个则使用模式和测试。

将阈值保留在脚本中，而不是记在脑子里。对于中型网站，五个链接域名是一个合理的起点。从那里开始。当整个网站的链接很少时降低数字，当人工列表对于单个审核者来说太长时提高数字。

将人工匹配行与规则匹配行分开

人工匹配行有指定的审核者，并附有选择目标的原因说明。规则匹配行有针对整个文件夹测试的模式，以便在上线前的测试报告中而不是在上线后的流量图表中发现异常。

混合情况导致大多数混淆。已停产并由继任者替代的产品映射到继任者。已停产且无继任者的产品属于其分类，绝不属于首页。

使用第二次抓取来查看变化

在映射表最终确定之前，对旧主机运行 refdomains，然后在上线后再次运行，并通过域名匹配两个列表。第二次抓取中缺失的链接域名是向链接所有者询问的问题，而不是惊慌的理由，因为移除的链接可能需要一段时间才能在索引中显示。

将两个文件并排保存在迁移文件夹中，每个文件名中包含日期。差异比较告诉你去哪里查找，映射表告诉你对此做了什么处理。

决定如何处理没有链接的 URL

没有链接也没有流量的孤立 URL 是简单部分。如果内容永久消失，返回清晰的 404 或 410，只有在存在接近的替代方案时才重定向，以便访客和爬虫都能到达有用的地方。

当你不确定时，在映射表中留下简短的注释，并在第一周日志查看后再回来。你的服务器日志显示哪些旧地址仍然收到请求，这是你拥有的最佳证据。

映射表如何融入发布流程

重定向映射表会随着网站的变化而变化。记住这一点。新页面会出现，旧页面会被重命名，模板更改可能会破坏上个月看起来安全的规则。将映射表视为代码，在版本控制中保留一个文件，每次部署前进行审核，每次更改后运行测试。

尽可能将映射表保持在一层中。重定向分散在应用程序、CDN 和 CMS 中是出现链的原因，而没有完整的爬取很难发现链。

规则应该放在哪里

服务器映射表速度快且易于测试。CMS 插件对于少量页面很方便，但在大规模下难以审计。无论你选择哪一个，单跳测试必须从同一位置读取。

如果两层重定向同一个 URL，测试会报告链。从你计划退役的层中删除重复项。

每次更改后在真实主机上测试

在规则文件每次更改后，先在预演环境运行跳测试，然后在生产环境运行。在预演环境中通过的规则在缓存持有旧响应时仍可能失败，因此第二次运行很重要。

保存带有日期的输出。当顶级 URL 几个月后出错时，旧结果可以显示是规则更改了还是网站发生了变化。迁移检查清单列出了该测试的时机，首先运行它可以使下一次检查与本次检查具有可比性。

审核规则文件的更改

为映射表的更改指定一名审核者，并要求该人检查三件事：每个目标是否仍然匹配主题，该规则创建了多少次跳转，以及模式是否足够窄以仅影响为其编写的 URL。未经审核的更改最有可能开始链式重定向。

当网站本身发生变化时，要求相同的审核。一个新分类吸收旧文件夹可能会使正确的规则指向错误的位置，而无需任何人编辑映射表。

将审核者的注释存储在更改旁边。六个月后，注释解释了看起来随意的规则，并节省了对同一问题的第二次调查。

在全量运行前测试样本

在运行整个列表之前，选择一个由顶级被链接页面和一些普通页面组成的 50 行样本。首先对该样本运行跳测试。样本易于阅读，规则错误会在整个文件显示之前就在样本中显示出来。

包含来自每个规则模式的至少一行，以及来自每个手动匹配组的一行。覆盖两百个 URL 文件夹的模式仅通过样本中碰巧包含的行进行测试，因此要有目的地选择它们。

保持规则文件小巧

包含数百个以上模式的规则文件难以审核。按网站部分拆分它，并保持每个文件足够短，以便审核者可以一次性阅读完。

在其文件夹消失的当天删除规则。遗留的旧规则是后来将流量引入链的原因。

映射表上线前

每一行都有一个新的 URL，或者是有意的 404 或 410。
没有目标是重定向本身。
链接域名最多的 50 个 URL 已由第二个人审核。
改变内容的查询参数被保留。
规则文件在版本控制中，每个模式都有注释。
保存引用域名基线以供上线后差异比较。

常见的重定向问题

一年后我应该删除旧的重定向吗？: 许多迁移团队至少保留一年。在此之后，只要旧 URL 仍然获得外部链接或流量，就保留它们。重定向服务的成本几乎为零，因此很少有必要过早删除它们。
只重定向已索引的页面可以吗？: 如果未索引的页面携带链接，则不行。索引状态对外部权重的说明很少。重定向每一个有链接域名的 URL，然后根据流量决定其余部分。
永久移动使用 302 或 307 可以吗？: 永久移动请使用 301 或 308。长期保留的 302 可能会被当作永久重定向处理，但结果取决于运气，且重定向的其他客户端可能不会做出相同的猜测。
我可以将旧站点的 404 重定向到新站点吗？: 只有在存在接近匹配时才可以。重定向到不相关页面在 Google 看来是软 404。如果内容已消失，返回真实的 404 或 410。