It sounds as if you have Content Negotiation (MultiViews) enabled on your server. If you are not actually using Content Negotiation, then you should disable it in your root-level .htaccess file:

Options -MultiViews

This should trigger a 404 Not Found error for all non-existent pages.

Hi encyclo,

Can you give me the actual code I should put in the .htaccess?
Or is it just:

Options -MultiViews

Thanks

You'll probably find parts of this code useful too: [webmasterworld.com...]

Wow, that sure gave me a headache :)

But basically I can go with:

Options -MultiViews
RewriteEngine on

Do I have to have "RewriteEngine on" for the code to work?

Misspelled URLs can go to 404 - I dont want to risk messing up the whole deal.

Ok, this is what I have in the file:

Options -MultiViews
RewriteEngine On
RewriteCond %{HTTP_HOST}!^www\..* [NC]
RewriteRule ^(.*) [%{HTTP_HOST}...] [R=301]

ErrorDocument 404 /404.html

But it still does not work, I tried putting the Options -MultiViews at the end, still no luck, the page shows 300 Multiple Choices. What am I doing wrong?

This is what I came up which actually worked:

ErrorDocument 300 /404.html

Should I expect any problems?

ErrorDocument 300 /404.html

This will display your custom 404 page for a 300 Multiple Choices response code, but it won't change the response code itself - so your custom 404 page would be indexed for the URL in question instead of the default 300 one.

I'm stumped as to why the

Options

directive doesn't fix the problem, and as such I'm struggling to find another situation which would generate a 300 Multiple Choices response.

I'm rather surprised that Google is indexing URLs which return a 300 response code. I would hesitate to call it a bug as such, but it is at the very least an oversight or a bad decision. Surely it would be much more logical to index the linked multiple choice documents instead of the error page itself?

I'm rather surprised that Google is indexing URLs which return a 300 response code. I would hesitate to call it a bug as such, but it is at the very least an oversight or a bad decision. Surely it would be much more logical to index the linked multiple choice documents instead of the error page itself?

I dont know, I am 99% confident I lost a website because of 300 Multiple Choices - it ranks somewhere in the last pages, but it's all supplemental and full of 300 MC pages - so yes, Google has been caching those pages for at least an year, and I guess Google penalizes for it - which is plain dumb, as I have no control over how people link to me, and would open a HUGE door for competitors to get you down. And, yes, that page (the 300 Multiple Choice) went supplemental as soon as Google got it.

If a competitor decides to place 1000s of links on blogs to a page of mine, one slightly different from the other, and all triger 300 Multiple Choice on the same page - I will have 1000s of dup-content pages overnight - which will turn on enough lights to get me banned. I guess it will be the same with the 404 page I have in place right now.

You can call me paranoid, but it's an easy exploit, and unfortunately my industry is full of all kinds of folks.

And therefore my urgency to slove this problem ASAP.

I understand that Google has indexed the 300 error message, but have you confirmed that there really is a 300 status code returned in the http header? I'm wondering here whether some incorrect server config is sending the wrong status code, perhaps a 302.

Yes, it is 300 Multiple choice.

I am using 1and1, and whatever I could find on the web - all talks about that they have MultiViews, but havent found anything specific to 1and1 about turning it off - just "Options -MultiViews".

And I have tried placing the .htaccess all over, including on the main directory (I host multiple websites on the same account) and still nothing.

There appear to be several million pages indexed by Google which return a "300 Multiple Choices" status code - easily distinguishable as the status code is the page title on the default Apache error page.

With the

Options -MultiViews

line in place, but no other rewrite rules (if this is possible with your current setup), can you confirm whether a request for a page without a file extension resolves to the same page with a 200 OK status code? For example, request the page:

http://example.com/index

Even with online Options -MultiViews, it still gives 300 Multiple Choice...

A point fix for the problem would be something like this:

Options -MultiViews
RewriteEngine on
#
# Redirect all requests for non-canonical domains
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) http://www.%{HTTP_HOST}/$1 [R=301]
#
# Redirect URLs with <br> appended to correct URL
RewriteRule ^([^<]+)<br http://%{HTTP_HOST}/$1 [R=301,L]
#
#
ErrorDocument 404 /404.html

Jim

I am using 1and1, and whatever I could find on the web - all talks about that they have MultiViews, but havent found anything specific to 1and1 about turning it off - just "Options -MultiViews".

I have 1and1 and have the exact same problem , 300 Multiple Choices, on one url.

jdMorgan - this did work, and it seems as good solution for the specific problem, however, 300MC error is still showing if you mistype in any other way.

Yes, well the solution previously cited above that fixes multiple problems is much more complex, and I can't recommend it for casual use.

In addition to MultiViews there's another setting you should look into *if* you are hosted on Apache 2.x. This is the AcceptPathInfo [httpd.apache.org] setting. You can try turning it off using

AcceptPathInfo Off

in .htaccess or in your server configuration file. Again this is an Apache 2.x (and later) feature. Like MultiViews, turning it off may break your whole site if you're using scripts that depend on it.

Jim

AcceptPathInfo Off

that just killed my website :)

I dont know why MultiViews does not want to work, I will email 1and1, as now I am sure it's their fault, let see what they have to say.