How to Diagnose and Recover From Problems After a Site Migration
This page is ordered by how likely each cause is and how quickly it can be ruled out, rather than by subject. Worked through from the top it is an investigation rather than a catalogue. The order is the most useful thing on it.
Start With The Most Likely Causes
Somebody investigating a decline usually starts with whatever they last read about, which is rarely the likeliest explanation. The order below exists to prevent that. Following it will save days.
Why the order matters so much. Cost and probability.
The things at the top of this page are both the most commonly wrong and the fastest to check. The things further down are less common, take longer to establish and are frequently what people investigate first, because they are more interesting to think about.
What a bad investigation looks like. Interesting first.
A fortnight spent on content quality, competitor analysis and algorithm speculation, on a site that has been telling crawlers to stay away since the day it launched. Every one of those enquiries was reasonable in isolation. None of them was the answer. The actual answer took seconds to find, once somebody thought to look.
The rule to apply. Cheapest and likeliest first.
Rule out the things that take seconds before spending anything on the things that take weeks. That is unglamorous, it produces no impressive analysis, yet it is what a competent diagnosis actually looks like.
What to do before starting. Get the record out.
The pre-migration crawl and benchmark, wherever they were stored. Most of what follows is a comparison against how things were beforehand. Without that record several of these checks are simply not available at all, which is worth establishing before you begin rather than halfway through.
The Two Instructions To Check First
Whether the site is blocking crawlers, plus whether it is asking not to be listed. These take seconds, they account for the most damaging failures in this subject and they are the reason this block is second rather than ninth.
Why they head the list. Severity against effort.
Either one makes an otherwise flawless site invisible to search. Both are a single line of text. No other check on this page has anything approaching that ratio, which is why it is worth doing even when you are entirely confident it is something else.
Why confidence is misleading here. Nothing looks wrong.
The site loads, the design is correct and every page works exactly as intended. There is no symptom to notice at all, so being sure it is not this is a feeling rather than a finding. It is also a feeling shared by everybody who has ever had it happen.
What causes them. Competent work, one step missed.
Both protections were added deliberately, by competent people, to keep the unfinished site private. They travelled with the build because they are part of it. Removing them was a step on a list nobody kept, on a day when a great many other things were happening.
Where the detail sits. Its own guide.
Including why applying both at once makes the second ineffective, in crawling and indexing during a site migration.
Broken And Missing Redirects
Old addresses returning errors rather than redirecting are the most frequent genuine cause of migration damage. Every one of them is losing whatever it held, continuously, for as long as it stays broken. Nothing announces that it is happening.
How they happen. Omission rather than error.
Almost never a redirect that was built wrongly. Nearly always an address nobody knew existed, which therefore never appeared in the map and never got a destination assigned to it. The redirect is not broken. It was never created.
Which addresses are missed. Predictably the same kinds.
Parameter and filtered addresses, pagination, tag pages, plus leftovers from a previous migration that nobody currently at the business remembers. Old addresses carry old links, which is why the missed ones are disproportionately valuable.
How to find them. Two sources together.
The reporting on the old property, which shows addresses returning errors, then the pre-migration crawl compared against what now resolves. Neither source is complete on its own, so the union of the two is the working list.
What to do. Map and fix, in value order.
Each one gets a destination decided the same way any mapping decision is made, starting with the addresses carrying links or traffic. The method is in URL mapping for a site migration.
Redirect Chains And Loops
Both involve redirects pointing at redirects. They behave completely differently, which is why they are found at completely different times.
Chains. Working, inefficiently.
An address arriving at the right page after two or three steps rather than one. Everything functions, nothing reports an error anywhere and a check that confirms the destination will pass it without comment.
Why chains persist. The test is wrong.
Testing whether an address ends up somewhere correct finds nothing at all. Finding a chain requires counting the steps taken to get there, which is a different check and one that most testing does not perform.
Loops. Failing, visibly.
Two redirects pointing at each other, so nothing ever arrives anywhere. The page is completely unreachable and somebody reports it quickly, which makes loops the easier of the two problems despite being the more alarming one.
Where the dangerous ones hide. Untested address types.
A loop on a page nobody visits during testing can persist for weeks unreported, which is another argument for testing every address category rather than a sample of ordinary pages that all behave the same way.
Wrong Destinations
A redirect can function perfectly and still be wrong. If the destination is not a genuine equivalent of the original, the redirect is working and achieving very little.
What this looks like. Everything passing.
No errors, no chains, every single address resolving. A technical check reports a clean migration, while the pages that used to perform are quietly not performing. Nobody can explain the contradiction.
The commonest version. The home page.
Unmatched addresses swept to one destination. Every address resolves and nothing carries anything forward, since a destination with no relationship to the original has nothing to continue. The vendor's own guidance advises against it.
The subtler version. Approximately related.
An address pointing at a page in the same section rather than at the equivalent page. Considerably harder to spot, because the destination looks entirely plausible to anybody who did not know the original page.
How to find it. Read the map, not the responses.
Take the priority addresses and ask whether each destination genuinely does the job the original one did. That is a judgement rather than a test, which is precisely why no software will find this one for you.
Content That Did Not Survive
Pages that lost content during the rebuild are weaker than the pages they replaced. This produces no error anywhere and is entirely undetectable by looking at the new site.
What goes missing. Sections and detail.
Supporting paragraphs, technical detail, examples and anything held in a format the new system did not understand. The page still reads perfectly well without them, which is precisely the problem.
Why nobody notices. No reference point.
Somebody reviewing a page after a migration is reading it for the first time in that form. Without the original beside them, a page missing a third of its content reads as a complete page that happens to be fairly short.
How to detect it. Compare, do not read.
The pre-migration crawl against the current pages, looking at length and structure rather than at quality. A page substantially shorter than it used to be is the signal. It is also a signal a machine can find even though a reader cannot.
Why this one is worth the effort. Fully reversible.
Unlike lost links, lost content can be put back exactly as it was. It is the most recoverable problem on this page, provided somebody took the record beforehand, which is one more argument for the audit.
Internal Links Still Pointing At Old Addresses
Internal links that were never updated still work, because the redirects catch them. That is precisely why they are missed, which is also why an ordinary broken link check finds nothing.
What the check has to look for. Links that redirect.
Not links that break, since none of them do. Links arriving via a redirect they should never have needed, which is an entirely different question and one that most testing does not think to ask.
Why it matters during a diagnosis. It signals more.
A site full of internal links pointing at old addresses suggests the templates were carried across rather than rebuilt, which usually means other inherited things are worth checking too. It is a symptom of a wider inheritance rather than a fault on its own.
Where to look. Templates before content.
Navigation and footers repeat on every page, so one wrong address there is that address wrong thousands of times over. Correcting those first fixes the largest number of instances for the smallest amount of work.
Why it is worth doing regardless. Removes a dependency.
Corrected links no longer rely on redirects that somebody may tidy away in three years, which removes a dependency the site never needed to have.
Structural Changes Nobody Recorded
A page can survive a migration completely intact, with a perfect redirect, yet still lose position because its place within the site changed. This is the cause that gets missed after every other check has passed.
What changed. How the page is reached.
A page previously linked from the main menu and a dozen other pages, now reached from one place two levels down. The page itself is identical in every respect. Its position within the site is not. Position is expressed almost entirely through internal links.
Why it was never recorded. It was a design decision.
Menus get simplified for sound usability reasons. Nobody writes down that a section was demoted, because nobody experienced it as a demotion.
How to detect it. Compare the linking, not the pages.
The pre-migration crawl records which pages linked to which. Comparing that against the new structure is the only way to see this. It is also the last remaining explanation when everything else checks out.
What to do. Restore prominence deliberately.
A page removed from the main navigation can be linked prominently from elsewhere on the site, which recovers much of its position without undoing any of the design work that removed it.
Working Out Whether It Is Actually The Migration
Not every decline following a migration was caused by it. Something unrelated can coincide with a launch. Investigating the wrong cause costs weeks that were available for the right one.
Test one: timing. Exactly, not approximately.
A decline beginning on the day of the launch points at the migration. One beginning a fortnight later, after a period of normality, points somewhere else entirely and should be treated as a separate question with its own investigation.
Test two: distribution. Pattern or spread.
Losses concentrated in one address type or section suggest a migration fault, because migration faults have shapes. Losses spread evenly across unrelated parts of the site suggest something affecting the whole site rather than particular pages.
Test three: channel. Search only or everything.
If direct visits and referrals fell alongside search, the cause is unlikely to be search handling at all. The investigation should start somewhere entirely different.
Test four: everybody or just you. The one people skip.
If competitors moved at the same time and in the same direction, something external happened rather than something you did. That belongs with our material on algorithm updates rather than here. Mistaking one for the other is the most expensive error on this page.
What A Failed Migration Actually Looks Like
A failed migration is rarely a dramatic event. It is usually a quiet one that nobody identified for weeks, which is what makes it a failure rather than a setback.
What it is not. A site that went down.
An outage is visible, reported by customers and fixed within hours. That is a bad afternoon rather than a failed migration. It is also the thing everybody prepares for.
What it usually is. Something invisible, left running.
A blocking instruction nobody removed. A mapping that missed the addresses carrying the links. Content lost in the rebuild that nobody compared against the record. Each of those ran for weeks while everybody involved assumed the decline they were seeing was the normal settling period.
The common factor. Time, not severity.
Most of these are ordinary problems made serious by duration rather than by severity. The same fault found on launch day is an inconvenience taking minutes. Found in month three it is a recovery project taking weeks.
What is genuinely reassuring. Most of it is recoverable.
Redirects can be built now, content can be restored from the record, internal links can be corrected. What cannot be recovered is external links pointing at addresses that stayed broken long enough for the linking sites to remove them altogether. The wider catalogue is in common site migration mistakes. The full series is on the website migration guide.
Cheapest
and likeliest
first.
The two invisible instructions ruled out before anything interesting is investigated, the missing redirects found from two sources rather than one, destinations judged rather than tested because software cannot read intent, content compared against the record instead of read, with the structural demotion checked last because it is what remains when everything else passes.
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.
