为什么有些网站在网址末尾添加“ Slug”？[关闭]

111

许多网站（包括该网站）在URL的末尾添加了明显的slug（描述性的，但据我所知，这些文本无用的地方）。

例如，网站为该问题提供的URL是：

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

但是以下URL也可以正常工作：

/programming/47427/

本文的目的仅在于使URL更加用户友好，还是有其他好处？

url  seo  friendly-url  slug 
— 戴夫·韦伯
source
44
子段充当URL的呼叫方ID名称。接到电话时，不必知道此人的名字，但这可以帮助您确定是否要接听电话。同样，URL段可以帮助用户确定是否要单击链接并为其提供一些固有的上下文。
— 阿姆斯特朗（Armstrongest）2010年
4
^^ +1，但它会得到更好的看到您的回复作为答案，而不是评论..
— Dienekes
帮助搜索引擎结果排名。
— 杰伊·
stackoverflow.com/q/47427也可以使用：P
— Habeeb Perwad '16

Answers:

166

这些标签使URL更加用户友好，并且您知道单击链接时的期望。如果搜索词在URL中，则Google等搜索引擎会将页面排名更高。

— 埃斯波
source
3
使网址易于使用的原因之一是“发现能力”，这意味着您可以简单地从地址栏中猜测网址。i.love.pets.com/search/cats+do​​gs很容易导致i.love.pets.com/search/pug+puppies等
— 西安
12
西安，我以前听过这种说法，但我认为它经不起审查。除了极客之外，几乎没有人真正真正地直接键入URL。可读性绝对重要，并且我认为越来越多的用户可以看到 URL，但是当涉及到“猜测”时，我认为少数人很少。
— 眼睑失明
4
@eyelidlessnes-我将不同意。尽管人们可能不会手动输入URL，但我看到了他们创建URL的证据。通过查看日志和监视设备，我们看到了一个用户会话将在其中执行某些操作然后修改URL的示例（由缺少引荐来源证明）。当然，并不是每个人都在这样做-但这绝对不是一笔微不足道的流量。
— 约瑟夫·费里斯
@西安 是的，URLS类型很少，但是，该段实际上是呼叫者ID。呼叫者的姓名不是必需的，但可以帮助您确定是否要接听电话。插件使URL看起来更友好，并使用户更有可能单击它。
— 阿姆斯特朗（Armstrongest）2010年
西安，那到底与google.com/search有什么不同？q = cat + puppy？发现URL的人可能会这样做。我做到了
— netrox
39

可用性是原因之一，如果您在电子邮件中收到该链接，则知道会发生什么。SEO（搜索引擎优化）是另一个原因。诸如google之类的搜索引擎会针对url中包含的关键字将您的页面排名更高

— 米歇尔·范·奥斯特豪特（Michiel van Oosterhout）
source
2
您为什么认为Google做出了这个决定？是什么动机呢？
— Mike Clark 2010年
您能从Google找到任何专门说明如果关键字包含在url中的文档，它们的排名会更高的文档吗？
— 连锁店2011年
@chainwork否，但是搜索引擎用来对页面进行排名的信号有数百种，您可以确定URL就是这样的信号。
— Michiel van Oosterhout 2012年
2
网址中与搜索匹配的关键字在Google搜索结果中以粗体显示，从而使它们在进行搜索的用户中更突出。
— 链
35

我最近从以下位置更改了我的网站网址格式：

www.mywebsite.com/index.asp?view=display&postid=100

至

www.mywebsite.com/this-is-the-title-of-the-post

并且注意到更改后，文章的点击率提高了约300％。从搜索引擎优化的目的来看，它当然可以帮助用户确定他们所考虑的单击内容是否相关，尽管我不得不说，更改后影响不大

— 凯蒂
source
4
我希望您的帖子标题永远不会改变：很多人讨厌死链接和产生它们的网络服务。
— Nikita Rybak 2010年
6
我无法真正猜出他正在使用哪种CMS或博客软件，但是对于WordPress和许多类似的软件，在帖子上线后修改帖子标题并不会改变代码（这正是您提到的原因）。
— Cyde Weys'2
25

我同意其他回应，即任何类型错误的子弹都应301-重定向到正确的格式。换句话说，/programming/47427/wh应重定向到/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls。它还有另一个未提及的好处-如果您不执行重定向到规范URL的操作，则将显示几乎无限数量的重复页面。Google讨厌重复的内容。

