Redirect Types & Concepts
What is a forced redirect?
A forced redirect is a redirect rule that unconditionally sends every visitor and web crawler from one URL to another with no exceptions, no conditions, and no way to access the original URL directly. Every request to the source URL, regardless of who is making it, what device they are using, where they are located, or how they arrived, receives the same redirect response pointing to the destination.
The word “forced” distinguishes this type of redirect from conditional redirects that only fire for some visitors: geo redirects that redirect based on location, device redirects that redirect based on device type, or A/B redirects that redirect based on test assignment. A forced redirect has no conditions. It fires for everyone, every time, without exception.
In practical terms the vast majority of standard URL redirects are forced redirects. A 301 redirect from an old page to a new one is forced: every visitor to the old page is sent to the new one regardless of any other factor. A domain redirect from an old domain to a new one is forced: every request to the old domain is redirected unconditionally. The term “forced redirect” is most commonly used in contexts where the unconditional nature of the redirect is being emphasised, typically in contrast to conditional redirects, or in discussions about HTTPS enforcement, www to non-www normalisation, and similar universal redirect policies.
How a forced redirect works
A forced redirect works through the same HTTP redirect mechanism as any other redirect. The server receives a request for the source URL, matches it against redirect rules, and responds with the appropriate HTTP status code and a Location header pointing to the destination. The browser follows the location and loads the destination page.
What makes a forced redirect “forced” is the absence of any conditional logic before the redirect fires. There is no IP address check, no User-Agent inspection, no cookie evaluation, no query string examination. The rule applies universally: if the request matches the source URL pattern, the redirect fires. Every time. For everyone.
In server configuration this is the simplest possible redirect rule:
Or in Nginx:
No conditions. No exceptions. The rule fires for every request matching /old-page.
Common applications of forced redirects
Forced redirects are the default mode of operation for the most important and universal redirect use cases on the web.
Forced HTTPS: redirecting all HTTP traffic to HTTPS is one of the most universal forced redirect implementations. Every request arriving on port 80, the HTTP port, is unconditionally redirected to the HTTPS equivalent on port 443. No visitor can access the HTTP version of the site. The redirect is forced for everyone without exception.
This is typically implemented as a 301 redirect: a permanent forced redirect, because the intent is permanent. The HTTP version of the site is never coming back. Every URL on the HTTP domain permanently redirects to its HTTPS equivalent.
WWW to non-WWW normalisation: choosing one canonical form of a domain and unconditionally redirecting the other. Every request to www.example.com is forcibly redirected to example.com, or vice versa. No exceptions for specific pages, specific visitors, or specific devices. The redirect fires universally to enforce a consistent canonical URL structure.
Domain parking and brand protection: parked domains that forcibly redirect all traffic to a primary domain. Every request to the parked domain, regardless of path, device, location, or referrer, is unconditionally redirected to the primary destination. This is a forced global redirect.
Retired page redirects: a page that has been permanently removed and replaced by a new equivalent. Every request to the old URL is forcibly redirected to the new URL. The old URL is completely inaccessible; there is no way to reach the original content because it no longer exists.
Domain migration: moving an entire site from one domain to another. Every URL on the old domain is forcibly redirected to its equivalent on the new domain. Visitors who bookmarked old URLs, who follow old links, or who type the old domain directly are all unconditionally redirected to the new domain. The old domain serves nothing but redirects.
Forced redirects and HTTPS enforcement
Forced HTTPS is the most widely deployed forced redirect on the web and warrants specific discussion. The combination of forced HTTPS redirects with HSTS, HTTP Strict Transport Security, represents the gold standard for HTTPS enforcement.
The forced HTTPS redirect: a 301 redirect configured at the server level that permanently redirects every HTTP request to its HTTPS equivalent. This is the first layer of HTTPS enforcement: the server-side redirect that catches any HTTP request and sends it to HTTPS.
HSTS: an HTTP response header that tells browsers to never make HTTP requests to the domain again for a specified period. Once a browser receives an HSTS header from example.com, it converts all future HTTP requests to HTTPS in the browser itself before they ever reach the server. The forced HTTPS redirect never fires for returning visitors because their browser pre-emptively upgrades the connection to HTTPS.
The combination of forced redirect and HSTS is more robust than either alone. The forced redirect catches the first visit. HSTS prevents the HTTP request from even being made on subsequent visits, eliminating the performance overhead of the redirect round trip.
HSTS preloading: the HSTS preload list is a browser-maintained list of domains that should always be accessed over HTTPS. Sites can submit to this list and have their domain included in browsers by default, meaning even first-time visitors never make an HTTP connection, because the browser already knows to use HTTPS before any request is made. This extends HTTPS enforcement to visitors who have never been to the site before.
Forced redirects and SEO
Forced redirects are the backbone of good SEO hygiene because they enforce the consistent URL structure that search engines need to properly consolidate authority and avoid duplicate content issues.
Canonical URL enforcement: forced redirects from non-canonical URL variants, HTTP, www, trailing slash variants, to the canonical version consolidate all SEO equity and backlinks to a single URL. Without forced redirects enforcing canonicalisation, the same content may be accessible at multiple URL variants, splitting equity between them.
Duplicate content prevention: when both http://example.com/page and https://example.com/page are accessible without a forced redirect between them, search engines may index both as separate pages. The forced HTTPS redirect eliminates the HTTP version entirely; there is only one URL for the content, and it is the HTTPS version.
Link juice consolidation: backlinks pointing to the HTTP version of a URL, the www version, or any other non-canonical variant are all captured by forced redirects and channelled to the canonical URL. Without forced redirects these backlinks are wasted on non-canonical variants rather than contributing to the canonical URL’s authority.
Predictable crawling: forced redirects create a deterministic URL structure that Googlebot can navigate reliably. When every HTTP request redirects to HTTPS and every www request redirects to non-www, the crawler knows exactly which URL is canonical for any given piece of content without needing to evaluate multiple variants.
Status code choice: the vast majority of forced redirects should use 301 Moved Permanently because they represent permanent URL policies: HTTPS will always be preferred, the canonical domain will never change, the retired page will never return. Using 302 Temporary for forced redirects that are actually permanent means search engines do not transfer SEO equity and do not update their index, defeating the purpose of the redirect.
Forced redirects vs conditional redirects
Understanding the distinction between forced and conditional redirects is important for choosing the right redirect type for each scenario.
A forced redirect fires unconditionally for every request matching the source pattern. No visitor can access the original URL. The original URL is effectively retired; it exists only as a redirect trigger, not as an accessible destination.
A conditional redirect fires only for requests meeting certain criteria: a specific location, a specific device type, a specific test assignment. Visitors not meeting the criteria reach the original URL normally. The original URL remains accessible; it is the default destination for visitors who do not meet the redirect conditions.
The choice between forced and conditional redirects depends entirely on the intent.
If the intent is to permanently retire a URL, enforce a protocol standard, normalise a domain variant, or consolidate a moved resource: use a forced redirect. The original URL should be inaccessible to all visitors.
If the intent is to serve different content to different audiences based on location, device, or test assignment, while keeping the original URL accessible as the default, use a conditional redirect. The original URL remains active for visitors who do not meet the redirect conditions.
Forced redirects in redirect management tools
In redirect management tools and platforms, forced redirects are the default mode of operation. When a redirect rule is created, source URL, destination URL, status code, it applies unconditionally to every request matching the source. There is no built-in condition filtering unless the tool explicitly supports conditional rules.
In Redirect Supply every redirect rule is a forced redirect by default. A rule sending /old-page to https://newdomain.com/new-page fires for every visitor requesting /old-page without exception. The forced, unconditional nature of redirect rules is what makes them reliable; administrators can be certain that a configured redirect will fire predictably for every matching request.
Forced redirects and redirect loops
The unconditional nature of forced redirects makes them a potential source of redirect loops when rules conflict. Because a forced redirect fires for every request without exception, including requests that arrive as a result of another redirect, a loop forms instantly when two forced redirects point at each other.
Forced redirect A sends every request for URL A to URL B. Forced redirect B sends every request for URL B back to URL A. Every request triggers both rules in succession indefinitely.
This is why forced redirects must be configured with care, particularly when setting up HTTPS and www canonicalisation at the same time. A forced redirect from HTTP to HTTPS and a separate forced redirect from www to non-www can interact correctly if configured in the right order, or create a loop if configured incorrectly. The safest approach is to combine all URL normalisation into a single forced redirect rule that handles all variants simultaneously: http://www.example.com/* to https://example.com/* in a single hop rather than two sequential redirects that could conflict.
Verifying forced redirects
Because forced redirects fire unconditionally for every request, verifying them is straightforward: any request to the source URL should trigger the redirect.
curl: curl -I https://example.com/old-page returns the response headers immediately. A correctly configured forced redirect returns the expected 3xx status code and Location header for every request.
Browser developer tools: the Network tab shows the redirect response as a separate request entry before the destination page loads. The status code and Location header confirm the redirect is firing correctly.
Testing all variants: for forced redirects enforcing HTTPS or www canonicalisation, test all four URL variants: HTTP/HTTPS, www/non-www, to confirm the redirect fires correctly for each one. Missing a variant means some requests bypass the forced redirect.