A fallback redirect is a redirect rule that activates when no other redirect rule matches an incoming request. It is the default: the rule of last resort that catches any URL not handled by more specific rules and sends visitors to a predetermined destination rather than leaving them on a 404 error page.

The term fallback redirect is used interchangeably with catch-all redirect in many contexts and the underlying mechanics are identical. Both describe a broad redirect rule that fires only when no more specific rule has already matched the requested URL. The distinction, where one exists, is primarily in framing: catch-all emphasises the broad matching scope of the rule, fallback emphasises the conditional nature of when it activates.

In Redirect Supply the fallback redirect is a first-class feature: a dedicated configuration option for each connected domain that defines where visitors go when they request a URL with no specific redirect rule defined. It is separate from individual redirect rules and applied automatically to any request that falls through the rule set without matching.

How a fallback redirect works

A fallback redirect works through redirect rule priority. When a request arrives at the server, redirect rules are evaluated in order from most specific to most general. Exact path matches are checked first. Wildcard patterns are checked next. Regex rules are evaluated in their configured order. The fallback is last.

If any rule in the hierarchy matches the requested URL that rule fires and the fallback is never reached. Only requests that pass through the entire rule set without matching anything fall through to the fallback. At that point the server responds with the fallback’s configured HTTP status code and a Location header pointing to the fallback destination.

The fallback is not a rule that always fires; it is a rule that fires only when nothing else does. This conditional activation is what makes it a fallback rather than a global redirect. A global redirect handles everything. A fallback handles only what nothing else claimed.

Fallback redirect vs catch-all redirect vs global redirect

These three terms describe closely related concepts that overlap significantly in implementation but differ in context and intent. Understanding the distinctions helps clarify when each term is most appropriate.

A global redirect is typically the only redirect rule on a domain. It is not conditional: it fires for every request regardless of path because there are no other rules to handle anything more specifically. Global redirects are the complete redirect strategy for simple domain parking and brand protection scenarios.

