PHP and index.html and 405 error

[Fred Bloggs]

Excuse me for being a little evasive about the domain name. I have a dispute ongoing with the website owners. However, if the domain is foobar.com and the search string is "foobar" Google indexed "foobar.com" and NOT "foobar.com/index.htm". So when the homepage was changed from index.htm to index.php it made not a jot of difference. The change was made in November 2007. HTH, YMMV, ofcourse.

[Jog On]

Well that's interesting, it means I can go PHP all the way without having to faff about with .htaccess and apache handlers

It's all set up now anyway..

[Fred Bloggs]

Please do a Google search on your website. You can see if it catalogues the website just by domain.suffix or not. I hope I have helped you anyway!

[Jog On]

The PHP Apache handler thing is all done and dusted now so it's not a problem anymore. I will make all my future sites and pages with .php extensions so I can split test conversion rates.

I once changed the meta tag keywords for the index.html page of one of my sites and got completely dropped by all the engines and set back to square 1. I assumed changing the extension to PHP would do the same if in fact the SE's saw it as a new version of the page.

Not something I want to find out through trial and error though..

[TheFaQQer]

The PHP Apache handler thing is all done and dusted now so it's not a problem anymore. I will make all my future sites and pages with .php extensions so I can split test conversion rates.

I once changed the meta tag keywords for the index.html page of one of my sites and got completely dropped by all the engines and set back to square 1. I assumed changing the extension to PHP would do the same if in fact the SE's saw it as a new version of the page.

Not something I want to find out through trial and error though..

Of course there is an argument to be had for not having any extension on the files at all, which would help. Then you can change them as you wish.

[Jog On]

Of course there is an argument to be had for not having any extension on the files at all, which would help. Then you can change them as you wish.

I've seen that and wondered how that works. Are files with no extensions enabled for PHP?

[TheFaQQer]

I've seen that and wondered how that works. Are files with no extensions enabled for PHP?

Not entirely sure to be honest - the pages on MrsF's website are all PHP but have no extension. I would imagine that there's something in the .htaccess for mod rewrite that does it, but I'm not certain.

No doubt when NickFitz reads this tonight he can tell me how it works

[Jog On]

Not entirely sure to be honest - the pages on MrsF's website are all PHP but have no extension. I would imagine that there's something in the .htaccess for mod rewrite that does it, but I'm not certain.

No doubt when NickFitz reads this tonight he can tell me how it works

Aaah yes - I shall look out for the hairy one later on

[NickFitz]

I've seen that and wondered how that works. Are files with no extensions enabled for PHP?

Not entirely sure to be honest - the pages on MrsF's website are all PHP but have no extension. I would imagine that there's something in the .htaccess for mod rewrite that does it, but I'm not certain.

No doubt when NickFitz reads this tonight he can tell me how it works

Aaah yes - I shall look out for the hairy one later on

