从 SEO 角度，网址中的查询 id 结构怎么设计才最好？

[Reign]

以 stackoveflow 为例，它的问题列表是： http://stackoverflow.com/questions

现在在它的问题列表下的一个问题是这种 URL 结构：

http://stackoverflow.com/questions/42406362/how-to-check-for-inclusion-of-multisets

理论上来说，最佳的 URL 结构应该是：

http://stackoverflow.com/questions/how-to-check-for-inclusion-of-multisets

这样就能突出 URL 目录的依次归属关系，也许数据表中“ how-to-check-for-inclusion-of-multisets ”来查询效率太低吧，所以他增加了一个 id 来传参： http://stackoverflow.com/questions/42406362/how-to-check-for-inclusion-of-multisets ，这样做的好处是增加了查询效率，坏处就是把 URL 结构的依次归属关系打乱了，而且增加了目录层次，那么从 Google SEO 的角度，下面哪种 URL 设计最好喃？

1. http://stackoverflow.com/questions/42406362/how-to-check-for-inclusion-of-multisets
2. http://stackoverflow.com/questions/42406362-how-to-check-for-inclusion-of-multisets
3. http://stackoverflow.com/questions/how-to-check-for-inclusion-of-multisets-42406362
4. http://stackoverflow.com/questions/how-to-check-for-inclusion-of-multisets/42406362

如果上述方式都不好，怎样快速在 MySQL 中查询“ how-to-check-for-inclusion-of-multisets ”？

[b821025551b]

全文索引。

[id4alex]

从 SEO 的角度,肯定是 3 但是可行性太低,问题太多.

[Reign]

@b821025551b 全文索引感觉非常不合适

[rogerchen]

@b821025551b quora 就是不带 ID 的，就看技术实力了。
https://www.quora.com/Data/Where-can-I-find-large-datasets-open-to-the-public

[Reign]

@rogerchen 但万一问题重复了咋办？

[qiayue]

如果你纠结的话，选 2 ，平衡了技术难度和 URL 结构

[rogerchen]

@Reign
quora 运营来处理，我记得他们还发起了一个利用深度学习判断两个问题是不是重复的项目。
技术上来说直接不允许两个完全一样的题目被创建就好。

[INW017bzMfgkkYGn]

@Reign 那个是可以设置成人工指定的，参考 Typecho 博客撰写文章功能

[Reign]

@default 但对于数据条目多的就麻烦了

[sexoutsex2011]

参考亚马逊做法即可。
canonical 标签
<link rel="canonical" href="https://www.amazon.cn/%E7%94%B5%E8%84%91-it-%E5%8A%9E%E5%85%AC/dp/B01I88B8F6" />
含关键词。

但用户访问时 https://www.amazon.cn/dp/B01I88B8F6 即可。

[id4alex]

@rogerchen
我觉得两个社区性质有一些不一样. sf 注重的是这个问题怎么解决,相对而言是有所谓的正确答案,关闭后就没有继续回答的必要了. quora 和 zhihu 之类的更偏重在你对这个问题的看法是什么样的,并不是一定有正确答案,即使有高票答案之后你也可以来分享你的见解.

两个完全一样的题目怎么去处理的方法导致最后 url 结果也不尽相同.

[yjxjn]

我是这么设计的 https://jetyu.me/%E6%8A%80%E6%9C%AF/20170112.html

分类 /页面名.html

[enenaaa]

单纯只是给搜索引擎看的话， 我个人觉得 url 有没有文本不重要。 因为你的页面里肯定包含了这些内容。

[GoBeyond]

直接拿 title 查可能会拖慢查询速度吧

[moult]

查询的话，数据库可以存储一下 URL 中标题的 md5 或者 sha1 就行了。这样查询跟用 ID 查询没太大区别了吧。

[bianhua]

其实楼主你关于 StackOverflow 的猜测完全弄错了。你可以试试这个 URL ：

https://stackoverflow.com/questions/42406362/this-slug-is-existing-totally-just-because-we-want-to-make-seo-friendly-url
和你直接访问 https://stackoverflow.com/questions/42406362 的结果是一样的。

从系统设计的角度来说， URL 本身就应该是 questions/42406362 ，后面的 Slug 只是为了 SEO 而已。

[allenhu]

除非是自己的 cms ，不然总得带个 id

[allenhu]

@moult 搞得好像 md5 sha1 不是 string 一样

[binux]

@allenhu #18 md5, sha1 不是 string ，是 128bit / 160bit integer

[Reign]

@bianhua 对啊，我也是这个意思啊，就是不知道怎样安排这个 id 值