301 Redirects: Intent First, Then the Status Code

One question decides the code — and the 15% myth that will not die.

Permanent means you are never bringing the old URL back

A 301 tells Google that the old URL has been replaced and that the target should be treated as canonical — the version that gets indexed (Redirects and Google Search, last updated 14 April 2026).

So the first question is not which line of code to write. It is whether you can promise never to serve that old URL again.

If the change is reversible — a seasonal landing page, a product out of stock for three weeks, a test, a maintenance page — it is a 302. Google's own advice is to use a permanent redirect "when you're sure that the redirect won't be reverted".

Redirects live in the same crawl-and-index layer as status codes and canonical tags, which our SEO guide maps out end to end. This post only covers the moving part.

The redirect codes that matter

Google sorts redirect methods into permanent and temporary, and ranks them by how reliably it can interpret them. Server-side codes sit at the top; a JavaScript redirect sits at the bottom because Google has to render the page to see it at all.

The "equivalent to" wording is Google's, from its crawl reference (HTTP status codes, network and DNS errors, last updated 4 February 2026). The same page notes that these codes differ semantically even where Google handles them alike, so pick the one that is actually true — other clients rely on it.

Two further rules from Google's redirect documentation: use a permanent server-side redirect wherever you can, and do not rely on crypto redirects to tell search engines content has moved.

What actually passes through a 301

Google calls a redirect a strong signal that the target should become canonical, and lists it above rel="canonical" in its ordering of canonicalisation methods (How to specify a canonical URL, last updated 10 July 2026). That is the mechanism: the target inherits the old URL's place in the index.

You will still be told a 301 "loses 15% of link equity". No Google documentation states any such percentage, and Google's Gary Illyes said plainly that "30x redirects don't lose PageRank anymore" (reported by Barry Schwartz, Search Engine Land, 27 July 2016). Do not plan a migration around a number nobody at Google has ever published.

The difference from a canonical tag in one sentence: a redirect moves the visitor and the signal and leaves the old URL unreachable, while a canonical tag keeps both pages live and only states a preference.

Redirect chains and loops

A chain is a redirect that lands on another redirect. Google's crawlers follow up to 10 hops by default, the content of the intermediate URLs is ignored, and only the final target's content is processed.

Chains are not a syntax error. They are an archaeology problem, and they appear in real migrations like this:

• Rebrand one moves /seo-company/ to /seo-agency/.
• Rebrand two moves /seo-agency/ to /services/seo-services/, and nobody updates rule one.
• The HTTP-to-HTTPS rule adds a hop. The trailing-slash rule adds another.
• An old URL is now four hops from a 200 response, and every hop is a round trip for the user.

Google's site-move guidance says it in four words — "Avoid chaining redirects" — and advises redirecting to the final destination directly (Site moves with URL changes, last updated 20 August 2026).

A loop is the same fault closed into a circle: A points at B, B points back at A, and nothing ever resolves. It usually means two people each decided their URL was the survivor.

The rule that prevents both: never append a hop. When a destination moves again, go back and repoint every existing rule at the new final destination.

The one-to-one rule, and when to break it

Map each old URL to its closest equivalent on the new site, and redirect to that. Google's wording is to use server-side permanent redirects "from the old URLs to the new URLs as you indicated in your mapping".

The classic migration disaster is skipping the mapping and sending everything to the homepage. Google addresses it directly: "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site," because it can confuse users and may be treated as a soft 404.

Break the rule in exactly two situations:

1. Genuine consolidation. Five thin city pages become one real page. Google's site-move page accepts consolidating content onto one new page; the test is whether the new page actually answers what the old ones did.
2. No equivalent exists. A discontinued product with no replacement has no honest destination. Let it return 404, or 410 if you want to state that the removal is deliberate.

A clean 404 is an honest answer and it is handled, not feared — see how to deal with 404 errors. A redirect to an unrelated page is a worse outcome for the visitor and risks being read as a soft 404 anyway.

Implementation by platform

Do it at the server or edge if you can. A plugin-based redirect is executed by PHP after WordPress boots, which is fine at low volume and wasteful at thousands of rules.

Apache, in .htaccess:

# one URL
Redirect 301 /old-page/ https://example.com/new-page/

# a whole folder, keeping the rest of the path
RedirectMatch 301 ^/old-blog/(.*)$ https://example.com/blog/$1

Nginx, inside the server block:

location = /old-page/ {
    return 301 https://example.com/new-page/;
}

rewrite ^/old-blog/(.*)$ https://example.com/blog/$1 permanent;

In Nginx, permanent means 301 and redirect means 302 — one word decides the signal, so read the rule before you copy it.

Cloudflare handles this at the edge with Single Redirects for a handful of rules and Bulk Redirects for a list. Each entry is an expression plus a status code:

When:  (http.request.uri.path eq "/old-page/")
Then:  static redirect to https://example.com/new-page/
       status 301  ·  preserve query string: on

On WordPress, a redirect plugin or the redirects module in your SEO plugin is the pragmatic choice for editorial moves. Keep the rules in one place — two plugins each holding half the map is how chains start.

The check we run before a migration, and the one we run the morning after

The day before go-live. We build one list of every old URL worth keeping — from the XML sitemap, the Search Console page-indexing export and the server logs, because each one misses URLs the others catch. Every URL on that list gets a mapped destination in a sheet. Then we request the whole list against the staging environment with the redirect rules already loaded, and we are looking for one thing: a single hop to a 200. Not 301 to 301 to 200, and not 301 to 404.

The morning after. We re-run the identical list against production, because staging and production rarely carry the same rules. Then Search Console gets checked for movement in "Page with redirect" and "Not found (404)", and we inspect the handful of URLs that actually earn money by hand. Note while doing this that Google's crawl reference states its inspection tools do not follow redirects — so inspect the destination URL, not the old one.

Auditing the redirects you already have

Most sites have never looked. Redirect rules accumulate over years, nobody owns the file, and the person who wrote rule 40 has left.

1. Export the rules. From .htaccess, the Nginx config, the edge dashboard and every plugin holding a map.
2. Crawl the sources, not just the targets. Request each old URL and record the full hop sequence and final status.
3. Fix in this order: loops, then redirects ending in a 404, then chains, then temporary codes that have quietly been permanent for two years.
4. Repoint internal links. No link in your own navigation or body copy should point at a redirecting URL — see internal linking.
5. Re-check the sitemap. A redirecting URL should not be listed in your XML sitemap; the destination should.

How long to keep a redirect in place

Google's site-move guidance is specific: "Keep the redirects for as long as possible, generally at least 1 year." The same page notes that from a user's point of view they could reasonably be kept indefinitely.

Our practice is to keep them permanently unless the rule itself is causing a problem, because old links and bookmarks do not expire on a schedule.

Two related points from that page: submit a Change of Address in Search Console if you are changing domain or subdomain, and you do not need it for an HTTP-to-HTTPS move.

Organic recovery after a well-executed move is not instant either. Treat three to six months as the honest window before the new URLs settle, and keep measuring in the meantime — the rest of the checklist sits in our technical SEO post.