It sounds like Comcast is redirecting to a search page instead of returning NXDOMAIN for non-existing ___domain names. That is certainly not possible do to and at the same time be standards-compliant.
That's what they're doing, though only if the ___domain matches /^www\..+/ which (along with their allowing you to opt-out) makes it a few degrees less evil than Verisign's infamous "Site Finder".
Isn’t that different? You already want to go to some Google page. Google’s result pages are also fast, so it’s not as though you would have to wait any longer.
Silent redirects are not so nice, but if you can see why you were redirected it shouldn’t be a problem.
I've always found Google's 404s jarring and retro in the worst way possible. They are in desperate need of a complete overhaul not the least of which should be the author's 'Did you mean?' functionality.
404's need to be somewhat jarring, because the user needs to see a difference between a normal and an error page. Having "did you mean" suggestions would still be useful, though.
In a situation such as this where there really can't be more than one interpretation of user intent, I would still redirect to the maps page but display a Twitter or Posterous-style animated message div at the top. The user then knows they made an error, and that it was corrected for them.
Just as an aside: Google’s misspelling detection is so damn good that I find myself smashing keys without much care whether I hit everything correctly or not whenever using Google.
In case anyone is tempted to downvote the parent, I'll attest that is pretty much my searching behavior as well - in fact, it's often the case that I don't use the built in spell check of OS X spotlight (CMD-Space), but instead do CMD-T (new Tab), CMD-K (Search) - and then type some characters that _roughly_ approximate what I'm trying to spell, and then hit enter.
Google usually has my results as one of the first hits, or, alternatively, pops it as a "suggestion"
Another interesting one: gears.google.com does not redirect to google.com/gears, which is a 404. Contrast with voice and talk. Discoverable URLs clearly aren't a priority.
1) I don't recall who it is, but someone who is not google holds a patent (sigh) on using the URL path after the host as the search string.
2) If it was my property to control, I would not want google.com/{*} to accumulate links on the internet. That is to say, before there was google.com/maps, one would expect some people to link to that URL directing their users to search for maps. Now that google is so big, that could be a dicey prospect, because substituting their own property for what would have previously been a search could reasonably be seen as anti-competitive.
In response to point 2, Google could still require that links to search pages still go to google.com/search?q=whatever. google.com/whatever would show a differently formatted page that shows a big error message at the top, with the search results as an extra, not the point of the page. This would mean that Google introducing new sections of the site would not conflict with links to search pages.
If google, in theory, determined that users almost immediately hit the back button when they hit a 404 page, it would make sense to have the page load & render as fast as possible. Right now, the page size is ~1.3k for me.
I also have a feeling that the 404 may be implemented in a different part of the stack than search. In a very unscientific test of data, the response times for 404 pages according to firebug are at least 10% faster than the normal response on the same subdomain. Also, of all the subdomains I tested, only m.google.com, picasaweb.google.com, and docs.google.com had different 404 pages.
Like I said, this is all blind guessing, but my feeling is that Google has reasons for not better utilizing 404s. Having better 404's isn't rocket science and there are google properties that have them (youtube) so there's certainly reasoning behind it.
It would be logical to conclude that there's some server you're hitting before you get to the service specific backend, and that maybe that is the reason the 404 pages come back faster.
Speed here is a subject of debate. Does Google want to minimize the load time of this particular 404 page (so you can do whatever you're going to do), or do they want to minimize the time to your intended destination? I think it's the later.
As I live in Ireland I use google.ie. I often accidentally type maps.google.ie or mail.google.ie, to be greeted with a 404. Seems like a fairly easy problem to fix.
If I had to guess, Google probably gets so many hits for bad URL's (from hackers and such) that it's not worth the processing power to return custom 404 pages. (Notice how it also has no images?)
Umm they don't want u to type in the URL they want you to Google even the URLs you visit daily. When people see the 404 I would fair to say they get frustrated and Google what they were looking for.
http://googlewebmastercentral.blogspot.com/2008/08/make-your...