HTTP Status Codes
What is the HTTP Location header?
The HTTP Location header is a response header sent by a server to tell a browser or client where to find a resource at a different URL. It is the mechanism that makes URL redirects work, without it, a 3xx status code would tell a browser that a redirect is happening but give it nowhere to go.
Every redirect you have ever encountered on the web, a 301 moving a page permanently, a 302 sending you to a maintenance page, an HTTP to HTTPS redirect enforcing a secure connection, relied on the Location header to deliver the destination URL to the browser.
How the HTTP Location header works
When a browser or web crawler makes a request to a URL, the server processes the request and sends back an HTTP response. That response contains a status code and a set of response headers. When the status code is in the 3xx redirect family, the response also includes a Location header containing the URL the browser should go to next.
A typical redirect response looks like this:
The browser receives this response, reads the Location header, and immediately makes a new request to the URL it contains. The whole process happens in milliseconds and is completely invisible to the visitor — they simply land on the destination page without seeing any of the underlying exchange.
The Location header contains a single URL value. That URL can be absolute, a complete URL including scheme, domain, and path, or relative, containing only a path that the browser resolves against the current domain. Absolute URLs are strongly preferred in practice as they are unambiguous and work correctly across all clients.
Location header and redirect status codes
The Location header works alongside specific HTTP status codes to communicate both where to go and what the move means. The status code carries the intent (permanent, temporary, method-switching) and the Location header carries the destination.
The redirect status codes that use a Location header are:
301 Moved Permanently: permanent redirect, browser caches the destination, SEO equity transfers to the new URL.
302 Found: temporary redirect, browser does not cache, original URL stays indexed.
303 See Other: temporary redirect that explicitly switches the follow-up request to GET, used in Post/Redirect/Get flows.
307 Temporary Redirect: temporary redirect that strictly preserves the original request method.
308 Permanent Redirect: permanent redirect that strictly preserves the original request method.
In every case the Location header is what makes the redirect functional. The status code without a Location header is meaningless, the browser knows a redirect is happening but has no destination to follow.
Location header and 201 Created
The Location header is not used exclusively with redirect status codes. It also appears with the 201 Created response, which is returned by servers after successfully creating a new resource, typically in response to a POST request in a REST API.
In this context the Location header points to the URL of the newly created resource rather than a redirect destination. For example, if a client sends a POST request to create a new user account, the server might respond with a 201 and a Location header pointing to the URL of the new account.
This dual use, redirects and resource creation, makes the Location header one of the most versatile response headers in the HTTP specification.
Location header and SEO
From an SEO perspective the Location header is the single most important piece of data in a redirect response. When Googlebot or another web crawler follows a redirect, it reads the Location header to find the destination URL and determines how to update its index based on the accompanying status code.
For permanent redirects, the URL in the Location header is the address that search engines will eventually index in place of the original. This means the Location header must point to the correct final destination, not an intermediate URL that redirects again, not a URL with incorrect parameters, and not a URL that returns a 404 error.
A misconfigured Location header pointing to the wrong destination is one of the most common causes of failed site migrations and lost SEO equity. Always verify that Location headers are pointing to exactly the right URLs before deploying redirects at scale.
Redirect chains and the Location header
A redirect chain occurs when the URL in a Location header itself returns another redirect, creating a sequence of hops before reaching the final destination. For example URL A returns a 301 with Location: URL B, URL B returns a 302 with Location: URL C, and URL C finally returns a 200.
Each hop in a redirect chain requires an additional round trip between the browser and server, adding latency to every page load. For web crawlers, redirect chains consume crawl budget and dilute SEO equity, each hop weakens the signal passed from the original URL to the final destination.
The best practice is always to configure Location headers to point directly to the final destination URL, eliminating intermediate hops entirely. Regularly auditing your redirects to detect and collapse chains is an important part of redirect management and site health.
Absolute vs relative URLs in the Location header
The Location header value can technically be either an absolute URL or a relative path. An absolute URL includes the full scheme, domain, and path:
A relative URL includes only the path:
While relative URLs are technically valid according to the HTTP specification, absolute URLs are strongly recommended in practice. Relative URLs require the client to infer the scheme and domain from the original request, which can produce unexpected results in some clients and proxy configurations. Absolute URLs are unambiguous and work correctly across all browsers, crawlers, and HTTP clients regardless of context.
When configuring redirects, whether in server config files, a .htaccess file, Nginx, Apache, or a redirect management tool, always use fully qualified absolute URLs in Location headers.
How to inspect the Location header
The Location header is visible in any tool that shows raw HTTP response headers. The most accessible way to inspect it is through browser developer tools, open the Network tab, visit a URL that redirects, and click on the request to see the full response headers including the Location value.
Command line tools like curl also show Location headers clearly:
The -I flag returns only the response headers, making it easy to see the status code and Location header without downloading the full page body. This is a quick and reliable way to verify that redirects are configured correctly and pointing to the intended destination.
Dedicated redirect checking tools go further, they follow entire redirect chains, show every hop including status codes and Location headers at each step, and flag issues like redirect loops, chains, and destinations returning error codes.
Common issues with the Location header
Pointing to a URL that redirects again: if the URL in a Location header itself redirects, you have created a redirect chain. Always point Location headers directly to the final destination.
Pointing to a URL that returns a 404: if the destination URL does not exist, every visitor following the redirect lands on a 404 error. Verify destination URLs before deploying redirects.
Using a relative URL incorrectly: relative URLs in Location headers can behave unexpectedly in some proxy and CDN configurations. Always use absolute URLs.
Missing the Location header entirely: a 3xx status code without a Location header leaves the browser with no destination to follow. Most browsers will display an error. Always ensure Location headers are present and correctly formatted on every redirect response.
Encoding issues in the Location header: URLs containing special characters, spaces, or non-ASCII characters must be correctly URL encoded in the Location header. Unencoded characters can cause redirect failures in some clients.