// SEO migration recovery

Your traffic fell off a cliff after the site move.

The site looks fine. Every page loads. But organic traffic dropped the week you launched and it has not come back. That is usually a handful of technical faults, and they are findable. Start with the free report on this site — it costs nothing and it does most of the diagnosis.

// The problem

“Our Google traffic fell off a cliff after the redesign”

It is the same story nearly every time. The new site went live, everyone was pleased with it, and then the numbers started falling. Nobody could point at anything broken, because from the outside nothing is.

Here is what makes it so hard to chase. A migration does not break the site — it breaks the connection between the site and everything Google already knew about it. Your old URLs carried years of accumulated ranking. If they now point nowhere, point at the wrong page, or point somewhere via three hops and a 302, that value is not transferred. It is simply dropped. Meanwhile every page renders perfectly for the one audience that cannot help you: visitors who already know your address.

So the usual reactions do not work. Rewriting the content will not help if the pages that earned the traffic no longer exist at the URLs Google has indexed. Neither will waiting, beyond a point. Every week the old URLs stay broken is a week Google spends removing them from its index.

// Why it happens

Four things break, and it is nearly always these

Not an exhaustive list of everything that can go wrong with a website. These are the four groups that actually cause traffic to fall after a move, and they are what the free tools on this site were built to detect.

Redirects: The old URLs are the whole asset, and a migration is where they get lost. A chain that ends on a 404. Deep pages all pointed at the homepage, which Google treats as a soft 404 rather than as a move. A 302 used for a permanent change, so nothing is passed on. A meta-refresh standing in for a redirect. Every one of these throws away the ranking the old URL had, and none of them looks broken in a browser.
robots.txt: The single fastest way to disappear. A staging Disallow: / that went live with the new site blocks every crawler on the internet. Blocking CSS and JavaScript is subtler and nearly as damaging, because Google renders the page and judges what it can see. And apex and www serving different robots files is a fault nobody finds by looking at one of them.
Sitemaps: XML that does not parse is discarded whole, silently. So are entries pointing at URLs that now 404, redirect, or carry noindex — you submitted a map of the site and Google kept none of it. Nested index files add a layer where this happens without ever showing an error.
DNS and host consistency: Apex resolving but www not, or the reverse. IPv6 published on one host and not the other, so some crawls reach a different site from others. An apex TTL of 24 hours or more, which turns any correction into a day of waiting. Small faults, and they make everything above them intermittent, which is the hardest kind of problem to diagnose.

Notice what these have in common: none of them produces an error message anybody sees. There is no alert, no broken page, no support ticket. The only symptom is a line on a graph going the wrong way, which is why these faults routinely survive for months after the migration that caused them.

// Free first

Most of the diagnosis is free. Genuinely.

This site gives away the technical scan, so it would be strange to pretend otherwise on the page that sells the follow-up work. Here is exactly where the line falls, so you can decide whether you need me at all.

The free Website Health Check

No signup · about a minute

Whether your redirects chain, loop, or land on a 404
Whether robots.txt is blocking crawlers, CSS or JavaScript
Whether your sitemap parses, and whether the URLs in it are real
Whether apex and www agree, and what your DNS is doing
The full verdict and the evidence, with nothing held back

Run the free check

What the paid work adds

Needs your Search Console and analytics

Which URLs Google actually dropped — from Search Console, not from a scan of the site as it stands today
What each one was worth, so the list is ranked by lost traffic rather than by severity
The rebuilt redirect map — old URL to new URL, reconstructed and deployed
Which three things to fix on Monday, rather than forty findings in a flat list
Whether the loss was caused by the migration at all

The short version: the free report tells you what is broken. The paid work tells you what it cost you, which URLs, and in what order to fix them — and it rebuilds the redirect map, which is where the actual labour is.

The reason a scanner cannot do the rest is simple enough. It sees your site as it is now. It has no way of knowing what used to be there, which of those pages earned anything, or what Google made of the change. That information lives in your Search Console and your analytics, and it is the difference between “your sitemap is malformed” and “these eleven pages were 60% of your organic traffic and they now 404”.