就是说，您实际上应该只关心内容ID，并在重定向时允许任何输入。为什么？

/programming/47427/why-do-some-网站将标签添加到网址的末尾

糟糕，邮件软件切断了URL的结尾！没问题，因为您仍然可以滚动/programming/47427

这种方法的一个大问题是，如果您从内容的标题中得出信息，那么您将如何处理非ASCII，UTF-8标题？

— 科里·金
source
1
帖子不错，很有效！+1关于您的问题，“您将如何处理非ASCII UTF8标题？” 为此有一些算法，例如WordPress使用的一种算法。如果允许超过600个字符，我将针对此确切问题发布PHP解决方案。如果您真的想知道，请将其发布为问题，我将很乐意回答;）
— Mathias Bynens 2009年
1
回复：“几乎无限数量的重复页面”-仅在存在指向非佳能URL的链接时才会发生。如果您在网站内保持一致，就不会有问题。您关于切断URL的理论有点愚蠢，可以在任何地方切断URL，对吗？即使在4742之后，这也会导致一个不同的问题。只要您仅坚持不太可能发生的URL中的标准字母，数字，破折号和/或下划线即可。
— DisgruntledGoat，2009年
2
正如DisgruntledGoat所建议的那样，除非有人用不同的标签链接到页面，否则Google从技术上讲不会找到任何重复的内容，因此欺骗了Google的蜘蛛，使之认为存在重复的内容。所以蜘蛛会讨厌这个页面，走的是家伙；）
— Austyn Mahoney 2010年
从技术上讲，如果在页面中嵌入rel =“ canonical”提示，则无需执行301重定向。不管“重复页面近乎无限数量”，google都将采用唯一有效的规范URL。亚马逊没有执行301。请尝试：amazon.com/lat-thinking-stragies/dp/0470942185 但是，最好同时执行这两种操作。原因是有人可以发布带有完全修改的内容的链接，当查看者阅读该链接时，它看起来与内容有所不同，这会混淆查看者。
— 伊桑（Ethan）2012年
“您将如何处理非ASCII UTF8标题？” 您对它们进行百分比编码。然后，所有现代浏览器实际上都会在地址栏中以多语言形式显示Unicode，但是当您将其复制到剪贴板时，会为您提供ASCII百分比编码的URL。
— Stijn de Witt
14

大多数网站使用它的原因可能是SEO（搜索引擎优化）。雅虎过去曾对URL本身中搜索关键字的存在给予合理的权重，这也有助于提高Google的搜索结果。

最近，搜索引擎降低了URL中关键字的权重，这很可能是因为该技术现在在垃圾邮件站点上比合法的更为普遍。现在，URL中的关键字对搜索结果的影响很小，甚至根本没有影响。

至于stackoverflow本身，SEO可能是一种动机（旧习惯很难解决）或仅仅是出于可用性。

— 绅士
source
SEO是一个因素。但更重要的是，它与可用性有关，就像您说的那样。
— 阿姆斯特朗（Armstrongest）2010年
14

基本上，这是资源的更有意义的位置。使用ID是完全有效的，但它对机器的意义远非对人的意义。

严格说来，如果段是唯一的，则不需要ID，您可以通过在日期中确定范围来更轻松地确保段。

即：

/2008/sept/06/why-some-websites-add-slugs-end-of-urls/

基本上，这利用了在同一天使用两个相同的弹药的低可能性。如果发生冲突，通常的约定是在子弹末尾添加一个计数器，但是很少见到这些：

/2008/sept/06/why-some-websites-add-slugs-end-of-urls/
/2008/sept/06/why-some-websites-add-slugs-end-of-urls-1/
/2008/sept/06/why-some-websites-add-slugs-end-of-urls-2/

许多of算法也摆脱了诸如“ the”和“ a”之类的常用词，以帮助保持URL简短。这种限定范围的方法还使查找给定日期，月份或年份的所有资源变得非常简单-您只需砍掉细分即可。

另外，stackoverflow URL在引入一个附加段以体现该特性方面是不好的，这违反了每个段都应代表资源层次结构递减的想法。

— 安德鲁·英格拉姆
source
11

