A redirect destination is the URL that a redirect rule sends visitors and web crawlers to when the rule fires. It is the second half of every redirect rule: the address that appears in the Location header of the server’s redirect response, telling the browser where to go next.

Every redirect rule has exactly two endpoints. The redirect source is the URL that triggers the redirect: the old address, the URL being retired. The redirect destination is where visitors and crawlers are sent: the new address, the current canonical URL, the live page that returns a 200 OK. The destination is sometimes called the target URL, the to URL, the new URL, or the forward address depending on the tool or context. Regardless of terminology it always refers to the same thing: the URL the redirect sends traffic to.

The destination is where the value of a redirect is realised or lost. A redirect rule configured with a precisely correct source but an incorrect, outdated, or broken destination sends visitors and crawlers to the wrong place, or to a dead end. Every SEO equity benefit, every preserved backlink, every retained visitor depends on the destination being correct, live, and returning the right content.

How a redirect destination works

When a server matches an incoming request against a redirect rule, it constructs a redirect response containing two essential pieces of information: the HTTP status code communicating the nature of the redirect, and the Location header containing the destination URL.

The browser reads the Location header value, the destination, and immediately makes a new HTTP request to that URL. If the destination returns a 200 OK the browser renders the page. If the destination returns another redirect, a second hop occurs and a redirect chain begins. If the destination returns a 404 error or 500 error, the visitor lands on an error page despite the redirect firing correctly.

The destination URL in the Location header must be a complete, valid URL that browsers and crawlers can request. It can be an absolute URL, including scheme, domain, and path, or a relative URL containing only a path. Absolute URLs are strongly preferred in practice because they are unambiguous and work correctly across all clients and configurations regardless of context.

What makes a good redirect destination

Not every URL is an equally good redirect destination. Several qualities distinguish a destination that serves visitors and SEO well from one that undermines the purpose of the redirect.

Returns a 200 OK: the single most important quality of a redirect destination. A destination that returns a live page with the expected content is the entire point of the redirect. A destination returning a 404 error sends visitors to a dead end. A destination returning a 500 error sends visitors to a broken page. A destination returning another redirect creates a redirect chain. Always verify destinations return 200 before deploying redirect rules.

Is the correct canonical URL: the destination should be the canonical URL of the content: the single definitive address search engines should index. If the destination has canonical tags pointing elsewhere, or is itself a non-canonical duplicate, the redirect is sending equity and traffic to the wrong address. The destination of a 301 redirect becomes the canonical URL for the content; it should already be configured as such.

Is the most relevant equivalent content: for domain migrations and URL restructuring, the destination should be the page on the new domain or URL structure most equivalent to the source. Redirecting every old URL to the new homepage rather than to equivalent pages loses path-level SEO equity and provides a worse experience for visitors following links to specific content.

Is served over HTTPS: redirect destinations should always be HTTPS URLs. Redirecting to an HTTP destination means visitors arrive over an unsecured connection. Any 301 redirect pointing to an HTTP destination should be updated to point to the HTTPS equivalent.

Does not itself redirect: a destination that itself redirects creates a redirect chain. Every redirect rule should point directly to the final destination returning a 200. Before deploying a redirect, trace the destination URL to confirm it resolves directly to a 200 without additional hops.

Is stable and permanent: a destination URL that changes frequently requires frequent updates to all redirect rules pointing to it. Where possible, destinations should be stable, long-lived URLs that are unlikely to change. If a destination must change, all redirect rules pointing to the old destination should be updated simultaneously.

Redirect destinations and SEO

The destination is where SEO equity and link juice from a 301 redirect ultimately accumulates. The quality of the destination determines how much of that equity is realised.

Equity transfer to the destination: Googlebot follows the redirect, processes the HTTP status code, and consolidates the ranking signals from the source URL, backlinks, traffic history, authority, to the destination URL. This consolidation happens at the destination. A destination that returns a 200 with relevant, high-quality content receives the full benefit of the transferred equity.

Destination relevance matters: search engines do not blindly transfer equity from any source to any destination. A 301 redirect from a highly specific article page to an unrelated destination homepage is less effective than a redirect to the most relevant equivalent article. Google has indicated that redirects to topically relevant destinations pass equity more effectively than redirects to unrelated pages. The closer the destination content is to the source content, the more completely equity transfers.

Duplicate content at the destination: if the destination URL serves content that is also available at other URLs without clear canonical tag signals, the equity transferred through the redirect is split across multiple versions of the content rather than consolidating on a single canonical page. The destination should have clean canonicalisation: one URL, one canonical address, clear signals.

Crawl budget at the destination: redirecting large volumes of traffic and equity to a destination domain affects how Googlebot allocates crawl budget to that domain. A significant influx of redirected authority from a well-established source can increase crawl frequency on the destination domain as search engines respond to the new equity signals.