// What it costs

Four ways in

Everyone starts with the audit, because until somebody has looked at your Search Console nobody knows how big the job is — including me. Where you go afterwards depends on what it finds.

Crawl & Indexing Audit

$99 one-off

Everyone starts here. It also scopes everything else.

A ranked list of the URLs Google dropped, and what each was worth
Search Console coverage and crawl stats read properly
Analytics correlated, so the date the loss began is a fact
Full technical sweep of all four fault groups
A verdict on whether the cause is technical at all
What is already correct, not just what is wrong
Your old site’s URL count, which prices the rest

Most common

Redirect & Crawlability Repair

$299 one-off

The audit found technical faults. This fixes them.

Redirect map rebuilt from Search Console history, the old sitemap, analytics and archived copies
Deployed, or handed to your developer to apply
Chains collapsed to single hops
robots.txt corrected, apex and www reconciled
Sitemaps regenerated and validated
DNS and TTL faults settled where they apply
Up to 500 URLs

Audit fee credited — you pay the difference, not both.

Repair + 30-Day Monitoring

$599 one-off

The repair, then someone watching what Google does with it.

Everything in the repair
Search Console resubmission, and change of address where the domain moved
Coverage re-checked across 30 days
New crawl errors caught while they are still cheap
A written 30-day report on what was recrawled and what still errors
Up to 500 URLs

Audit fee credited — you pay the difference, not both.

Recovery Monitoring

$49 per month

Afterwards, so the next change does not undo it.

Coverage reports read every month
New crawl errors flagged as they appear
Progress tracked against the agreed baseline
Monthly summary in plain English
Monthly in advance, cancel anytime, never auto-renewing

Three things about those prices, before you ask

The 500-URL cap is on your old site’s indexed URLs — not your new site’s page count, and not every crawlable variant. Above that, the repair tiers are quoted after the audit, because rebuilding a redirect map scales almost linearly with URL count. A twenty-page brochure site and a five-thousand URL shop are not the same job and it would be dishonest to price them as one.
The audit fee is credited for 30 days. Come back inside a month and you pay the difference. After that it lapses, and the reason is not a sales tactic: the audit genuinely ages. The site changes, Google recrawls, and a diagnosis of a site that no longer exists would have to be redone from scratch. The same 30 days applies to upgrading the repair to the monitored version at the difference.
If the audit finds the cause was not technical, that is the end of it. The fee is earned, you get the reasoning in writing, and there is nothing further to buy — so the credit applies to nothing. Better said now than discovered later.

These are launch prices for a new practice rather than a permanent position, and they will go up once there is finished work behind them. If your situation does not fit any of the four, say so in the form and I will tell you honestly whether it is worth doing at all.

// What I need

What you have to supply

Listed openly, because it is the fastest part to get wrong and the slowest part to chase. If you cannot grant something below, say so — there is a workaround for most of it, and one genuine exception.

Access — least privilege, always

Google Search Console, as a Full or Restricted user. Not owner, and I will decline owner if offered. This is the one item with no workaround — without it the audit is a scan you could have run free, and I would tell you so rather than invoice for it.
Analytics read access. GA4, or whatever you actually use. This is what turns a list of broken URLs into a list ranked by what they cost you.
Somewhere to deploy redirects, or a developer who will apply a map I supply. Server config, CDN rules or a plugin — whichever your stack uses.
DNS zone editing, only if apex, www or TTL findings apply. Not your registrar login. Full registrar access carries the power to transfer or lose your domain, and that is not a liability worth accepting for work that does not need it.

Information — and the first item matters most

What changed, and exactly when. Redesign, replatform, domain change, host move, HTTPS migration. The date matters more than anything else on this page, because it is what the traffic gets correlated against. A drop that began three weeks before the launch is a different problem entirely.
The old site’s URL list, if it exists at all. An old sitemap, a crawl export, a CMS dump, a backup. If none of that survived, say so — reconstructing it is real work and it belongs in the repair tiers, not the audit.
Any redirects already in place, including ones a previous developer added and nobody documented.

