How to Check HTTP Response Status Codes
Last Updated: March 28, 2022
Whenever you load a page or file on a website, the server hosting that website returns a numerical code that indicates the page’s status, called an HTTP Response Status Code. The status code says if the page is operating correctly, is in error, requires authentication, and more. The HTTP Response Status Code is returned in the HTTP Response Header, which contains other details about the page. You won’t see the HTTP Response Header or the status code displayed on the page itself. Instead, the browser or bot loading the page will see this response status code and will use that information to help load and process the page.
There are a number of different response status codes that can be returned. As an example, if the page loads successfully in response to a visitor’s request for that page, the website will return a response status code of 200. With that status code, browsers and bots know to load the page as usual. Alternatively, if the requested page is not found, the status code returned will be a 404. Browsers and bots know to handle this type of HTTP status code as an error page. If the requested page redirects elsewhere, the HTTP status code returned will be a 301 or 302. With a 301 or 302 status code, browsers and bots will process the redirect to a different URL.
How to Check HTTP Response Status Codes
There are a number of tools you can use to check 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 of 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 is loading your website in the same way and also as a way to help confirm that Googlebot is loading your website correctly.
After you’ve submitted the URL (with or without those advanced settings), Web Sniffer will return you three pieces of information. First, Web Sniffer will show you the HTTP 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, the request header can be useful.
The more interesting information, and what we are after, is the HTTP 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, indicating 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 version of this page redirects to the HTTPS (secure) version of this page. This is the expected behavior and, therefore, what we’d want to see here.
Finally, Web Sniffer will also show the content of the returned page. You won’t see this for a redirected page because a server doesn’t return content when a redirect occurs. However, you will see content for other status codes, such as a status 200. To see an example of the content, we can check a URL that returns a status code of 200.
Viewing the Content 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 entirely different HTML code than you see 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 HTTP Status Codes In Bulk
Instead of checking an individual page at a time, you can also check several pages’ response codes at once using tools like HTTPStatus or Knowledge Bull’s. Alternatively, you can use a tool like Screaming Frog or Jet Octopus to check the response status 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.
As an alternative, you can also check the page’s status code via PHP. This will work for the same domain and for (most) external domains. For example, this code will return the response status code for the stated URL (“HTTP/1.1 200 OK” in this example).
$url = 'https://www.elementive.com/web-analytics/';
$headers = get_headers($url, 1);
What Status Codes Are Returned by a Website?
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 more details below)
- 301 – Permanent redirect
- 302 – Temporary redirect (technically “Found”)
- 304 – Not Modified (see more details below)
- 307 – Temporary Redirect
- 308 – Permanent Redirect
- 401 – Unauthorized (invalid credentials, see more details below)
- 403 – Forbidden (permission denied, see more details below)
- 404 – Not Found
- 410 – Gone/removed page
- 500 – Internal server error
- 503 – Service unavailable
When you check your website’s response codes, you want to confirm the HTTP status code returned by every page on your website 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 code versus 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 to check the HTTP response code each page returns on your website.
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 indicating where to locate that newly created resource. More often than not, you’ll see this status code used within APIs instead of websites. However, certain web apps do use 201 response codes in response to user behavior, such as after a user uploads a new file or adds a post to a forum. 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 run 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 a URL that redirects, in this case, I’ve entered “https://www.elementive.com/redirect/chain”, which redirects to the website’s home page. After entering the URL, click “Trace URL”.
The results will then tell you where this URL redirects to. In this example, /redirect/chain redirects to chain1, which redirects to chain2, which redirects to chain3, which redirects to chain4, and chain-4 redirects to Elementive’s home page.
For more help on redirects, including how to address redirect chains and whether you should use 307 or 308 status codes, check out my in-depth guide to redirects.
304: Not Modified Response Code
When checking your website’s 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.
401 vs. 403 Status Codes
Both the 401 and 403 status codes can both be used to indicate restricted access to a file or directory. By restricting access, you are telling robots from search engines not to index the page. The difference is that a 401 is about authentication while a 403 is about permission.
A 401 status code indicates authentication failed and is often used with a login page. For example, let’s say you have a password-protected area of your website. When a visitor (or bot) provides invalid login credentials, a 401 response status code says that proper credentials were not provided. (A 401 must also include WWW-Authenticate in the header with authentication methods.)
A 403 status code indicates the requested file or directory is forbidden because the person or robot making the request does not have permission to access the file. This is often used to block off large sections of the website that people and robots should not be able to view. For example, you would not want robots or people to see your entire image library, so the main page of the image library could return a 403 status code. This is what WordPress does by default, as you can see on my website:
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.
Monitoring Status Code Usage
It is also important to monitor what status codes Googlebot is encountering when crawling your website. One way to do this is in Google Search Console. In the sidebar, click on Settings, then under Crawling click on “Open Report”. On the main page, you can view crawling By Response. Clicking on any of the status codes will provide a list of pages that were returning that response code and the date of the last crawl.
If you have questions about what response status codes your website returns, or want help resolving any related problems with those response codes, please check out my book, Tech SEO Guide, or contact me.