VMware ESXi and vSphere Cluster Management

HTTP Redirects

Learn how HTTP redirects work, when to use 301, 302, 303, 307, and 308, and how to implement, test, and secure redirects.

An HTTP redirect is a 3xx HTTP response that tells a browser, crawler, or another HTTP client to request a different URL. Redirects connect an old or temporary address to a destination without requiring the visitor to know the destination in advance.

Common reasons to redirect include changing a page URL, moving a site or section, migrating from HTTP to HTTPS, enforcing one canonical hostname, retiring content, and running a temporary campaign. A redirect is different from a normal link: a link requires the user or crawler to choose and request the destination, while a server-side redirect is returned automatically in response to the original request.

How an HTTP Redirect Works

The redirect sequence normally has three steps:

1. The client requests the original URL.
2. The server, reverse proxy, CDN, or application returns a 3xx response containing a Location header.
3. The client requests the URL identified by Location and displays or processes the final response.

GET /old-page HTTP/1.1
Host: example.com

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

A Location header identifies the redirect destination. The destination can be an absolute URL such as https://example.com/new-page, or a relative URL such as /new-page. Absolute URLs are useful when the redirect crosses hosts or when configuration needs to be explicit. Relative URLs are convenient for redirects within the same site.

Redirects may be cached. The status code, response headers such as Cache-Control, browser behavior, intermediary caches, and CDN configuration all affect how long a client reuses a redirect. Test permanent redirects carefully: browsers can retain them, making a recently changed rule appear to continue after it has been corrected.

HTTP Redirect Status Codes

Choosing a Status Code

• Use 301 for a lasting change to a normal page request, such as moving /products/widget to /products/widget-pro.
• Use 302 for a temporary browser redirect when method-preservation requirements are not important. For new API or non-GET designs, prefer the more precise 303 or 307.
• Use 303 after a successful POST when the client should retrieve a separate result page with GET. This is the common post-redirect-get pattern and helps prevent accidental form resubmission on refresh.
• Use 307 for a temporary redirect that must preserve the original method and request body.
• Use 308 for a permanent redirect that must preserve the original method and request body.
• 300 Multiple Choices is an uncommon redirect-related response. It indicates that several representations or destinations may be available, but it is not the usual choice for ordinary URL migrations.

The two key decisions are whether the move is permanent and whether the original request method and body must be preserved. For an ordinary GET page, 301 is usually appropriate for a permanent move. For a POST or API request, choose deliberately between 303, 307, and 308.

Permanent URL Changes and SEO

A permanent redirect should map an old page to the closest relevant replacement. For example, a discontinued product page may redirect to its successor or to a closely related product category, but it should not automatically redirect to an unrelated homepage.

During a migration, update references so users and crawlers can reach the preferred URL directly:

• Internal links and navigation
• Canonical tags
• XML sitemaps
• Breadcrumbs and other site structure
• External references that your organization controls

A redirect is not a substitute for a clear destination page. Redirect chains, redirect loops, irrelevant destinations, and mass redirects to the homepage can harm usability and search visibility. A redirect also does not guarantee immediate indexing or ranking changes; crawlers need to revisit the source and evaluate the destination.

Common Redirect Patterns

HTTP to HTTPS

After adopting TLS, redirect every HTTP variant to the canonical HTTPS URL. Combine this with hostname normalization when possible so a request such as http://www.example.com/about reaches https://example.com/about in one hop.

Canonical Hostname

Choose one public hostname, such as www.example.com or example.com, and redirect the other hostname to it. Apply the same decision consistently in links, canonical tags, sitemaps, and configuration.

Domain Migration

When replacing a domain, map old URLs to equivalent URLs on the new domain. Retain the path and query string when they remain meaningful, but transform or remove parameters when the new site uses a different structure or when forwarding them would expose sensitive data.

Page, Directory, and Variant Changes

• Redirect one renamed page directly to its new path.
• Redirect a moved directory while retaining the remaining path when the content structure is equivalent.
• Redirect trailing-slash, index-file, and other duplicate variants to one canonical URL.
• After an information architecture change, create specific mappings rather than relying on a broad rule that sends every URL to one destination.

Temporary Campaigns

A campaign URL can temporarily redirect to an active landing page. Use 302 or 307 when the original URL may resume later. Remove or change the temporary rule when the campaign ends.

Removed Content

Redirect removed content only when there is a genuinely relevant replacement. If no suitable replacement exists, return 404 Not Found or 410 Gone. Do not redirect every retired URL to the homepage merely to avoid an error response.

Implementation Methods

For ordinary redirects, prefer web-server, reverse-proxy, or CDN rules. They run before page rendering and provide a clear HTTP response. Use application redirects when the decision requires authentication, locale selection, business logic, or user-specific state. CMS tools are practical for editors, but their rules should still be reviewed and tested.

