JavaScript 重定向是网站管理员向用户和搜索引擎传达所请求的 URL 永久或暂时不可用的一种方法。然后为您提供的 URL 应被视为替代或新的永久地址。
通常最佳实践呼应您应该使用服务器端 301s、302s 或 307s。
通常，托管 JavaScript (JS) 应用程序的服务器是 Nginx 服务器，其配置文件始终可以实现服务器端重定向，这是 Google SEO优化推荐的方式。
但是，让我们看一下越来越流行的无头网站架构。我们注意到，并非所有无头构建都允许服务器端重定向并依赖于客户端实现——这些是 JavaScript 重定向。
虽然一些无头 CMS 平台已在服务器或应用程序级别配置重定向，但迁移到无头架构的好处之一是您不再运行单体，而是运行微服务模型。
因此，开发人员将寻求减少依赖关系并在堆栈中创建灵活性。
在前端（例如 Vue.JS）中管理重定向意味着您可以少考虑更改 CMS。
当客户希望迁移到无头架构或任何其他形式的 JAMstack 技术堆栈时，这就是我们作为 SEO 专业人士需要概述和建立 URL 重定向功能的地方。
就 JavaScript 重定向的工作方式而言，它们通常是通过 window.location.replace 函数实现的，并且对用户来说效果很好。
但是搜索引擎对它们的解释程度有待商榷。
在 Google 的 Search Central 文档中，搜索引擎警告您应该：
仅当您无法进行服务器端或元刷新重定向时才使用 JavaScript 重定向。
并且随着他们的加入，从 SEO 的角度来看，他们为谷歌工作（从 SEO 的角度来看，这绝对是许多开发人员的解释）。
但相比之下，就在 2020 年，谷歌的 Gary Illyes 曾公开表示 JavaScript 重定向“可能不是一个好主意”。
Js 重定向可能不是一个好主意。
— Gary 鲸理／경리 Illyes (@methode) 2020 年 7 月 8 日
这是对围绕国际化和重定向的主题的直接回应。尽管如此，它提出了为什么它们可能不是一个好主意的问题，可能重申谷歌的文档警告不要将它们用作优先解决方案。
如何实现 JavaScript 重定向
实现 JavaScript 重定向最常用的方法是通过 window.location.replace，例如：
window.location.replace(“https://www.bjxts.com/”);
如果您打开开发工具（CTRL + SHIFT + I）并在控制台中输入上述行，您将转到我的网站主页。
另一种实现方法是通过 window.location.href，但这可能会导致用户问题。
使用 replace 方法，当用户单击返回时，浏览器将加载上一页 – 但使用 href 方法，浏览器将加载并将用户重定向回他们刚刚尝试离开的同一页面（因为它存储在导航历史）。
这会导致 UX 重定向循环/陷阱，导致用户关闭选项卡并对网站产生负面体验。
对于许多流行的无头平台，例如Gatsby，有处理和实现重定向的预构建方法。
在 Gatsby 中，您可以安装 gatsby-plugin-gatsby-cloud，并实现 1:1 重定向、通配符重定向和“splat”重定向。
同样，流行的无头 CMS，如Jekyll和Strapi，带有预构建的模块和插件，以简化重定向的实施。
Google 如何处理 JavaScript 重定向
与 JavaScript 渲染一样，Google 分两步执行 JavaScript，并依赖 Web Rendering Service 进行处理。
您可以在此处阅读有关 Google 如何处理 JavaScript的更多信息。
然而，就本文的目的而言，重要的是要强调 JavaScript 的细微差别以及 Google 经常如何谈论它——以及我们作为 SEO 专家如何解释这一点。
2019 年，在Google Mythbusting 视频中，Martin Splitt 强调您应该“负责任地”使用 JavaScript，以帮助防止内容在 Google 的流程中“落后”。
正如本文前面的推文所强调的那样，在 2020 年，Gary Illyes 认为使用 JS 重定向可能不是一个好主意。
在 2021 年的 Search Off The Record 播客中，谷歌的拥护者强调，只要谷歌能看到页面的关键（价值主张、有益目的） ，你就不应该对 JavaScript 有任何问题。
将其与 JavaScript 重定向以及 Google 如何处理它们联系起来：当 Google 遇到 JS 重定向时，搜索引擎首先必须渲染 JS，将其识别为重定向，然后“遵循”新路径。
这会花费额外的时间和资源（Google 在网站上限制的两件事，我们通常简称为抓取预算）。
正因为如此，与 JS 重定向相比，Google 更喜欢服务器端重定向（传统的 301、302、307）。
谷歌最近在 2022 年 6 月的SEO Office Hours 视频中重申了这一点。
在 2020 年 1 月的另一份 SEO Office Hours 记录中，谷歌强调 JavaScript 重定向确实比服务器端重定向需要更长的时间来处理。
作为参考，谷歌关于重定向的搜索中心文档首先包括 2021 年 6 月的 JavaScript 重定向，因此就整体“SEO 时间线”而言，这仍然是相当新的。
JavaScript 重定向对 SEO 有用吗？
回顾 Google 的 Search Central 文档和JavaScript 重定向的实现，它扩展了使用 JavaScript 重定向的警告，内容如下：
虽然 Google 会尝试呈现 Googlebot 抓取的每个 URL，但呈现可能会因各种原因而失败。这意味着如果您设置 JavaScript 重定向，如果内容呈现失败，Google 可能永远看不到它。
这与另一个技术 SEO 的最爱有关：渲染。
更具体地说，如果 Web 渲染服务无法执行和渲染用于重定向的 JavaScript，会发生什么情况？
如果由于某种原因，Google 无法执行/呈现 JavaScript，那么 Google 将加载初始请求 URL。
根据您的设置，可能会发生两件事：
- 它将为空白或在Google Search Console中导致软 404 错误。
- 它将返回原始页面内容，对其进行处理，然后开始将其作为“正常”处理，如果您希望该内容不再可访问，这并不理想。
为了尽可能降低风险，在实施 JavaScript 重定向时，您应该：
- 请记住，Google 是无国籍的；任何前端重定向都不应依赖本地存储或 HTTP cookie（也称为数据持久性）。
- 不要依赖用户权限来启动重定向，因为 Google 会拒绝用户权限请求。
- 不要使用片段 URL。
- 减少到“原始”URL 的内部链接并将其从 XML 站点地图中删除，确保新的“目标”URL 存在，从而向搜索引擎提供一致的信号。
最后一点，涉及链接资产和 PageRank/链接资产的分布。
对此的研究已有七年多的历史，可通过 Wayback Machine 获得。但逻辑、理论和先前的研究表明，PageRank 确实像在服务器端重定向一样在 JavaScript 重定向上流动（一旦 Google 有机会处理它）。
