We all know about HTTP codes, or at least we know there is a 404 one which means not found. Some of us know that there's a 200 code (meaning OK), and that there's some odd ones in the 500 meaning something went bang! Those interested in SEO will be aware of 301 and 302 codes for things being removed, but very few will have heard of the 418 code (I'm a teapot - yes, really!). Whilst planning a greenfield project (something built from the ground up, to those who aren't developers), I came to the realisation that very few of the codes provided by the specification are actually used. In a world where APIs are becoming more prevalent, and the micro-service architecture is taking over, the status codes of the HTTP specification should be more widely known.
Mozilla has a page dedicated to them and what they mean, so I won't over cover them, but I will cover some of the ones which should be used, and a prediction for the future on one of them.
Successful Responses
I've already mentioned that the 200 code is for 'OK'. This is used by most applications to let the client know that the request has completed successfully. However when it comes to APIs, or general web applications, sometimes a 201 is more correct than a 200. This means "created", so if you're adding a new record via an API, you should get a 201 rather than a 200 to know that the record was created. Whilst 200 does work in this situation, 200 really means that nothing of note went wrong to stop the server responding.
When it comes to things like scheduling things to happen in future - an e-mail campaign, for example - 200 is fine; 201 would be better, to let you know it was created; but if it's something which will be done in the future, then 202 might be more appropriate. This means "accepted", but that the request is in a queue to be processed. Perhaps a combination of those would be relevant, depending on the steps taken to get from crating the campaign to scheduling the e-mails.
Client Errors
This is where things are interesting, and extend much further than normal 404 pages. Some people may have seen a 401 page (if you try to access something which requires you to be logged in and you aren't), or a 403 (when you are logged in, and try to access something you aren't allowed to).
A 405 error should be in the mind of API developers for requests via a method which isn't allowed, such as trying to delete a resource when no delete command exists, or trying to create or update a record which can't be updated. This should be used when no actual function for filtering the relevant request type exists, not if the client just isn't allowed to do it.
The error code which got me thinking about this post is the 410 code - Gone. The specification states this should be used when a resource has been permanently removed from the server, and there is nothing it can replace it with. If you speak to SEO agencies, they will likely tell you to set up a 301 redirect to a different page to keep "link juice" and other link authority and ranking for that domain. Here's the problem though, a 301 means the resource has been moved i.e. relocated, not removed. This becomes more of an issue in areas such as e-commerce where product pages may have schema markup to allow search engines better understand the content. If you tell the search engines that the resource has moved, they will still expect that schema markup. The likes of Google have search console tools which will then flag things as an error.
Here's my prediction, as alluded to at the start. Google (and other search engines in turn) will start penalising sites where 301s are used incorrectly i.e. to redirect traffic from one indexed page to something which isn't the same, or similar, to the previous page. This is likely to be a few years off, but as Google are in the business of providing people with the best answer to their question as fast as possible, linking to an old page which redirects to something unrelated, or worse, lands the user in a long redirect chain taking up their time, is not good for business.
Personally, I feel that the best course of action when a page is deleted would be to use the 410 error for a short period of time (as mentioned in the HTTP spec), and then go to a 404 page. This time frame should be around the equivalent of two crawl windows i.e. let Google and other search engines crawl it with a could of times when it has the 410 status, then move it to a 404. The best part of doing it that way - you know what the user was looking for, so you can customise the page and make your 410 and 404 pages incredibly helpful, and direct the user to other relevant information and/or products. That has to be better than redirecting them to a generic category listing, or just telling them the page can't be found and leaving them to figure out the next steps (hint: it's close the window, go back to their search engine and start again).
Server Errors
These are the ones which are often forgotten about by developers, and most often seen in their raw form by clients. Usually a white or pale yellow background with a bunch of gibberish about something which wasn't set, or was a wrong type. Basically, a stack trace. Useful to the developers. Potentially useful to hackers looking for issues and ways in, but absolutely useless to anyone else. As most applications aren't actually tested for every possible combination of things happening (because it's simply not possible and/or practical to do so, and unit testing only gets you so far), these errors should be forced during development to make sure the pages at least look useful.
One which really should be used is the 503 error, "service unavailable". This should be used when a site or application is down for maintenance. It lets people know that something is happening, things are normal(ish), but can also give an indication when they might be able to use the service again. If you let people see the plain 503 - unavailable error page of your server, they will likely lose trust in you, as you can't keep things available for them when they need you, or can't be bothered to let them know when you'll be back. Think of it as going to a high street store in the middle of a busy Saturday, and the store is locked with the lights off, despite the opening hours informing you they should be open. You'll go elsewhere for what you came for.
Brief Conclusion
There are far more error codes available than I've covered here, but if you're building an application or website, you should consider those codes and the workflow you will need around them. Give the user the best, most informed journey, of which status codes are a small, but important part of it.
I really do think search engines will look to focus on status semantics in certain areas in future, so letting them know you no longer have the answer to the question someone is asking is going to be important. Anything else is just lying and cheating your way to traffic, which will only result in lost confidence and trust in your brand.
This was originally posted on my blog at https://www.garybell.co.uk/http-status-codes-and-their-uses/ on 23rd August 2019
Top comments (0)