Everybody shows you the week after a migration. Here’s the week after that.
Most migration write-ups end on the good week. I’m going to give you both weeks, because the shape of the two together is the thing worth knowing, and because the number people quote at you is almost always the first one.
What happened when I moved 690 pages
Claims Bible is a UK claims publisher operating under an FCA authorisation, which means every page on it counts as a financial promotion. I co-founded it, so I can show you the whole thing rather than the part a client would let me publish. It had grown up on WordPress over five years, around 1,320 files, with years of accumulated address debt from sections that had been renamed, merged or abandoned. I rebuilt it as a custom static build of about 2,800 lines of Node that generates between 670 and 690 pages, and it cut over on 19 August 2026.
Comparing the week before cutover with the week after, search clicks went from 484 to 611, which is up 26%.
The week after that, 27 August to 2 September, they came back to 443, which is below where they started. Over the eighteen days after cutover against the eighteen before, clicks were up 7%. Average position went from 22.5 to 23.7, so slightly worse.
There’s one more thing about those numbers that nobody tells you. When I first wrote this up, on the day, Search Console showed 442 going to 563, and a position that had improved rather than slipped. By 8 September, Google had revised both. Figures read on the day of a cutover are not final, and if you report them to a client that week you will be explaining a different set a fortnight later.
The result I’d actually point to is the one that kept going. On the tracked keyword set, visibility went from 28.0% on 18 August to 40.2% on 8 September, and the site passed moneysavingexpert.com on 1 September and was still ahead three weeks later. In the week after cutover, 332 tracked keywords improved against 168 declining, and 78 reached the first page for the first time. A click count over seven days is noisy. Where a few hundred keywords are sitting three weeks later is not.
Indexed pages fell from about 1,100 to 751, against a target of roughly 670. That fall was the point. A lot of what the old site had sitting in Google was duplication and thin pages competing with each other, and a migration that leaves the page count where it was has usually not done the hard part.
Why sites lose traffic in a migration, and it isn’t the technology
I want to be careful here, because this is the part of the subject where everybody has a percentage and almost nobody has a source. I have one migration with proper before-and-after figures. One data point cannot support a range, so I’m not going to give you one.
What I can describe is the mechanism, and I think the mechanism is the answer anyway.
The dip is organisational rather than technical. Redirect mapping is not difficult work. It is long, dull, unglamorous work that has to be done by somebody who cares about the outcome, and on most projects the person doing it is not the person who will be blamed in November. The agency’s fee is for the build. The invoice goes out at launch. Nobody’s payment is contingent on the site still having its traffic three months later, and so the step that protects the traffic is the step that gets compressed when the timeline slips.
And without a page-level baseline, the excuse is always available. This is the part that keeps it going. Search Console will not give you a page-level history retrospectively once the old addresses are gone. So when traffic is down in November, there is no way to show which pages lost it, and the conversation becomes a discussion about an algorithm update, or seasonality, or the market. Every one of those explanations is unfalsifiable, which is exactly why they get used.
I’d rather be straight that this cuts at me too. Even on the Claims Bible move I do not have a page-level before-and-after capture. I have totals, positions, keyword visibility and an index count, and I did not take the top-twenty-pages-by-clicks snapshot before the URLs changed. That is the single most useful thing to capture and I didn’t capture it. It’s the reason the section further down exists.
What the work actually is
If the dip is organisational, then the fix is mostly a matter of refusing to compress the dull part. On this move that meant a redirect file of 344 lines, and a separate list of 98 addresses that were deliberately gone.
Those 98 matter more than they sound. Five years of WordPress leaves a lot of paths that should not resolve and should not redirect either, because sending somebody who asked about a retired claim type to a live one puts them on a page about a claim they were not asking about. Those return 410 Gone through a Cloudflare Worker, which tells a search engine the page is intentionally finished rather than temporarily broken. A 301 to the nearest living page is the lazy option and it produces a site full of near-misses.
The bit I’d most like people to take from this is the eighty-four. I had 84 broken paths to map onto live pages, most of them lender-specific pages in the unaffordable lending section. The obvious way to do that is fuzzy string matching: run each dead slug against the live ones, take the closest match, done in an afternoon. I wrote it, ran it, and then read the output properly.
It had confidently mapped salary-finance to jaja-finance, and amigo-loans to bamboo-loans, and five more like them. Seven wrong lenders, each served with a 200 OK, each one a page about a different company’s lending practices, on a site under an FCA authorisation.
So I threw it out and rebuilt the classifier as exact slug match, then hand-verified alias, then section hub, and nothing else. It took considerably longer and it moved fewer URLs. On a regulated site a wrong page served correctly is worse than a missing one, and I’d argue that holds on an unregulated one too, just with a smaller bill attached.
A later pass over the redirects found seven more holes that had been sending roughly 470,000 impressions’ worth of personal injury searches to dead pages. That recovery came from going back and looking, a fortnight after everybody had agreed the migration was finished.
What I capture now, so the next one isn’t a story
Here’s the method, because it’s more use to you than my conclusions are. Three moments, seven numbers, every time.
The three moments. Before anything is touched, which is the one that gets skipped and the one that cannot be recovered later. The cutover week, seven days either side, same days of the week. And twenty-eight days after, which is long enough for recrawling and reprocessing to settle, and is the honest window rather than the flattering one.
The seven numbers, at each of the three moments, with the date read and the source named.
- Total clicks and impressions, Search Console, 28 days.
- Clicks for the top twenty pages by clicks, at page level. This is the one that makes “there’s no page-level baseline” impossible to hide behind later, and it is the single most valuable capture of the seven.
- Average position across the same set, stated plainly as an average of averages and treated as directional only.
- Indexed pages from the coverage report, with the target written down, so that a fall reads as intent rather than as damage.
- Visibility on a tracked keyword set, with the set named and frozen before cutover so it is the same set afterwards.
- Conversions, meaning whatever the site’s real one is. Enquiries, calls, sales. Sessions are not the objective and should not be the headline.
- A note on measurement changes. Analytics reimplemented, consent mode altered, a tag missing. Some of what looks like lost traffic is lost counting, and if that isn’t written down at the time nobody can tell the two apart afterwards.
If you are commissioning a migration and you take one thing from this note, take number two. Ask for it in writing, before the work starts, and keep the file yourself.
Questions I get asked
Will I lose rankings when my site moves?
Not necessarily, and the honest answer is that it depends on whether the dull part gets done rather than on the technology you move to. What I would not promise you is a line that only goes one way. On the move described above clicks went up 26% in the first week and then fell below where they started in the second, which is normal, and a supplier who shows you only the first week is either not looking or hoping you won’t.
How long should I wait before judging it?
Twenty-eight days, and look at impressions and keyword positions before you look at clicks, because they move first. A page that looks like it has failed after three weeks usually hasn’t. Judging a migration on the week after cutover is how both the celebrations and the panics happen.
What happens to my old addresses?
Every one that had a genuine equivalent gets mapped to it by hand. The ones that have genuinely finished should say so with a 410 rather than being redirected to the nearest surviving page, because a redirect to something that isn’t the same thing is a worse experience than an honest dead end and it teaches search engines nothing.
My agency says the traffic drop was an algorithm update. Is that plausible?
It can be true, and it is also the least falsifiable thing anybody can say to you, which is why it gets said. The way to know is a page-level baseline taken before the move, because that lets you see whether the loss is spread across the site, which points at an update, or concentrated in the pages whose addresses changed, which points at the migration. If nobody took that baseline, the question cannot be settled, and that in itself tells you something about how the job was run.
If you’re moving a site
The technical work is knowable and most of it is written down above. What decides the outcome is whether somebody whose reputation is attached to the traffic does the mapping by hand and takes the baseline before anything moves.
If that’s a job you’re about to hand to somebody, send me the domain and tell me what’s moving and when, and I’ll tell you what I’d want captured before anybody touches it. That part is worth doing whether or not I’m the one who does the move.
The service this note is about is website rebuilds and migrations, and the full write-up with the rest of the build in it is the Claims Bible rebuild.
Moving a site with a history?
Send me the domain and tell me what’s moving and when, and I’ll tell you what I’d want captured before anybody touches it.