The Redirects Nobody Set Up After a Website Relaunch

A joinery business with seven employees moves its site from a page builder to a custom-built platform during a relaunch — assume this is the trigger for this case. Three weeks later, the local search positions the firm had held for years are gone.

What migration included meant

The quote from the new developer listed one line: "content migration included." Nobody defined what that covered. In practice it meant: copy the text and photos from the old site, drop them into new templates, adjust the layout. URLs, the sitemap, and redirects never appeared in that scope.

That's where the usual break happens. The page builder had generated addresses like /services/fitted-wardrobes and /gallery/oak-kitchen-2019 automatically from page titles. The new, custom-built site used a leaner structure: /services/wardrobes, /projects/1. The content overlapped almost completely; the addresses didn't overlap at all. Without a mapping between old and new, the server returns a 404 for every old address. Google notices within days.

The second factor

In this case, a second issue compounded the first: the hosting move happened the same weekend as the platform switch, because both contracts happened to run out at month's end. Two fault patterns overlapped — missing redirects and DNS that hadn't fully propagated yet. Working out which problem caused which symptom took longer than either issue would have alone. It took two weeks before the redirect map was complete and the domain was stable again.

The math: lost leads and cleanup time

Before the outage, the firm's own estimate was six organic leads a week (an assumption, typical for a joinery outfit of this size with a strong local position). During the two weeks without rankings, that dropped to two leads a week; the rest still came through repeat customers and referrals. That's four lost leads a week, eight over two weeks.

Not every lead turns into a job. Putting an assumed average lost margin of €270 per lead on that — a rough figure built from typical job value and close rate for a firm this size — gives:

8 leads × €270 = €2,160 in lost margin.

Add the cleanup itself: five hours of the owner's time chasing the developer and testing links, at an assumed internal rate of €40/hour, comes to €200. The developer needed a further six hours to build the redirect map after the fact, at €90/hour, comes to €540. Cleanup total: €740.

€2,160 plus €740 comes to €2,900.

Checking the numbers the other way

If only one of the two migrations had been involved, the confusion would likely have lasted one week instead of two. Four lost leads at €270 comes to €1,080. Owner time would likely have halved, to two hours (€80); the developer's time stays the same six hours (€540), since building the map takes just as long either way. Total: roughly €1,700. Not half — the developer's fixed cost doesn't shrink with less downtime.

If the fault had gone unnoticed for four weeks instead of two — nobody in the business tracks rankings — lost leads climb to sixteen, or €4,320. Cleanup grows too: ten hours of owner time (€400) and eight hours of developer time (€720), for €1,120. Total: roughly €5,440. Nearly double, but not quite — the fixed developer cost again holds the number down slightly.

A second case: changing the domain, not just the platform

A four-person landscaping outfit — again a constructed example — changes both the platform and the domain in the same relaunch, moving from greenscape-services.co.uk to greenscape.design. A correct 301 redirect table alone isn't enough here. Google treats a domain change differently from a platform change: without the Change of Address tool in Google Search Console, the new domain gets treated as an unfamiliar, brand-new site, even when every single address redirects correctly. The old property in Search Console has to stay verified until the new one has fully taken over. Delete it too early, and the proof of the redirect goes with it.

The steps, in order

Inventory: export every indexed address, either through Google Search Console (the Pages report) or with a crawler such as Screaming Frog, before the old site goes offline. Mapping table: give every old address a specific new target — never a blanket redirect of everything to the homepage. Server-side setup: put the table into the server configuration as a 301 redirect, in .htaccess on Apache or the matching block on nginx, not as a JavaScript redirect in the browser. Post-launch check: test every old address individually, the status code has to read 301, not 302 and not 200 with the wrong content. Search Console follow-up: submit the new sitemap, and file the Change of Address if the domain itself moved.

Where the effort isn't worth it

On a site with three or four pages, few inbound links, and little organic traffic, a full mapping table is overkill. A single blanket redirect from the old domain to the new homepage covers it — there's barely any ranking to protect. The same goes for a genuine content overhaul, where the old pages are meant to disappear for good: redirecting a page about a discontinued service to an unrelated page confuses visitors more than it helps them. And a correct redirect table fixes nothing else about the new site. Slow load times or a broken mobile layout stay exactly as broken, regardless of the redirects.

Where this differs from the alternatives

Some developers use a JavaScript or meta-refresh redirect instead of a server-side 301. Search engines treat that as a weaker signal: link equity doesn't transfer reliably, and if the script runs slowly, the crawler may only ever see a blank page. Wildcard redirects — sending whole folders to a new pattern — work when the URL structure changes in one consistent way, say for a blog with numbered posts. On a site with individually named pages and an inconsistent new structure, wildcards point to the wrong targets. That's what the one-to-one table is for.