There are a number of http status codes that you should become acquainted with on the SEO side of things. They may not make sense on the surface, but once you understand them they are extremely useful.
The first thing to remember when dealing with status codes is that there are five different types: client-side errors, server-side errors, informational responses, successful responses, and redirects.
These can be returned for anything from a successful request (200) and up to something as extreme as an error or redirect (300 or 500).
As we’ll see later, these will dictate how your page is accessed by search engines which in turn will change what SERP (search engine results pages) listing data they present.
This allows a client program to determine if its connection was successful or not. In layman’s terms it means that if you want to know if your server has received and encoded correctly all of the following info, then use a status code in the 200 range.
Anything in this status code denotes an error on the part of your server. Think of it as saying “I can’t talk to you right now, please try again later.”
What’s interesting is that these status codes will change how Google views whatever page they are linked to (more on that later). Given that a number of them are not extremely visible unless you know what you’re looking for, identifying errors is a key task for any site owner to complete when diagnosing why something isn’t working.
Now let’s dive into some of the more useful codes.
Status Codes You Need to Know
200 means everything was successful. Pretty straightforward! This is the status code that you want to return in response to a page request. 200 is the only code that will always be indexed by Google (though they can choose not to display it if they have reason to).
201 Created – This means that your server has successfully created what has been requested. This can either mean creation of a new document or an update/modification to an existing document. The latter would be something like PUT /blog_post_123 when blog_post_123 doesn’t exist yet, but after its created status 201 should be returned as confirmation. It’s worth noting however that search engines may take some time before crawling and indexing such pages.
202 Accepted – Pretty much the same as 201 except that it means your server has accepted and is processing the request. Sometimes this is used when a document needs to be generated but isn’t ready yet.
204 No Content – This could mean a couple of things; generally it is used with an API where you want to return info but don’t have any specific data for the user at hand. You would also use this if there was no update, like with scheduled tasks (i.e hourly or daily jobs), etc.
You could also use 204 for example if you were updating a footer link on every page in real time without returning new content (just changing its location). In short, anything where there’s no actual new content returned.
301 Moved Permanently – This is what you want to return when a page has been permanently moved to another location (i.e www.example.com/mypage now points to www.example.com/anotherpage ). It’s important that you remember that people will get pissed off if they click on a link and it doesn’t work so make sure the redirect works! In terms of search engine optimization: 301s are considered “soft” redirects and generally speaking, it’s not great practice to have hundreds of them pointing to one page because most likely your website has changed layout/navigation since then or there are better ways to improve navigation for users like breadcrumbs (just an example). Google seems to have gotten a bit better at handling these kinds of redirects recently but it still isn’t recommended for large amounts.
The best and most common use for 301 redirects is on your site’s main navigation – if the page you are attempting to get users to has been moved somewhere else then it’s good practice to direct them there through a 301. This way, users who might be bookmarking that URL or typing it into their browser manually will always end up where you want them to be (e.g www.example.com/product rather than www.example.com/products).
There are several other ways that you can handle this, particularly with JavaScript, but at the time of writing this is the cleanest and simplest way.
The response code 304 indicates that no new content was found because the document has not been modified since you last requested it. It’s basically like saying “it’s right here on my hard drive, but I don’t have to go get it from the server again if you’re asking for it.” Given modern server technology this happens a lot—i.e your browser stores data like cookies so that when you visit example.com/products in future, we can return a 200 OK error rather than having to re-download all your products (and strain bandwidth in general). In short, anytime there is some kind of caching happening between your browser and Googlebot then a 304 might be returned. Note also that in the case of HTML pages, this means that they haven’t been changed (which isn’t necessarily a good or bad thing)— it just means nothing has changed since you last downloaded them (i.e not worth downloading again if nothing new has happened).
This is one of those status codes best left to search engine providers’ documentation as there are so many edge cases and it changes all the time! Just make sure you aren’t using it for everything like we see people do all too often.
The response code 302 indicates that your server is attempting to automatically redirect clients from the requested resource to another, and is usually used temporarily, rather than permanently like a 301. It does this by attaching a special “Location” header which contains the URL where content is now located. In the past this was used to change the actual location of a file on a server (i.e. example.com/foo to example.com/bar).
It’s also been known to be used in cases where there has been a domain name change and you direct users from one domain to another even though they will end up at the same URL anyway (we have seen this before: an old blog post that got moved but still used “old” URLs as redirects). It’s important to note that some webmasters tend to use 302s instead of 301s, which is incorrect. Always make sure to use 301 redirects if you want full SEO value to be transferred to the new URL. There is some skepticism about whether or not 302 redirects actually transfer the full SEO value that a 301 redirect does. It’s worth reading the following Google developer guide on implementing redirects that Google can work with.
The response code 307 is similar to a 302 in that it will redirect you, but it won’t store your session information for the next time you visit. It’s basically like saying “I’m going throw you out of my house now”. There used to be some arguments around whether this was better than using a 301 or 302 but we think Google changed their approach on this and there’s no longer any definitive answer. You can still use them sometimes (particularly if you are creating many temporary redirects for one-off events) or if you have a solid reason for not using anything else but personally if we can avoid them then we do.
One of the most common uses for 308 status codes is when moving pages from one directory to another (this may happen if you are moving a blog’s permalink structure from domainname.com/blog/pagename to domainname.com/blog ). You may also want to read this article about how Google treats 308 status codes.
This is a status code that we have spotted search engines using quite frequently over the years for pages which were once found and then have disappeared completely – sometimes as a result of a 404 error (and perhaps replaced with something else). You may find that if you check the source code for a 301 (permanent redirect) you might even see something like “HTTP/1.0 302 Found” which are essentially the same thing – it might be worth having a read of this article on how Google treats 302s.
Google’s webmaster guidelines used to indicate that the 404 “Not Found” error was a bit of a red flag. But it seems this has since been relaxed (or more accurately, there is now an official statement which indicates that it isn’t as bad) and you don’t need to go out of your way to hide these errors. This means that when someone asks for a page you don’t have, returning this HTTP Status Code shouldn’t hurt too much, unless you get into the area of having more than 35-50 percent of your site returning 404 errors.
There are plenty of good reasons to allow users to browse your site even when something has gone wrong. For example: if you have a link on your blog or website about a news story that isn’t available, then the browser will automatically interpret that as a request for an article title which doesn’t exist (e.g. “Google Buys Apple” leads to no page titled “Google Buys Apple”). Returning a standard, uncustomized 404 page is unfair to the visitor and it might be worth just setting up some custom error pages instead.
This way, you can let them know what they’ve done wrong but also give them hints at how to fix it, so they don’t feel like their query wasn’t handled well by your website.
It’s also worth mentioning that sometimes your website could return a rather different response code instead of the usual 200 OK status code. For example, when you type in an address and no content is served at all and you get a 302 redirection instead. This is because the web server is configured to redirect visitors rather than serving an actual page of content. The 200 OK status code could also be misleading, because it could be a soft 404, which means that the page physically loads and displays a 200 OK status, but it doesn’t have any content. In which case, you need to add some content.
Another example is when someone searches for an article title on your website which doesn’t exist. You could use the 404 response code here, but it’s probably best to just go ahead and provide an alternative page through a 301 redirect.
This is particularly useful, in our opinion, as otherwise the visitor only knows that they either need to search for a different keyword or aren’t getting good results from their current query. However, with a custom error page, people will then know what’s going on— that there are no results because it hasn’t been written yet. If you want to be really helpful then you could even include a small “coming soon” notice or something similar.
This brings us to another point. If your site contains broken links (that were accidentally created earlier on) then returning 4xx codes are exactly what you should do! For example, if someone pastes in: http://www.example.com/link-that-does-not-exist then the server can return a 404 code to tell them: “hey, this page does not exist!”. This is obviously very different from the usual case where they want to read something but it’s not here, and so returning a 200 OK would confuse them!
The same goes for robots.txt files too. If a user types in www.example.com/robots.txt or just /robots.txt then your server should respond with a 404 error instead of an empty page (as there is no robots.txt file in that directory).
How Do You Plan on Using Status Codes On Your Website?
This should cover most of these response codes and how they are used by Google. There are actually a few more response codes in the 4xx range which could be useful but most of them are not relevant to SEO, plus they don’t tend to be used very often (so even if they were relevant they would not be useful from an SEO perspective).
Pay attention to how you create and delete your pages, and how you use these status codes. They can make a big difference in terms of how Google interprets and interacts with your website. They can also make a difference in rankings if you use them correctly.
How do you plan on implementing status codes on your website?
