Canonical Redirects

What a canonical redirect does

A canonical redirect is a server-side permanent redirect, a 301 or a 308, that sends a non-canonical variant of a URL to the single address you want indexed. Enforce it with one hop from every variant: Google counts a permanent redirect as a strong canonicalization signal, and it works best when it is permanent, direct, and backed by matching canonical tags, internal links and sitemap entries.

The phrase is practitioner shorthand; Google's documentation treats redirects as one canonicalization method and never defines a "canonical redirect," and the wording circulates mostly because WordPress ships a core function called redirect_canonical(). The variants it collapses are predictable:

• Protocol and host: http:// or the other hostname answering alongside the canonical one.
• Trailing slash: /page and /page/ both answering.
• Letter case: /Page and /page; paths are case-sensitive, hostnames are not.
• Default documents and legacy queries: /a/index.html for /a/, or a WordPress ?p=123 for the pretty permalink.

Crawlers cannot safely work this out alone. URI normalization under RFC 3986 treats lowercasing the scheme and host or dropping a default port as harmless, but adding a slash, removing www or stripping index.html may yield a different resource, so the site must pick one form and enforce it. Whether a duplicate should be redirected or canonicalized at all has its own guide; this page assumes it should stop being reachable.

How Google weighs a permanent redirect

Google's page on specifying a canonical URL describes a redirect as "A strong signal that the target of the redirect should become canonical" (Google Search Central). The same page applies the same word, strong, to rel="canonical", and calls sitemap inclusion weak. Nothing in that wording ranks a redirect above a canonical tag, so the common claim that a redirect "beats" a canonical is inference. The real difference is that a redirect removes the duplicate for people and crawlers alike, while a tag leaves both URLs working. Either way the choice stays with Google: a canonical preference is "a hint, not a rule."

Permanence decides whether the redirect counts. Google's redirects documentation says the indexing pipeline uses permanent redirects (301, 308, instant meta refresh, JavaScript location changes) as a canonical signal and does not use temporary ones (302, 303, 307, delayed meta refresh) that way. Its crawler documentation is softer and calls 302 and 307 a weak signal. Google has not reconciled the two wordings, but neither makes a temporary code right for a permanent decision, and server-side redirects are the ones Google says are most likely to be read correctly.

Google's crawlers follow up to 10 hops by default and ignore any content the redirecting URL returns. The five-hop figure in older articles, from a 2014 John Mueller remark, is superseded. Treat 10 as the failure point, not a budget; Google's site-move guide asks for a redirect straight to the final destination. Bing agrees on the tool: its webmaster team called a 301 the best fix for existing duplicates in December 2025, and its 2012 guidance noted that crawlers keep revisiting URLs that are merely canonicalized.

301 or 308, and the defaults that send a 302

RFC 9110 lets a client turn a POST into a GET when following a 301 and forbids that for a 308 (a permanent redirect that also preserves the request method). Google treats the two identically, so either suits page requests; a 308 earns its place where the old URL also receives form posts or API calls. The commoner failure is a 302 nobody asked for, because several standard tools default to it:

# Apache: state the code every time
RewriteRule ^old-page$ https://www.example.com/new-page/ [R=301,L]
# nginx
return 301 https://www.example.com$request_uri;
# WordPress: $status defaults to 302
wp_redirect( $redirect_url, 301 );

The WordPress case catches plugin and theme authors most, because core's own canonical function passes 301 while any other call that omits the status is temporary. Host and protocol rules belong to the canonical domain page; the rule that carries over is that no redirect ships without an explicit status.

WordPress and redirect_canonical()

Since version 2.3.0, core has hooked redirect_canonical() to template_redirect at the default priority and sent its redirects with wp_redirect( $redirect_url, 301 ), so they are permanent. It maps ?p=, ?page_id= and ?attachment_id= requests to pretty permalinks, matches www or non-www to home_url(), applies the permalink structure's trailing slash through user_trailingslashit(), and tidies pagination, old feed files and percent-encoding case.

Its limits matter as much. A core comment reads "Only redirect no-www <=> yes-www," and host capitalization is ignored because it "can lead to infinite redirects," so an alias domain pointed at the install is the server's job. It skips non-GET/HEAD requests, the admin, search, previews, trackbacks and the favicon. Whether it enforces HTTPS from home_url() is unconfirmed; handle the scheme at the server, host or plugin level.