A catch-all redirect is a broad wildcard rule that exists alongside more specific rules in a larger redirect configuration. It is the broadest rule in the set but is still defined as a rule with a /* pattern. Its conditional nature comes from being evaluated last due to its low specificity.

A fallback redirect is conceptually similar to a catch-all but is often implemented as a distinct configuration option rather than a regular redirect rule. Rather than being a /* wildcard rule in the rule list, it is a separate setting, “where should traffic go if no rule matches?”, that the system applies automatically after evaluating all regular rules. This implementation distinction makes the fallback cleaner and less prone to the interaction issues that a /* wildcard rule can cause when placed in a list alongside other rules.

In practice the terms are used interchangeably and the distinction matters more for understanding the concept than for any operational difference.

Why fallback redirects matter

The fallback redirect is one of the most practically valuable features in redirect management because it provides complete coverage without requiring complete URL mapping.

No visitor ever hits a dead end: without a fallback, any URL on a domain that does not have a specific redirect rule configured returns a 404 error. With a fallback, every such URL is redirected to a useful destination. Visitors following old links, bookmarks, or links from external sites that were not mapped in the redirect configuration always reach a live page rather than an error.

Long-tail coverage in domain migrations: a thorough domain migration maps the most important URLs, those with significant traffic and backlink profiles, to their specific equivalents on the new domain. But a large site may have thousands of URLs that were not individually mapped. The fallback ensures all of those unmapped URLs redirect somewhere useful rather than generating a wave of 404 errors after the migration.

Safety net for unforeseen requests: even on well-managed domains with comprehensive redirect rules, traffic arrives from unexpected sources. Old email links, references in PDFs, bookmarks dating back years, links on obscure external sites: any of these could point to URLs that were not anticipated during redirect setup. The fallback catches all of them.

Simplified redirect management: knowing that a fallback is in place means redirect rule creation can focus on the URLs that matter most rather than attempting to enumerate every possible URL that might ever be requested. Important pages get specific rules. Everything else is handled by the fallback. This division of responsibility makes redirect configurations simpler to build and easier to maintain.

Fallback redirects and SEO

The SEO implications of a fallback redirect depend on what it is replacing, specific redirect rules for individually mapped URLs, and what it is handling: all the URLs that were not specifically mapped.

Not a substitute for specific rules on important pages: the fallback redirect is not an excuse to skip specific rule mapping for important pages. A 301 redirect from an important page to its most relevant equivalent on the new domain is significantly more valuable for SEO equity preservation than that same page being caught by a fallback redirect to the homepage. Specific rules that map high-value pages to their closest equivalents should always be created. The fallback handles what is left.

Capturing link juice from unmapped backlinks: backlinks pointing to URLs that were not individually mapped still carry SEO equity. Without a fallback those backlinks point to 404 errors and pass nothing. With a fallback they redirect to the fallback destination and pass at least some equity. The equity transfer is less efficient than with a specific redirect to the most relevant equivalent page, a backlink to a specific article redirected to the homepage passes less value than the same backlink redirected to the equivalent article, but it is significantly better than a 404.

Crawl budget implications: Googlebot and other web crawlers follow the fallback redirect just as they follow any other redirect. The fallback converts crawl requests that would otherwise return 404 errors into redirects that resolve to a live destination. This is more efficient than 404s but less efficient than direct specific rules: the fallback destination may be less relevant to the content the crawler was expecting, which reduces the signal quality of the crawl.

Avoiding homepage overload: if the fallback destination is the homepage, very large volumes of unmapped redirects can create an unusual signal where hundreds of different old URLs all resolve to the homepage. Google has noted that this pattern, sometimes called a “redirect to homepage” issue or soft 404 equivalent, can be treated with reduced equity transfer compared to specific relevant redirects. For domains with large numbers of unmapped URLs, a more targeted fallback destination, a relevant section page or a dedicated “page moved” landing page, is better than defaulting to the homepage.

Choosing a fallback destination

The fallback destination is a single URL that receives all traffic the specific rules did not claim. Because it handles a diverse and unpredictable set of requests, choosing the right destination requires balancing several considerations.

Homepage: the default choice for most configurations. The homepage is broadly relevant, always live, and provides visitors with the full navigation of the site to find what they were looking for. Its limitation is that visitors following specific old links are delivered to a generic starting point rather than to anything related to what they were looking for.

Dedicated “content moved” page: a custom landing page on the destination domain that acknowledges the content has moved, provides a search bar, and links to popular sections. This is a significantly better user experience than a raw homepage redirect; it communicates to visitors that their link is old and gives them tools to find the content they were looking for. It also provides a cleaner SEO signal; a dedicated page for handling old redirects is more explicitly a redirect landing page than the homepage, which helps search engines understand why large volumes of old URLs are pointing there.

Most relevant category or section page: if the redirected domain had a clear primary topic or content type, redirecting unmapped URLs to the most relevant section of the destination site is better than the homepage. A domain that was primarily a product blog redirecting its unmapped URLs to the blog section of the new domain delivers more relevant experiences and better equity signals than redirecting to the homepage.

Site search results page: an advanced approach that uses the URL path of the incoming request to generate a search query at the destination. A visitor following a link to /old-product-name is redirected to newdomain.com/search?q=old-product-name, showing search results that may include the equivalent new product. This requires custom implementation but delivers the best user experience for visitors following specific old links.

Configuring fallback redirects in Redirect Supply

In Redirect Supply the fallback redirect is configured as a dedicated setting for each connected domain, separate from individual redirect rules and applied automatically after all rules have been evaluated.

Setting a fallback is one of the first steps when connecting a new domain. It ensures that from the moment the domain is connected, no visitor requesting any URL on the domain ever lands on a dead end. Specific rules are then added progressively to handle important URLs with greater precision, while the fallback continues to cover everything else.

The fallback can be updated at any time: changing the destination, updating the HTTP status code, or disabling it entirely for domains where all expected traffic is handled by specific rules. On the free plan the fallback effectively functions as the complete redirect configuration: a single global destination covering all domain traffic. On paid plans it works alongside path-level redirect rules as the safety net for unmapped URLs.

Fallback redirects and HTTPS

The fallback redirect must handle all URL variants correctly, HTTP and HTTPS, www and non-www, the same requirement that applies to all redirect rules on a domain.

A fallback that handles only HTTP requests leaves HTTPS visitors receiving certificate errors or 404s. A fallback that handles only non-www misses www traffic. Complete fallback coverage requires the domain to have a valid SSL certificate so HTTPS connections can be established before the fallback redirect fires.

Redirect management platforms that provision SSL automatically for all connected domains handle this correctly: every URL variant on the connected domain is covered by the fallback from day one, regardless of protocol or subdomain prefix.

Common fallback redirect mistakes

Using the fallback instead of specific rules for important pages: the fallback is not a substitute for properly mapped redirect rules on high-value pages. Pages with significant traffic or backlink profiles need specific 301 redirects to their most relevant equivalents. Relying on the fallback for these pages loses the path-level equity they carry.

Setting the homepage as fallback without considering user intent: the homepage is a sensible default but not always the most useful fallback destination. For domains with identifiable primary content types, a more relevant section page or custom landing page delivers better experiences and SEO signals.

Not setting a fallback at all: leaving no fallback means every unmapped URL returns a 404 error. All backlinks to unmapped URLs pass no equity. All visitors following old links hit dead ends. A fallback should always be configured for any domain with live incoming traffic.

Fallback destination returning a non-200 response: a fallback pointing to a destination that itself redirects creates a redirect chain. A fallback pointing to a 404 defeats its entire purpose. Always verify the fallback destination returns a 200 OK before activating it.

Not updating the fallback when the destination changes: if the fallback destination is moved or retired on the destination domain, the fallback begins pointing to a 404 or redirect chain. Include the fallback destination in regular redirect audits to confirm it continues to return a 200.