When should I use a trailing slash in my URL?

Question

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?

Liscomb

Same question on Pro Webmasters: Does it make a difference if your URL path ends in a trailing slash or not? – Whiteness

This question is posed as one of preference, and thus would seem to be off topic as primarily opinion-based. However, as my answer shows, in fact posing this question as a matter of preference is a mistake: this is an XY problem, and the underlying "real" question has a precise technical answer, and thus is not primarily opinion based. – Bryna

Questions about what types of URLs Google likes are not programming related (as mentioned in tag wiki) and are off-topic for Stackoverflow. – Phototherapy

Here are some views specific to REST: stackoverflow.com/a/2022938, softwareengineering.stackexchange.com/a/187006, and this table on wikipedia – Wards

Answer 1

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.

A typical URL for this book on a Unix-like operating system would be a file path such as file:///home/username/RomeoAndJuliet.pdf, identifying the electronic book saved in a file on a local hard disk.

Source: Wikipedia: Uniform Resource Identifier

Another good source to read: Wikipedia: URI Scheme

According to RFC 1738, which defined URLs in 1994, when resources contain references to other resources, they can use relative links to define the location of the second resource as if to say, "in the same place as this one except with the following relative path". It went on to say that such relative URLs are dependent on the original URL containing a hierarchical structure against which the relative link is based, and that the ftp, http, and file URL schemes are examples of some that can be considered hierarchical, with the components of the hierarchy being separated by "/".

Source: Wikipedia Uniform Resource Locator (URL)

Also:

That is the question we hear often. Onward to the answers! Historically, it’s common for URLs with a trailing slash to indicate a directory, and those without a trailing slash to denote a file:

http://example.com/foo/ (with trailing slash, conventionally a directory)

http://example.com/foo (without trailing slash, conventionally a file)

Source: Google WebMaster Central Blog - To slash or not to slash

Finally:

1. A slash at the end of the URL makes the address look "pretty".

2. A URL without a slash at the end and without an extension looks somewhat "weird".

3. 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.

Check

great answer: here is an answer form a pure SEO perspective: #3889497 – Precarious

This is weird, you can not name a file "stylesheet/" - and slash or no slash are entirely different resources on the server, no matter how the URL looks – Scales

@nicogawenda, .htaccess can do all sorts of magic ;) your CSS might actually be a php file! – Dysgenics

Web servers are often set up by default to serve index.html (or similarly named file) when a directory is accessed, so /foo/ is /foo/index.html without the extra mess. Also, in the past, browsers would append / to the domain name, but they (Firefox, Chrome, Opera) have since changed to omit the / when accessing the homepage. – Horst

I agree with @bfrohs. Surely default pages for directories contravene this principle. If we are to enforce 'trailing slash = directory', then surely all urls which point at a directory must either return a directory listing or a 403 forbidden http response. – Solidify

I'm not sure if points #1 and 2 in the "Finally" section are still accurate. Over the years since this was originally written, tastes have changed. I haven't studied this in detail, but it seems that on newer websites, it's more common and "prettier" to omit the slash. – Ectropion

@Ectropion - The rules still apply. The opinion "which is nicer" is still an issue (beauty is in the eye of the beholder) – Check

What I found important under the GoogleBlog link is that "Rest assured that for your root URL specifically, example.com is equivalent to example.com and can’t be redirected even if you’re Chuck Norris." Meaning the host and path separator slash is something different than slashes in path. – Subir

URLs with slash look pretty? I think it's quite the opposite, I prefer no slash by far. It's cleaner and elegant. – Sparke

Nice research work in this answer. It is pity that the final conclusion is purely subjective. – Valuate

Main issue is most of the sites pages these days are using directory structure that is without any extension as .html, .php etc. This creates a duplicate page issue, therefore it is recommended to use any with or without trailing slashes, with looks more pretty and clear that this is end page. Also, it is good practice to set rule to 301 redirect non trailing slashes one to preferred and vice versa. – Billybillycock

Answer 2

It is not a question of preference. /base and /base/ have different semantics. In many cases, the difference is unimportant. But it is important when there are relative URLs.

• child relative to /base/ is /base/child.
• child relative to /base is (perhaps surprisingly) /child.

Bryna

Helpful article that goes into some depth on this: cdivilly.wordpress.com/2014/03/11/… – Synoptic

Yes, I think this, along with SEO, are the most important things to this question. – Lait

Just went through this problem when using .Net's Uri.MakeRelativeUri. Results reflect exactly what you said. I fixed the issue by adding the trailing slash to my base Uri. – Krissie

No trailing slash is helpful for working with relative sub-paths AND also trailing slash is improper when the url denotes a resource. So it's better in both cases and thus is the best practice. – Melosa

@JacekJ All URLs represent resourses; that is what the R of URL stands for. – Bryna

@Bryna true. I referred to situations when, for example, you define a (so called) base url in the code as https://example.com/api. Then, without child /resource, it is not a real resource (as you pointed, it's not even a url - it's a url base). So I tried to say, that also in such cases it's better to define url base as https://example.com/api than https://example.com/api/. – Melosa

@JacekJ You have several misunderstandings. A base URL is still a URL. You are insisting on a distinction that is simply not true. – Bryna

Answer 3

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:

• Slashes always denote directories, never files.
• Files may be named anything (with or without extensions), but cannot contain or end with slashes.

Using these guidelines, it's wrong to put a slash after a non-directory resource.

Panacea

