seo website migration audits
SEO migration audit
A fixed-scope review with one job: tell you whether the migration plan holds up before you commit the launch date, or tell you exactly what broke if it already happened.
- Definition
- An SEO migration audit — An SEO migration audit is a fixed-scope technical review of a website move. Before launch it assesses redirect coverage, structural risk and crawl parity against the current site. After launch it diagnoses what changed, separating redirect failures from indexation problems and from genuine content loss, and ranks findings by traffic at risk.
Two different products under one name
SEO website migration audits come in two shapes, and buying the wrong one wastes both time and money.
The pre-launch audit is preventative. It answers whether the plan will hold, while there is still time to change it. Its most valuable output is often a single number: the percentage of traffic-carrying URLs with a verified one-hop redirect to a relevant destination.
The post-launch audit is forensic. It answers what changed and how much is recoverable. Its hardest constraint is whether anyone captured a pre-migration benchmark — without one, the analysis has to be reconstructed from Search Console’s retained data, which is possible but less precise.
Why findings are ranked by traffic, not severity
Most audits rank findings as critical, high, medium, low. That ordering is close to useless for decision-making, because a “critical” issue affecting forty URLs nobody visits should not outrank a “medium” issue affecting a section that drives a fifth of your organic revenue.
Every finding here carries the organic traffic exposed to it. That changes the conversation from an argument about severity labels into a prioritization exercise anyone in the room can follow: fix the top five rows, then reassess.
It also makes the audit honest about its own findings. Some issues are real and not worth fixing before launch. Saying so is more useful than padding a register to justify its length.
What the pre-launch audit will not do
It will not write your redirect map. It tests coverage, identifies the gaps and quantifies them — producing the map itself is the full engagement.
It will not implement anything. Findings come with enough specificity that your engineers can act without further interpretation, but the fix is theirs to ship.
It will not tell you the migration is fine when it is not, and it will not manufacture problems when it is. Both failure modes are common in productized audits — one sells reassurance, the other sells the next engagement. The register is what the testing found.
The post-launch version, in sequence
When traffic has already dropped, the order of investigation matters, because the three main causes look identical from a traffic graph and get confused constantly.
First, redirect failures. Take the pre-migration top URLs and test each one. Non-200 final statuses, chains and homepage catch-alls are the fastest thing to find and usually the largest single cause.
Second, indexation changes. Compare indexed URL counts and coverage states before and after. A site-wide directive problem, a canonical pointing at the wrong host, or a sitemap listing pre-migration URLs will all show here.
Third, content loss. Compare word counts and internal link counts per matched URL pair. Migrations quietly drop content — a module that did not get rebuilt, a sidebar that was cut, a tab whose contents now load on click.
Only after those three are separated is it possible to say what is recoverable. Doing them in a different order produces a plan that fixes the wrong thing first.
If you would rather do it yourself
The diagnostic on the homepage is the first hour of a pre-launch audit, written so you can run it without help. If it comes back clean, you may not need this at all — and the published checklist will take your team most of the rest of the way.
| Dimension | Pre-launch | Post-launch |
|---|---|---|
| Question answered | "Will this migration hold?" | "What broke, and how much is recoverable?" |
| Inputs needed | Current site access, staging access, proposed redirect rules | Search Console, pre-migration data if it exists, the live site |
| Main output | Risk register ranked by traffic exposed, with go/no-go criteria | Diagnosis by cause, with a remediation sequence |
| What you can still change | Redirects, structure, staging fixes, the launch date itself | Redirects, indexation directives, reinstated content |
| Hardest constraint | Time before launch | Whether a pre-migration benchmark was ever captured |
| Typical trigger | Launch scheduled, nobody has independently checked the plan | Traffic dropped and the cause is disputed internally |
When an audit is the right purchase
- A migration plan already exists and you want an independent read before committing.
- Traffic dropped after a launch and the internal explanation is contested.
- You need a defensible written assessment for a stakeholder or a board.
- You want to know whether you need a full engagement before buying one.
When it is not
- No plan exists yet — there is nothing to audit, and scoping is the useful first step.
- You already know what is wrong and need implementation help rather than diagnosis.
- The launch is in days and the finding could not be acted on in time.
- You want ongoing support, which is an engagement rather than a fixed-scope review.
What a pre-launch audit examines
Fixed scope, so you know in advance what is covered and what is not. Every finding is ranked by the organic traffic exposed to it rather than by a severity label.
- 01
Redirect coverage against the traffic and link inventory
Every URL in the top traffic tiers and every URL with meaningful referring domains, tested individually for final status and hop count.
Output Coverage percentage with a named exception list
- 02
Structural risk in the new URL design
Where the proposed structure creates avoidable problems: taxonomy mismatches, parameter handling, pagination and unnecessary depth.
Output Structural findings ranked by traffic exposed
- 03
Staging parity against production
Field-level diff across titles, canonicals, meta robots, internal link counts and structured data for matched URL pairs.
Output Parity diff with variance counts by field
- 04
Rendering and indexability
Whether content and internal links exist in the raw HTML, and whether staging directives are at risk of shipping to production.
Output Rendering and directive findings
- 05
Launch readiness
Whether a runbook exists, whether DNS TTL has been planned, who is on call, and what the rollback trigger is.
Output Go/no-go criteria with owners
Deliverables
What this engagement hands over
-
Pre-launch
Risk register
Every finding with the organic traffic exposed to it, the effort to fix, and whether it blocks launch. Sorted so the first ten rows are the ones that matter.
-
Pre-launch
Redirect coverage report
What percentage of traffic-carrying and link-carrying URLs currently resolve correctly, with the full exception list attached rather than summarized.
-
Staging QA
Go/no-go criteria
The specific conditions that should be true before launch proceeds, written so they can be checked by someone other than the person who wrote them.
-
Pre-launch
Readout session
One working session to walk the findings with your team and engineering together, because a document nobody discusses changes nothing.
Questions people ask before starting
What does an SEO migration audit include?
Redirect coverage tested URL by URL, structural risk in the new design, a staging parity diff, rendering and indexability checks, and launch readiness. The output is a risk register ranked by traffic exposed, plus go/no-go criteria your team can check independently.
How long does an audit take?
Typically one to two weeks depending on site size and how quickly access comes through. If your launch is sooner than that, say so — a narrower emergency scope focused only on redirect coverage is possible and is usually the highest-value part anyway.
Do we need an audit if we already have an agency?
Only if you want an independent read. An audit is a second opinion, which is valuable precisely because it is not produced by the people who made the plan. If you trust the plan and can describe its parity process, you probably do not need one.
What if the audit finds the launch should be delayed?
Then that is what it says, with the traffic exposure attached so the decision can be made commercially rather than emotionally. Delaying is a business decision, not an SEO one — the audit's job is to make sure it is an informed one.
Can you audit a migration that already happened?
Yes, and that is the post-launch variant. It separates redirect failures from indexation problems and from genuine content loss. Those three look almost identical in a traffic graph and have completely different remediation paths, so getting the diagnosis right matters more than moving fast.
Does an audit lead to a bigger engagement?
Sometimes, and often not. Plenty of audits conclude that the plan is sound and the team should carry on. The audit is priced and scoped as a standalone piece of work precisely so that its conclusion is not influenced by what it might sell next.
Start with the launch date
Tell us what is changing and when. We will tell you what is realistic in the time available before anyone discusses scope.
- Reply
- Typically within one business day.
- Hours
- Monday to Friday, 9am–6pm US Eastern.
- First call
- Scoping, not a pitch. No deck.