Apache

At a conceptual level, Apache can redirect one path with the Redirect directive:

Redirect 301 /old-page https://example.com/new-page

Apache mod_rewrite can retain a suffix while moving a section:

RewriteEngine On
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]

In a .htaccess file, rule scope, relative paths, existing rewrite rules, and query-string behavior matter. Test in a staging environment or with a small representative set before applying a broad rule.

Nginx

An exact path can be redirected with a location block:

location = /old-page {
    return 301 https://example.com/new-page;
}

An HTTP listener can normalize both common hostnames to one HTTPS hostname while retaining the requested path and query string:

server {
    listen 80;
    server_name www.example.com example.com;
    return 301 https://example.com$request_uri;
}

Application Redirects

Application-level redirects are appropriate when a route depends on login state, a selected locale, account permissions, or business data. They should still return an HTTP 3xx response and a Location header. A login flow, for example, must validate a return destination before using it.

if destination is an approved local path:
    respond with 303 and Location: destination
otherwise:
    respond with 303 and Location: /account

Query Strings, Fragments, and Request Methods

Decide explicitly what to do with query parameters. Retain them when they carry meaningful information such as a product identifier or a necessary campaign value. Remove tracking parameters when they should not define the destination, and transform parameters when the new URL uses different names or formats. Avoid unintentionally forwarding credentials, tokens, session identifiers, or other sensitive values.

A URL fragment begins with #. Fragments are generally handled by the browser and are not sent in the HTTP request, so a server cannot normally redirect based on the original fragment. If fragment-based navigation must be converted, the client-side application needs to perform that work.

Method preservation is important for POST, PUT, PATCH, and other non-GET requests. A 307 or 308 tells the client to repeat the original method and body at the destination. A 303 instead tells the client to retrieve another resource with GET, which is useful after form processing. Do not use an ambiguous redirect when replaying the request could create a duplicate transaction.

Testing and Monitoring

Inspect the response status and Location header directly:

curl -I https://example.com/old-page

Follow the chain and inspect every hop:

curl -I -L https://example.com/old-page

Test both the old and new URLs, with and without representative query strings. Check that:

• The old URL returns the intended status code.
• The Location header points directly to the final canonical URL.
• HTTPS and hostname normalization work as intended.
• The path is retained or transformed correctly.
• Query strings are preserved, removed, or rewritten deliberately.
• POST and other non-GET methods behave safely.
• The destination returns the expected final status rather than another unnecessary redirect.

Review server logs, crawl reports, browser developer tools, and search-console-style reporting for redirect errors, soft errors, broken destinations, and crawl anomalies. Keep important permanent redirects long enough to serve users, bookmarks, crawlers, and legacy external links. Do not remove a valuable migration mapping immediately after the site appears to work.

Security and Safety

An open redirect is a flaw that lets an attacker use a trusted site to send users to an arbitrary destination. It commonly occurs when a login or tracking parameter such as next, return, or redirect is copied directly into the Location header.

• Prefer validated site-relative paths such as /account.
• If external destinations are required, allowlist exact trusted hosts and schemes.
• Reject malformed, encoded, scheme-relative, or unexpected destination values.
• Send authenticated users only to approved destinations.
• Provide a safe default when validation fails.

Redirect loops can result when CDN, proxy, web-server, and application rules disagree. For example, a proxy may terminate HTTPS while the application believes the request is HTTP and redirects it back to HTTPS. Define one canonical scheme and hostname, then make each layer aware of the original request state.

Common Redirect Problems and Corrections

Practical Examples

• Permanent replacement: https://example.com/products/widget can return 301 to https://example.com/products/widget-pro. For ordinary GET page requests, 301 is usually the appropriate choice.
• One-month campaign: https://example.com/summer-sale can temporarily return 302 to https://example.com/promotions/summer. Use 307 instead when the original method must be preserved.
• Form confirmation: A POST to /contact can return 303 with Location: /contact/thanks, causing the confirmation page to load with GET.
• HTTPS and hostname normalization: http://www.example.com/about should reach https://example.com/about in one hop.
• No replacement: A discontinued product with no genuinely related destination should return 404 or 410 rather than redirecting to the homepage.
• Login destination: A value such as next=https://untrusted.example must be rejected or replaced with a safe internal destination.

Redirect Decision Checklist

1. Does the original URL have a relevant replacement? If not, consider 404 or 410.
2. Is the move permanent? Choose a permanent status only when it is intended to last.
3. Must the original method and body be preserved? Choose 307 or 308 when yes.
4. Should the next request use GET, such as after a form submission? Choose 303.
5. Can the old URL point directly to the final canonical URL in one hop?
6. Have query strings, sensitive values, fragments, and authentication behavior been considered?
7. Have all configuration layers been tested for loops and conflicting rules?