301 redirects: the list that saves a migration's traffic

A website migration almost never loses its traffic because of the new design. It loses it through its URLs: pages that received visits for years change address, and nothing tells search engines or visitors where they went. The document that prevents this is a list, boring and decisive: the redirect list. It comes after sorting the pages, as described in our method to decide which pages to keep, merge or delete, and before the switch. It is the core of any migration to a static site.

What a redirect says

The status code is not a detail. Google’s documentation on HTTP status codes sorts them into two families:

Google adds, in its page on redirects, that a JavaScript redirect should only be used when neither the server nor a meta refresh tag can do it: the search engine might never see it if rendering the page fails.

Where old URLs come from

The classic trap is redirecting the pages you know: the ones in the menu. The URLs that matter are the ones that receive something, and many of them are in no menu at all.

1. 01A crawl of the current site.

   Every URL reachable by following links, with its response code.

2. 02The sitemap actually served.

   The one the host returns, not the one you think you configured.

3. 03Sixteen months of Search Console.

   Pages that got clicks or impressions, seasons included.

4. 04Inbound links.

   URLs that other sites cite, sometimes pages forgotten for years.

5. 05The URLs you have spread.

   Campaigns, email signatures, PDF documents, printed QR codes.

The result is a four-column table: old URL, new URL, code (301 or 410) and the reason for the decision. The reason pays off the day someone asks why a page disappeared.

The rules that hold

One hop, to the final destination

Each redirect adds a request before the page displays, and chains grow with every redesign: the 2015 URL redirects to the 2019 one, which redirects to the 2026 one. Google sets clear markers:

Google’s crawlers, for their part, follow at most ten hops before giving up. In practice, a migration also rewrites the old redirects: each one now points to the new final URL, not to an intermediate step.

Never the home page by default

Redirecting every vanished page to the home page looks safe. Google treats it as a disguised 404 error, and a visitor looking for a specific page lands on one that does not answer them. A page with no replacement says it no longer exists (404 or 410); a merged page redirects to the page that took over its content.

Variants of the same URL

An old URL often exists in several forms: with or without www, over http or https, with or without a trailing slash, with capital letters. Each variant must reach the same place, in one hop. Campaign parameters (?utm_source=…) must survive the redirect, or tracking for running campaigns breaks on the day of the switch.

On this site, a URL without a trailing slash still answers with a temporary redirect to its slashed version: it is a known gap of our hosting setup, which is why all our internal links carry the slash. Better to know your gaps than to discover them in Search Console.

Where the rules live

A redirect is written in one place only. On a static site, that is a file versioned with the site and reviewed like the rest. On this site, every rule sits in a single file in the repository:

• prefixes: the old /en/ prefix, and the Spanish and Chinese URLs, archived on 9 September 2026, redirect to English;
• renames: the old blog categories, merged or renamed on 2 October 2026, lead to the new ones, articles included;
• exact URLs: the deleted pricing page redirects to the page that groups our offers;
• removals: three ghost pages answer 410, because no page replaces them.

A check refuses to deploy if a page still lives under a redirected URL: without it, the host would serve the page and ignore the rule. The order between files and redirects is not the same with every host either, as our comparison of static site hosting shows.

Test before, monitor after

Testing is done by script, not by hand, and with the right tool. On an online plush toy store we are putting back on its feet, a first check counted 516 temporary redirects that were in fact permanent: the platform did not answer the same way depending on the program asking. So check with a tool that behaves like a search engine crawler, and confirm a few URLs by hand.

After the switch, Google warns that a small or medium site takes a few weeks for most of its pages to move, and that visibility can fluctuate meanwhile. Two moves shorten the period: update internal links to the new URLs, so no visitor goes through a redirect, and submit the new sitemap.

Redirects in the rest of the project

A clean list protects traffic; it does not create it. The rest of the project matters just as much: a migration is priced with its takeover of the existing site (how much a business website costs), each hop adds a request that weighs on speed as measured by Core Web Vitals, and a multilingual site adds a list per language (one language, one URL). Leaving a WordPress site that keeps getting hacked is often what triggers the migration; form URLs change too (forms and search on a static site), as do those of a blog that changes tools (Markdown in the repository or a CMS, or a headless site with Astro and Sanity). The new site must be accessible, generate enquiries, can be hosted in Europe, and pages rewritten with AI raise the question of disclosing it.

Our static site migration starts with this list: an inventory of URLs, a written decision for each, redirects tested on the preview, then Search Console monitored for fourteen days after the switch. A new site with no history falls under the business website offer, which has nothing to redirect.

Frequently asked questions

Sources

1. Google Search Central, HTTP status codes and network errors (new tab)developers.google.com
2. Google Search Central, redirects and Google Search (new tab)developers.google.com