HSTS 预加载列表 - www 站点可能出现的 SEO 问题
HSTS preload list - possible SEO issue for www sites
让我在这里解释一个真实世界的情况。
我 运行 网站 https://www.liloo.ro 我想为其启用 HSTS（+HSTS 预加载）。
问题是，为了将其提交到 preload list， 主域 必须使用 HSTS header.[=14= 进行响应]
让我更准确地说：
为了将站点提交到预加载列表并满足要求，第一个重定向 必须 到主域的 https 版本。
在我的例子中，我不能直接从 http 重定向到 https + www -> 我必须先从 http 重定向到 https（这里提供主域名 HSTS header），然后再次重定向到https + www
这会带来巨大的重定向稀释 SEO 问题（更不用说链式重定向并不理想）。
所以无论我怎么看，我要么必须放弃 HSTS 预加载列表，要么使用链式重定向。这两个选项看起来都不理想。
唯一可能的解决方法可能是预加载列表要求中的某些内容，但我不太明白它的含义：
If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.
据我所知，在进行重定向时无法提供 HSTS header 之类的服务……但也许我错了。
任何想法如何解决这个问题？ ...或者我应该完全放弃 HSTS 预加载列表，因为我的网站只有 www？
此时我不能只从 www 切换到 non-www...我知道这会是 "easy" 解决方案。
任何想法 - 非常感谢。
我注意到这个线程
...但我怀疑它是否能解决问题（+ 我正在使用 nginx）
我真的很感谢你发布这个，因为我有完全相同的问题，即 http://DOMAIN 重定向 直接 到 https://www.DOMAIN，合并 重定向到 HTTPS 和 重定向到 www 子域。
I know it would have been the "easy" solution.
请注意，已经有好几次 reasons to use a subdomain like www, as has been discussed，所以这个选择是完全可以理解的。
然而，HSTS 没有办法（至少现在还没有）将这两种重定向结合起来：它只能直接转发到HTTPS。我想如果 HSTS 预加载站点检测到这是 而不是 纯 HTTP 服务器本身所做的，那么强制执行“307 内部重定向”到 HTTPS 是不允许的。 （据我所知，此要求并未在 hstspreload.org 上明确说明，但只能通过实际尝试设置 HSTS 预加载才能找到。）
我没有完整回答你的问题，但我可以就你提出的几点提供更多信息：
If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.
请注意 hstspreload.org 的确切（当前）引述：
If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
这与以下几点有关：
As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ...
HTTP 重定向响应也 完全有可能具有 HSTS header。这仅意味着 HTTP 重定向响应还包含一个带有合适参数的 Strict-Transport-Security header 字段。例如，使用 SWI-Prolog 作为 HTTP 服务器，您可以发出这样的响应：
?- http_status_reply(moved('https://whosebug.com'), current_output,
[strict_transport_security('max-age=63072000; includeSubdomains')], Code).
产量：
HTTP/1.1 301 Moved Permanently
Date: Sun, 12 Feb 2017 10:04:55 GMT
Location: https://whosebug.com
Strict-Transport-Security: max-age=63072000; includeSubdomains
Content-Length: 366
Content-Type: text/html; charset=UTF-8
etc.
请注意，此 header 字段仅在 TLS 已经 被使用时才允许（否则，攻击者可能会通过一个连接强制流量到不同的端口未认证！）。事实上，header 绝不能 出现在 HTTP→HTTPS 重定向中，因为它使用未经身份验证的连接，如果它（错误地） 确实 发生在纯 HTTP 上，客户端 必须 忽略它。
现在进入您问题的真正要点：
This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).
我完全同意链式重定向远非理想，而且对于我们这样的（常见！）设置似乎没有办法解决这个问题，至少目前不是。
但是，我个人希望额外重定向的影响不会对您网站的排名产生太大影响：理论上，一旦搜索引擎看到您的网站在 HSTS 预加载列表中，它应该关心的只是它的 HTTPS 版本（因为这也是支持 HSTS 预加载的浏览器会做的！）。因此，您最终只有一个重定向，即 https://DOMAIN→https://www.DOMAIN 一个，这应该与您当前的情况相当。至少那是我有点幼稚的希望。在此重定向中，确保包含 HSTS header，因为这是进入预加载列表的必要条件。当然具体的配置细节取决于你具体的网络服务器。
另外请注意，即使 在 进入 HSTS 预加载列表后，您也无法恢复原始重定向链。这是因为 Continued requirements 部分指出：
You must make sure your site continues to satisfy the submission requirements at all times.
让我在这里解释一个真实世界的情况。
我 运行 网站 https://www.liloo.ro 我想为其启用 HSTS（+HSTS 预加载）。
问题是，为了将其提交到 preload list， 主域 必须使用 HSTS header.[=14= 进行响应]
让我更准确地说： 为了将站点提交到预加载列表并满足要求，第一个重定向 必须 到主域的 https 版本。
在我的例子中，我不能直接从 http 重定向到 https + www -> 我必须先从 http 重定向到 https（这里提供主域名 HSTS header），然后再次重定向到https + www
这会带来巨大的重定向稀释 SEO 问题（更不用说链式重定向并不理想）。
所以无论我怎么看，我要么必须放弃 HSTS 预加载列表，要么使用链式重定向。这两个选项看起来都不理想。
唯一可能的解决方法可能是预加载列表要求中的某些内容，但我不太明白它的含义：
If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.
据我所知，在进行重定向时无法提供 HSTS header 之类的服务……但也许我错了。 任何想法如何解决这个问题？ ...或者我应该完全放弃 HSTS 预加载列表，因为我的网站只有 www？
此时我不能只从 www 切换到 non-www...我知道这会是 "easy" 解决方案。
任何想法 - 非常感谢。
我注意到这个线程
我真的很感谢你发布这个，因为我有完全相同的问题，即 http://DOMAIN 重定向 直接 到 https://www.DOMAIN，合并 重定向到 HTTPS 和 重定向到 www 子域。
I know it would have been the "easy" solution.
请注意，已经有好几次 reasons to use a subdomain like www, as has been discussed，所以这个选择是完全可以理解的。
然而，HSTS 没有办法（至少现在还没有）将这两种重定向结合起来：它只能直接转发到HTTPS。我想如果 HSTS 预加载站点检测到这是 而不是 纯 HTTP 服务器本身所做的，那么强制执行“307 内部重定向”到 HTTPS 是不允许的。 （据我所知，此要求并未在 hstspreload.org 上明确说明，但只能通过实际尝试设置 HSTS 预加载才能找到。）
我没有完整回答你的问题，但我可以就你提出的几点提供更多信息：
If you are serving a redirect, that redirect must have the HSTS header, not the page it redirects to.
请注意 hstspreload.org 的确切（当前）引述：
If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
这与以下几点有关：
As far as I know there is no way to serve such thing as a HSTS header when doing a redirect ...
HTTP 重定向响应也 完全有可能具有 HSTS header。这仅意味着 HTTP 重定向响应还包含一个带有合适参数的 Strict-Transport-Security header 字段。例如，使用 SWI-Prolog 作为 HTTP 服务器，您可以发出这样的响应：
?- http_status_reply(moved('https://whosebug.com'), current_output,
[strict_transport_security('max-age=63072000; includeSubdomains')], Code).
产量：
HTTP/1.1 301 Moved Permanently Date: Sun, 12 Feb 2017 10:04:55 GMT Location: https://whosebug.com Strict-Transport-Security: max-age=63072000; includeSubdomains Content-Length: 366 Content-Type: text/html; charset=UTF-8 etc.
请注意，此 header 字段仅在 TLS 已经 被使用时才允许（否则，攻击者可能会通过一个连接强制流量到不同的端口未认证！）。事实上，header 绝不能 出现在 HTTP→HTTPS 重定向中，因为它使用未经身份验证的连接，如果它（错误地） 确实 发生在纯 HTTP 上，客户端 必须 忽略它。
现在进入您问题的真正要点：
This poses a huge redirect dilution SEO problem (not to mention the fact that chained redirects are not ideal).
我完全同意链式重定向远非理想，而且对于我们这样的（常见！）设置似乎没有办法解决这个问题，至少目前不是。
但是，我个人希望额外重定向的影响不会对您网站的排名产生太大影响：理论上，一旦搜索引擎看到您的网站在 HSTS 预加载列表中，它应该关心的只是它的 HTTPS 版本（因为这也是支持 HSTS 预加载的浏览器会做的！）。因此，您最终只有一个重定向，即 https://DOMAIN→https://www.DOMAIN 一个，这应该与您当前的情况相当。至少那是我有点幼稚的希望。在此重定向中，确保包含 HSTS header，因为这是进入预加载列表的必要条件。当然具体的配置细节取决于你具体的网络服务器。
另外请注意，即使 在 进入 HSTS 预加载列表后，您也无法恢复原始重定向链。这是因为 Continued requirements 部分指出：
You must make sure your site continues to satisfy the submission requirements at all times.