Redirect Types & Concepts
What is a server-side redirect?
A server-side redirect is a URL redirect that happens at the server level, before any page content is delivered to the browser. When a request arrives at a server for a URL that has a redirect configured, the server responds immediately with an HTTP status code and a Location header pointing to the destination. The browser follows the location and loads the destination page. No content from the original URL is ever rendered.
Server-side redirects are the standard, correct way to implement redirects for virtually every use case. They are faster than client-side redirects, more reliable for SEO, cleaner for user experience, and the only redirect type that communicates clear intent, permanent or temporary, method-preserving or method-switching, to browsers and search engines through proper HTTP status codes.
Every redirect that matters, domain migrations, HTTP to HTTPS, www to non-www, domain parking, URL restructuring, should be implemented as a server-side redirect.
How a server-side redirect works
The mechanics of a server-side redirect are straightforward. A browser or web crawler sends an HTTP request to a server for a specific URL. The server receives the request and checks it against its configured redirect rules before doing anything else. If a matching rule exists, the server returns an HTTP response with a 3xx status code and a Location header containing the destination URL. No page HTML is sent. No content is rendered.
The browser reads the status code and Location header. Depending on the status code it either caches the redirect, for permanent redirects like 301 and 308: or treats it as transient. It then immediately makes a new HTTP request to the destination URL. If the destination returns a 200 OK the browser renders the destination page. The visitor sees the destination content with the destination URL in the address bar.
The entire exchange, request to original URL, redirect response, request to destination, destination response, typically completes in milliseconds. A single redirect hop is imperceptible to visitors on a normal connection. Multiple hops in a redirect chain add measurable latency which is why keeping redirects to a single hop is best practice.
Types of server-side redirects
Server-side redirects are defined by the HTTP status code they return. Each code communicates different information about the nature of the redirect to browsers and search engines.
301 Moved Permanently: the most widely used server-side redirect. Signals a permanent move. Transfers SEO equity and link juice to the destination. Cached by browsers. The correct choice for any URL change that is intended to be permanent.
302 Found: temporary redirect. The original URL stays indexed by search engines. Not cached by browsers. Correct for maintenance pages, A/B tests, and any temporary redirect scenario.
303 See Other: temporary redirect that explicitly switches the follow-up request to GET. Used in Post/Redirect/Get patterns after form submissions and login flows.
307 Temporary Redirect: temporary redirect that strictly preserves the original HTTP request method. Used in API and application contexts where POST, PUT, or DELETE requests need to be temporarily redirected without losing their method.
308 Permanent Redirect: permanent redirect that strictly preserves the original request method. Used for permanently moving API endpoints and webhook receivers.
Every one of these is a server-side redirect. The server evaluates the request, determines the appropriate response, and returns the status code and Location header before any content is delivered.
Where server-side redirects are configured
Server-side redirects can be configured at several different layers of the web infrastructure stack. The correct place depends on the hosting environment and the complexity of the redirect requirements.
Apache .htaccess files, on Apache web servers, redirect rules are commonly defined in .htaccess files, plain text configuration files placed in the web root or specific directories. The Redirect and RewriteRule directives in .htaccess files are among the most widely used ways to configure server-side redirects on shared hosting environments. A simple permanent redirect in .htaccess looks like this:
More complex rules using RewriteEngine support wildcards, regex patterns, conditional logic, and query string handling.
Nginx server configuration: on Nginx servers, redirect rules are defined in the server configuration block rather than in per-directory files. Nginx handles redirects through return and rewrite directives. A permanent redirect in Nginx configuration looks like this:
Nginx is generally considered faster and more efficient than Apache for redirect processing because it evaluates configuration at startup rather than on every request.
Application-level redirects: web frameworks and applications can issue server-side redirects programmatically. In Express.js, res.redirect(301, '/new-page') sends a server-side redirect. In Django, HttpResponsePermanentRedirect('/new-page') does the same. In Laravel, redirect()->permanent('/new-page') handles it. These are genuine server-side redirects — the application code runs on the server and returns the redirect response before any content is sent to the browser.
CDN and edge redirect rules: modern CDN platforms like Cloudflare, Fastly, and AWS CloudFront support redirect rules at the edge. Requests are intercepted at the CDN layer, geographically close to the visitor, and redirect responses are returned without the request ever reaching the origin server. Edge-level redirects are the fastest possible implementation because they eliminate the round trip to the origin entirely.
Redirect management platforms: dedicated redirect management tools handle server-side redirects through their own infrastructure. Domains are pointed at the platform via DNS changes, and the platform’s servers receive incoming requests and return appropriate redirect responses. This is the approach Redirect Supply takes, handling server-side redirects for connected domains through edge infrastructure that provides automatic SSL, www and non-www handling, and a management interface for defining rules without touching server configuration files.
Server-side redirects vs client-side redirects
The distinction between server-side and client-side redirects is fundamental to understanding redirect quality. Every aspect of redirect behaviour, speed, SEO reliability, user experience, security, differs between the two approaches.
Speed: server-side redirects happen before any content is delivered. The redirect response is typically just a few bytes, a status code and a Location header, returned in a single round trip. Client-side redirects require the browser to load the original page, parse its content to find the redirect instruction, either a meta refresh tag or JavaScript code, and then initiate navigation to the destination. This is always slower, even with a zero-second delay.
SEO reliability: server-side redirects communicate clear intent through standardised HTTP status codes. A 301 is an unambiguous permanent redirect signal that search engines have processed billions of times. SEO equity transfer is reliable and well-understood. Client-side redirects return a 200 OK on the original URL, the wrong status code for a redirect, and search engines must infer the intent from the redirect instruction in the page content. The equity transfer is less reliable and the canonical URL signal is weaker.
User experience: server-side redirects are invisible to visitors. The address bar updates to the destination URL, the destination site loads with full functionality, and navigation behaves normally. Meta refresh redirects may show a blank page or the original content briefly. JavaScript redirects require script execution before navigation begins. Masked redirects keep the wrong URL in the address bar and break site functionality.
Crawl budget: server-side redirects are processed by Googlebot in a single request-response cycle. The crawler sends a request, receives the redirect response, and follows the Location header. Client-side redirects require the crawler to load the full page, render its content, and then follow the redirect in a second step, consuming more crawl budget per redirect.
Security: server-side redirects are processed before any content is delivered, making them transparent and verifiable. Client-side redirects, particularly JavaScript redirects, can be harder to audit and easier to manipulate in ways that create security concerns.
Server-side redirects and HTTPS
HTTPS handling is one of the most important aspects of server-side redirect configuration. For a server-side redirect to function correctly on both HTTP and HTTPS connections, the server needs to be set up to handle both.
For HTTP to HTTPS redirects. one of the most universal server-side redirect use cases, the server needs to be listening on port 80 (HTTP) and configured to return a redirect to the HTTPS equivalent of every requested URL. The HTTPS version of the site handles the actual content serving on port 443.
For domain-level redirects where the redirected domain needs to handle HTTPS connections before forwarding visitors, the server at the redirected domain needs a valid SSL certificate. Without it, browsers attempting HTTPS connections to the redirected domain get a certificate error before the redirect can fire. This is the most common failure point in domain redirect setups, the redirect handles HTTP correctly but fails on HTTPS due to missing SSL.
Dedicated redirect management platforms provision SSL certificates automatically for connected domains, eliminating this failure mode. Every connected domain gets a valid SSL certificate and all four variants, HTTP/HTTPS, www/non-www, are handled correctly out of the box.
Server-side redirects and redirect chains
Even though server-side redirects are the correct redirect mechanism, they can still create redirect chains if not configured carefully. A chain occurs when a server-side redirect points to a URL that itself has another redirect. rather than pointing directly to the final destination returning a 200 OK.
Common causes of chains in server-side redirect configurations include:
Stacked rules: a redirect pointing to a URL that has its own redirect rule defined. For example a domain-level redirect pointing to the HTTP version of the destination, which then has its own HTTP to HTTPS redirect. The fix is to point the domain redirect directly to the HTTPS destination.
www handling: a redirect from the old domain to the non-www version of the new domain, where the new domain has its own rule redirecting non-www to www. Point the original redirect directly to the canonical www or non-www version of the destination.
Outdated rules: a redirect pointing to a destination URL that has since been moved or renamed, creating an unintentional chain. Regular redirect audits identify and collapse these.
Every redirect chain adds a round trip and dilutes SEO equity. The goal is always a single server-side redirect hop from any given source URL to its final destination returning a 200.
Verifying server-side redirects
Confirming that a redirect is genuinely server-side, rather than a client-side redirect that only appears to work the same way, is straightforward using standard tools.
Browser developer tools: open the Network tab before visiting a URL. A server-side redirect appears as a request returning a 3xx status code followed by a second request to the destination. A client-side redirect appears as a request returning a 200 OK followed by a navigation event.
curl: curl -I https://example.com/old-page returns only the response headers. A server-side redirect shows the 3xx status code and Location header immediately. A client-side redirect shows a 200 with no Location header.
Redirect checking tools: dedicated tools show the status code and Location header for every hop in a redirect chain, making it easy to confirm server-side redirects are in place and chained correctly.