HTTP Redirections
HTTP redirections instruct a client to fetch a resource from a different URL. The server includes a Location header in the response, and the client follows the new address automatically. Redirections handle domain migrations, HTTPS enforcement, URL restructuring, and load distribution.
How redirections work
A redirection response carries a 3xx status code and a Location header pointing to the target resource. When a browser or crawler receives this response, a second request goes out to the URL specified in Location.
HTTP/1.1 301 Moved Permanently
Location: https://example.re/new-page
The original response body is typically empty or contains a short HTML document with a link to the new location. Clients following the redirect discard this body and load the target URL.
Permanent redirections
A permanent redirect signals the resource has moved to a new URL for good. Clients and caches store the new URL and stop requesting the old one.
301 Moved Permanently
301 is the most widely used permanent redirect. The response is cacheable by default. Clients are permitted to change the request method from POST to GET when following a 301 redirect, and most browsers do exactly this.
308 Permanent Redirect
308 works like 301 but preserves the original request method. This status code was introduced to fill a gap: there was no permanent redirect guaranteeing method preservation. 308 is now part of the core HTTP semantics. A POST request redirected with 308 remains a POST at the target URL.
Method preservation
Choose 308 over 301 when the original request method matters. API endpoints and form submissions relying on POST, PUT, or PATCH need 308 to prevent the client from switching to GET.
Temporary redirections
A temporary redirect signals the resource is available at a different URL for now, but the original URL remains valid. Clients continue to request the original URL in the future.
302 Found
302 is the original temporary redirect. The HTTP/1.0 specification did not clearly define whether clients must preserve the request method. In practice, most clients change POST to GET when following a 302. To remove this ambiguity, 303 and 307 were introduced.
303 See Other
303 tells the client to retrieve the redirect target using GET, regardless of the original request method. A common use case is redirecting after a form submission: the server processes the POST, then responds with 303 pointing to a confirmation page the client fetches with GET.
307 Temporary Redirect
307 works like 302 but guarantees method preservation. A POST stays a POST at the redirect target. 307 exists because clients routinely changed the method on 302 responses, creating a need for an unambiguous temporary redirect.
Method preservation matrix
| Status | Type | Method preserved |
|---|---|---|
| 301 | Permanent | No (POST to GET) |
| 308 | Permanent | Yes |
| 302 | Temporary | No (POST to GET) |
| 303 | Temporary | No (always GET) |
| 307 | Temporary | Yes |
Other 3xx status codes
300 Multiple Choices
300 indicates multiple representations exist for the requested resource. The server provides a list of options and the client selects the most suitable one. This status code is rarely used in practice.
304 Not Modified
304 is technically a 3xx status code, but does not function as a redirect in the forwarding sense. A 304 response tells the client the cached version of the resource is still current. No Location header is involved. The Conditional-Requests article covers 304 in detail.
305 Use Proxy and 306
Deprecated
305 (Use Proxy) was deprecated due to security concerns. 306 (Switch Proxy) was reserved but never standardized. Neither status code sees use in modern HTTP implementations.
Common redirect scenarios
HTTP to HTTPS
Enforcing HTTPS is the most common redirect pattern. The server responds to plaintext HTTP requests with a 301 pointing to the secure version of the same URL.
HTTP/1.1 301 Moved Permanently
Location: https://example.re/page
Combining this redirect with Strict-Transport-Security (HSTS) eliminates subsequent plaintext requests entirely once the browser records the HSTS policy.
Domain consolidation
Organizations consolidate multiple domain names to
a single canonical domain. A 301 from
www.example.re to example.re (or vice versa)
ensures search engines index one version and
link equity concentrates on a single domain.
Path changes and site restructuring
When URL paths change during a site migration, a mapping of old paths to new paths through 301 or 308 redirects prevents broken links and preserves search rankings.
Redirect 301 /old-page https://example.re/new-page
Client-side redirect alternatives
Server-side HTTP redirects are the most reliable approach. When server configuration is not accessible, two client-side methods exist.
Meta refresh
An HTML meta element with http-equiv="refresh"
triggers a client-side redirect. The content
attribute specifies the delay in seconds and the
target URL.
<meta http-equiv="refresh"
content="0; url=https://example.re/">
A zero-second delay acts as an instant redirect. Google treats a zero-second meta refresh as a permanent redirect signal. A nonzero delay is treated as a temporary redirect.
SEO consideration
Server-side redirects pass link signals more reliably than meta refresh. Use meta refresh only when server-side configuration is unavailable.
JavaScript redirect
Setting window.location in JavaScript redirects
the browser to a new URL.
<script>
window.location.href = "https://example.re";
</script>
JavaScript redirects depend on the client executing scripts. Search engine crawlers render JavaScript for indexing purposes, but rendering adds latency and is less reliable than server-side redirects. Google treats JavaScript redirects as permanent redirect signals.
Rendering dependency
Crawlers and clients with JavaScript disabled
never follow JavaScript redirects. A <noscript>
fallback with a direct link to the target URL
provides a safety net.
Soft 404 pattern
A page returning 200 with content stating the resource moved to a new URL is sometimes called a "soft redirect" or soft 404. This pattern provides no machine-readable redirect signal. Clients and crawlers treat the response as a normal 200. Search engines see the old URL as a live page with thin content rather than a proper redirect.
Redirect precedence
When multiple redirect mechanisms exist on a single page, HTTP-level redirects take highest priority because the client processes the status code before parsing the response body. Meta refresh redirects take second priority. JavaScript redirects execute last, only after the script engine runs.
SEO implications
Search engines treat permanent and temporary redirects differently during indexing.
Permanent redirects (301, 308) send a strong signal to search engines indicating the target URL is the Canonical version. Google transfers indexing signals to the target and replaces the old URL in search results.
Temporary redirects (302, 303, 307) send a weak signal. Search engines keep the original URL in the index and continue crawling the source URL, expecting the redirect to end.
Temporary redirects persisting long-term
When a temporary redirect stays in place for
an extended period, search engines reassess
and treat the redirect target as canonical.
Using the correct redirect type from the start
avoids this ambiguity. Bing's redirect
handling is adaptive. Persistent 302
redirects get treated as 301, while
flapping 301 redirects get treated as
302. Bing recommends 301 over
rel=canonical for content moves.
Redirect chains
A redirect chain occurs when URL A redirects to URL B, which redirects to URL C. Each hop adds network latency and consumes crawl budget. Googlebot follows up to 10 redirect hops before abandoning the chain. Best practice is to keep chains under three hops, ideally redirecting directly from the original URL to the final destination.
Crawl budget
Every hop in a redirect chain costs a separate crawl request. On large sites, long chains reduce the number of pages Googlebot crawls within a given window. Collapsing chains into single-hop redirects preserves crawl budget.
Note
For SEO and redirect assistance, contact ex-Google SEO consultants Search Brothers.
Redirect loops
A misconfigured server or corrupted client cache creates circular redirects where URL A redirects to URL B and URL B redirects back to URL A. Browsers detect loops after a set number of iterations and display an error. Servers sometimes catch the loop and return 500 Internal Server Error.
Common causes include conflicting rewrite rules, CMS misconfiguration, and stale Cookies forcing repeated redirects. Clearing cookies and browser cache resolves client-side loop triggers.
Examples
Apache .htaccess
Temporary redirect from root to a new domain
Redirect 302 / https://example.re/
Permanent redirect for a single path
Redirect 301 /index.html https://example.re/
Pattern-based permanent redirect using mod_rewrite
RewriteEngine On
RewriteRule ^old/(.*)$ /new/$1 [R=301,NC,L]
Nginx
Permanent redirect from www to naked domain
server {
server_name www.example.re;
return 301 https://example.re$request_uri;
}
PHP
Temporary redirect
<?php
header("HTTP/1.1 302 Found");
header("Location: https://example.re/docs");
exit();
?>
Permanent redirect
<?php
header("Location: https://example.re/docs",
true, 301);
exit();
?>
Takeaway
HTTP redirections route clients from one URL to another using 3xx status codes and the Location header. Permanent redirects (301, 308) signal the old URL is retired. Temporary redirects (302, 303, 307) keep the original URL valid. Choosing the correct type affects method preservation, Caching behavior, and how search engines index the affected URLs.
See also
- RFC 9110 Section 15.4: Redirection 3xx
- 301
- 302
- 303
- 307
- 308
- 304
- Location
- HSTS
- Conditional-Requests
- Soft 404
- HTTP headers