Redirects and URL stability

Compounding depends on URLs surviving. A post that earns links for three years and then changes address without a redirect has spent those three years building an asset it then discards. This page sets out which redirect to use, when a redirect is the wrong tool, how to build a redirect map for a migration, and how to verify that any of it worked.

The short answer

For a permanent move of a page you want indexed at the new address, use 301. For anything genuinely temporary, use 302. Use 307 and 308 when the HTTP method must not change, which for article URLs it never does. Redirect every old URL to its specific equivalent, never in bulk to the home page. Point every redirect directly at the final destination rather than through a chain. Keep them in place forever.

Then verify with curl -I -L rather than trusting the plugin that created them, because a redirect that silently became a chain is the most common way a migration leaks.

The four codes that matter

One more is worth knowing. 303 See Other deliberately converts the request to a GET, which is what you want after a form submission so that a refresh does not resubmit it. It has nothing to do with content migration and appears here only because it shows up in redirect chain output and gets mistaken for a misconfiguration.

Why 301 and 308 both exist

301 and 302 predate any requirement to preserve the HTTP method. In practice, clients routinely converted a POST into a GET when following them, and enough of the web came to depend on that behaviour that the specification could not simply be tightened. 307 and 308 were introduced to remove the ambiguity: they preserve the original method.

For a publisher moving article URLs, every request involved is a GET, so 301 and 308 behave identically. 301 remains the conventional choice and is the most widely understood by tooling, analytics and reporting. There is no benefit to switching to 308 for content, and a small cost in explaining it to every tool that reports on it.

The cacheability difference

A 301 is cacheable by default, and browsers cache it aggressively and for a long time. This is usually what you want and is occasionally a serious problem: a 301 deployed by mistake will keep sending returning visitors to the wrong place long after the server has been corrected, because their browser is not asking the server anymore. If you are uncertain whether a move is permanent, a 302 costs almost nothing and can be reversed. A mistaken 301 cannot be reversed for the people who already received it.

Redirects, canonicals, 404 and 410 are four different tools

These get used interchangeably and they solve different problems. Choosing wrongly is how an archive loses value quietly.

The distinction that causes the most damage is the first two. A redirect is not a canonical tag. A redirect moves people and machines to a different URL and makes the original unreachable. A canonical tag tells machines which of several reachable URLs is authoritative while leaving all of them reachable. Using a canonical where a redirect belongs leaves duplicate URLs in circulation. Using a redirect where a canonical belongs breaks a URL somebody needed.

The second most damaging is redirecting deleted content to the home page instead of returning an error. This is covered below because it deserves its own explanation.

The rules that matter in practice

Redirect to the equivalent page, not the home page

Mass-redirecting a retired archive to the root is treated as a soft error rather than a move. Search engines detect that the destination has nothing to do with the request and handle it as though the original URL simply failed, which means the accumulated value of those URLs is lost anyway. The reader experience is worse than a 404: someone who clicked a link to a specific article lands on a home page with no explanation and no path to what they wanted.

If an equivalent page genuinely does not exist, a 404 with a useful page, a search box and links into the relevant hub is a better answer than a dishonest redirect.

Avoid chains, and check for them after the fact

Each hop adds a round trip of latency and one more thing that can break. If URL A moved to B and B later moved to C, update A to point at C directly rather than leaving A pointing at B.

Chains form by accident and almost always through accumulation. A slug change, then a category restructure, then an HTTPS migration, then a domain move, each handled correctly in isolation, produces a four-hop chain for the oldest and most valuable URLs on the site. Nothing warns you. The redirects all work.

Crawlers follow a limited number of hops in a single attempt before giving up and returning later, and browsers stop entirely after around twenty. A redirect loop, where A points to B and B points back to A, fails immediately and visibly, which makes it the least dangerous of the two problems.

Redirect at the highest level you can

A rule in server or edge configuration is faster than a plugin that boots the application to decide where to send a request. For a small number of one-off moves this does not matter. For a migration with a thousand rules it is the difference between a redirect resolving in milliseconds and it resolving after a full application load, and it shows up in time to first byte for every visitor arriving on an old link.

Pattern rules also beat enumerated lists where the change is structural. If every URL moved from /blog/slug/ to /slug/, that is one rule, not four hundred, and one rule cannot develop gaps.

Keep redirects in place indefinitely

There is no point at which old links stop existing. Search engines consolidate signals to the new URL over a period of months, and that is often cited as a reason redirects can be retired afterwards. It is not a good reason. Links in other people’s archives, bookmarks, newsletter back issues, cited references and feed readers do not update, and removing a redirect discards whatever still points at the old address.

Redirects are cheap to keep. Treat them as a permanent part of the site rather than migration scaffolding.

Use server-side redirects, not meta refresh or JavaScript

