3

Running a Nibbler analysis on a static website I just built, I got the following feedback:

Avoid use of file extensions wherever possible. File extensions appear at the end of web addresses, and have several negative effects. They make the address harder to remember or type (particularly for non-technical users), and can reveal the underlying technology of the website making it very slightly more vulnerable to hackers. They also tie the implementation of the website to a specific technology, which can make subsequent migration of URLs difficult.

The above message is a result of having a flat directory structure and linking directly to the individual web pages (whatever.html). So is it really that much better to put every html file on a website in its own personal subdirectory (giving every webpage the file name index.html and relying on the directory name to identify the file) vs simply linking directly to the individual html files? I did some searching but didn't really find anything useful. This discussion had some info but didn't answer my question.

I'm curious to know what folks think of the two different approaches. Thanks.

Jim
  • 51
  • 3
  • 2
    /file-name/ is a directory. /file-name is a file. – Rob Sep 07 '21 at 09:42
  • 1
    This claim seems odd to me for most uses, as how often are URLs meant to be typed in and remembered? Normally all you care about is the URL to the site. Also, if you type a URL with a / at the end, it is generally treated as if the / wasn't there. Try adding a / to the end of this URL. No one cares if it's actually directory or a file. – trlkly Sep 07 '21 at 09:47
  • 3
    See also: Does it make a difference if your URL path ends in a trailing slash or not? – Stephen Ostermiller Sep 07 '21 at 09:48
  • That "feedback" doesn't really apply to .html files/URLs ("harder to remember or type" - perhaps, but debatable - see trlkly's comment above). (It would be more relevant to .php or .asp URLs etc. but even those can be worked around.) There was even a trend a few years ago to go back to using .html URLs. – MrWhite Sep 07 '21 at 13:01
  • 2
    @Rob "/file-name/ is a directory. /file-name is a file. " No, not necessarily. There is no 1-1 mapping from URL to filesystem. The whole underlying engine can be some sort of dynamic page generation, and path elements could merely reflect some routing, irrespective to what is on disk. – Patrick Mevzek Sep 07 '21 at 15:41
  • @PatrickMevzek The web is based originally on Unix and in Unix that's a directory. Whether one wants to follow proper architecture or not can be their choice. It's been too long since I bothered to follow the standards regarding this because I'm positive it is proper procedure so I can't comment more than this but it makes me want to look into it again. I will should I find the time today. – Rob Sep 07 '21 at 18:09
  • 2
    @Rob "The web is based originally on Unix and in Unix that's a directory. " You seem to forget, or put aside, that HTTP and URLs, by definition, is an abstraction that do not force anything really about how data is retrieved on the server, that is its own prerogative. See for example, also coming from Unix, the /~johndoe/ convention, and you could say that is a directory too, which is kind of true, except that the directory is not called itself ~johndoe but more probably /home/johndoe/, and this shows the abstraction/level of redirection (unrelated to HTTP redirections) – Patrick Mevzek Sep 07 '21 at 18:12
  • 1
    @trlkly The main domain will not show the closing slash in browsers for reasons I can't recall but browsers will treat it as if it were there. Whether a web site properly handles the closing slash as a directory is up to them but, to me, that is mishandling it if it doesn't refer to that directory's index file. Whether that is proper internet handling by standards, I can't recall at the moment but I intend to look into it again. – Rob Sep 07 '21 at 18:12
  • 1
    @PatrickMevzek Yes, I said I agree with the prerogative, but whether it is proper or a standard somewhere, I just can't recall at the moment and am under pressure to finish my sandwich and be somewhere. – Rob Sep 07 '21 at 18:14
  • @Rob "but whether it is proper or a standard somewhere, I just can't recall at the moment" I don't follow what there is even to check there. "Of course", especially at the beginning, when it is just a matter of offering access to files remotely, a 1:1 map between path elements in URL and directories in filesystem make sense and simplify life. Yet, see Apache Alias directive for example that shows that any filesystem path can appear under any URL. There is no 1:1 mapping, as there is no need to. – Patrick Mevzek Sep 07 '21 at 18:19
  • @PatrickMevzek You misunderstand me. It's not about 1:1 mapping. It's about what the slash means and the slash always means a directory and that directory or file can lie anywhere. – Rob Sep 07 '21 at 18:43
  • @Rob " It's about what the slash means and the slash always means a directory" No (for URLs). At best it means a hierarchy and it is defined as such in first URL specifications. A directory is one form of hierarchy, but not the only one. It is the distinction between an abstract idea (hierarchy) and a specific implementation of it (a directory in a filesystem). I will stop here now on this subject. – Patrick Mevzek Sep 07 '21 at 18:45

4 Answers4

8

You have several options for removing extensions. You don't have to create a directory for each file.

  • Use Apache's mod_negotiation with multiviews. You enable it with Options +multiviews in your .htaccess file. Then you can link to <a href="some-page"> and Apache will find some-page.html and serve it. Same goes for <img src="some-image"> for which Apache will automatically serve some-image.png, some-image.jpg, or some-image.gif if any of them exist.
  • You can save your files without a file extension. However that introduces other problems: Its difficult to configure your server to serve the correct content type for different files and it will make editing the files harder for you.
  • Use mod_rewrite to remove extensions from some files.
  • Use a front controller to serve your entire site from one script that does its own content mapping based on the URL. That is how most content management systems such as WordPress work.

