A redirect source is the URL that a redirect rule is applied to, the original address that triggers the redirect when requested. When a browser or web crawler requests the source URL, the server matches that request against configured redirect rules, finds the source in its rule set, and responds with the appropriate HTTP status code and Location header pointing to the redirect destination.

Every redirect rule has exactly two endpoints: a source and a destination. The source is where visitors and crawlers come from. The destination is where they are sent. The source is sometimes called the redirect origin, the from URL, the old URL, or the input URL depending on the tool or documentation using the term. Regardless of terminology, it always refers to the same thing: the URL that triggers the redirect.

Getting redirect sources right is as important as getting destinations right. A redirect rule with an incorrect source either does nothing, because the source URL never matches incoming requests, or matches unintended URLs and redirects traffic that should not be redirected. Both failure modes have real consequences for users and SEO.

How a redirect source is matched

When a request arrives at a server, the server compares the requested URL against the source patterns of all configured redirect rules. The matching process depends on how the source is defined.

Exact match sources: the source URL must match the requested URL exactly, character for character. A rule with source /about matches only requests for example.com/about. It does not match example.com/about/ (trailing slash), example.com/about-us, or example.com/About (different case). Exact match sources are precise and predictable: they match only what they are configured to match and nothing else.

Pattern-based sources: the source uses a wildcard or regular expression pattern to match multiple URLs. A source pattern of /blog/* matches every URL under the /blog/ path. A regex pattern like ^/products/([0-9]+)$ matches any URL where the path is /products/ followed by a numeric ID. Pattern-based sources trade the absolute precision of exact matching for the ability to apply a single rule to many URLs.

Domain-level sources: the source is an entire domain rather than a specific path. Every request arriving at olddomain.com regardless of path matches the source. Domain-level sources are the foundation of global redirects and domain parking configurations.

What a redirect source contains

A redirect source is defined by several components of the URL that together determine what it matches. Understanding each component helps configure sources correctly and avoid common matching errors.

The path: the part of the URL after the domain name and before any query string. /about, /blog/post-title, /products/category/item are all paths. The path is the most fundamental component of a redirect source for most redirect rules.

Query string handling: the ?key=value portion of a URL that appears after the path. How redirect rules handle query strings varies by implementation. Some sources match the path only and ignore query strings: a source of /page matches both example.com/page and example.com/page?ref=newsletter. Others treat the query string as part of the source and require it to be specified explicitly. Understanding how the tool or server handles query strings prevents unexpected matching behaviour.

Trailing slash: whether /about and /about/ are treated as the same source or different ones depends on the server configuration and redirect tool. Many servers treat these as different URLs by default. A redirect rule with source /about may not match /about/ unless trailing slash normalisation is configured. This is a common source of redirect rules that appear to work in testing but fail for a subset of real-world requests.

Case sensitivity: URLs are technically case-sensitive. /About and /about are different URLs. Most web servers on Linux-based systems treat them as different: a redirect rule with source /about does not match /About. Windows-based servers may handle case insensitively. For redirect sources, defining rules to handle both cases, or configuring case normalisation, prevents missing redirects for users who type URLs with unexpected capitalisation.

URL encoding: URLs containing special characters, spaces, or non-ASCII characters are percent-encoded. A URL with a space becomes %20 in the encoded form. A redirect source must match the encoded form of the URL as it appears in the actual request, not the human-readable decoded form. Mismatches between encoded and decoded forms are a common cause of redirect rules that fail to match their intended source URLs.

Redirect sources in different contexts

Redirect sources are defined differently depending on the context in which the redirect is being configured.

Path-level sources: the most common form for rules within a single domain. The source is a path starting with /: /old-page, /old-section/*, /blog/2023/*. The domain is implicit: the rule applies to the domain it is configured on. This is how the vast majority of redirect rules in .htaccess files, server configs, and redirect management tools are defined.

Full URL sources: some redirect tools and configurations accept full URLs including the scheme and domain as the source: https://example.com/old-page rather than just /old-page. This is useful when managing redirects across multiple domains from a single interface, where the path alone would be ambiguous without the domain context.

Domain sources: the source is an entire domain, olddomain.com, without a specific path. All requests to the domain match regardless of path. Used for global redirects, domain parking, and domain migration configurations.

Subdomain sources: the source matches a specific subdomain, old.example.com, or a pattern of subdomains, *.example.com. Used when retiring or reorganising subdomain structures.

Redirect source accuracy and SEO

The accuracy of redirect sources has direct implications for SEO. A redirect rule is only as effective as its source matching, a rule that does not match the actual URLs being requested does nothing, and all the link juice and SEO equity from backlinks pointing to those URLs is lost.

Exact source matching for important pages: for pages with significant backlink profiles or traffic, the pages where preserving SEO equity matters most, the redirect source should be defined as precisely as possible. An exact match source ensures the rule fires reliably for the specific URL that backlinks are pointing to, without risk of accidentally matching unintended URLs.

Source verification after configuration: after configuring a redirect rule, always verify that the source is matching incoming requests correctly. The most common verification is a direct request to the source URL, using a browser, curl, or a redirect checker, to confirm the server returns the expected redirect response. A rule that looks correct in a management interface may fail to match real requests due to trailing slash differences, query string handling, or encoding issues.

Monitoring for unmatched sources: server logs and Google Search Console surface URLs that are returning 404 errors rather than being matched by redirect rules. These are redirect sources that were not configured: URLs that visitors and crawlers are requesting but the server has no rule for. Regularly reviewing 404 reports and adding redirect rules for high-traffic or high-equity missing URLs is an important part of ongoing redirect management.

Bulk redirect source accuracy: when importing large numbers of redirect rules via CSV or bulk import, source URL accuracy across hundreds or thousands of rows is critical. A systematic approach to source URL generation, exporting URLs directly from the old site’s CMS or analytics rather than manually typing them, minimises errors and ensures sources match the actual URLs that traffic and backlinks point to.

Common redirect source mistakes

Trailing slash inconsistency: defining a source as /about when real-world traffic arrives at /about/, or vice versa. The redirect rule never fires because the source does not match the actual URL format visitors use. The fix is to either define both variants as sources pointing to the same destination, or configure trailing slash normalisation at the server level so both formats are treated equivalently.

Wrong case: defining a source as /About on a case-sensitive server when actual traffic arrives at /about. The case mismatch prevents matching. Always define sources in the exact case that matches the actual URLs being requested, or configure case-insensitive matching if needed.

Missing URL encoding: defining a source as /café in decoded form when the actual request arrives as /caf%C3%A9 in encoded form. The encoding mismatch prevents matching. Sources should always use the encoded form of any non-ASCII characters.

Overly broad pattern sources: a wildcard or regex source pattern that matches more URLs than intended, catching live pages that should not be redirected. Always test pattern sources against a representative sample of URLs including ones that should not match before deploying.

Forgotten query string variants: defining a source that matches the clean path but missing the same path with common query strings appended. If significant traffic arrives at /old-page?ref=email and the redirect source is only /old-page, some traffic may not be matched depending on query string handling configuration.

Source URL with fragment: URL hash fragments, the #section part of a URL, are never sent to the server in HTTP requests. They exist only in the browser. Defining a redirect source that includes a fragment, /page#section, will never match any server request because the fragment is stripped before the request leaves the browser. Sources should never include fragment identifiers.

Redirect source in redirect management tools

In redirect management tools and interfaces, the source is typically the first field in a redirect rule: the “from” URL. Most tools accept path-level sources, /old-page, and handle the domain context implicitly based on which domain the rule is being configured for.

Good redirect management tools provide source validation: checking that the source URL format is valid, flagging obvious issues like absolute URLs where relative paths are expected, and warning when a source pattern might conflict with existing rules or match URLs that are currently returning live content.

When configuring sources in bulk, importing hundreds or thousands of rules via CSV, the source column should contain consistently formatted URL paths. Common formatting inconsistencies in bulk imports include mixed use of trailing slashes, inconsistent encoding of special characters, inclusion of domain names when only paths are expected, and mixed case across rows. Normalising the source column before import prevents these inconsistencies from causing rules to fail silently.

Redirect source vs redirect destination

The redirect source and redirect destination are the two halves of every redirect rule and are worth understanding clearly in relation to each other.

The source is the URL visitors and crawlers come from: the old address, the URL being retired, the URL that triggers the redirect. It is where the redirect rule listens for incoming requests.

The destination is the URL visitors and crawlers are sent to: the new address, the current canonical URL, the URL that returns live content. It is where the redirect rule sends matched requests.

The relationship is one-directional. A redirect from source A to destination B does not create a redirect from B back to A. The source is always the incoming URL and the destination is always the outgoing URL. Configuring both directions, A to B and B to A, creates a redirect loop.