ASP.NET Core迁移后Google显示旧URL及重定向实现失败的问题

一、重定向代码不生效的核心排查与修正 #

重定向规则失效的核心原因集中在三类，按以下步骤排查修正即可：

• 修正中间件注册顺序
  ASP.NET Core的中间件按注册顺序依次处理请求，如果将UseRewriter放在UseRouting、UseEndpoints这类负责匹配请求、返回404逻辑的中间件后面，请求会先被路由逻辑判定为无对应处理程序，直接返回404，根本轮不到重定向规则执行。
  正确的管道顺序是把重写中间件放在最靠前的位置：异常处理 → HSTS/HTTPS跳转 → URL重写规则 → 静态文件处理 → 路由 → 认证授权 → 端点映射。
• 修正正则匹配逻辑
  AddRedirect的正则匹配范围是请求的相对路径部分（不含域名、协议），原代码中写的带全路径转义斜杠的正则，很容易和实际请求路径不匹配；同时新旧域名存在“带www/不带www”的差异，需要把这部分跳转规则也统一配置。
  修正后的可运行代码参考：

  var rewriteOptions = new RewriteOptions()
      // 统一将带www的旧域名请求301到不带www的正式域名
      .AddRedirect("^(www\\.)(.*)$", "https://roberttayloronline.com/$2", (int)HttpStatusCode.MovedPermanently)
      // 匹配指定的旧aspx路径，301到对应新页面
      .AddRedirect(
          @"^Trips/2019PineRiverTrail/2019PineRiverTrail\.aspx$",
          "/recreation/trips/2019-pine-river-trail",
          (int)HttpStatusCode.MovedPermanently);
  // 关键：将重写中间件注册在所有会返回404的中间件之前
  app.UseRewriter(rewriteOptions);
  

• 排查托管层拦截问题
  如果站点托管在IIS上，需要确认带.aspx后缀的请求没有被IIS默认的旧版ASP.NET处理程序拦截。默认情况下IIS会对带.aspx后缀的请求优先分配给内置的页面处理器，如果对应路径下没有物理aspx文件，会直接在IIS层返回404，根本不会把请求转发给ASP.NET Core应用。需要检查站点的web.config配置，确保所有请求都被转发给ASP.NET Core模块处理，没有被其他处理器提前拦截。
• 验证重定向是否生效
  不要靠浏览器访问测试（301跳转是强缓存，很容易残留旧的404缓存），直接用命令行测试：
  curl -I https://www.roberttayloronline.com/Trips/2019PineRiverTrail/2019PineRiverTrail.aspx
  如果返回头里有HTTP/1.1 301 MovedPermanently和对应的Location指向新URL，说明规则已经生效。

二、Google搜索结果的更新逻辑 #

不需要额外指导Google做跳转导流，只要旧URL正确返回301永久重定向，Google爬取时会自动识别跳转规则，替换索引里的旧URL，同时将旧URL积累的搜索权重完全传递到新URL上。
需要调整之前的操作误区：

• 不要直接使用Search Console的旧URL移除工具：这个工具只是临时将URL从搜索结果中隐藏90天，不会触发Google跟踪跳转、也不会传递权重，完全达不到导流目的。
• 正确的操作流程：
  • 先确保所有旧URL的301规则稳定运行，没有出现跳转死循环、404的情况
  • 在Search Console中，对需要更新的旧URL使用“请求编入索引”功能，主动触发Google爬取该URL，Google爬取时识别到301后就会自动更新索引
  • 对于域名从带www到不带www、更换托管服务商的场景，可以使用Search Console的“更改地址”工具提交变更通知，加快Google的索引更新节奏
  • 索引更新周期通常为1-4周，大站点可能需要几个月，期间只要保持301规则稳定即可，不需要重复提交。

内容的提问来源于stack exchange，提问作者Robert Taylor