A meta refresh or a JavaScript location change does eventually get a visitor to the right place. Both are slower, both require the page to load first, both fail if scripting is unavailable, and both are treated as weaker signals than an HTTP status code. They exist for situations where server configuration is genuinely not available. If you can set a header, set a header.

The four canonicalization decisions every site has already made

Before any content migration, four structural choices are already generating duplicate URLs unless they have been resolved. Each should resolve to exactly one form with a 301:

• HTTP and HTTPS. Every HTTP URL should redirect to its HTTPS equivalent, in one hop, including the home page.
• www and non-www. Pick one. Redirect the other. There is no correct answer and there is a wrong answer, which is serving both.
• Trailing slash. Pick one convention and enforce it. Serving both /post and /post/ as valid is two URLs for one page.
• Case. Paths are case sensitive on most servers. If uppercase variants resolve, they are separate URLs.

The compounding failure here is that these combine. A site serving both protocols, both hostnames and both slash conventions has eight URLs for every page. The redirect chain from the worst combination to the canonical form can be three hops before any content-level move is considered.

Building a redirect map for a migration

The map is only as good as the inventory of old URLs, and no single source is complete. Pull from all of these and deduplicate:

1. The old sitemap. Fastest source of every URL the platform knew about. Save a copy before the migration, because it disappears with the platform.
2. Server access logs. The only source that shows URLs real people and crawlers actually requested, including ones no sitemap listed.
3. Search Console. The Pages report shows what was indexed. The Links report shows which URLs earned external links, which is the subset that matters most.
4. Analytics landing pages. Export the full list over the longest available window, not the top fifty.
5. Backlink tools. Catch URLs that earned links but never earned traffic. These are the ones a traffic-based inventory misses entirely.
6. Old feed archives and the Wayback Machine. Useful for recovering the structure of an archive whose platform is already gone.

Then sort the map by external links pointing at each URL, not by traffic. Traffic tells you what people are finding now. Links tell you what the archive is worth, and links are what a broken redirect actually destroys.

A worked example of a real migration map, including the platform-specific path collision that has to be handled, is in the Substack to Ghost migration.

How to verify

The single most useful check is one command:

curl -I -L -o /dev/null -w "%{url_effective} %{num_redirects}n" https://example.com/old-url/

That reports the final destination and the number of hops taken. Any result above one hop is a chain to flatten. Run it against a sample that includes the oldest URLs, the most-linked URLs, and at least one from every structural pattern in the map.

Four further checks are worth doing after any migration:

• Confirm the status code is the one you intended, not a 302 emitted by a plugin default.
• Confirm the feed URL redirects. It is the most commonly forgotten URL on a site and the one subscribers cannot re-find on their own.
• Confirm the sitemap contains only destination URLs. A sitemap listing redirecting URLs wastes crawl budget and signals that the migration is unfinished.
• Watch Search Console for a rise in soft 404 reports, which is how the home page redirect mistake surfaces if it was made.

How this is scored

URL stability sits inside Compounding, which asks whether each new post makes the existing ones worth more. Band 1 is write-once publishing with no guarantee that URLs survive. Band 4 requires that posts route into maintained hubs and that URLs are stable over time. Band 5 requires that the archive demonstrably earns links and traffic independent of new publishing, which is impossible if the URLs those links point at have moved.

A publisher who has changed platform without a redirect map, or whose archive returns 404 for links that still exist elsewhere, has an archive that does not accumulate regardless of how good the writing is. This is the failure mode that is least visible from inside a publication and most visible from outside it, which is why a teardown checks it directly: sample the oldest URLs a subject ever published, and see what they return.

Questions

Does a 301 pass full link value?

Google has stated there is no loss from a 301 for signal consolidation purposes, and has said the same of chains within reasonable limits. Treat that as a reason not to worry about a single well-formed redirect, not as permission to build chains. The measurable costs of chains are latency and fragility, and those are real whatever the signal treatment is.

How long until a redirect takes effect?

Immediately for readers. For search engines, the old URL has to be recrawled first, and consolidation follows over weeks. A high-traffic URL updates quickly; a page nobody has requested in two years may take months.

Should I redirect an old post to a newer one on the same topic?

If the new post genuinely supersedes it, yes, and this is one of the better uses of a 301 in ongoing publishing rather than migration. If the old post is merely related, no. Redirecting a reader away from the thing they asked for towards something you would rather they read is the same mistake as the home page redirect, at a smaller scale.

What about query parameters and tracking URLs?

Do not redirect them individually. Handle them with a canonical tag pointing at the clean URL, and let the parameters keep working for whatever appended them. Redirecting a tracking URL breaks the tracking without helping anything.

Sources

• RFC 9110, HTTP Semantics, section 15.4, Redirection 3xx
• Google Search Central, Redirects and Google Search
• Google Search Central, Site moves with URL changes

Status code semantics verified August 2026 against RFC 9110. Search engine handling of redirects is documented behaviour rather than specification and has changed before, so this page records the state of the guidance on the date given.