New site, new domain, or new platform. Every URL that changes is a page Google has to be told about, and the work that protects your rankings happens before launch, not after the drop.
They carry very different levels of risk, and the ones people worry least about are often the ones that cause the most damage.
What's actually changing
Six causes account for nearly all of it, and every one is preventable with work done before the site goes live.
The most common and the most damaging. Old pages return an error instead of pointing at the new equivalent, so everything they had built up is lost.
A shortcut that looks like it works because nothing errors. Google treats a mass redirect to one page as effectively deleting all of them.
A rebuild trims pages down for visual reasons. The page that ranked because it answered fifteen questions now answers four.
The block that stopped Google seeing the test site gets carried across to the live one. The whole site disappears from search within days.
Old redirects layered on new ones, so a page passes through four hops before arriving. Some of the value leaks at every step.
Problems are recoverable if caught in week one. The same problems found in month three have cost a quarter of traffic that then takes months to rebuild.
None of these are exotic. They happen because the migration was scoped as a design or development project and nobody owned the search side of it. If your new site is being built by someone else, this work still needs doing, and we're happy to do it alongside them.
The middle column is the only part most people plan for. The first column is where the outcome is actually decided.
Phase 01
Phase 02
Phase 03
The pre-launch record matters more than it sounds. Without it, when someone says traffic is down, nobody can tell whether it dropped, which pages dropped, or whether it's normal seasonal movement. That single spreadsheet is the difference between fixing a problem and arguing about whether there is one.
Even a well handled migration moves around for a while. Knowing the normal shape stops a panic in week two.
Week 1
Rankings shift as Google recrawls. Some pages up, some down. Unsettling and usually not meaningful yet.
Weeks 2 to 4
Most migrations lose some traffic temporarily while the new URLs are reassessed. A modest dip here isn't a failure.
Weeks 4 to 12
Things settle back toward where they were. This is the window where a genuine problem becomes obvious rather than debatable.
Beyond
If traffic hasn't recovered after a few months, it isn't going to on its own. Something needs investigating rather than waiting out.
A word on guarantees: nobody can promise zero loss from a migration, and anyone who does is either inexperienced or hoping you won't check. What can be promised is that the preventable causes are handled, the outcome is measured against a real baseline, and problems get found in the first week rather than the first quarter.
This is half the work we get asked for on migrations, and it's usually recoverable. Later than ideal, still worth doing.
The drop has to line up with the launch date. Sometimes it does and sometimes the timing coincides with something else entirely, and fixing redirects wouldn't have helped either way.
The old URLs still exist in archives, in Search Console history, and in the links pointing at you. That's enough to reconstruct what should have been mapped.
Pages that were earning the most come first. On a large site there may be thousands of broken URLs, and a few dozen of them account for most of what you lost.
Recovering months later is slower and usually incomplete. Most of it returns. Expecting every position back exactly as it was isn't realistic and we'd say so upfront.
A well handled migration usually sees a temporary dip that recovers within a couple of months. A badly handled one can lose a large share of traffic and take much longer to come back, if it does.
We won't quote you a percentage, because it depends on how much is changing and how much of your traffic comes from search in the first place.
Before the new site's structure is decided, ideally. Once the URLs are built we're mapping around decisions already made rather than influencing them.
The worst time is the week of launch, when everyone is busy and the mapping gets rushed. The second worst is after the drop.
Yes, and that's how most of these run. We produce the redirect map and the requirements, they implement it, and we verify against staging before launch.
It works better when we're talking directly rather than through you as a messenger. That's usually fine to arrange and worth doing.
Longer than most people do. A year at minimum, and permanently if there's no cost to keeping them, which on most setups there isn't.
Links on other sites don't get updated. Someone clicking a five year old link should still land somewhere useful.
Point them at the closest relevant page rather than the homepage. A discontinued product goes to its category, not to the front door.
If a page genuinely has no relevant destination and wasn't earning anything, letting it return an error is honest and fine. Forcing a redirect to something unrelated is worse than nothing.
If you can separate them, do. Doing both at once means that if something goes wrong you can't tell which change caused it.
Often it isn't practical, and then it's a matter of being more careful rather than avoiding it. We'd just want more time for verification before launch.
Usually scoped as a one-off project around your launch date rather than an ongoing retainer. Pricing sits on the main SEO page.
Related services
Thirty minutes on what's changing, what's at risk, and what needs doing before it goes live.
Or email hello@culmen.digital