Destination URL formats

Redirect destinations can be expressed in several formats. Understanding the differences helps configure destinations correctly across different tools and server environments.

Absolute URLs: include the complete URL with scheme, domain, and path: https://newdomain.com/new-page. Absolute URLs are unambiguous and work correctly regardless of which domain the redirect is configured on. They are the preferred format for all redirect destinations, particularly for cross-domain redirects.

Protocol-relative URLs: begin with // rather than https://: //newdomain.com/new-page. The browser uses the same protocol as the current request. This format was once used to handle HTTP and HTTPS transparently but is now considered a poor practice because it can result in HTTP destinations when the source request is HTTP. Always use fully absolute HTTPS URLs.

Root-relative paths: begin with / and are resolved against the current domain: /new-page. A root-relative destination of /new-page configured on example.com sends visitors to example.com/new-page. This format only works for same-domain redirects; it cannot be used for cross-domain destinations. For same-domain redirects it is a valid and clean format.

Relative paths: do not begin with / and are resolved relative to the current path. These are fragile and unpredictable in redirect contexts: their meaning changes depending on the path of the source URL. Relative paths should never be used as redirect destinations.

Dynamic destinations

Some redirect configurations generate destination URLs dynamically rather than pointing to a fixed address. This is most common with wildcard and regex redirect rules where the destination incorporates captured segments from the source URL.

A wildcard redirect matching olddomain.com/* with a destination of newdomain.com/* uses the captured path segment from the source to construct the destination dynamically. olddomain.com/about becomes newdomain.com/about. olddomain.com/blog/post-title becomes newdomain.com/blog/post-title. The destination is not fixed: it varies based on what the source URL contained.

A regex redirect uses back-references, typically $1, $2, etc., to insert captured groups from the source pattern into the destination. A rule matching ^/products/([0-9]+)/old-detail$ with destination /products/$1 uses the captured product ID from the source URL to construct the destination, /products/12345/old-detail becomes /products/12345.

Dynamic destinations require additional care in verification because the destination varies with input. Testing should cover a representative sample of source URLs to confirm the dynamically generated destinations are correct and return 200 responses across the range of expected inputs.

Verifying redirect destinations

Destination verification is a critical step before deploying any redirect rule. A redirect with a broken or incorrect destination actively harms users and SEO; it is worse than having no redirect at all in some cases.

Manual verification, visit the destination URL directly in a browser and confirm it returns the expected page with the correct content. This is sufficient for individual rules but impractical for bulk imports.

curl: curl -I https://destination-url.com/path returns the HTTP response headers including the status code. A destination returning 200 OK is live. A destination returning a 3xx redirect creates a chain. A destination returning 404 or 500 is broken.

Bulk destination checking: when deploying large numbers of redirect rules via CSV import, running the destination URL column through a bulk URL checker before import confirms that all destinations are live and returning 200 responses. This is an essential quality control step for any large-scale redirect deployment.

Post-deployment monitoring: after deploying redirect rules, monitor destination URLs for changes over time. A destination that was live at deployment can be moved, deleted, or changed later, turning a previously correct redirect into one pointing at a 404 or redirect chain. Regular audits that re-verify destination URL status catch these regressions before they cause lasting SEO damage.

Common redirect destination mistakes

Destination returns 404: the most common and most damaging destination error. The redirect fires correctly but sends visitors and crawlers to a page that does not exist. All SEO equity transferred through the redirect goes nowhere. Always verify destinations are live before deploying.

Destination returns another redirect: creates a redirect chain. Trace the full chain from source to final destination before configuring any redirect. The destination field should always contain the final destination URL, the URL that returns a 200, not an intermediate URL that redirects further.

Destination is HTTP rather than HTTPS: a destination on an insecure HTTP URL undermines the security of the redirect. Update all destinations to their HTTPS equivalents.

Destination is the same as the source: a redirect rule where the source and destination are identical creates a redirect loop of one hop: the URL redirects to itself indefinitely. Always verify that source and destination are different URLs.

Destination is too generic: redirecting specific pages to the homepage rather than to the most relevant equivalent page. This loses path-level SEO equity and delivers a poor experience for visitors following links to specific content. Take the time to map important source URLs to their most relevant destinations rather than defaulting everything to the homepage.

Destination changes after deployment: the destination URL is moved or retired without updating the redirect rules pointing to it. The redirect begins pointing to a 404 or new redirect chain. Implement a process for keeping redirect destinations current as the destination site evolves.

Dynamic destination generates invalid URLs: a wildcard or regex rule generates destination URLs that contain invalid characters, incorrect paths, or unexpected formats for certain source inputs. Test dynamic destination generation across a representative range of source URLs before deployment.