Protecting the work

Your current redirect rules and robots.txt, exported before anything changes. That is the rollback, and it exists before the first edit.
Written authorisation naming the site, what will change, and the rollback plan.
Written agreement on the baseline — which metric is being tracked, over which period, compared against what. This is about the reporting being meaningful, not about defining success: the work is delivered when the work is done, and the baseline is how you read the report afterwards.

// Scope

What I will not promise you

Rankings and traffic are decided by the search engine and cannot be guaranteed by anyone. Google says so itself: its documentation states plainly that it cannot make predictions or guarantees about when or if URLs will be crawled or indexed. This engagement covers diagnosis, correction of crawlability and redirect faults, rebuilding the redirect map, and resubmission for crawling.

If the loss was not caused by a technical fault, the engagement ends with the audit fee earned and the reason in writing. A core update, a manual action, seasonality or a genuine content problem are all real causes, and not one of them is fixed by redirects.

Recovery is not instant, even when the fix is correct. Google has to recrawl before anything changes, and its own guidance is that a medium-sized site takes a few weeks for most pages to move in the index — longer for large ones. Weeks, not days. You are hearing that before you pay rather than after.

Some of it may not come back. If the migration removed pages entirely, or competitors took those positions in the months since, restoring the technical position does not restore the ranking. That is worth knowing before you spend anything.

Saying this plainly costs me some sales, and it is still the right way round. Nobody controls Google’s crawl schedule, so a competitor offering you a traffic guarantee is either misinformed or counting on you not checking. The top tier is called “Repair + 30-Day Monitoring” rather than “Full Recovery” for exactly this reason: it is named after the work, because the work is the part I can actually deliver.

// Billing

How payment works

Plainly, so nothing about it is a surprise later. There is no account to create, no portal to log into and no card stored anywhere.

You apply through the form

No payment at this point, and no commitment. Tell me the domain, what changed, and when the traffic started falling.
I review it and confirm the scope

If it is not worth doing, I say so here and it costs you nothing. If it is, you get the scope in writing before any invoice exists.
An invoice arrives, payable within 48 hours

It carries an invoice number and a due date. Unpaid past 48 hours, the application lapses and the slot is released to somebody else.
Work begins once payment is received

Not before. For one-off work there is nothing to suspend after delivery, so payment comes first — that is the standard arrangement and it runs both ways.
Monitoring, if you take it, is monthly in advance

Non-payment simply stops the reporting. Nothing is billed silently in the background and you can stop whenever you like.

// Not moved yet?

If the migration has not happened yet

Everything above is about repairing damage already done. If you are still planning the move, the same work costs a fraction as much and prevents the problem instead of chasing it.

What that involves

The URL map built before launch, not after. Every indexed old URL matched to its new home while the old site still exists to be crawled — which is the single reason this is so much cheaper done in advance.
Redirects tested on staging, before anything is pointed at the public internet.
Staging kept out of the index, and the Disallow: / removed on launch day. That one line going live with the new site is the most damaging single fault in this whole document.
TTLs lowered in advance, so a mistake is minutes to undo rather than a day.
Monitoring from launch day, so a problem is caught in the first week rather than at the end of the quarter.

Mention the planned date in the form and I will quote it as its own piece of work. Redirects still need keeping afterwards, incidentally — Google's site-move guidance is at least a year where possible, and where the domain changes it treats 180 days as the floor. Removing them a month after launch because the migration “was finished” is its own way of causing this problem.

Run the free check, then send me the result.

It takes about a minute and costs nothing. The Website Health Check tests your redirects, robots.txt, sitemaps and DNS together and shows you everything it finds, with no signup. If it comes back clean, the cause is probably not crawlability and I will tell you where to look instead. If it comes back with findings, paste them below and you have already done part of the audit yourself.

