How to Check HTTP Response Status Codes
January 29, 2021
Every page on every website returns a numerical code that indicates the page’s status. These numbers are called HTTP Response Status Codes. When the browser request is successful, the website returns a status code of 200. When the webpage is not found, the status code returned is a 404.
You can see all the HTTP status codes on Mozilla’s list, but there are only a few commonly seen HTTP status codes that you really need to understand. These are the HTTP status codes that have the greatest impact on UX and SEO:
- 200 – Ok – the page is successfully loaded – normal
- 201 – Created (see below)
- 301 – Permanent redirect
- 302 – Temporary redirect (technically “found”)
- 304 – Not Modified (see below)
- 403 – Forbidden (i.e. password protected)
- 404 – Not Found
- 410 – Gone/removed page
- 500 – Internal server error
- 503 – Service unavailable
You want to make sure that every page on your website returns a proper HTTP status code that accurately reflects the nature of the page. If the nature of the page and the status code are in conflict, search robots can be confused by your website and that confusion will affect rankings and, ultimately, traffic.
The most common example of this status vs. page conflict is a Soft 404. With a soft 404, the http status code returned is 200, which would indicate everything is normal. However, with a Soft 404, the page content says the requested file could not be found. In this case, the http status code should be a 404 to indicate the webpage is not found and to match the page’s content.
To begin identifying issues, like Soft 404s, that might exist on your website, the first step is checking what http status code each page returns on your website currently.
How to Check HTTP Response Status Codes
There are a number of tools that can identify the http status codes your website’s pages currently return. For a one-by-one analysis of a page, I recommend WebSniffer’s header check tool. When you arrive on the page, you want to enter the URL to the page you want to test. Then click submit for a basic check.
For a more advanced check, Web Sniffer lets you configure a few extra settings, including changing the user-agent from Web-Sniffer to different browsers or to Googlebot. That provides a helpful way to determine if every browser sees your website the same way and if Googlebot can see the website the same way as a human visitor.
After you’ve submitted, Web Sniffer will give you three pieces of information. First, Web Sniffer will give you the request header. This repeats the settings you had specified on the first step and can generally be ignored. But, if you need to remember what settings you had entered, especially if you used any of the advanced configurations, this request header information can be useful.
The more interesting information, and what we are after, is the response header. In this example, we can see that the requested URL of http://www.matthewedgar.net returns an HTTP response status code of 301, indicated the URL has moved permanently. Within the response header we can use “Location” to see where this URL redirects to—in this case, it redirects to https://www.matthewedgar.net. That means the non-secure HTTP redirects to HTTPS, which is the expected behavior.
Finally, Web Sniffer also will also show you the content of the returned page if the content-length of the response header is greater than 0. In the case of a redirected page, the content-length is 0—that’s because no content is returned by the server when a redirect occurs. To see an example of this, let’s run a URL that returns a status code of 200.
Below this table, you will see the content for the status 200 page. This helps you compare what is returned against what you expected to be returned. For example, perhaps you load the page as Googlebot in Web Sniffer and see an entirely different HTML code than you do when loading the site in a browser—this would be a big problem for SEO and one you’d want to fix immediately.
How To Check Website Response Codes In Bulk
Instead of checking an individual page at a time, you can also check several pages’ response codes at once using a crawl tool. Free crawl tools exist as do bulk status code checkers. Alternatively, you can use a tool like Screaming Frog to check this as well. After running a crawl, you will see a list of all pages contained on your website and their respective status codes. Pay attention to any pages that don’t return a status 200.
Reviewing Specific Response Codes
Status 200 vs. Status 201
One of the response codes returned might be a status 201 instead of the expected status 200. A status 201 indicates that a resource has been created and the expected behavior is that the page returning the 201 should provide a location to that newly created resource. More often than not, you’ll see this within APIs instead of websites. However, certain web apps do use 201 response codes in response to user behavior, such as uploading a new file or adding a post to a form. If your website is returning a status 201 you want to make sure it is used appropriately and that the location to the new resource is correctly stated as part of the response. For example, if you ran a status 201 page through WebSniffer, you should see a line for Location in the HTTP Response Header table.
Checking 301s & 302s: Following Redirect Chains
If any URLs return a 301 or 302 response code, that means the URL redirects somewhere else. In these cases, it is helpful to know where those URLs redirect. As well, you’ll want to check if the redirect happens in one step or multiple steps. There are several tools for this but one we recommend is a simple and free tool called WhereGoes.com. To begin, enter in a URL that redirects, in this case, I’ve entered in “elementive.com/chain”. Then click “Trace URL”.
The results will then tell you where this URL redirects to. In this example, /chain redirects to chain-1, which redirects to chain-2, which redirects to chain-3, which redirects to chain-4, and chain-4 redirects to Elementive’s home page.
For more help on redirects, including how to address redirect chains, check out my in-depth guide to redirects.
304: Not Modified Response Code
When checking http response codes, you might also see a 304 response code returned. Although it is sometimes considered an error, it isn’t necessarily a problem. A 304 response code indicates the file requested has not been modified since the previous request. Instead of loading the file, the browser or bot requesting this file can use a cached version instead. In some cases, this can help with a website’s speed. However, using a 304 still makes a request to the server because the server has to check if the requested file has been modified since a particular date. If you have 304 response codes returned for files on your website, you want to determine if those are helping with the website’s speed or if other forms of caching may work better.
404 vs. 410 Status Codes
When the webpage is not found, the http response status code should either be a 404 or 410. As mentioned above, you also want to watch out for Soft 404s too. For more about 404 vs. 410, Soft 404s, and other similar errors to check for on your website, see my guide to website error pages.