I'm receiving 404 Page Not Found errors (80% of the time) on any links off of http://doubleabody.com/, but only for IE browsers, and only if "Friendly Error Messages" is turned on. Go into IE settings and turn off "Friendly Error Messages", and the problem doesn't come back. Turn "Friendly Error Messages" on again, and the problem comes right back, but only 80% of the time. No other browser except IE has this problem. So far we see this problem in IE8 and IE9.
When I say 80% of the time, I mean that I click a link after clearing browser history and cache and get the 404 message in IE. But then refresh like 4 times, and suddenly the page comes up fine. Turn off "Friendly Error Messages", and the problem comes back. We are seeing this on multiple types of Windows (XP, Vista, Windows 7, Windows Server 2008 in a VM on Ubuntu Linux).
Also, this is only a recent problem of about 2 weeks ago. For several months this website ran just fine on a2hosting.com. So far, a2hosting.com is still troubleshooting and they can't figure the problem out either.
This is a WordPress site that's been loaded up with Pods CMS. It has no other plugins besides Pods CMS. I built a custom WordPress theme and then use the Pods CMS API to pull in content to display. This converted this from a blog into a small business website.
The .htaccess of this site is also the normal WordPress variety.
UPDATE1
Per a request from @JeffAlbert, I am showing what the error logs say when I encounter the 404 from an IE8 browser. This was when I clicked a link called "/map" off the homepage. (Note that I have changed the IP addr for my workstation protection.) Note on the first attempt, it failed. On the second attempt, it went through.
50.0.0.0 - - [25/Mar/2011:00:56:51 -0400] "GET /map HTTP/1.1" 404 9082 "http://doubleabody.com/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
50.0.0.0 - - [25/Mar/2011:00:56:59 -0400] "GET /map HTTP/1.1" 404 9216 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
And now this is what happens when I click /map again with "Friendly Error Messages" turned off in IE8, where it consistently comes up just fine:
50.0.0.0 - - [25/Mar/2011:01:03:19 -0400] "GET /map HTTP/1.1" 404 9216 "http://doubleabody.com/liftgates" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
And here's the result when I use Google Chrome from Ubuntu Linux, where it works consistently:
50.0.0.0 - - [25/Mar/2011:01:07:20 -0400] "GET /about HTTP/1.1" 404 11801 "http://doubleabody.com/map" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.151 Safari/534.16"
I had a custom theme in WordPress that I coded. The way it worked was that it grabbed all connections to the site and sent it to the index.php file of the theme. This would then call WordPress's get_header(), get_sidebar(), show content, and then get_footer() -- standard WordPress stuff.
Oddly, though, the logs were reflecting a 404 status. So, in my index.php, I made the first line look like this:
header('HTTP/1.1 200 OK');
At that point, the Apache logs were no longer showing 404, but 200. Now the problem in IE no longer occurs.
So, here's what I surmised from this problem. Evidently IE was ignoring the 404 condition since the dawn of IE. But last week, evidently I have surmised that Microsoft introduced a system update for IE7, IE8, and IE9 that caused it to stop immediately on a 404 status header, even if valid content came back. By me forcing a 200 header through the theme, IE no longer sees the 404 and sees a 200. Thus, no error.
Off-the-cuff guess: bad client-accessible DNS. Testing methodology: confirm in your web server access logs whether you're actually seeing 404s returned for any clients; if not, then the requests never got to your web server in the first place, and you should start looking at either DNS (starting with the authoritative source for your domain) or actual network connectivity problems from the client side.
If you do see actual 404s being returned, the path your client attempted to load will probably give you a pretty good idea of what's causing the problem. Hope that helps!