I've used both index.html and default.html in the past for home pages on sites I've built. These days I mostly use index.html, but I'm not sure why... consistency I suppose.
I'm pretty sure IIS handle them the same, but I am wondering, though, if there's any benefit or pitfall in using one over the other, or are they treated the same in all respects?
Thanks!
index is traditional, and more servers are configured to look for it than for default.
It is recommended to stick with either index.html or index.htm in most cases, default.html is generally used on a windows environment, i.e IIS, so you may come unstuck if you moved to Apache. Saying that you could get around this issue using a .htaccess file for Apache to use default.html as the default file location.
In IIS you can set the file(s) to look for when the url points to a folder.
You can specify multiple files. And they are tried in order to see if they exist.
If your site is under heavy load, and you have a index.html, but default.html is in the list before index.html, you might have a slight decrease in performance.
So normally it does not matter.
I prefer index.html (I think this is typically more popular), but that said it doesn't matter, because users should never know the name of the file from which they are being served!!!. If you are giving users links such as http://path/to/some/name_of_entity.html, then you are doing things wrong! Links should be clean and look like http://path/to/some/name_of_entity/. Use rewriting rules (if necessary) to, behind the scenes, serve the request using a specific page (e.g. to make http://path/to/some/entity/ serve from http://path/to/cgi-bin/entities.pl?name=blah without the user seeing the actual resource or extension). The name of the actual page is an implementation detail that no one should ever know about, and by hiding this implementation, it gives you the freedom to switch between index.html, default.html, index.php, index.jsp, and any other underlying implementation. This allows your pages to evolve and change their implementation without invalidating your URLs, and since invalidating URLs weakens the rank of your pages, it is a really good idea to set up a URL scheme that can survive changes to your website for SEO purposes.
See also:
It's all about consistency, since today you work with a IIS server, and tomorrow you may be with an APACHE server that will be looking for index.html/index.htm/index.php!
So, if you use a consistent method, you'll have no problem changing server's... if you don't, you'll be always facing additional configuration issues...
This is applied not only to this topic, but to many coding issues! A consistent method is always the way to go :)
default.html is the default page for the requesting location if no specific page is specified. ex: http://myname.com/place/ will load default.html in /place folder.
index.html is used as listing page that displays index of all available resources.
Now a days this difference is eliminated and it is hardly evident anywhere. Its now just a preference of the webmaster to decide index.html or default.html as default load.
The choice of the first page is absolutely yours. Few servers are configured to run for Default.html and few to Index.html. You can change these in the configuration files. For consistency purposes, use index.html. Most of the servers recognise it.
Although I prefer to use index.html myself (mostly because I'm more of an apache than an iis user) , I have to say that on the semantic level, default.html makes more sense.
index.html originates from a time when you could strip the page name from almost every web page there was and get a directory listing. The index.html provided an alternative way to display this directory listing. So basically: the user looks inside a folder and index.html is what he sees
default.html uses a different abstraction: the user has not specified which resource inside a certain path he wants to see, so I show him my default resource
So while one could argue that index.html is the more restful version, default.html is the service oriented version.
Of course, this is only relevant on the semantic level, on the technical level it makes no difference, all webservers in existence should be able to cope with both if properly configured.