How to Monitor Rankings and Traffic After a Site Migration
If you are reading this because performance has fallen since your site moved, the short answer is that a drop is normal. The useful questions are how deep, how long and which way it is going. The third of those is the one that tells you anything.
A Drop Is Normal
Performance almost always falls after a migration. That is the ordinary consequence of a site changing rather than evidence that something has gone wrong. Knowing it in advance is what stops a normal fortnight becoming a crisis.
Why it happens even when everything was done correctly. Re-assessment.
Addresses have changed, pages have moved and everything has to be revisited and assessed again. That process takes place gradually rather than instantly. During it the picture is incomplete. An incomplete picture produces lower numbers than a complete one.
Why nobody warns you properly. It sounds like an excuse.
Saying a drop is expected, after a drop has happened, sounds exactly like somebody covering for a mistake. Said beforehand it is a forecast. Said afterwards it is indistinguishable from an apology, which is why it belongs in the plan rather than in a difficult meeting.
The three questions that matter. Depth, duration, direction.
How far it fell, how long it has been falling and which way it is moving now. The third is worth more than the other two combined, because a decline that has stopped and begun returning is behaving correctly regardless of where it currently sits. Depth on its own tells you almost nothing.
What we will not tell you. How far is normal.
No published source supports a figure and we do not invent one. Anybody quoting a typical percentage is describing their own experience of their own sites rather than anything about yours, which differs in size, age and how often it is visited.
What To Measure Against
Against the benchmark taken before anything changed, rather than against last month. That distinction sounds pedantic and it decides whether the numbers mean anything at all.
Why last month is the wrong comparison. It was a different site.
Comparing the new site's first fortnight with the old site's last fortnight compares two different things, one of which no longer exists. It also compares two different points in the trading year, which introduces a second variable nobody accounted for.
What seasonality does to this. Manufactures a crisis.
A quiet period following a busy one produces a decline with nothing to do with the migration. Businesses have panicked, spent money and made changes for exactly that reason. The changes then made everything harder to read, which turned an imaginary problem into a real one.
What the benchmark should contain. Per the audit.
Visibility, traffic by page rather than in total, whatever the business counts as a result and the queries that matter commercially. Taken before anything moved, because it cannot be taken afterwards at any price.
If nobody took one. Use what exists.
Year on year comparison is imperfect and better than nothing. It at least removes the seasonal problem, even if it cannot separate the migration from everything else that changed in a year. That is a reason to take the benchmark next time rather than a reason to despair now.
The Three Things To Watch
Watching everything produces noise rather than insight. Three things carry nearly all the signal. They answer different questions in a deliberate order. That order is itself the useful part.
Whether new addresses are being found. The leading indicator.
This moves first, before anything else does. It tells you whether the mechanical part of the migration is working. If new addresses are not being discovered at all, nothing further is worth analysing.
Whether old addresses are behaving. The diagnostic one.
Whether they still resolve, whether they redirect and whether any are returning errors. This is where a mapping gap announces itself. It is also the source people check last when it should be second, because it looks like a technical detail rather than a commercial one.
Whether performance is recovering. The lagging one.
Visibility, traffic and results. This moves slowest and gets watched most, which is the wrong way round: by the time it moves, the causes are weeks old and the opportunity to correct them cheaply has gone.
Why the order matters. Causes before symptoms.
The first two explain the third. Watching only the third means watching a symptom with no access to its cause, which is how a fortnight gets spent on speculation.
Page Level, Not Site Level
Site totals conceal exactly what you need to know. A migration affects different parts of a site differently. Averaging that into one number destroys the information.
What a total can hide. A section collapsing.
One area failing completely while another rises can produce a stable total. The site looks fine and something important has stopped working, which is the worst possible situation because nobody investigates a number that looks acceptable.
Why the rise happens. Rebuilds change emphasis.
A new structure frequently promotes something that was previously buried, which is a genuine improvement. That is not compensation for what was lost. A total treats them as though it were, which is the whole problem with totals.
What page level reveals. Patterns with causes.
Whether the affected pages share an address type, a template or a section. A pattern points at a mapping gap and can be traced to a cause. Scattered losses point at something else entirely, usually the general re-assessment rather than a fault.
Where to start. The priority list.
The addresses identified as most valuable during the audit, checked individually rather than sampled, because a sample of ordinary pages can pass completely while every address of one type fails. What to do with what you find is in redirect errors and recovery after migration.
Search Console And Analytics Are Different Views
The two reporting sources measure different things and will not agree. That is not a fault in either. Expecting them to match wastes a great deal of time during a period when time matters.
What the search side shows. What the search engine did.
Which addresses it knows about, which queries produced appearances and which received clicks. This is the view of the mechanism rather than of your visitors, which makes it the earlier warning of the two.
What analytics shows. What people did.
Who arrived, where they went and what happened next. This is the only source that connects an address to a commercial outcome, which makes it the one that matters to the business and the one that moves last.
Why they differ. Different measurement entirely.
Different definitions, different collection methods and different treatment of the same visit. Two sources of truth about a migration is not a problem to resolve. It is two instruments with different purposes. Trying to reconcile them produces nothing useful.
How to use them together. One for cause, one for consequence.
The search side tells you whether the migration is being processed. Analytics tells you what it is costing. Both answers are needed and neither substitutes for the other. The mechanism for each is covered in our separate material on those platforms.
Tracking Traffic Drops
A traffic drop is a symptom with several possible causes. The useful work is narrowing which. That is done by shape and distribution rather than by depth.
Look at where it fell. Not how far.
Whether the loss is concentrated in one section or spread evenly across the site. Concentrated losses have a specific cause and can be traced. Even losses are usually the general re-assessment described in block one, which is a waiting matter rather than a fixing one.
Look at what kind of traffic went. Search or everything.
If direct visits and referrals fell alongside search, the cause is unlikely to be the migration's search handling. Something more basic is wrong, else something outside the site changed. That distinction redirects the whole investigation.
Look at when it fell. Against the launch.
A drop starting exactly at launch points at the migration. A drop starting a fortnight later may be something else entirely. Treating it as migration damage sends the investigation in the wrong direction.
Look at whether it is still falling. The direction test again.
A decline that has flattened is settling. One still deepening is not. That is the distinction worth acting on rather than a depth figure.
What Warrants Action
Being told to wait without being told what would change that is not advice. Four things warrant acting rather than watching. None is defined by a period.
Old addresses returning errors. Immediate.
A mapping gap that will never improve on its own, however long anybody waits. This is not a waiting matter and it should be checked on day one rather than found in week four, by which time the addresses have been failing throughout.
A decline that keeps deepening. Wrong direction.
Settling looks like decline, then stabilisation, then return. Something still falling well after launch is not following that shape. The shape is the diagnostic rather than the timing.
Complete flatness. No movement at all.
Instability is a sign of processing. A perfectly flat line at a lower level can mean nothing is happening at all, which is worth investigating rather than waiting out, since waiting only ever helps when something is already under way.
One section failing while the rest is fine. A pattern.
Patterns have causes and causes can be found. This is the most tractable of the four and the one most likely to be fixable today rather than eventually.
Do Not Change Anything While Watching
Every change made during this period destroys the only clean reading available. That is the argument, made from measurement rather than from technique.
What makes the reading clean. One variable.
Immediately after a migration, one thing changed. Any movement has one candidate explanation, which is a luxury that never exists at any other time in a site's life.
What a second change costs. The luxury.
Two things changed means two candidate explanations and no way to separate them. Three means the question becomes unanswerable. The site enters a state where nothing can be attributed to anything.
The two exceptions. Both narrow.
Fixing migration problems, which is the point of watching in the first place. And anything genuinely urgent for the business, which is a commercial judgement rather than a technical one. The rule protects diagnosis rather than stopping the business operating.
What to do with everything else. A list.
Write it down and act on it once the site has settled. Nothing on that list is urgent, while having one is itself a form of doing something. It also means the work is not lost, which is the objection people usually have to waiting.
How Long To Watch
Until performance has stabilised and any effect is visible. That is a judgement rather than a period, deliberately not a number, because a number would be wrong for most of the sites reading it.
Why no period is given. It depends on the site.
Size, how much changed and how often the site is visited all move it. Those differ enormously between businesses. Anybody offering a fixed timescale is describing a different site, which is set out in how long Google takes to process a migration.
What stabilised looks like. Movement stopping.
Readings settling into a consistent pattern rather than swinging about. Whether that pattern sits at the old level, above it or below it is a separate question, addressed by the recovery guide rather than this one.
Why the attention fades too early. Nobody scoped it.
The build was scoped and the watching was not, so it happens on goodwill. By the time effects are visible, everybody has been reassigned to something else. Goodwill does not survive a competing deadline.
What prevents that. Reserved time.
Named people and named time, agreed during planning rather than found afterwards. Work that is not scoped does not happen when everybody is busy, which is precisely when the watching period arrives.
Reporting Is Not Fixing
Watching a number fall is not the same as doing something about it. A monitoring arrangement producing reports and no actions is an expensive way of being informed about a decline.
Why this happens so easily. Reports feel like work.
A weekly report is visible, regular and demonstrably being produced. It looks like the situation is being handled, while producing it is genuinely effort. None of that is the same as anything changing on the site, which is the only thing that moves the numbers back.
What the gap looks like. Familiar.
Six weeks of reports each describing the same decline, each read by somebody who assumed the person producing it was also addressing it. Nobody was. The reports were accurate throughout, which is what makes the failure so hard to see from inside it.
What closes it. Two words in an agreement.
Who acts. Not who reports, not who reviews. Who is responsible for doing something when the report says something is wrong. Also what they are authorised to do without asking anybody.
The question worth asking your supplier. Directly.
When this report shows a problem, what happens next and who does it. An answer describing more analysis is not an answer. The diagnosis itself is in how long rankings take to recover. The full series is on the website migration guide.
A report is
not the same
as a fix.
Performance compared against the benchmark rather than last month, read at page level because totals hide a collapsed section, the causes watched before the symptoms rather than after them, nothing else changed while the reading is still clean, with somebody named who acts rather than somebody who reports.
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.
