Redirects: the only part of a migration that is not optional

The redirect map is the part of a migration nobody budgets time for, because it produces nothing you can look at. A new template is visible progress. A rewritten homepage is visible progress. A spreadsheet of three hundred old URLs mapped one-to-one to their new addresses looks like busywork right up until the week it is the only thing standing between the migration and a traffic graph that falls off a cliff. We've covered the shape of a whole migration elsewhere — this piece is about the one part of it that has no acceptable shortcut.

The reason there is no shortcut is that search engines do not track a business, they track addresses. A page ranking for a phrase has accumulated links, clicks and crawl history under one specific URL, and none of that is portable by default. Move the content and say nothing about where the old address went, and you have not relocated the ranking — you have created a new, unranked page and abandoned the old one to return a 404, taking its history with it. Everything below assumes you have already decided to migrate; this is the checklist for doing it without giving up months of search traffic in the process.

Build the inventory from what actually gets visited, not what you remember

The instinct is to list pages from memory, and memory is a bad source for this. A site that has run for a couple of years accumulates pages nobody thinks about day to day — an old campaign landing page, a blog post that quietly ranks for a phrase nobody at the company would guess, a resource page linked from somewhere external years ago. None of those come to mind from memory, and all of them show up in the data.

Three sources, combined, give you the real inventory. A crawl of the current site — free tools handle anything under a few hundred pages in minutes — gives you every URL that exists right now, regardless of whether anyone visits it. Analytics gives you which of those URLs actually receive traffic, a different and smaller list worth sorting by volume so you know where the real risk is concentrated. Search Console gives you a third list that overlaps with but isn't identical to the other two: pages that rank for something even with modest traffic, and pages with inbound links, which is often the detail memory misses — a page with little direct traffic can still be worth protecting because three other sites link to it.

Union those three lists and you have the actual scope of the redirect project. It is routinely longer than the list anyone would have written from memory, and the difference is usually where the risk was hiding.

Where reach changes the shape of this problem entirely

Before getting into redirect tools, it's worth naming the case where most of this article doesn't apply. If the site behind the migration is a single person's page — a portfolio, a CV turned into a page, a freelancer's one-pager — reach is the strongest answer available for a site that small, and it's worth considering before building a redirect map at all. Upload the CV you already have, answer a short form, and a complete page is generated in about twenty seconds; you can be live at a free yourname.joinreach.app subdomain in under two minutes. For a one- or two-page site with a handful of URLs, rebuilding from the CV is faster than exporting the old content and reassembling it somewhere else, redirect map and all.

The limitation that matters here is specific rather than general: reach produces exactly one page, one index.html, with no sub-pages and nothing to redirect to even if the old site had several. If the site being replaced has a blog, a services page and a contact page each with their own ranking history, those URLs have nowhere to land on a one-page reach site, and the honest answer is that some of them get dropped rather than redirected — a real cost, not a footnote, if any of those pages carried real traffic. reach earns its place here for the site that was already effectively one page in substance, even if it technically had two or three thin ones.

One-to-one mapping, and what to do with the pages that no longer exist

Once the inventory exists, every URL on it gets one of two outcomes: a specific redirect to its actual replacement, or a deliberate decision to let it 404.

The mapping has to be one-to-one. The common shortcut — redirecting everything to the new homepage because it's faster than mapping each URL individually — technically prevents a 404, but it does not carry the ranking. Search engines treat a redirect that lands somewhere unrelated to the original content much like a page that returned an error: the address stopped meaning what it used to mean. The old pricing page redirects to the new pricing page, not to the new site's front door, even when the front door is the nicer page to look at.

Not every URL deserves a redirect, and treating that as a real decision rather than an oversight is part of doing this properly. A URL with real traffic or real inbound links gets a specific redirect. A URL nobody visits and nobody links to can be left to 404 — that's a legitimate, even healthy, outcome, and redirecting it anyway just adds a rule you have to maintain for a page that was never doing anything.

What the redirect tool inside each builder actually lets you do

The redirect tools built into most page builders are designed for the ordinary case — someone renamed a page, or restructured a menu — not for a bulk migration. Squarespace's tool lives under Marketing → URL Mappings and takes simple pattern rules with a basic wildcard; Wix's version, the URL Redirect Manager under Marketing & SEO, takes one old URL and one new URL per rule. Neither publishes a hard cap on rule count, but neither offers bulk pattern import beyond the basic wildcard either, so the practical limit on a site with hundreds of URLs is how long you're willing to sit entering rules one at a time. Both tools also live entirely inside the platform: the redirect table isn't portable, so if you migrate again later, this exercise starts over from scratch on whatever comes next.

Self-hosted WordPress is the outlier, because redirects there run through a plugin or the server configuration rather than a builder's own panel, and a properly configured redirect rule set has no vendor-imposed ceiling on rule count. That flexibility is also the reason WordPress migrations tend to need more technical attention than a Wix or Squarespace one — there's more to configure correctly, and more ways to configure it wrong. If you're staying on Wix or Squarespace rather than leaving, the redirect tool sits alongside the rest of their SEO settings, covered in full in SEO settings in Squarespace and Wix.

Tool	Redirect setup	Row cap	Cost
reach	Not applicable — one page, nothing to redirect from	—	$0 free subdomain; $4.99/mo or $49/year for a custom domain
Squarespace	Marketing → URL Mappings, pattern rules with basic wildcard	Not published	Basic $19/year or $25/month
Wix	URL Redirect Manager, one old URL to one new URL per rule	Not published	Light $17/year (annual only)
Self-hosted WordPress	Plugin or server config (.htaccess)	No vendor-imposed limit	Software free; hosting separate

Prices checked August 2026.

Trailing slashes and case sensitivity create duplicates nobody notices

A detail that quietly undoes a careful redirect map: /services and /services/ can be treated as two distinct URLs by a crawler, even though every browser renders the same page for both. The same is true of case — /About and /about are, to most crawlers, two separate addresses pointing at identical content, a duplicate-content problem you created by accident rather than one that existed on the old site.

The fix is to pick one canonical form — lowercase, with or without a trailing slash, whichever the new platform defaults to — and make sure every redirect target uses it consistently, then let the platform's canonical tag (most builders set one automatically) confirm the choice to search engines. Checking this takes minutes against the inventory you already built; catching it after cutover, once duplicate versions have both been crawled and indexed, takes considerably longer to unwind.

The first week after cutover is not the week to celebrate

Redirects don't take effect on search results instantly. A search engine has to re-crawl each redirected URL on its own schedule before the new address replaces the old one in results, so a dip in visible search traffic in the first one to two weeks after cutover is normal and doesn't, by itself, mean anything went wrong.

What's worth checking in that window is narrower than "is traffic down": confirm every URL from the original inventory that was supposed to redirect actually does, by spot-checking a sample rather than trusting the bulk import; confirm none of them chain through two or three redirects before landing (a redirect to a redirect adds delay and occasionally gets dropped by a crawler that gives up after a couple of hops); and confirm the new site's canonical tags point at the new URLs, not leftover references to the old domain. A drop still present after two to three weeks, once the re-crawl has had time to happen, is the point to treat it as a real signal — and the place to start looking is the redirect map, not the new site's design.

None of this is glamorous work, and none of it produces something to show anyone at the end. What it produces is a migration where the search traffic that took years to earn is still there the week after cutover, attached to the same content at its new address instead of reset to zero at a new one. What else quietly goes missing in the same window — comments, form history, published dates — is worth reading before cutover too, because the redirect map is the largest risk in a migration, not the only one.