Redirect mapping, the part everyone skips

On one migration I mapped and verified 773 redirects.

The site had nothing like 773 pages. It had years of blog posts, resource pages, gated assets, tag archives and two previous URL structures layered on top of each other, and every one of those addresses was the destination of a link somebody else controls. The pages a person would count from the navigation were a small fraction of the number.

That gap is the whole subject of this post. A quote priced from the page count reads a deep archive as a small site, because the archive does not look like pages until you sit down to map it.

Getting the real URL list

There is one mistake here and everything else follows from it: building the list by crawling the current site.

A crawl finds what is linked from somewhere else on the site right now. It does not find the page you unlinked from the navigation two years ago that still gets four hundred visits a month from a Reddit thread. It does not find the campaign landing page that never had an internal link. It does not find the old permalink structure, because nothing on the site points at it any more, and it is still what every link from 2021 uses.

Four sources, and you need all four.

Three years is a starting point, not a rule. If the site has been publishing for a decade, go back a decade. Pulling more data costs an afternoon; missing a URL costs whatever that URL was earning.

Mapping one-to-one, many-to-one, and gone

Once you have the list, every row gets one of four decisions. Most of the work is in the last two.

One-to-one. The page exists on the new site with a different address. Straightforward, and roughly the share of the list people assume is all of it.

Many-to-one. Six thin pages have become one good page. This is normal on a rebuild and it is the right call, but it is a decision with a consequence: the equity consolidates, and it is worth knowing which of the six was actually earning the traffic before you fold it into something else.

Gone, with a relevant parent. The page is not coming back. It redirects to the nearest genuinely useful page: the category it sat in, the product it described, the hub above it. Not the homepage.

Gone, honestly. The page is not coming back and nothing on the new site is about it. This gets a 404 or a 410, and that is a legitimate answer.

The temptation to send everything unmatched to the homepage is strong, because it makes the spreadsheet go green. Resist it. A page that has no equivalent should say so; the visitor is one click from finding what they came for, rather than dropped at the top of a site with no idea what happened.

Webflow's redirect limits

Two constraints worth knowing before you promise anything.

Redirects require a paid plan, with a recommended ceiling around a thousand rules rather than a hard one. Source: Webflow pricing On a large archive that ceiling is reachable, and the way through it is not a bigger plan: it is wildcards.

Webflow supports pattern rules, so /blog/2019/* mapping to /blog/:splat replaces several hundred individual rows with one. A list of 773 URLs is usually a much smaller list of rules once the structural moves are expressed as patterns and only the genuine one-offs are written out. Build the full map first, then compress it. Compressing as you go is how a wildcard quietly swallows a page that needed its own destination.

The second constraint is that the rules are evaluated in order, so a broad pattern placed above a specific rule wins over it. Specific first, patterns underneath.

Verifying after launch

The map is a hypothesis until something checks it. Three things, in this order.

Request every old URL and record what comes back. Not a sample: the whole list, from the file you already have. You are looking for three failures: anything returning 404 that should not, anything returning 200 that should have moved (which means the rule never fired), and anything taking more than one hop.

Flatten the chains. A redirect pointing at a URL that is itself redirected still arrives, so nothing looks broken. On a site that has been through two previous migrations you will find links resolving in four hops. Point each rule at the final destination.

Watch Search Console for a month. The coverage report will show what the crawler is actually finding, which is the only opinion that matters on whether the map worked. Errors appearing in week three are normal and are usually URLs nobody knew existed, which is the fourth source you did not have.

Doing this well takes a day on a site of any size, and it is the cheapest day in the project. It is also the line item that separates two quotes that look like the same job: what a Webflow migration costs goes through the rest of what the lower one is leaving out.