500 error (?) in Google Webmaster Tools

[LuckyLiz]

Webmaster tools is showing a 500 error for an page that is a feedback form that includes a captcha. ( It's an aspx page, if that matters. ) When I clicked on the link that was showing in webmaster tools the first time, I saw a server error, and unfortunately didn't copy down what the error actually said.

I went to the site and clicked on a link to that form that was on the website and it worked just fine. So then I went back to webmaster tools and clicked on the same link that didn't work the first time and it worked the second time. I switched browsers in case and tried again, and it worked again from webmaster tools.

Then I used fetch and render, and I got an error that the page is unreachable.

Does this sound like it's a Google issue (since it works from the live site)? Would the Captcha interfere for some reason with Google getting the page?

Or would this indicate something might be wrong and I need to call a programmer to go look at it? No other pages are showing server errors.

[netmeg]

I get random 500 errors in GWT that are fine when I try them - I just rack it up to maybe some kind of temporary glitch when Gbot tried to access the page. If they persist, then I investigate to see if there's a server problem. But it's not unheard of to see a one off from time to time.

[not2easy]

You could take a look at your server logs for the time and day in question, to see what requests and responses were being sent and returned. You might spot something simple to fix that takes care of it. Or not - some processes don't produce http requests, such as js or php functions. Doesn't hurt to look.

[LuckyLiz]

Thanks... our server logs for the site are pretty big. I guess I'll wait until I happen to be up after a new log starts for a day and then try to reproduce the error from WMT.. and if I can, then download the log file while it's small enough to be manageable for me to download open and search.

[not2easy]

Some servers will have a separate log you can download that rolls over to a new log at server midnight - OR you could try using a tool to record headers and look at just one or two visits separately. Firefox browser has the LiveHeaders plugin that is handy for that kind of thing.

[LuckyLiz]

Our logs do rollover at midnight.. and it's those individual logs that are really big.. which is why I need to try to recreate the error just after the log rolls over.

I don't understand what you mean by looking at headers. I pretty much only know enough tech stuff to do really basic things and be able to talk with and understand (sort of) the programmers we outsource work to.

[not2easy]

Firefox Live Headers captures the requests and responses between your browser and the server so you can see exactly what browser request is returning the "500" response.

This is an edited copy of a live header request/response - lots of blah-blah in there, but you can see that the broswer (via the html page) is asking for an image in the page, named "newdesign.png":
GET /newdesign.png
and the server receives that request and returns a "200" (found) response:
HTTP/1.1 200 OK

----------------------------------------------------------
http://www.example.com/newdesign.png

GET /newdesign.png HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:21.0) Gecko/20100101 Firefox/29.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.example.com/brands/?manufacturersearch=Panasonic&mode=electronics
Cookie: __utma=1234567890.123456789.123456789.1234567890.123456789.5; __atuvc=1234%5678%
Connection: keep-alive

HTTP/1.1 200 OK
Date: Tue, 07 May 2014 02:03:40 GMT
Server: Apache
Last-Modified: Tue, 02 Jun 2009 17:43:58 GMT
Accept-Ranges: bytes
Content-Length: 135
P3P: policyref="/w3c/p3p.xml"
Cache-Control: max-age=86400
Keep-Alive: timeout=5, max=75
Connection: Keep-Alive
Content-Type: image/png
----------------------------------------------------------

For your test, you would save the live headers (as a .txt file) from opening the URL that gives the error, and look for the request that returns the "500" (config) error to see what needs to be fixed.

It might look like gobbledygook, but the part you're interested is pretty simple. And it lets you run your testing at your convenience.

[LuckyLiz]

Thanks :) I'll get the add on.