"slashes after directories, not after resources": URLs do not refer to two types of things, "resources" and "directories"; they refer to one kind of thing: resources. The clue is in the R of URL. – Bryna

And everything in a *nix file system is a file, but directories still exist. What's your point? – Panacea

Whether it's served by a file or a directory internally, what the user sees is just a web page. And example.com/about could actually be reading from example.com/about/index.html. – Annettannetta

@Annettannetta - Yes, but in your example URL, 'about' clearly resolves as a directory. (Otherwise, it could not contain 'index.html'.) When I make a similar request to my IIS 7.5 server for http://hostname/directory, I get: 301 Moved Permanently and Location: http://hostname/directory/. – Clary

@DavidRR: You're right. And the browser needs the redirect because the name resolution has to happen from inside directory (otherwise, image.png in http://hostname/directory would point to http://hostname/image.png). I was just saying that the distinction between a file and a directory may not be very important from the user's point of view. – Annettannetta

I agree with your result, but I'm not sure we should be designing our URL system to emulate *nix-style file systems. That may have originally served a purpose, but now much less so. – Ectropion

But the actual source that's being served is index.php, generated by wordpress dynamically. By configuration, servers generally serve up these files by default, if they exist in a directory: index.php, index.html, and index.htm, otherwise either a directory listing, or a 404 page is served. So one could argue that myblog.com/todayspost/ is serving up a dynamically generated index.php file from a "virtual" or dynamically generated "todayspost" directory. So an argument can be made that the resource referenced is a directory, hence needs a /, file name is inferred. But Really: Just Pick One – Dispensation

php files do not get served to the client. They are evaluated and the result is sent to the client. Big difference. – Bloodred

Answer 4

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.htm and 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.htm you uploaded that file as dvd (with no extension) to /.

Someone bookmarked your /dvd/ directory listing (of course you didn't want to create and always update that nifty index.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 /dvd file, 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 Permanently with Location: 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.php and 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/list is doing exactly the same: Redirecting to /dvd/list/ which is then internally translated into index.php?controller=dvd&action=list. One additional request - but even worse! customer/login redirects to customer/login/ which in turn redirects to the HTTPS URL of customer/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=dvd with no action simply internally loads index.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 ;)

Scales

So in a summary are you all for adding the slash at the end ? :) – Liscomb

I'm all for using it when you mean it;) For example speaking of controllers and actions it would be: Controllers should end with slash. When you reference a file or an action omit the slash – Scales

Hold on, why would you omit the slash for an action? As per your example, isn't that going to result in the extra redirected request? I mean, presumably your server is smart enough to recognise a controller action and won't actually redirect to look for files or directories in that case, but it still goes against your example doesn't it? – Tithonus

I don't understand your example. What filesystem allows a directory and another regular file with the same name (dvd)? – Annettannetta

@Annettannetta I'm pretty sure AWS S3 does this. aws s3 cp local.txt s3://my-bucket/my-folder/ copies local.txt into "my-folder" (i.e. s3://my-bucket/my-folder/local.txt). aws s3 cp local.txt s3://my-bucket/my-folder copies local.txt to an object called "my-folder" (i.e. s3://my-bucket/my-folder) – Wolfenbarger

Servers are not required to be that naive any more. Just let Nginx forward all requests to your backend software and let it gracefully handle the rest. – Bloodred

Answer 5

When you make your URL /about-us/ (with the trailing slash), it's easy to start with a single file index.html and 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.

Annettannetta

I'm sorry I didn't get it . if I start with /about-us or /about-us/ I still need to change the published URL in both cases if I expanded the directory. the new file will be /about-us/new-file.html in both cases !! what am I missing here? – Condyle

@Accountant I think OP may be thinking that if you publish "/about-us" without a trailing slash then you can't later add sub-resources using relative paths. When you don't have the trailing slash the browser will believe a reference to "ceo.jpg" on the about page will live at the root of your domain and will request example.com/ceo.jpg. With the slash, the browser will request example.com/about-us/ceo.jpg and you can statically route a whole tree of folders for your site as you expand. – Hung

FYI - I don't believe any of the above is true - Why can't there be an /about-us and /about-us/company? In terms of serving the files, both Apache and IIS can handle this just fine, so I disagree. – Coracorabel

@Coracorabel Yes, but if, from /about-us you wanna link to /about-us/company, you have to use href="/about-us/company" or href="./company" (not sure about that one, though). If you are on /about-us/, though, it's simple: href="company". – Haase

Answer 6

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.com
• http://mysite.example.com/rated.example.com/

In such a case, I would choose the one with the trailing slash. That is because the .com extension 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.

Whiteness

No real search engines are that stupid. This answer is pure speculation. – Schnell

I've actually seen this issue with Google. That was several years ago, so I'm not sure if that would still be the case today. – Whiteness

Huh, that's a good data point. Though we still don't know if it was caused by something else. – Schnell

What do you mean by ".com extension is an extension for Windows executable command files"? And "distributed through such mechanisms" – Squash

Wikipedia has a ton of information about Windows com files: en.wikipedia.org/wiki/COM_file The "Execution preference" and "Malicious usage of the .com extension" sections says how they are used by computer viruses and other malware. – Whiteness

Answer 7

Who says a file name needs an extension?? take a look on a *nix machine sometime...
I agree with your friend, no trailing slash.

Cult

Answer 8

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/ and example.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.

Groundmass

Answer 9

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

Pomeroy