c# - 基于当前 URL 创建规范 URL 有什么好处？

Question

我有一个用 C# 编写的 MVC3 应用程序，我想为其生成 rel=canonical 标签。在寻找自动实现这一目标的方法时，我遇到了 this post .

我在我的开发环境中实现了它，它按预期工作并生成标签，例如

<link href="http://localhost/" rel="canonical" /> .

我的问题是，这样做有什么好处？规范 URL 不应该明确指向我想要的位置(即我的生产站点)，而不是 URL 恰好是什么吗？

我提出这个问题的原因是因为我的托管服务提供商(暂时匿名)也生成了另一个指向我网站的 URL(相同的 IP 地址只是不同的主机名，我不知道为什么，他们声称这是为了反向 DNS 目的——这是另一个主题)。但是，我已经开始看到我的页面出现在这个镜像 URL 下的 Google 搜索结果中。不利于 SEO，因为它是“重复内容”。现在，我通过简单地将我的 IIS 站点配置为仅响应对我站点域的请求来修复它，但是，现在似乎是查看规范 URL 可以在此处提供哪种类型的解决方案的好时机。

使用上面帖子中的解决方案，如果有人要访问镜像站点，rel=canonical 链接标记将输出包含 MIRRORED URL 的规范 URL，这根本不是我想要的。它应该总是 <link rel="canonical" href="http://www.productionsite.com" /> ，不管地址栏中的 URL，对吧？我的意思是，这不是规范 URL 的意义所在，还是我遗漏了什么？

假设我是对的，是否有一种公认的通用方法来为 MVC3 应用程序生成规范 URL？我显然可以为每个页面单独定义它们，或者我可以简单地替换 rawUrl.Host在我与硬编码域名链接的解决方案中的参数，我只是想知道为什么我看到这么多人以这种方式生成规范 URL 的例子，而它似乎不符合目的(至少在我的例子中)。他们试图通过将当前 URL 插入 rel=canonical 链接元素来解决什么问题？

Answer 1

问得好，您还在说镜像站点仍然被标记为规范站点。事实上，您必须先解决几个问题，然后它才能更加有效地打击您的“链接汁”。

我怀疑主要原因是因为 MVC 在设计上是一个 URL 重写/路由系统。因此，根据最初请求的 URL 发生的消息，人们试图将规范链接设置为“确定的”最终 URL 格式，重写后。也就是说，我认为您已经注意到了大多数人的疏忽 - 即“到达页面的 URL 是什么，这些 URL 没有预料到并被重写以成为 URL 的有效、规范路径？”这里的答案是在发现这些“错误请求”时重写它们。例如:如果您重写了您的 ISP 的镜像域请求，那么当它到达加载页面时，它现在是一个有效的 url；这是因为它已被您的重写规则“修复”。有道理？因此，您需要更新 MVC 路由以处理由您的 ISP 创建的错误路由。注意:在构建规范链接值时，您必须确保不使用最初请求的 URL，而是使用最终的、重写的 URL。

继续我的 WWW 与非 WWW 提示，以及对您提到的不处理无效 URL 的担忧。

人们这样做还因为您的站点已经“镜像”了人们总是忘记的另一个域。 “WWW”子域。

信不信由你，尽管存在争议，但许多人表示拥有 www.yourdomain.com/mypage.htm 和 yourdomain.com/mypage.htm 实际上会由于“重复”内容而损害您的网页排名。我怀疑这就是人们在那里显示“相同域”的原因，因为它实际上是剥离了“WWW”的域。 (我使用重写规则使 www 与 no-www 保持一致。)

此外，请注意“将我的 IIS 站点配置为仅响应对我站点域的请求”，因为如果 Google 仍然看到那里的链接并认为它们是您站点的一部分，它实际上可能只是因为页面失败而惩罚您加载(即 404s)我建议有一个重写规则，将它们发送到您的“真实”域，或者至少将规范链接设置为仅使用您的“真实”域与 WWW 一致，或者不存在。 (有人争论哪个更好，我认为这不重要，只要你是一致的。)