WordPress 迁移至 Astro 后的 SEO 修复：重定向链、sitemap 与 GSC 清理

从 WordPress 迁移到 Astro 之后，你的网站构建更快、加载更快，托管成本也更低。但如果迁移过程中博客 URL 发生了变化——例如从 /post-slug/ 改成了 /insights/post-slug——那么 SEO 问题很可能在数周后 Google 完成重新抓取时才会浮出水面。

Google Search Console 会开始发送邮件，提示"Duplicate, Google chose different canonical than user（重复页面，Google 选择了与用户指定不同的 canonical）"以及"Not found (404) validation failed（404 页面验证失败）"。你的高流量页面可能正因不必要的重定向跳转而损失外链权重。更糟的是，你可能有两个 sitemap 在互相竞争，却毫不知情。

本指南将带你找出并修复这些问题。我们在自己的 WordPress 到 Astro 迁移 SEO 清理过程中遭遇了所有这些情况，并在此整理了完整的修复方案。

你需要准备什么

服务器的 SSH 访问权限（用于修改 nginx 配置）
对应站点的 Google Search Console 访问权限
本地已安装 curl
数据分析工具（我们使用自托管的 Plausible）

本指南能解决哪些问题

多跳重定向链（2 次及以上）精简为单跳 301
多个相互竞争的 sitemap 合并为一个自动生成的来源
从 sitemap 中移除带有 noindex 标记的页面
清理过时的 GSC 属性和遗留的 WordPress sitemap
修复新旧 URL 结构之间的 canonical 混乱问题

第一步：排查重定向链

检查你的主要 URL 经过了多少次重定向。如果你的 WordPress URL 带有末尾斜杠，而 Astro URL 没有，那么很可能存在两跳链：一次重定向去掉斜杠，另一次添加新的路径前缀。

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\
" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

如果输出显示 Hops: 2，说明存在重定向链。对流量最高的五个页面依次执行此检查——这些页面的外链权重损失影响最大。

同时与你的数据分析结果交叉比对。如果同一篇文章以多个 URL 变体出现（带斜杠、不带斜杠、带新路径前缀），说明重定向没有成功合并流量。我们在 Plausible 中发现，访问量最高的文章被拆分到了三个 URL 变体下，这印证了重定向链问题的存在。

第二步：配置 nginx 实现单跳重定向

标准的 nginx 末尾斜杠规则如下：

location ~ ^(.+)/$ { return 301 $1; }

这条规则只负责去掉末尾斜杠，并不了解你博客路径的变化。请求随后会命中第二条规则，将 /slug 重定向至 /insights/slug。结果就是两跳。

将其替换为能感知博客结构的规则：检查 slug 是否对应一篇博文，如果是，则直接跳转到最终 URL：

# 带末尾斜杠的博客 slug — 单跳直达 /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://yourdomain.com/insights/$slug;
    }
    return 301 https://yourdomain.com/$slug;
}
# 多段路径 — 仅去掉末尾斜杠
location ~ ^(.+)/$ { return 301 $1; }

第一条规则处理根路径级别的 slug（即你原来的 WordPress 博客 URL）。它会检查 /insights/ 下是否存在匹配的页面，若存在则直接重定向过去。非博客路径则落入通用的斜杠去除规则。部署后请验证：

curl -sL -w "Hops: %{num_redirects}\
" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# 预期结果：Hops: 1

第三步：合并 sitemap

检查是否存在多个 sitemap。迁移后常见的情况是：迁移时手动创建的静态 sitemap.xml，加上 Astro 的 @astrojs/sitemap 集成自动生成的 sitemap-index.xml，两者同时存在。

# 分别检查两个 sitemap
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

如果两者都返回 200，说明存在相互竞争的 sitemap。检查 robots.txt 引用的是哪一个：

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

修复方案：从 public/ 目录中删除静态 sitemap.xml，更新 robots.txt 使其指向 sitemap-index.xml，并让 Astro 的集成全权接管。此后每次构建，新文章都会自动出现在 sitemap 中。

同时检查静态 sitemap 中是否包含带有 noindex 标记的页面。如果你的 sitemap.xml 列出了 /legal 或 /privacy-policy 等设置了 <meta name="robots" content="noindex"> 的页面，就是在向 Google 发送相互矛盾的信号。@astrojs/sitemap 自动生成的 sitemap 可以通过过滤规则配置来正确排除这些页面。

第四步：清理 Google Search Console

打开 GSC，重点检查两项内容：资源（Properties）和 sitemap。

资源：如果你同时拥有域名资源（sc-domain:yourdomain.com）和网址前缀资源（https://www.yourdomain.com/），同一个问题会触发重复告警。保留其中一个即可。如果你的子域名是独立项目，网址前缀资源更为简洁——它只报告正式环境的流量。

Sitemap：进入"索引 → 站点地图"，删除仍在注册的旧 WordPress sitemap（如 post-sitemap.xml、page-sitemap.xml、sitemap-post-type-product.xml 等），然后将新的 sitemap-index.xml 作为唯一的 sitemap 提交。

404 验证：进入"索引 → 网页 → 未找到 (404)"，查看列出了哪些 URL。如果是那些已不存在、也不应存在的旧 WordPress 路径（WooCommerce 商品页、作者页、Feed URL 等），它们会随时间自动从索引中移除。如果是本应有重定向的博文，则需要更新你的 nginx 规则。修复重定向后，点击"验证修复"以触发重新抓取。

第五步：全面验证

部署修复后，运行以下检查：

# 1. 确认重定向链已解决
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\
" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# 预期结果：Hops: 1，URL 以 /insights/your-top-post 结尾

# 2. robots.txt 指向自动生成的 sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# 预期结果：sitemap-index.xml

# 3. 旧的静态 sitemap 返回 404
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# 预期结果：404

# 4. 自动生成的 sitemap 返回 200
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# 预期结果：200

# 5. 非 www 重定向至 www
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\
" \
  "https://yourdomain.com/insights"
# 预期结果：301 https://www.yourdomain.com/insights

Google 需要多久才能跟上

单跳重定向对新抓取立即生效。sitemap 的变更通常在数天内被识别。而 canonical 混乱问题——即 Google 仍偏好旧 URL 而非新 URL——则需要更长时间解决。Google 将 <link rel="canonical"> 标签视为建议，而非强制指令。如果旧 URL 拥有更多外链和历史点击数据，Google 可能在数周内仍将其选为 canonical。

干净的重定向、单一权威的 sitemap，加上整合后的 GSC 资源，三者结合能为 Google 提供最清晰的信号。在我们的案例中，部署这些修复后约两周，GSC 中的"重复 canonical"警告便开始减少。

这类迁移工作是我们 WordPress 性能优化与迁移服务的日常内容。如果你正面临迁移后的 SEO 问题，欢迎联系我们。