Send me a message ↓

Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.

// FAQ

Questions

Can I just run the free check instead?

Yes, and you should, before contacting me about anything. The Website Health Check on this site tests your redirects, robots.txt, sitemaps and DNS together and shows you everything it finds — free, no signup, no email address. It is the same technical sweep I would run. If it comes back clean, the cause is probably not crawlability, and you have narrowed it down without spending anything. If it comes back with findings, send me the result and you have done the first part of the audit yourself.

Then what does the paid audit actually add?

Three things a scanner cannot reach, because they are not visible from outside your site. Which URLs Google actually dropped, from Search Console rather than from a crawl. What those URLs were worth, from your analytics, so the list is ranked by lost traffic instead of by severity. And the redirect map — the old-URL to new-URL inventory rebuilt from your old sitemap, Search Console history, analytics and archived copies. The free report tells you what is broken on the site as it stands today. It has no way of knowing what used to be there.

How long until my traffic comes back?

Longer than you want, and it depends on a schedule nobody outside Google controls. Google's own documentation says a medium-sized site takes a few weeks for most pages to move in the index, and larger sites take longer. So the honest answer is weeks, not days, even when the fix is correct and applied on day one. Anyone giving you a date is guessing.

Can you guarantee my rankings come back?

No, and neither can anybody else. Google states plainly that it cannot make predictions or guarantees about when or if URLs will be crawled or indexed — that is the search engine itself declining to promise, in its own documentation. What I guarantee is the work: the diagnosis, the redirect map, the correction of crawlability faults, the resubmission, and the reporting. If a competitor offers you a traffic guarantee, ask them which part of Google they control.

What if the drop was not caused by the migration?

Then I tell you that in writing, with the evidence, and the engagement ends there. A core algorithm update, a manual action, seasonality or a genuine content problem are all real causes of a traffic fall, and none of them is fixed by redirects. The audit fee is earned because the audit was delivered — finding out that your problem is not technical is worth considerably more than paying someone to keep editing redirects that were already right. It is not the common outcome, but it is a real one and you should hear about it before you buy.

Do you need to be an owner on my Search Console?

No. Full or Restricted user is enough, and I will turn down owner access if it is offered. Owner carries the power to remove other users, verify new ones and file a change of address — none of which the audit requires. Search Console access is the one genuinely essential item on the list, though. Without it this is a scan you could have run yourself for nothing, and I would rather say so than take the money.

What counts toward the 500-URL limit?

The number of URLs in your old site's index — from Search Console's historical URL list, or from the old sitemap if you still have it. Not your new site's page count, and not every crawlable variant. That distinction matters: a shop with faceted navigation can show forty thousand crawlable URLs against six hundred real pages. Rebuilding the redirect map scales almost linearly with that number, which is why it is the one thing quoted after the audit rather than before it.

The old site is gone. Can you still rebuild the map?

Usually, yes, and this is the situation the audit is most useful for. Search Console keeps a historical record of URLs it crawled. Analytics holds the pages that earned traffic. Archived copies fill gaps in the structure. Between them the old URL list can normally be reconstructed well enough to map the pages that were actually worth something — which is the part that matters. It is slower than being handed an old sitemap, so say up front if you do not have one.

How long should redirects stay in place?

Longer than most people leave them. Google's guidance on site moves is to keep redirects as long as possible and generally at least a year, which is what gives signals from other sites still pointing at your old URLs time to transfer. If the domain itself changed there is a harder floor: Google asks for at least 180 days, and says that after that period it no longer recognises any relationship between the old site and the new one. So a previous developer removing the redirects a month after launch because the migration “was finished” can on its own explain a drop that started well after the move.

Is a 302 really a problem if the page loads fine?

It is, and this is one of the most common faults I see. A 302 tells search engines the move is temporary and the old URL should be kept. For a permanent change that is the wrong instruction, so the new URL does not inherit what the old one earned. Visitors notice nothing at all, which is exactly why it survives for months. It is also a one-character fix once somebody has found it.