何时应在 URL 中使用尾部斜杠？例如 - 我的 URL 应该类似于 /about-us/ 还是 /about-us？
我完全意识到与 SEO 相关的问题 - 重复内容和规范问题；我正在尝试找出应该在单独正确地提供页面的上下文中使用哪一个。
例如，我的同事认为末尾的斜杠意味着它是一个“文件夹” - 一个“目录”，所以这不是正确的样式。但我认为最后没有斜杠 - 它也不太正确，因为它几乎看起来像一个文件夹，但它不是，它也不是一个普通文件，而是一个没有扩展名的文件名。
有没有正确的方法知道使用哪个？
When should a trailing slash be used in a URL? For example - should my URL look like /about-us/ or like /about-us?
I am fully aware of the SEO-related issues - duplicate content and the canonical thing; I'm trying to figure out which one I should use in the context of serving pages correctly alone.
For example, my colleague is thinking that a trailing slash at the end means it's a "folder" - a "directory", so this is not a correct style. But I think that without a slash in the end - it's not quite correct either, because it almost looks like a folder, but it isn't and it's not a normal file either, but a filename without extension.
Is there a proper way of knowing which to use?
发布评论
评论（9）
这不是一个偏好问题。
/base和/base/具有不同的语义。在许多情况下，差异并不重要。但当存在相对 URL 时，这一点就很重要。/base/的child是/base/child。/base的child是（也许令人惊讶）/child。It is not a question of preference.
/baseand/base/have different semantics. In many cases, the difference is unimportant. But it is important when there are relative URLs.childrelative to/base/is/base/child.childrelative to/baseis (perhaps surprisingly)/child.在我个人看来，尾部斜杠被滥用了。
基本上，URL 格式来自相同的 UNIX 文件和文件夹格式，后来出现在 DOS 系统上，最后适应了 Web。
来源：维基百科：统一资源标识符
另一个值得阅读的好来源：维基百科：URI 方案
来源：维基百科统一资源定位器 (URL)
另外：
来源：Google 网站管理员中心博客 - 斜线或不斜线
最后：
URL 末尾的斜杠使地址看起来“漂亮”。
末尾没有斜杠且没有扩展名的 URL 看起来有些“奇怪”。
您永远不会命名您的 CSS 文件（例如）http://www.sample.com/stylesheet/ 你会吗？
但无论环境如何，我都是网络最佳实践的支持者。
它可能会很不稳定且不清楚，就像您所说的没有扩展名的 URL 一样。
In my personal opinion trailing slashes are misused.
Basically the URL format came from the same UNIX format of files and folders, later on, on DOS systems, and finally, adapted for the web.
Source: Wikipedia: Uniform Resource Identifier
Another good source to read: Wikipedia: URI Scheme
Source: Wikipedia Uniform Resource Locator (URL)
Also:
Source: Google WebMaster Central Blog - To slash or not to slash
Finally:
A slash at the end of the URL makes the address look "pretty".
A URL without a slash at the end and without an extension looks somewhat "weird".
You will never name your CSS file (for example) http://www.sample.com/stylesheet/ would you?
BUT I'm being a proponent of web best practices regardless of the environment.
It can be wonky and unclear, just as you said about the URL with no ext.
我总是对非目录 URL（WordPress 等）上广泛使用尾部斜杠感到惊讶。这确实不应该是一个非此即彼的争论，因为在资源后面加斜杠在语义上是错误的。 Web 旨在提供可寻址资源，而这些地址（URL）旨在模拟 *nix 风格的文件系统层次结构。在这种情况下：
使用这些准则，在非目录资源后面添加斜杠是错误的。
I'm always surprised by the extensive use of trailing slashes on non-directory URLs (WordPress among others). This really shouldn't be an either-or debate because putting a slash after a resource is semantically wrong. The web was designed to deliver addressable resources, and those addresses - URLs - were designed to emulate a *nix-style file-system hierarchy. In that context:
Using these guidelines, it's wrong to put a slash after a non-directory resource.
这并不是真正的美学问题，而是技术上的差异。目录的想法是完全正确的，并且几乎解释了一切。让我们来解决一下：
您现在回到了石器时代，或者只提供静态页面
您的 Web 服务器上有固定的目录结构，只有静态文件，如图像、html 等 - 没有服务器端脚本或任何内容。
浏览器请求
/index.htm，它存在并被传递到客户端。稍后，您会在/dvd/目录中查看大量（比方说）DVD 电影以及每个电影的 html 页面。现在有人请求/dvd/adams_apples.htm并且它已被交付，因为它就在那里。有一天，有人只是请求
/dvd/- 这是一个目录，服务器会尝试找出要传送的内容。除了访问限制等之外，还有两种可能性：向用户显示目录内容（我打赌您已经在某处看到过这个）或显示默认文件（在 Apache 中是：DirectoryIndex：设置 Apache 将提供服务的文件如果请求一个目录。)到目前为止一切顺利，这是预期的情况。它已经显示了处理方面的差异，所以让我们开始讨论它：
在凌晨 5:34 你做了一个上传文件时出错
（这是由方式完全可以理解。）因此，您做了一些完全错误的事情，您没有上传
/dvd/the_big_lebowski.htm，而是将该文件作为dvd（无扩展名）上传到/。有人为您的
/dvd/目录列表添加了书签（当然您不想创建并始终更新那个漂亮的index.htm）并正在访问您的网站。目录内容已交付 - 一切都很好。有人听说了您的列表并正在输入
/dvd。现在它被搞砸了。服务器找到具有该名称的文件并传送您的 Big Lebowski 文件，而不是列出您的 DVD 目录。因此，您删除该文件并告诉该人重新加载页面。您的服务器查找
/dvd文件，但它已经消失了。然后，大多数服务器会注意到有一个具有该名称的目录，并告诉客户端它正在寻找的内容确实在其他地方。响应很可能是：状态代码：301 永久移动，位置：http://[...]/dvd/因此，完全忽略 >你考虑目录或文件，服务器只能处理这些东西，并且 - 除非另有说明 - 为你决定“斜线与否”的含义。
最后，在收到此响应后，客户端加载
/dvd/并且一切正常。还好吗？不。
“刚刚好”对您来说还不够好
您有一些动态页面，其中所有内容都传递到
/index.php并得到处理。到目前为止，一切都进展顺利，但整个事情开始变得缓慢，你开始调查。很快，您就会注意到
/dvd/list正在执行完全相同的操作：重定向到/dvd/list/，然后在内部翻译为index.php ?controller=dvd&action=list。一个额外的要求 - 但更糟糕的是！customer/login重定向到customer/login/，后者又重定向到customer/login/的 HTTPS URL。您最终会遇到大量不必要的 HTTP 重定向（= 额外请求），从而使用户体验变慢。您很可能在这里也有一个默认目录索引：没有
action的index.php?controller=dvd只是在内部加载index.php?controller=dvd&动作=列表。摘要：
如果它以
/结尾，则它永远不可能是一个文件。没有服务器猜测。斜线或无斜线是完全不同的含义。“斜线或无斜线”之间存在技术/资源差异，您应该意识到这一点并相应地使用它。只是因为服务器很可能加载
/dvd/index.htm- 或加载正确的脚本内容 - 当你说/dvd时：它会这样做，但不是因为你做了正确的要求。应该是/dvd/。省略斜线，即使您确实意味着斜线版本会给您带来额外的 HTTP 请求惩罚。这总是不好的（考虑移动延迟）并且更重要比“漂亮的网址” - 特别是因为爬虫并不像 SEO 认为或希望您相信的那样愚蠢；）
That's not really a question of aesthetics, but indeed a technical difference. The directory thinking of it is totally correct and pretty much explaining everything. Let's work it out:
You are back in the stone age now or only serve static pages
You have a fixed directory structure on your web server and only static files like images, html and so on — no server side scripts or whatsoever.
A browser requests
/index.htm, it exists and is delivered to the client. Later you have lots of - let's say - DVD movies reviewed and a html page for each of them in the/dvd/directory. Now someone requests/dvd/adams_apples.htmand it is delivered because it is there.At some day, someone just requests
/dvd/- which is a directory and the server is trying to figure out what to deliver. Besides access restrictions and so on there are two possibilities: Show the user the directory content (I bet you already have seen this somewhere) or show a default file (in Apache it is:DirectoryIndex: sets the file that Apache will serve if a directory is requested.)So far so good, this is the expected case. It already shows the difference in handling, so let's get into it:
At 5:34am you made a mistake uploading your files
(Which is by the way completely understandable.) So, you did something entirely wrong and instead of uploading
/dvd/the_big_lebowski.htmyou uploaded that file asdvd(with no extension) to/.Someone bookmarked your
/dvd/directory listing (of course you didn't want to create and always update that niftyindex.htm) and is visiting your web-site. Directory content is delivered - all fine.Someone heard of your list and is typing
/dvd. And now it is screwed. Instead of your DVD directory listing the server finds a file with that name and is delivering your Big Lebowski file.So, you delete that file and tell the guy to reload the page. Your server looks for the
/dvdfile, but it is gone. Most servers will then notice that there is a directory with that name and tell the client that what it was looking for is indeed somewhere else. The response will most likely be be:Status Code:301 Moved PermanentlywithLocation: http://[...]/dvd/So, totally ignoring what you think about directories or files, the server only can handle such stuff and - unless told differently - decides for you about the meaning of "slash or not".
Finally after receiving this response, the client loads
/dvd/and everything is fine.Is it fine? No.
"Just fine" is not good enough for you
You have some dynamic page where everything is passed to
/index.phpand gets processed. Everything worked quite good until now, but that entire thing starts to feel slower and you investigate.Soon, you'll notice that
/dvd/listis doing exactly the same: Redirecting to/dvd/list/which is then internally translated intoindex.php?controller=dvd&action=list. One additional request - but even worse!customer/loginredirects tocustomer/login/which in turn redirects to the HTTPS URL ofcustomer/login/. You end up having tons of unnecessary HTTP redirects (= additional requests) that make the user experience slower.Most likely you have a default directory index here, too:
index.php?controller=dvdwith noactionsimply internally loadsindex.php?controller=dvd&action=list.Summary:
If it ends with
/it can never be a file. No server guessing.Slash or no slash are entirely different meanings. There is a technical/resource difference between "slash or no slash", and you should be aware of it and use it accordingly. Just because the server most likely loads
/dvd/index.htm- or loads the correct script stuff - when you say/dvd: It does it, but not because you made the right request. Which would have been/dvd/.Omitting the slash even if you indeed mean the slashed version gives you an additional HTTP request penalty. Which is always bad (think of mobile latency) and has more weight than a "pretty URL" - especially since crawlers are not as dumb as SEOs believe or want you to believe ;)
当您创建 URL
/about-us/（带有尾部斜杠）时，可以轻松地从单个文件index.html开始，然后扩展它并添加更多内容文件（例如our-CEO-john-doe.jpg），甚至在其下构建层次结构（例如/about-us/company/、/about- us/products/等）根据需要， 无需更改已发布的 URL。这为您提供了很大的灵活性。When you make your URL
/about-us/(with the trailing slash), it's easy to start with a single fileindex.htmland then later expand it and add more files (e.g.our-CEO-john-doe.jpg) or even build a hierarchy under it (e.g./about-us/company/,/about-us/products/, etc.) as needed, without changing the published URL. This gives you a great flexibility.这里的其他答案似乎倾向于省略尾部斜杠。在一种情况下，尾部斜杠有助于搜索引擎优化 (SEO)。在这种情况下，您的文档的文件扩展名似乎不是
.html。这成为对网站进行评级的网站的一个问题。他们可能会在以下两个网址之间进行选择：http://mysite.example.com/erated.example.comhttp://mysite.example.com/erated.example.com/< /code>在这种情况下，我会选择尾部带有斜杠的。这是因为
.com扩展名是 Windows 可执行命令文件的扩展名。搜索引擎和病毒检查程序通常不喜欢看起来可能包含通过此类机制分发的恶意软件的 URL。结尾的斜杠似乎减轻了任何担忧，允许页面在搜索引擎中排名并通过病毒检查程序。如果您的 URL 的文件部分没有
.，那么为了简单起见，我建议省略尾部斜杠。Other answers here seem to favor omitting the trailing slash. There is one case in which a trailing slash will help with search engine optimization (SEO). That is the case that your document has what appears to be a file extension that is not
.html. This becomes an issue with sites that are rating websites. They might choose between these two urls:http://mysite.example.com/rated.example.comhttp://mysite.example.com/rated.example.com/In such a case, I would choose the one with the trailing slash. That is because the
.comextension is an extension for Windows executable command files. Search engines and virus checkers often dislike URLs that appear that they may contain malware distributed through such mechanisms. The trailing slash seems to mitigate any concerns, allowing the page to rank in search engines and get by virus checkers.If your URLs have no
.in the file portion, then I would recommend omitting the trailing slash for simplicity.谁说文件名需要扩展名？找个时间看看 *nix 机器...
我同意你朋友的观点，没有尾部斜杠。
Who says a file name needs an extension?? take a look on a *nix machine sometime...
I agree with your friend, no trailing slash.
尾部斜杠对于您的根域或子域并不重要。谷歌认为两者是等同的。
但尾随斜杠对于其他一切确实很重要，因为 Google 认为这两个版本（一种带有尾随斜杠，一种没有）是不同的 URL。
按照惯例，URL 末尾的尾部斜杠 (/) 表示该 URL 是文件夹或目录。
末尾没有斜杠的 URL 过去常常表示该 URL 是一个文件。
了解详情
Google 推荐
The trailing slash does not matter for your root domain or subdomain. Google sees the two as equivalent.
But trailing slashes do matter for everything else because Google sees the two versions (one with a trailing slash and one without) as being different URLs.
Conventionally, a trailing slash (/) at the end of a URL meant that the URL was a folder or directory.
A URL without a trailing slash at the end used to mean that the URL was a file.
Read more
Google recommendation
从 SEO 的角度来看，选择是否在 URL 末尾包含尾部斜杠是无关紧要的。如今，在网络上经常可以看到这两种情况的示例。无论哪种方式，网站都不会受到惩罚，这种选择也不会影响您网站的搜索引擎排名或其他 SEO 考虑因素。
只需选择您喜欢的 URL 命名约定，并在每个网页的
部分中包含规范元标记即可。当搜索引擎遇到带或不带尾部斜杠的单个网页时，可能会将单个网页视为两个单独的重复 URL，即
example.com/about-us/和example.com/about-us。最佳做法是在每个页面上包含规范元标记，因为您无法控制其他网站链接到您的 URL 的方式。
规范标签如下所示：
。使用规范元标记可确保搜索引擎仅对您的每个 URL 计数一次，无论其他网站在链接到您的网站时是否包含尾部斜杠。From an SEO perspective, choosing whether or not to include a trailing slash at the end of a URL is irrelevant. These days, it is common to see examples of both on the web. A site will not be penalized either way, nor will this choice affect your website's search engine ranking or other SEO considerations.
Just choose a URL naming convention you prefer, and include a canonical meta tag in the
<head>section of each webpage.Search engines may consider a single webpage as two separate duplicate URLS when they encounter it with and without the trailing slash, ie
example.com/about-us/andexample.com/about-us.It is best practice to include a canonical meta tag on each page because you cannot control how other sites link to your URLs.
The canonical tag looks like this:
<link rel="canonical" href="https://example.com/about-us" />. Using a canonical meta tag ensures that search engines only count each of your URLs once, regardless of whether other websites include a trailing slash when they link to your site.