Server Responses – The What and Why for SEO

Sometimes not understanding why a website isn’t performing well can be a difficult thing to figure out. However, many times it is important to take a step back and look at what signals can be seen. When looking for technical concerns can appear to be a daunting task, however, we are going to review server responses and hopefully I can help you take a look at a website and not feel like you just pulled up to the intersection pictured here.

If you are like me, you like to leave the mechanics of pretty much everything important to those who know not only what is going on, but also how to fix the concern. But, if you are also like me, you really want to know what is going on and knowing what the outcome should be can ensure proper management of expectations, usually your own! To ensure accuracy you might need a tool and a couple of minutes to check things out, however, showing up at the desk of the person in charge of the web server with the right information is usually the first step in a speedy recovery if anything is wrong.

So, with that I will cover the most common classes and numbers of HTTP Status Codes, what they do and what they should do send the right signals to search engines.

HTTP Status Codes

• 200 Series – Successful
• 200 – The request has been successfully completed, aka “here it is.”
• 300 Series – Redirected
• 301 – The page requested has been permanently moved to the given page, aka “permanent detour.”
• 302 – The page requested has been temporarily moved to the given page, aka “temporary detour.”
• 400 Series – Error Request
• 404 – The requested information is not available, aka “can’t find it.”
• 500 Series – Server Error
• 500 – Internal server error resulting in inability to fulfill request, aka “too busy.”

I know, you are thinking, I know the lingo and what these mean to the engines but I really don’t know how or where to find these mysterious server responses. Here are a couple of tools that are easy to use and understand. The first is a plugin for Firefox called Httpfox and the other way, if you are using IE, Chrome or another browser, is to use a browser based tool like Web Sniffer. I prefer Httpfox because you can keep it running and check the server response code while you surf, bonus!

So, you know what to look for and you have the tool to check it out, what now?

Know when and why a certain server response should be used.

Every page you publish intentionally should return a 200 response, except your custom 404 page. This let’s the search engine crawler know that everything is good to go.

When you move or remove a page, intentionally or otherwise, a redirect should be in place to send the user and the crawler to the new location or to your custom 404 page. The biggest difference between a 301 and 302 is not just semantics of permanence when it comes to a search engine crawler. Search engines (speaking in generalities) do two things when they receive a 301 redirect, first, they note the new permanent location of the requested page while getting it on their list to crawl in the future and second, they pass the value from the previous location and drop it from their list to crawl in the future. This lowers the number of pages they need to visit plus it makes sense from a means of housecleaning. Now, a 302 redirect does something different, first, the crawler doesn’t necessarily not the new location because it is temporary and second, it doesn’t take the old page off the list and keeps the value for the previous page to be returned when that page comes back. This can impact the performance of websites in two big ways, it can trap value from flowing properly through your website and it doesn’t pull the old page from their crawl keeping them coming back for nothing. There are some theories that search engines only visit a limited number of pages when they visit a website, so keeping these old pages that don’t exist on the checklist keeps them from exploring deeper into your site.

OK, the 404 server response is one of the most misunderstood of all of the HTTP Status Codes, mostly because you return a page (custom “could not find page” is recommended, for instance take a look at mine) but you return a server response of could not find. This is important because it takes the page off of the list of pages to revisit and you the ability to track in your analytical package where these are coming from to either correct the link (internal) or request the publisher to correct (external).

Last, but not least would be a 500 response. This is an internal error at the server level and if this is the code you get, it should be addressed quickly by a technician.

What’s the big deal? Well, when you are building or optimizing a website you may need to affect changes like navigation, links and even page names. While doing this for optimal performance, many content management systems, or CMS, automatically change the name of a given page and set a redirect from the old URL, but this might pass a 302 response keeping all of the value the old page URL there and not passing through to the new name or location. This can also be impacted if you have made changes to address canonical concerns with the www or non-www and even http or https versions of pages that could be considered as duplicate content (bad) or dilute link value to multiple versions of the same page (worse).

Hopefully this will help you do a quick health check of your website and keeping it healthy, technically speaking, is the best way to ensure you are performing well in SERPs.

related posts >>

• Been Lookin’ for More?
• Don’t Believe Me? Listen to Another Expert!
• Is Your Web Server Limiting Your SEO Performance?
• Focus on What is Important
• The Marketing in SEO

Tagged as: cms, firefox, internet explorer, plugin, serps