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