Before you go and do any of that, I'd suggest that you read Jesper M's answer to the question that you linked. Having the extension match the mime type can be beneficial when somebody saves something from your site locally. If your page gets saved locally as some-page.html it will likely work correctly but if it gets saved as just some-page without an extension, the user may not be able to open the file. I'd recommend removing extensions from the URL that indicate what scripting language you are using (.php, .cgi, .asp, etc) but not necessarily removing extensions that indicate the file type (.html, .png, .jpg, etc.)

As far as SEO goes, it doesn't matter if you have file extensions or not. Google doesn't give much (if any) weight to what your URL looks like right now. I'd focus on how your URLs impact usability: descriptive, reasonably short, and maybe a file extension that matches the file type.

Stephen Ostermiller
  • 98,758
  • 18
  • 137
  • 361
  • " If your page gets saved locally as some-page.html it will likely work correctly but if it gets saved as just some-page without an extension," The browser can suggest adding an extension, based on content-type. This is separate from how the content was retrieved (which URL). – Patrick Mevzek Sep 07 '21 at 02:42
  • @PatrickMevzek from a practical standpoint modern browsers don't always add extensions. I use Firefox. If I use ctrl-s to save the current page, FF will add an extension. However if I right click on a link and choose to save that link, FF will not add an extension. – Stephen Ostermiller Sep 07 '21 at 09:43
4

A document that is not often read but should be:

https://www.w3.org/Provider/Style/URI.html "Cool URIs don't change"

To extract the parts relevant to your question:

So what should I do? Designing URIs

[..]

What to leave out

Everything! After the creation date, putting any information in the name is asking for trouble one way or another.

[..]

File name extension. This is a very common one. "cgi", even ".html" is something which will change. You may not be using HTML for that page in 20 years time, but you might want today's links to it to still be valid. The canonical way of making links to the W3C site doesn't use the extension.

In fact, the web is just an extension of an earlier practice started by brain-dead OS: having to put an extension to a filename to just denote its content. This is at best metadata and at worst can be inferred from the content. But as this existed it leaked to the web. If you are old enough, you know by that time that some people had to use index.htm instead of index.html because of other brain-dead OS limitations in filenames.

It may not be true anymore today, but some bad/old/non-conforming software might deduce actions to do based on the name, instead of honoring what is in content-type.

So then the question could be rephrased as:

Best form for URLs: file-name or /file-name/

And now it is 100% subjective. Or at least the answer is far too dependent on local circumstances that no external tool could take into account. For example, if you have various rules in your webserver regarding the path, the regular expressions can be simpler with /file-name/ (because there are clear delimiters) instead of just file-name.

Patrick Mevzek
  • 8,375
  • 1
  • 20
  • 42
3

"(file extensions) can reveal the underlying technology of the website making it very slightly more vulnerable to hackers" is humorous. It is trivial to find out the underlying technology with or without extensions.

Your idea " to put every html file on a website in its own personal subdirectory (giving every webpage the file name index.html and relying on the directory name to identify the file) vs simply linking directly to the individual html files?" will work but you are possibly creating a nightmare trying to maintain the site if it starts to get large, all those "index.html" files :o( Add to that, any rearranging of the site structure will be difficult. Plus links from one page to another are going to get complex. Don't do it, it isn't necessary.

I can see the advantage of not having a file extension e.g. .html or .php, that can be done via a .htaccess. There is a similar question here https://stackoverflow.com/questions/13540353/using-htaccess-to-remove-php-file-extension-from-url

Steve
  • 8,448
  • 23
  • 29
2

The suggestion is almost purely cosmetic; Google doesn't care. I guess if you decided to blaze your own trail and make all of your page extensions .jpg then you can deal with the fallout of such a silly decision.

Yes, file extensions can be considered ugly but maybe some people think they're beautiful. Think about when's the last time you had to manually type out a URL?

The benefits stem from a primarily server-side administration perspective.

Consider this URL: https://mashable.com/article/singapore-police-patrol-surveillance-robots

It's basically domain/page-type/unique-article-slug and this is likely consumed by an MVC architecture which is not dealing with a physical file but rather making a database call to retrieve the content.

If your website is static then it's basically a "meh" situation and you have to ask yourself whether you want to get on the extension-less bandwagon. This can be achieved purely through a single .htaccess rewrite (not redirect) directive.

If you have a bunch of dynamic user-generated content or are building an administrative interface then the allure of an MVC architecture or something more robust cannot be ignored.

MonkeyZeus
  • 281
  • 1
  • 6
  • Traditional server side content management systems and code frameworks for the web use the model-view-template (MVT) rather than the model-view-controller (MVC) model: https://www.geeksforgeeks.org/difference-between-mvc-and-mvt-design-patterns/ – Stephen Ostermiller Sep 07 '21 at 16:38
  • @StephenOstermiller django is the only MVT framework I've been able to find. Are there other examples? It's hard to consider one example to encompass "traditional CMS" options. What about MVP, MVA, or MVVM? Regardless, the distinction is hardly relevant given that the URL slug-ification is the meat-n-potatoes of my answer. The implementation details aren't really relevant. I'm just most familiar with MVC since it has withstood the test of time. – MonkeyZeus Sep 07 '21 at 16:56
  • 1
    Until recently there are very few true MVC frameworks for the web. Django is one of the few that acknowledges that fact. With the view on the client, a controller on the server has a hard time to updating that view. Some newer frameworks for the web are starting to MVC by moving the controller to the client in JavaScript or by using web sockets to push data from a controller on the server to the view on the client. – Stephen Ostermiller Sep 07 '21 at 17:27