Returning false from the redirect_canonical filter cancels the redirect. The blunt versions:

// Cancels every canonical redirect core would issue
add_filter( 'redirect_canonical', '__return_false' );

// Unhooks the function entirely
remove_action( 'template_redirect', 'redirect_canonical' );

Both are usually the wrong fix. Better is a callback that returns false only for the misbehaving request and hands $redirect_url back otherwise. Two cases call for it. Trac ticket #15551, marked invalid and then reopened, records /page/2/ on singular custom post types and custom queries bouncing to page one; its workaround applies the filter conditionally on parse_query. The other is 404 guessing, which redirects an unknown URL to the closest-matching slug; since 5.5.0, do_redirect_guess_404_permalink and its sibling filters control it, and they are the first place to look when a retired URL lands on an unrelated post.

Chains, loops and the redirect Googlebot never sees

Chains

Correct rules firing in sequence produce a chain: http://example.com/page to https://example.com/page to https://www.example.com/page to https://www.example.com/page/. Merge them so the first matching rule computes the final protocol, host and slash at once. Related: a canonical tag whose target redirects, which RFC 6596 advises against and Ahrefs reports as "Canonical points to redirect." After any redirect change, update tags to the final address.

Loops

Loops usually come from two layers correcting each other: a server rule insists on the bare domain while the WordPress Address says www, or a CDN passes plain HTTP to an origin that sends everything back to HTTPS. Decide which layer owns the canonical form and make the others agree, rather than adding another rule.

The HSTS 307

Sites that send HSTS (a header telling browsers to use HTTPS only) show a "307 Internal Redirect" in Chrome, but the browser generates it. Mueller: "Googlebot doesn't see the 307 that you'd see in the browser." The server 301 is still required.

Case rules

Mueller has said case matters for canonicalization. A blanket lowercasing rule, though, 404s on a case-sensitive server wherever the lowercase target does not exist, so test it against a crawl first.

Diagnosing redirects with curl, Search Console and crawlers

curl -sIL http://example.com/Page

-I fetches headers only and -L follows each Location. More than one 3xx line is a chain; a 302 or 307 anywhere is temporary. Run it per variant, since each often hits a different rule.

In Search Console's Page indexing report, "Page with redirect" is the expected state for a variant. "Redirect error" needs action: it covers overlong chains, loops, redirects exceeding the maximum URL length, and bad or empty URLs (Search Console Help). Inspect the destination rather than the redirecting URL, since Google's inspection tooling does not follow redirects, and compare the user-declared and Google-selected canonical.

Ahrefs reports "Redirect chain," "Redirect loop," "302 redirect" and "Page has links to redirect"; Semrush reports "Redirect chains and loops" and "Pages with temporary redirects." Prioritize links to redirects: they mean templates still emit variant URLs.

On WordPress, check the X-Redirect-By response header: wp_redirect() sends X-Redirect-By: WordPress by default, and since 5.1.0 plugins can substitute their own name. No header suggests the server or CDN; switching the redirect_canonical filter off on staging confirms whether core is involved.

When to redirect, and when to leave things alone

• Keep duplicates that serve users. Tracking parameters, filtered views and print versions have a reason to exist; give them a rel="canonical" instead, because a redirect takes the page away from the people using it. HTTP, wrong-host and index.html forms, which nobody needs, get the redirect.
• Fix links as well as redirecting. Google asks sites to "link to the canonical URL rather than a duplicate URL." A redirect is a safety net for stray links, not a replacement for correct templates.
• Filter, don't disable. A pagination bug in redirect_canonical() calls for a conditional filter, not removing the function sitewide.
• Leave working redirects in place. A correct single-hop 301 gains nothing from a tidy-up rewrite, which only risks a loop. After a migration, Google's site-move guide says to keep redirects "generally at least 1 year."
• Resolve disagreements rather than analyzing them. If a redirect and a canonical tag point to different URLs, there is no published tiebreaker. Mueller said in July 2026 that "There's no publicly defined order of precedence for metadata reconciliation" and that "if you're giving conflicting metadata, you should fix it."

Frequently asked questions