I was checking out Google's web master tools site the other night. In order to verify the ownership, I opted to create a static HTML file on my site. Google failed to verify the ownership, stating it received a 404 error inside a 220-status page. I saw the file on the server and could browse to it properly using a browser too.
Puzzled, I looked at the server's access log. It turned out the Google attempted to retrieve two files. One was the long-winding name it stipulated. The other was the former file with its name prefixed with 'noexist_'. The logic is clear: Google wants be sure the 220 code returned for the "magic" file is real, by verifying a different code (404 in this case) would be returned if the "magic" file doesn't exist.
66.249.74.2 - - [11/Jan/2007:20:12:20 -0500] "GET /google0467d40068c96de7.html HTTP/1.1" 200 59
66.249.74.2 - - [11/Jan/2007:20:12:20 -0500] "GET /noexist_0467d40068c96de7.html HTTP/1.1" 200 5306
The help page claims Goggle does HEAD only. This obviously isn't true, or isn't true any more, per Apache's access log entries above.
<META name="verify-v1" content="DGxlTrIdDwI9xwBYeYOMddr34POYb934o45vCpf3t+nvcI=" />
I ended up use the META tag instead. I copy+pasted it into /wp-content/themes/myTheme/header.php right before </HEAD><BODY>. This time it worked just fine.
The mischief was caused by a beautified 404 page generated by the /wp-content/themes/myTheme/404.php. Vaguely recalling Apache's manual pages do state that ErrorDocument directive and some other types of redirect tend to lose the original response status code, be it 404, 501, or 403.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment