例如，出现一个随机问题：需要使用工具或插件来显示使用给定css选择器的html文件，请注意相关部分是/questions/16999。现在，URL可能像这样完成：在question_id之后。

我还在一篇文章中读到，只有前两个子目录是相关的，因此只有/question/16999是相关的。因此，这绝对是不正确的，但是我不能决定它的权重。

我问的是因为我将要实现seo优化，并且不想更改链接到我的页面。

评论

顺便说一句，我想将子目录添加为标签
分页@Jeff Atwood。 （也可以参考资料来源。）
有时，URL可能会被截断（故意（太长而无法存储在数据库中，等等）或错误）..如果id在段符之前，则服务器/脚本仍可以识别您想要的页面，但是id末尾很可能不。尝试此页面的URL-删除最后几个字符并提交-服务器会将您重定向到正确的URL（显然，后面的代码对此情况有特殊处理）。以id结尾，您可能会看到完全不同的问题（或错误页面）。 webmasters.stackexchange.com/questions/16641/…
@Lazyone，请回答一下，以便我们对其进行投票
如果您将此问题留在网址的最后一个“目录”中，则仍然会遇到以下问题：webmasters.stackexchange.com/questions/17002/foo-bar

#1 楼

我不知道为什么StackExchange站点确实会在ID之前具有ID，但是这就是为什么我会这样：

有时URL可能会被截断（故意（太长，无法存储在DB中，等等）或由于错误（在复制粘贴时经常发生））。并且，如果ID在段符之前，则服务器/脚本仍可以识别您想要的页面，但ID末尾很可能不会。

尝试使用此页面的URL-删除最后几个字符并提交-服务器会将您重定向到正确的URL（显然，本网站后面的代码对此情况有特殊处理）。以ID结尾时，您可能会看到完全不同的问题（在这种情况下，这是最常见的行为）..或只是错误页面（当服务器/脚本确保Slug与ID匹配时）。

SEO效果-看到以下问题：SEO：URL：ID的最佳位置

评论

关于截断+1的要点

–UpTheCreek
2011年7月19日在8:19

#2 楼

是的，如果他们愿意，他们可以在问题标题后添加ID。

关于ID和SEO的位置，我认为这没有什么关系（好吧，如果它在域名中）。

从人类可读性的角度来看，（至少对我而言）在末尾使用人类可读的标题似乎更为清晰，而不是埋藏在URL中。


我还在一篇文章中读到，只有前两个子目录是相关的，因此只有/ question / 16999是相关的。从SO
来看，这绝对是不正确的，但是我不能决定它的分量。


您从哪里读到的？我认为这是不正确的，如今，这些重写的URL通常不以任何方式与子目录相关。

评论

我想我们将不得不同意不同意。对我而言，URL中间的随机数（好是问题ID）比/ question / what-did-youve-for-lunch / mumble-jumble这样的自然阅读的东西有点尴尬。在这里，我将忽略从混乱到混乱的一切。

– andho
2011年7月18日在14:37
顺便说一下，这是我阅读有关2个子目录的内容的链接，goodwebsiteinspector.com / en /…

– andho
2011年7月18日在14:38
是的，我们将不得不同意：)我不同意该链接中有关“子目录”的结论。这些通常根本不是子目录，而google知道这一点。即使是这样，为什么Google会因为“深度”而降低潜在的有用资源？

–UpTheCreek
2011年7月19日在8:18

#3 楼

服务器对URL的处理忽略了问题ID号和斜杠后面的URL部分。所有这些都是等效的：


/ questions / 16999
/ questions / 16999 /
/ questions / 16999 / any-text-at-all


它们都重定向到斜杠后带有（重新格式化的）问题文本的URL。 （例如本页相关侧边栏中的链接），从而节省了HTML传输时间以及存储和CPU周期。通过将问题文本包含在规范的URL中（重定向到该文本），他们仍然可以获得在URL中具有相关文本以用于搜索引擎索引的好处。

评论

我看不到任何使用简化版网址的示例。

–UpTheCreek
2011年7月18日在6:39
@UpTheCreek，单击任何答案下方的共享按钮。例如webmasters.stackexchange.com/q/17002

–azerafati
17年6月13日在5:55