弹头一词来自报纸/出版业。这是一个简短的标题，用于标识正在进行的故事。对URL语义感兴趣的人开始在URL中使用简短的标题。由于URL中的关键字增加了页面的重要性，因此在SEO领域也有回报。

具有讽刺意味的是，出于严格的SEO目的，许多网站已开始在其URL中放置带有连字符的标题的完整序列化版本，这意味着“塞子”一词不再完全适用。这也激怒了语义纯粹主义者，因为许多实现只是在其URL末尾附加了标题的序列化版本。

— 艾伦·斯托姆
source
10

我注意到您可以自由更改文本。此URL似乎也可以正常工作。

/programming/47427/why-is-billpg-so-very-awesome

— Billpg
source
这是错误还是功能？
— JakubŠturc08年
4
实际上，它可以确保即使主题已被修改（因此有一个新的URL），您也可以访问帖子。
— Dirk Vollmar 09年
3
不过，理想情况下，每个Internet资源（“文档”）都只有1个URI。因此，基本上，允许通过不同的URI查看同一文档可能会对SERP中的站点产生负面影响。这可能是我不喜欢堆栈溢出的唯一原因；）
— Mathias Bynens
3
这就是为什么存在规范页面，而Stack Overflow使用它们的原因。=）
— Alix Axel，2009年
4
@Alix Axel：301重定向>规范页面
— Mathias Bynens 2010年
6

如前所述，“子弹”可以帮助人们和搜索引擎...

值得注意的是，页面源中有一个规范的网址

这将阻止页面多次被索引。

例：

<link rel="canonical" href="http://stackoverflow.com/questions/47427/why-do-some-websites-add-slugs-to-the-end-of-urls">
— 罗布斯
source
3

发送链接时不要忘了可读性，而不仅仅是在搜索引擎中。如果您通过电子邮件将第一个链接发送给某人，他们可以查看该URL并大致了解其含义。第二个页面在单击之前不会显示该页面的内容。

— 克里斯·巴托
source
2

如果您通过电子邮件向某人发送了链接，那么通过实际写一个描述而不是让其他人解析存在该描述的URL并尝试阅读一些链接来包含描述就没有多大意义了。连字词卡在一起。

— 基比
source
您显然从未去过Rick Roll'd，对吧。您收到多少个链接：请检查一下。搞笑！<link>。如果Youtube这样做Urls，那就太好了：youtube.com/12345/evil-bikini-wax-job-not-work-safe。这将使链接更值得信赖，并帮助我做出是否单击的决定。
— 阿姆斯特朗（Armstrongest）2010年
1
但是，我见过的任何MVC系统都不需要多余的邪恶比基尼比基尼蜡工作而不是工作安全的部分，并且可以像youtube.com/12345一样容易地发送，大多数人想要寄出类似内容的人很快就会学会将其删除。
— Kibbee
2

首先，它是SEO且对用户友好，但是在示例（本网站）中，它做得不好或不正确（因为它容易受到黑帽技巧和其他人的毒害，这在该网站上可能会很不好地反映出来） 。

如果

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

有内容，然后

/programming/47427/

和

/programming/47427/any-other-bollix

不应重复。他们实际上应该自动检测到未使用当前文本的链接（显然，该子句是由问题标题定义的，以后可以进行编辑），并且应该自动将301重定向到

/programming/47427/why-do-some-websites-add-slugs-to-the-end-of-urls

从而确保“一条内容到一个URI”规则，并且如果URI移动/更改，请确保旧书签通过301重定向跟随/移动（智能浏览器可以更新书签）。

— 艾伦·多赫蒂
source
1
查看页面源代码，你会发现这样的：<链接的rel =“规范” HREF =“ stackoverflow.com/questions/47427/... ”>请参见：这里：googlewebmastercentral.blogspot.com/2009/02/...
— Armstrongest
0

理想情况下，“子弹”应该是所需的唯一标识符。实际上，在诸如此类的动态站点上，您要么必须具有唯一的数字标识符，要么像Digg一样开始将数字附加/递增到“子段”。

— 凯尔·克罗宁（Kyle Cronin）
source
1
Digg链接是我浏览主页时遇到的第一个链接。纯粹是巧合，它也恰好说明了Digg的堕落程度-关于性成瘾的故事已经发表了3次。
— 凯尔·克罗宁
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.