Skip to content

How to Check HTTP Response Status Codes

By Matthew Edgar · Last Updated: March 31, 2024

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. This code is called an HTTP Response Status Code. It is also referred to as a response code or status code.

The status code indicates if the page is operating correctly, is in error, requires authentication, and more. The HTTP Response Status Code is returned as part of the HTTP Response Headers, which contains other details about the page.

You won’t see the HTTP Status Code displayed on the page itself. Instead, the server will return this response status code to the browser or robot requesting the page. The browser or robot will use that information as it loads and processes the page.

Several different response status codes can be returned. A few examples:

  • 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 robots know to load the page as usual.
  • If the requested page cannot be located on the server, the server returns a status code of 404. Browsers and robots know to handle this type of HTTP status code as a not found error page.
  • If the requested page redirects elsewhere, the server will return an HTTP status code of 301, 302, 307, or 308. With a 301 or 302 status code, browsers and robots will process the redirect to a different URL.

In this article…

How to Check HTTP Response Status Codes

There are several tools you can use to check the HTTP status codes your website’s pages currently return.

Simple Status Code Check: REDbot and WebSniffer

For a basic one-by-one analysis of a page, you can use a header check tool like REDbot. Enter the URL of the page you want to test then click the arrow button to fetch the page headers.

Fetch HTTP status code in REDbot
Fetch HTTP response status code in REDbot

For a more advanced check, you can use WebSniffer. You can enter a URL and hit “Lookup” to load a simple test. You can also click “Options” to configure the request type, HTTP version, and the user agent. It can be helpful to change the user agent to Googlebot to see what HTTP status codes are returned when Google is crawling the website. Ideally, Googlebot should get the same response codes as any other user agent but occasionally, something is misconfigured on the server.

Fetch HTTP response status code as Googlebot in WebSniffer

After clicking Lookup, WebSniffer will fetch the HTTP headers and status code. You will need to scroll down the page to see the results.

When WebSniffer returns the response information, we can locate the HTTP response status code in the HTTP Response Header section. In the following example, we can see that the requested URL returns an HTTP response status code of 301, indicating the URL has moved permanently. Within the response header, we can use the “Location” header to see where this URL redirects to—in this case, it redirects to That means the non-secure HTTP version of this page redirects to the HTTPS (secure) version of this page. This is the expected behavior.

Example HTTP response header, including status code, for a redirected page

Check HTTP Status Code in Google Chrome DevTools

You can also check a page’s status code using Google Chrome’s DevTools.

To load DevTools, before opening a webpage, right click in Chrome and click “Inspect”. You can also press F12 to open. Once the Dev Tools area opens, click “Network” in the top bar. (Note that this may be hidden from view and you’ll find Network by clicking “>>”.) After opening Network, load the webpage as usual in your Chrome browser.

You will see all of the resources needed for your page to load listed in the Network area. The first resource listed is the main page loaded. Click on that item and a new panel will appear. In this panel, you can see the status code of the requested page. In this example screenshot, you can see that my website’s homepage returns a response status of 200.

Viewing status code in Chrome Dev Tools - showing status 200 page

Here is another example, showing how you can see the status code of a redirect in Chrome DevTools. The redirected page is listed first and the redirect destination is listed second. In this example, the redirect returns a 301 status code, indicating a permanent redirect.

Chrome Dev Tools - view 301 redirect

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.

Bulk check of HTTP response status codes in
Bulk check of HTTP response status codes in

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.

Status Codes in JetOctopus
Status Codes in JetOctopus

Monitoring Status Code Usage

It is also important to monitor what status codes Googlebot encounters 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.

View response codes crawled by Googlebot in Google Search Console

Checking HTTP Status Code in JavaScript

Along with the tools discussed above, you can also obtain the HTTP status via code. Using JavaScript, you can get the HTTP status code of a URL via an XMLHttpRequest. You can see an implementation of that on this JSFiddle.

This code will not work on external domains or subdomains for security reasons. If you try to run this JavaScript code to check status codes on an external domain, you will get an “Access-Control-Allow-Origin” error message. That means you’ll have to run this code on the same domain but that can be helpful to check pages on your own website.

For example, to check a page on Elementive’s site, I’d have to run this code on Elementive’s domain and pass in relative URLs. To check the status code of the page, I’d use the code:


Checking HTTP Status Code in PHP

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 = '';
$headers = get_headers($url, 1);

What HTTP 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 need to understand. These are the HTTP status codes that have the greatest impact on UX and SEO:

As you audit websites, you will see other status codes. Here are a few more that are less common but can still surface in Google Search Console or log files.

  • 201 – Created (see more details below)
  • 204 – No content
  • 304 – Not Modified (see more details below)
  • 400 – Bad Request (see more details below)
  • 401 – Unauthorized (invalid credentials, see more details below)
  • 403 – Forbidden (permission denied, see more details below)
  • 406 – Not Acceptable
  • 429 – Too many requests (see more details below)
  • 451 – Unavailable For Legal Reasons

There can also be custom codes used in specific applications. You will need to check with your developers or third-party services to understand why these codes are used.

Status Code Classes

There is a trick you can use to keep track of all the different status codes. The first digit in the status code represents the class of that status code. There are only five valid classes, 1 through 5. Sometimes the class is referred to with the first digit followed by “xx” values, such as 4xx or 5xx.

Class 1, or 1xx, response codes are purely information status codes. These are seen in APIs but are rarely used on websites.

Class 2, or 2xx, response codes are used for successful requests. Status 200 is the most common.

Class 3, or 3xx, response codes are used to instruct the browser or robot it needs to take further action to process the request. For example, a status 301 is used for a redirect and tells the browser or robot it needs to take further action to process the redirect.

