| 10:24 am on Apr 27, 2010 (gmt 0)|
|It's better to close "webpage" with .html extension so no confusion to anyone. |
i disagree. extensionless is the way to go... there are just too many variables in play asp, aspx, php, htm, html - that if anything is wildly confusing. especially if you switch between more than one over an entire site.
| 12:03 pm on Apr 27, 2010 (gmt 0)|
gn_wendy - sorry , my bad . Definitely "/" forward slash in the cases I was thinking , although in terms of the question i guess it makes no difference.
| 9:27 pm on Apr 27, 2010 (gmt 0)|
This discussion is largely over my head, but am I correct in reading that regardless of the way we have our folders set up we need to make a rule about which way to go (example.com/directory) , and then 301 all example.com/directory/ requests to the non slash version?
| 3:29 am on Apr 28, 2010 (gmt 0)|
Yes, you definitely don't want the same content indexed with two versions of the URL, both with and without the slash. That potentially splits the content's ranking power.
And since Google is far from the only outfit that collects URLs, I'd still go with the original convention if possible: pages have no final slash but directory indexes do. Some programmers may still be using that assumption, embedded in their code and logic.
| 7:03 am on Apr 28, 2010 (gmt 0)|
Tedster, that's the definition found in the official HTTP specs, so certainly highly recommended.
Someone at Google with a sense of humour:
"Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and canít be redirected even if youíre Chuck Norris." I would always link to root with a trailing slash.
| 7:39 am on Apr 28, 2010 (gmt 0)|
I'm currently working with a development team who is implementing the canonical tag - and this area has become a source of stress. So I thought I'd add - maintain this convention in your canonical tag in the <head> section, not just in your <body> area content links.
| 7:50 am on Apr 28, 2010 (gmt 0)|
Alright, let's all laugh at a semantic argument for a minute...
In accordance with web standards I have opted to not use directory indexes (which is allowed). As a visitor convenience I use directory overview pages in their stead. Each directory overview page is located one level up from where each directory index would be located, on a page with the same name as the directory...
Again as a convenience to visitors, and to ensure there are no canonicalization issues with search engines, I have chosen to redirect visitors from the directory index location to the location of the corresponding directory overview page when they request a directory index rather than serving them content, a 403 or 404 error at the location they requested, because the overview pages are essentially the same as the indexes from a visitor and site usability perspective.
Can I do that? LOL!
Sorry, but we're having a really semantic argument about whether there should be a / on the URL from a 'technically correct' POV and I just see some humor in it some times, so IMO each to their own on this one, because it's really a very semantic argument to say they are technically necessary, but as stated previously in this thread, you should know what you are doing before attempting to make a site completely extensionless, because an error can cause linking, image and style sheet location issues.
[edited by: TheMadScientist at 8:15 am (utc) on Apr 28, 2010]
| 8:06 am on Apr 28, 2010 (gmt 0)|
When people are using the term "directoy index", does that refer to any file named index.whatever within the directory or is it specifically a page that lists the contents of the directory?
g1smd: Where in the spec please? (However, I previously missed your other argument about relatively addressed files. Good point (if using relative addressing anyway)).
| 8:17 am on Apr 28, 2010 (gmt 0)|
It refers to whatever your server returns when /directory/ is requested - it could acutally be the default "index listing" of all the files in that directory - unless you change that default possibility!
If your server is configured to return a particular file when /directory/ is requested, it could be any variation of index.htm[l], default.htm[l], home.htm[l] or any other .asp[x], .php, .cfm -- or whatever you like.
| 8:23 am on Apr 28, 2010 (gmt 0)|
What tedster said, and (on an Apache Box for sure) you can even go one step farther and declare an order to check for them, so you could theoretically set it to look for the files in the following order:
index.htm index.html index.php home.asp someotherfile.php
And if one file was not present and the other would be checked for... Even further, the declared DirectoryIndex does not even need to be in the directory it's serving as the index for:
From the Apache Docs: [httpd.apache.org...]
DirectoryIndex index.html index.txt /cgi-bin/index.pl
| 10:45 am on Apr 28, 2010 (gmt 0)|
Same thing on IIS - and even on the more obscure web servers I've run into.
| 8:42 am on Apr 29, 2010 (gmt 0)|
I'm aware of the technical aspects. I've been around long enough to remember when such a facility was often recommended as way of doing friendly URLs in the absence of mod_rewrite; which I suspect caused the myth of "SEs prefer a '/' on the end".
I was wondering whether those debating in this thread would include in their definition say... an automatically served index.html page when the "directory" path is requested, even if that page in no way indexes the content of that directory? Or does it have to serve the purpose of an index in some way? Is it location (default serving), filename (index.whatever), or purpose (even if for practical purposes for 99% webmasters all three will coincide) that makes something an index page?
Just want to make sure we're not arguing at cross purposes.
| 8:53 am on Apr 29, 2010 (gmt 0)|
200 -> 202 -> 206 -> 304 -> Semantics -> 303 -> 410
| 9:33 pm on Apr 29, 2010 (gmt 0)|
Generally, a URL is a
/folder/ if there are (or can be) other valid URLs like
/folder/page on the site, otherwise it is a
/page only. That is,
/folder/page is valid and
/page/page is not.
| This 44 message thread spans 2 pages: < < 44 ( 1  ) |