Common Site Migration Mistakes That Damage Rankings
Almost none of these is a technical error. None was made by somebody incompetent. They are decisions taken by capable people who had no reason to know what would follow, at moments when nobody who did know was involved. That pattern is the whole subject.
The Pattern Behind Most Failures
Migrations rarely fail because somebody did something badly. They fail because a decision with a search consequence was made by somebody who had no reason to consider search, at a point where nobody who would have was in the conversation.
What that looks like in practice. Ordinary competence.
A developer chose an address pattern during setup. A designer simplified a menu. A project manager scheduled performance work for after launch. Each was doing their job correctly and none of them was wrong about their own subject. The consequences arrived weeks later, in somebody else's.
Why the consequence stayed hidden. It was not their subject.
Nothing about a menu tells you it also expresses which parts of a site matter most. Nothing about an address setting announces that it will apply to every page simultaneously. These are not obvious facts that people carelessly overlooked. They are facts belonging to a different discipline.
What follows from that. A sequencing fix, not a skills one.
The remedy is not better developers or more careful designers. Treating it as one produces nothing except resentment. It is somebody with the missing knowledge present at the points where these decisions get made, which is a scheduling change rather than a hiring one.
Why the framing matters. It determines whether you check.
A reader who believes these things happen to careless people will not look for them on their own project, because they know their own team is not careless. Almost everybody reading this has one of them in progress right now.
Not Knowing What You Had
No record of the old site means no way to establish what was lost, no way to prove anything recovered and no way to separate migration damage from anything else. It is first because everything below it depends on it.
Why it gets skipped. It produces nothing.
No page, no design, no visible improvement of any kind. A file that sits unopened unless something goes wrong is the easiest thing on any plan to defer. On a project running late it is the first thing to go. Deferring it is indistinguishable from deciding not to do it.
What becomes impossible without it. Most of a diagnosis.
Whether content was lost. Whether a page is shorter than it was. Which addresses existed. Which pages linked to which. Every one of those questions is a comparison. Comparisons need two sides.
Why late is the same as never. The subject stops existing.
Unlike everything else in this list, this one cannot be corrected afterwards at any price. The old site is gone, no budget recovers it and no supplier can produce it from anywhere.
What it costs to avoid. Very little.
A modest amount of time before a project that is already happening, set out in site audit before migration.
Changing Addresses Without Needing To
A great many migrations change every address on a site for no reason anybody can articulate afterwards. Each changed address needs mapping, testing and watching. Every one that did not need to change is cost with no benefit attached.
How it happens. Nobody was asked.
Address structure gets set during technical setup, before search has been raised, by somebody choosing what looks sensible. It is not a decision anybody remembers making, which is why it never appears in a project record.
Why it is expensive. It scales with the site.
One setting changes every page simultaneously. On a large site that converts a straightforward move into the largest mapping exercise the business has ever undertaken, without anybody choosing to take that on.
When changing is right. When the old structure was genuinely poor.
That is a real reason and it is a decision with a known cost, made deliberately and recorded somewhere, with a mapping attached to it. The problem is never the change itself. It is the change nobody chose.
The question that prevents it. One sentence.
Ask whether addresses will be identical afterwards, at proposal stage. A migration with no address changes is the cheapest and safest kind there is.
Incomplete Mapping
Maps built from a page list miss the same categories every time. That predictability is useful, because a known list of blind spots can be checked deliberately.
Why a page list is not enough. Sites have more addresses than pages.
Parameters and filters, pagination, tag and category listings, search results and old addresses still reachable through earlier redirects. None of those appears in anything anybody would reasonably call a page list.
Which omission costs most. The previous generation.
A site that has moved before carries addresses from that move. They still receive traffic and still hold links. They are also invisible to anybody working from the current site alone.
Why the person asked cannot help. They answer in good faith.
Somebody asked to list the site's pages produces the navigation and the content they can remember. Nothing in that process surfaces a filtered address from four years ago that a trade publication happened to link to once and nobody has thought about since.
What prevents it. Several sources combined.
A crawl, the search reporting, analytics and a link source, because each has blind spots the others cover.
Losing Backlinks
Everything else on a website can be rebuilt. Links pointing at addresses that stop working are lost in a way nothing else is, because somebody else owns the decision to make them.
Why they cannot be recreated. They were not yours.
Every one was a choice made by another organisation, frequently years ago, often by somebody who has since left. You cannot request them again, certainly not at the scale a mature site has accumulated.
How they are lost. Silently, by omission.
The linked address was missed from the map, so it stops working. Nothing reports this. The link still exists on the other site and now points at nothing, which is worse than never having existed.
Where they concentrate. On old addresses.
Links accumulate over time, so the oldest addresses carry the most. Those are also the addresses most likely to be forgotten entirely, which is an unfortunate pairing and the reason this subject appears more than once in this cluster.
What prevents it. A separate list.
Addresses with external links recorded during the audit, mapped by hand and tested individually before launch.
Redirect Chains
An address redirecting to an address that redirects again. Everything works, nothing reports an error and the site is doing more work than it needs to on every one of those requests.
How they build up. Successive migrations.
A site moves and old addresses point at new ones. Years later it moves again, then the new redirects are built from the current addresses rather than the original ones. The oldest addresses now travel through two hops, then three after the next move.
Why nobody finds them. The wrong test.
Checking that an old address reaches the right page passes, because it does reach it, eventually. Finding a chain requires counting the steps taken along the way, which is a different check and one that most testing never performs.
Why it matters. Speed and clarity.
Each hop is another request before anything appears. A longer chain is also a less direct statement about where content lives.
What fixes it. Flattening.
Every old address pointing directly at its final destination. Straightforward once found, which makes chains one of the better returns available after a move.
Changing Too Many Things At Once
A move that also rewrites content, redesigns everything and restructures the navigation is four changes arriving together. If performance moves afterwards, nothing can be attributed to anything.
Why it is tempting. Efficiency, genuinely.
Everything is being touched anyway, everybody is available and doing it all at once is considerably cheaper than four separate projects. That argument is sound in every respect except one. The exception is not obvious until afterwards.
What it costs. The only clean reading you will ever have.
Immediately after a single change, any movement has one candidate explanation. That situation exists at no other point in a site's life. Combining changes spends it.
What that means practically. Decisions made blind.
Somebody will decide whether the migration succeeded, whether the redesign worked and whether the new content was worth writing. All three get decided on evidence that cannot support any of them.
The alternative. Sequence them.
Move, settle, then improve. Slower, considerably more legible, which is the position taken throughout how to plan a site migration.
Nobody Owning The Search Side
This is not one mistake among several. It is the condition that allows all the others, which is why it sits in the middle of this page rather than at the end of it.
How the gap forms. Two reasonable assumptions.
The developer assumes the marketing side has search, since that is their subject. The marketing side assumes the developer has it, since it lives in the build. Both assumptions are entirely sensible and together they produce nobody.
Why it never surfaces. Unassigned work is never late.
A task nobody owns generates no meeting, no ticket and no escalation. It is not on any list, so it cannot slip. It appears after launch as a consequence rather than beforehand as a warning.
What the owner actually does. Less than expected.
They build nothing at all. They confirm the audit happened, the map exists, the tests were run and somebody is watching afterwards. It is a responsibility rather than a workload, which is why the objection about resource does not apply.
Why this is the cheapest control available. It costs a sentence.
Naming one person, in writing, at the start of the project. A project unwilling to name anybody has told you something useful about how the rest of it will run.
Launching Without Checking The Two Instructions
Whether the live site is blocking crawlers, plus whether it is asking not to be listed. Either makes a perfect migration invisible, both take seconds to check and neither shows any symptom at all.
Why competent teams ship them. They were correct decisions.
A site under construction should not be discoverable, so the protections were added deliberately. They live inside the build, so they deploy with it. Nothing malfunctioned and nobody was careless.
Why the last step gets missed. Launch day is crowded.
Removing a one-line instruction with no visible effect does not compete for attention against a form that is not submitting or a logo that came out wrong.
Why it survives so long afterwards. The warning conceals it.
The only symptom is a decline, while everybody was correctly told that a decline is normal. The one signal this produces is the signal the team has agreed to ignore for a few weeks.
What prevents it. A line on a list.
Not more knowledge, since everybody involved already knows. It belongs in the site migration SEO checklist rather than in somebody's memory.
Not Watching Afterwards
Attention ends shortly after launch, which is before most effects become visible. The most attentive period is the first day, when almost nothing has been processed.
Why it happens. The deliverable arrived.
A build project is scoped to produce a working site. Once it exists the contract is fulfilled, the team is allocated elsewhere and the budget is spent. Everything after that runs on goodwill.
Why goodwill is not enough. It has competition.
Work that was never scoped does not happen when everybody is busy. The watching period arrives precisely when everybody has moved on to the next thing.
What is missed by not watching. The cheap window.
Every problem in this list is inexpensive to fix on launch day and expensive in month three. Duration is what converts an ordinary fault into a recovery project.
What prevents it. Reserved time, named people.
Agreed during planning, with agreement in advance about what warrants acting rather than observing.
Removing Redirects Too Soon
Redirects get tidied away later, during a clean-up nobody connects to the migration. That single act undoes the work quietly, months after anybody is watching for it.
Why they get removed. They look like clutter.
A long list of addresses that no longer serve content looks like accumulated mess to somebody maintaining the site. Removing it feels like housekeeping rather than a decision with consequences.
Why the timing hides it. Nothing connects the two.
The removal happens long after the migration, so nobody links the decline that follows to the tidy-up that preceded it. Traffic simply stops arriving.
What the published guidance says. Checked August 2026.
The vendor's own site move documentation advises keeping redirects for as long as possible and generally at least a year, adding that from a user's perspective keeping them indefinitely is worth considering.
Why indefinitely is the right answer. Links do not expire.
A link made five years ago still sends people. Neither it nor the person clicking it knows anything about your migration timetable.
Nobody here
did anything
badly.
Somebody named for the search side before anything is decided, the old site recorded while it still exists, addresses left alone unless there is a reason to change them, one thing changed at a time so the numbers stay readable, the two invisible instructions checked within the hour, with the redirects kept rather than tidied away.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
