如果你不关心SEO / SEM,是否值得使用“漂亮的URL”

时间:2009-10-26 18:16:08

标签: ruby-on-rails seo friendly-url

我正在设计托管的软件即服务应用程序,就像37Signal的Highrise产品的高度专业化版本。在这种情况下,SEO不是问题,是否值得实施“漂亮的URL”而不是使用数字ID(例如customers/john-smith而不是customers/1234)?我注意到很多网络应用程序都不打扰它们,除非它们提供真正的价值(例如电子商务应用程序,博客 - 需要通过搜索引擎找到SEO的东西)

7 个答案:

答案 0 :(得分:20)

取决于用户口头传输网址的频率。人们倾向于发现发音类似

的相对困难
http://www.domain.com/?id=4535&f=234&r=s%39fu__

并且喜欢

http://www.domain.com/john-doe

好多了;)

答案 1 :(得分:8)

除了可读性之外,另外要记住的是,通过公开自动递增的数字键,您还可以让某人猜测其他资源的URL,并可以泄露有关您数据的某些详细信息。例如,如果有人注册您的应用并发现他们的帐户位于/customer/12,则可能会影响他们对您的应用的信心,因为您知道您只有11个其他客户。如果他们的网址为/customer/some-company,则不会出现问题。

答案 2 :(得分:7)

如果你有时间做正确的话,这总是值得的。

  • 友好网址看起来更好,他们可以更好地了解链接的引导位置。如果链接是共享的,这很有用。通过即时消息。
  • 如果您要从浏览器历史记录中搜索特定页面,那么人类可读的网址会有所帮助。
  • 友好的网址更容易记住(在某些情况下很有用)。
  • 如前所述,口头沟通也更容易(需要比你想象的更频繁)。
  • 它隐藏了用户不必要的技术细节。在用户ID在网址中可见的一种情况下,多个用户询问为什么他们的用户ID高于用户总数。没有造成任何损害,但如果你能避免它,为什么会让用户感到困惑。

答案 3 :(得分:2)

当鼠标悬停在链接上时,我肯定更有可能点击链接,并且它有http://www.example.com/something-i-am-interested-in.html

而不是看http://www.example.com/23847ozjo8uflidsa.asp

点击MSDN上的链接非常烦人,因为我永远不知道会发生什么。

答案 4 :(得分:1)

当我创建应用程序时,我会尽力将其结构隐藏起来 - 虽然它主观关于你从中获取了多少“SEO” - 漂亮的URL往往有助于人们在保护代码的同时导航和理解它们的位置从可能的注射。

我注意到你正在使用Rails应用程序 - 所以你可能没有像ASP,PHP或其他语言那样庞大的查询字符串 - 但在我看来,增加的清洁度和整体外观是客户互动的一个加分。当共享链接时,客户能够复制网址:customer / john_doe,而不是寻找“链接我”或随机/客户/

更好

答案 5 :(得分:0)

我通常使用组合 - 保持使用Rails RESTful路由的便利性,同时仍然在URL中提供一些扩展信息。

我的应用网址如下所示: http://example.com/discussions/123-is-it-worth-using-pretty-urls/ http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments http://example.com/discussions/123-is-it-worth-using-pretty-urls/comments/34567

您无需添加任何自定义路由即可将其关闭,只需将以下方法添加到模型中即可:

def to_param
  [ id, permalink ].join("-")
end

并确保通过设置params [:id] .to_i将控制器中的任何调用params [:id]转换为整数。

只需注意,您需要在保存记录时设置永久链接属性...

答案 6 :(得分:0)

如果你的应用程序是安静的,那么rails默认为你提供的URL是SEO友好的。

在您的示例中,customers/1234可能会返回类似

的内容
<h1>Customer</h1>
<p><strong>Name:</strong> John Smith</p>
etc etc

任何当前的搜索引擎优化蜘蛛都足够聪明,可以解析目标网页并从那里提取“John Smith”。

因此,从这个意义上说,customers/1234已经是一个“不错”的URL(与其他系统相反,对于客户1234 resource/123123/1234,客户端可以使用resource/23232/321 321)。

现在,如果您希望您的用户经常使用网址(例如美味等),您可能希望开始使用登录和可读字段而不是ID。

但对于搜索引擎优化,ids很好。