What would you prefer? and does google treats them with any differences? (I hope not...)
2:05 am on Mar 9, 2011 (gmt 0)
The extension (.htm, .aspx, etc) does not matter to a search engine. The words in the URL should be relevant to the content of the page as they help a user to recognise this relevance, e.g. blah/widget-user-guide is more intuitive than blah/index.php?page=345
2:50 am on Mar 9, 2011 (gmt 0)
I would go for site/page It is better not having extension, in case you change underlying technology in the future (your URLs can stay the same).
As for last forward slash, the page should not have it as it denotes folder.
7:41 am on Mar 9, 2011 (gmt 0)
I second aakk9999.
1:53 pm on Mar 9, 2011 (gmt 0)
No extension at all is probably best for usability. Its the easiest to remember and type in.
I have seen some evidence that having .html on your urls increases click through rate from the SERPs a small amount. That was measured before Google started showing bread crumbs in place of the URL in SERPs, so even that probably doesn't apply anymore.
2:00 pm on Mar 9, 2011 (gmt 0)
Extensionless is the way to go. As stated, its easier to use, is platform-agnostic, and additionally reduces URL bloat.
2:08 pm on Mar 9, 2011 (gmt 0)
i agree that no extension (or trailing slash) is better, because it is neater and shorter.
i totally disagree with the oft mentioned reason that you see repeated here continually: eg. in case you change underlying technology in the future
any server that can support no extensions will have the ability to parse any file as directed. for instance i have an old .asp site that i moved to an apache server and converted it to php, i kept all the urls the same 'example.asp' and just instructed the server to parse .asp as php
2:09 pm on Mar 9, 2011 (gmt 0)
I think baidu prefers .html and I think in some way google too. But i am not too sure on google
2:10 pm on Mar 9, 2011 (gmt 0)
I would go for site/page [...] As for last forward slash, the page should not have it as it denotes folder.
Here is the counter-argument (in favor of site/page/):
I do use a trailing slash, even below the top-level. If provided with site/page, I 301 to site/page/.
Note, however, that I think of it more as site/topic/ than site/page/. URIs really indicate resources, not pages and folders.
2:20 pm on Mar 9, 2011 (gmt 0)
What about on having:
site/page (without last slash) if someone calls site/page/ you redirect to /page
for other pages related to page
that would mean for a SE, that you have both a directory and a page named "page"
2:21 pm on Mar 9, 2011 (gmt 0)
That article is incorrect. Sorry to be so blunt but there is incorrect advice given there.
This is a document level URI...
This is a directory level URI...
Years ago, the advice was to put everything at a directory level URI. That was before we all started discussing Content Negotiation, Extensionless URIs, etc.
Use /directory/ for directory level and use /document for document level. Don't be misled into the whole trailing slash myth. Go extensionless and serve your documents from their appropriate directory.
There are plenty of proactive options you can take to make sure the above works 100%.
Are Yahoo! and Bing still stripping the trailing slashes from Display URIs? ;)
2:25 pm on Mar 9, 2011 (gmt 0)
A URL ending in a slash is for a folder or the index page of a folder.
URLs for pages do not end with a slash.
URLs for pages can have an extension or can be extensionless.
Images and media files (nearly) always require an extension.
If you use URL rewriting, extensionless URLs are best as you can then detect that any URL without a period needs to be rewritten to fetch the content from your dynamic script. The RegEx pattern matching is very simple.
This also completely avoids those inefficient -f and -d server filesystem "exists" checks that slow so many dynamic sites down.
URLs ending in .html will not be rewritten and the server will fetch the content from the matching static .html file. Extensionless URLs get rewritten to the dynamic script.