A post-migration audit verifies that a completed migration did what it was supposed to do. It is a verification exercise, not a recovery one: it runs whether or not traffic has fallen, precisely because the point is to find problems before they show up in revenue.
That distinction matters. If traffic has already dropped and you need to know why, that is migration recovery. This is the check that should prevent needing it.
What gets verified
Redirects, individually
- Every old URL resolves, in one hop, to the intended destination.
- No chains, no loops, no unintended 302s where 301s were specified.
- Nothing redirecting to the homepage as a catch-all, which is treated as a soft 404.
- Externally linked URLs specifically, since those carry the most transferable value.
Testing a sample is not sufficient on a large site. Test every pattern, and every URL that carried meaningful traffic or links.
Indexation directives
- No sitewide noindex carried over from staging, checked in headers as well as HTML.
- robots.txt matches intent and does not block anything required.
- Canonicals point at final URLs rather than at redirecting ones.
- Sitemaps list the new URLs and have been resubmitted.
Content parity
The most frequently missed check. Templates get rebuilt and copy gets trimmed as a design decision, so pages that ranked on depth quietly lose it.
- Compare word counts and headings between old and new versions of key pages.
- Confirm title and meta description logic produces sensible output at scale.
- Check that structured data survived the template rewrite.
- Verify content is present in rendered HTML rather than loaded client-side.
Internal linking
- Internal links point at final URLs, not through redirects.
- Click depth has not increased for commercially important pages.
- No pages have been orphaned by the navigation rebuild.
Performance
Compare Core Web Vitals against the pre-migration baseline on the same templates. Regressions here are common after a redesign and are usually attributed to something else.
Timing
- Within 48 hours: redirects, directives and status codes. These are the faults that cause immediate damage.
- First two weeks: indexation progress, crawl errors, content parity.
- Four to eight weeks: rankings and traffic against the stored baseline.
Judging a migration in week one is premature; waiting until month three to check the redirects is negligent. Both mistakes are common.
Frequently asked questions
Traffic has not dropped. Do we still need this?
Yes, and this is the best time to run it. Some migration faults take weeks to surface as recrawling progresses. Finding them while traffic is stable is far cheaper than diagnosing them after a decline.
How is this different from a recovery engagement?
Scope and assumption. A post-migration audit checks a defined list against a known baseline. Recovery starts from an unexplained decline and works backwards, which is slower and less certain.
How much of a dip is normal?
A shallow decline recovering over two to four weeks is typical. Depth beyond roughly thirty percent, or a decline still deepening after three weeks, warrants investigation now.
What if we have no pre-migration baseline?
The audit still verifies redirects, directives and content parity against the archived site. What it cannot do is tell you reliably whether performance changed, which is the argument for capturing a baseline beforehand.
Consulting CTA
If you have migrated recently, book an SEO consultation for a post-migration audit while faults are still cheap to correct.