The best thing to do is to use mod_rewrite. Oh, and your canonical URL for the homepage is better off without index.whatever, IMHO: just have it at the root, i.e. "http://www.example.com/" rather than "http://www.example.com/index.html". (If it has previously existed as "index.html" then use mod_rewrite to send a 301 Moved Permanently redirect from there to "/", and you won't lose any Google juice.)

For example, take a site that recommends foodstuffs. The URLs for the various categories might be:

http://food.example.com/vegetable/BestTomato
http://food.example.com/dairy/BestCheese
http://food.example.com/realfood/BestDeadCowPart

and so forth. The mod_rewrite rule which would handle these cases would be:

RewriteRule ^(.*)/(.*)/?$ foodstuff.php?category=$1&subcategory=$2 [QSA,L]

Requests such as

http://food.example.com/seafood/DimmestPrawn

are then converted, internally to Apache (i.e. no redirect is sent to the client), to be treated as if they had originally been:

http://food.example.com/foodstuff.php?category=seafood&subcategory=Dimmest Prawn

because it's just a PHP app using the $_GET array to find its arguments.

By following this scheme, the underlying mechanics of the implementation are hidden, so if the client wanted to continue to use this domain, but had switched to JSP, all that would be necessary would be to change the relevant rewrite rule(s): the search engines, and indeed the people who had bookmarked the site, would still have the readable URLs to go to.

Obviously it can get considerably more complex than this: the default .htaccess file on a WordPress install includes such rules as

RewriteRule ^([0-9]{4})/([0-9]{1,2})/page/?([0-9]{1,})/?$ /index.php?year=$1&monthnum=$2&paged=$3 [QSA,L]

which will take a URL like

http://blog.example.com/2008/03/page/?12

and unpack it into the parameters needed for WP's front controller (which lives in index.php) to gather the arguments needed to show the 12th page of blog posts from this month (obviously a very active blogger, this example.com chap).

In fact, if you use the front controller pattern, this sort of technique is pretty much essential to make readable URLs; nobody is ever going to think of typing in

http://blog.example.com/index.php?year=2008&monthnum=03&paged=12

whereas the preceding version is reasonably intuitive.

As far as SEO is concerned, it definitely can be of some help when you bear in mind that (it is said) search engines tend to ignore more than three items in a query string. So

http://example.com/shop/music/instruments/guitars/Fender/

has probably got a better chance of rising to the top than

http://example.com/index.php?s=shop&d=music&pt=instruments&it=guitar& make=Fender

and certainly will do better than some mess like

http://example.com/index.php?s=shop&d=1473&pt=8031&it=zxcvbnm45&make= Fender

Or at least that's what they say... SEO is a morass of old wives' tales and cargo cults, at best

One last thing: if you can get your rewrite rules into the server config file "httpd.conf" then it will improve performance, but this isn't normally possible with virtual hosting; if your traffic is such that virtual hosting meets your needs, then it's also adequate to have the rules in your ".htaccess" file at the server root.

If you're hosting in, IIRC, any but the very latest versions of IIS, you'll need an ISAPI filter to do any of this - as usual, MS technology requires a C compiler where others get away with a text editor

[NickFitz]

Of course there is an argument to be had for not having any extension on the files at all, which would help. Then you can change them as you wish.

Further to this point (which I addressed above in terms of allowing concealment of the mechanics of the implementation): it's possible that you want to have the same resource available in different representations - a URI, of which URLs are a subset, is after all a Uniform Resource Identifier, not a Representation Identifier.

So one may want to have http://example.com/goats available as HTML for the normal case, but also want the same data to be available as XML, or JSON, or CSV, for use by network-aware applications that want to consume the same resource (and it must be the same actual information, no more, no less - that is, although an XML representation wouldn't be expected to have the same "chrome" as HTML such as logos, footer links, and so forth, the actual content of the resource - the names of all your goats - should be the same whether I get it as HTML, CSV, XML or whatever).

Although the HTTP standard already allows for this via the Accept header, which allows one to specify the content type in which one would prefer the resource to be served, it is an unfortunate fact that the web (and indeed the net) is riddled with misconfigured proxies which will strip out or mutate this header. Therefore, it is sensible (if one provides multiple representations of a given resource) to not only respond to the Accept header, but to also use extensions as additional (though not canonical) paths to one's content in a particular representation:

http://example.com/goats
http://example.com/goats.html
http://example.com/goats.json
http://example.com/goats.kml

and so forth, but to use

http://example.com/goats

as the canonical URL, serving the default content type: this would probably be HTML, although one can certainly imagine cases where a different content type (such as KML) would be the default.

Either way, the point is that the undifferentiated URL would be the published URL that is normally linked to, and would therefore be the one indexed by search engines. As the alternate representations of the resource would generally be used by applications such as mashups, there would normally be no need to make their URLs available other than in documentation (where they would be indexed as text, but not treated as links adding to the connectivity of the web), thereby maintaining the "purity" of the canonical representation, whatever its content type may be.

Google are already good at this: a search from their normal home page will tend to surface HTML content at a given domain, whereas a search using the same terms from Google Maps will preferentially surface KML content at the same domain which also matches those search terms. (This fact could be used to, let us say, ensure that a domain that only offers KML data for a term doesn't appear in searches for textual content containing that term.)