Class 4, or 4xx, response codes indicate the browser or robot has made a mistake with this request. After receiving the 4xx status code, the browser or robot needs to change how it interacts with the website. For example, a server sends a 404 to tell the browser or robot that the file it requested cannot be found and that it should stop requesting that page.

Class 5, or 5xx, response codes are used to communicate server failures. The server received a valid request but could not respond. The different 5xx status codes indicate different types of problems and indicate how browsers or robots need to respond.

Why Check Status Codes

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 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 of 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.

Need help on redirects? For more information about redirects, including how to address redirect chains, check out my in-depth guide to redirects.

There are several tools to check redirects and identify redirect chains, including and HTTPStatus. Using HTTPStatus as an example, begin by entering a URL (or multiple URLs) that redirects. For example, I’ve entered “”, which redirects to the website’s home page through multiple redirect hops.

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.

Results of redirect chain from
Results of redirect chain from

We can see similar results in WhereGoes.

WhereGoes Result of Trace
WhereGoes Result of Trace for Redirect

304: Not Modified Response Code

A 304 HTTP response code is not an error. Instead, a 304 response code means the requested file has not been modified since the previous request was made and has been cached. This can be a way to help speed up a website because 304 responses can help reduce unnecessary network traffic.

Before requesting a file, the browser or robot checks if a cached version of that file already exists. If a browser or robot has a cached version of the file, it first sends a conditional request to the server, including the last modified date for the cached file via the If-Modified-Since HTTP Header.

The server then checks if the file has been modified since the stated date. If the file has been modified, then the file is sent from the server to the browser. This loads it as normal.

If the file has not been modified since that date, the server responds with a 304 Not Modified status code, and no file is sent. When a robot or a browser receives the 304 response code, then the robot knows the cached version of the file can be used.

This saves bandwidth and time for robots and browsers because the condition request and subsequent 304 response are significantly smaller than sending the whole resource again.

For Googlebot, this will improve processing time for files, allowing Google to use saved copies of files. Especially resource files, including images, CSS, or JavaScript files. This also improves crawl efficiency, which is especially important for larger websites.

400: Bad Request

A 400 status is a general error message indicating the server is unable to correctly process the request. The status code does not specify the exact reason for the error, simply indicating the request was “bad”. One common cause is malformed URLs that the server does not understand. So, when this is detected, it is important to check if query strings added to a URL are causing a problem. Sometimes, cookies or an outdated cache can cause processing issues as well.

If detected, Googlebot assumes the page with that status code does not exist. As a result, URLs returning a 400 Bad Request status code will be treated similarly to a URL returning a 404 Not Found status code. As a result, this can remove the page from search results. If pages are found returning a status 400, your first step is determining if that page needs to be indexed in search results. If it should be indexed, the 400 response code is a critical error to address. If it is not a page that should be indexed, then the 400 status will help Google keep these pages out of rankings.

401 vs. 403 Status Codes: Restrict Access

Both the 401 and 403 status codes can 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. For example, let’s say you have a password-protected area of your website. When a visitor (or robot) provides invalid login credentials, a 401 response status code says that proper credentials were not provided. A 401 can also be returned when invalid credentials are provided when connecting to an API. When used, a 401 must also include WWW-Authenticate in the response headers that specify the authentication methods (also known as challenges).

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:

Using a 403 to forbid access to viewing the uploads directory

It is important to not use a 401 or 403 to control crawling from robots. While a 401 or 403 will tell Google to not crawl the pages, they do not adjust how frequently Google will attempt to crawl the page. To control crawling, use a 429 status instead.

404 vs. 410 Status Codes: Page Not Found

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 or learn how to fix 404 errors on your website.

429: Too Many Requests

A 429 response status code can be returned to tell a browser or robot that it is requesting too many files from the website and is overextending the server limits. This status code is used alongside rate limiting. Typically, this response code is not needed but can be useful on larger websites dealing with a high volume of requests.

Google recommends using this status code as part of emergency measures to limit crawls from Googlebot when Google’s crawls are harming website availability. The first step is to establish a method of detecting and responding dynamically if Googlebot is making too many requests. If Googlebot does make too many requests, approaching or exceeding the limit, the server should return a 429 response status code. If this status code is returned for more than a few days, it can permanently alter how frequently Google crawls the website.

5xx: Server Errors

The status code for any server error should be within the 5xx class. It is important to not return a status 200 with a server error because that tells robots the page is operating correctly. Similarly, returning a 404 with a server error confuses robots about what the error is. There are different types of 5xx response codes that can be returned:

  • A 500 response code is the most generic response code to use in the event of a server error. While generic, it still communicates that an error has occurred. Where possible, you want to use a more specific status code.
  • A 501 indicates that the server failed because the functionality requested is not available yet. This isn’t very commonly used and is not explicitly supported by Googlebot.
  • A 502 indicates the server received an invalid response. For example, Cloudflare received a request for a file but couldn’t fetch that file from the website’s server.
  • A 503 indicates the website is down for maintenance or is currently overloaded. This is the most common status code to use for server errors. You can also return a Retry-After header to indicate when the service will be returned (a Retry-After header is easier to return for planned maintenance when there is an established time window).

Need Help?

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.

You may also like

Google Search Console: Page Indexing Report

Is Google indexing every page on your website? If not, why not? To answer these questions, you need to use the Page Indexing Report in Google Search Console. Find out how to use and understand this report.

Noindex vs. Nofollow vs. Disallow

Are you confused about the difference between noindex, nofollow and disallow commands? All three are powerful tools to use to improve a website’s organic search performance, but each has unique situations where they are appropriate to apply.

How to Use a Headless Browser

Learn what a headless browser is, why you should use a headless browser and how to launch a headless browser on your own computer.