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

Last updated: March 11, 2026