A pre-migration SEO audit is the work done before a replatform, redesign or domain change goes live. Its purpose is to establish exactly what exists today, so that what exists tomorrow can be checked against it.
It is the cheapest hour in the whole migration. Every problem caught here costs a configuration change; the same problem caught after launch costs a recovery engagement and weeks of lost revenue.
The wider process is on SEO migration. This page covers the audit that should precede it.
What it captures
A complete URL inventory
Migrations fail on the URLs nobody remembered. A crawl alone is not sufficient, because it only finds what is currently linked.
- A full crawl of the current site.
- Indexed URLs from Search Console, which routinely include pages no crawl reaches.
- Analytics landing pages across at least twelve months, catching seasonal entry points.
- XML sitemap contents, reconciled against the crawl.
- Externally linked URLs from backlink data, which matter disproportionately.
The union of those sources is the real inventory. Any of them alone will miss pages.
A performance baseline
- Rankings for the queries that matter, recorded before anything changes.
- Organic sessions and conversions by landing page.
- Impressions and clicks by query and by page.
- Core Web Vitals on representative templates.
Without this, nobody can say afterwards whether the migration succeeded, because there is nothing to compare against. Post-launch arguments about whether traffic fell usually trace back to a missing baseline.
The current technical state
- Which pages are indexed, and which are excluded and why.
- Existing canonical, redirect and directive behaviour.
- Structured data currently emitted.
- Internal linking structure and click depth.
- Any problems that already exist, so they are not blamed on the migration later.
That last point saves a great deal of argument. Pre-existing faults get attributed to the migration by default unless they were documented beforehand.
What it produces
- A URL inventory with the source of each URL recorded.
- A prioritised list of URLs by traffic, rankings and links, so mapping effort goes where value is.
- A stored baseline in a format that can be re-run identically afterwards.
- A documented list of existing issues.
- A pre-launch checklist to run against staging.
When to run it
Before the new URL structure is finalised. That is the point at which findings can still influence decisions rather than merely record them.
- Ideal: during planning, when structure is negotiable.
- Workable: during build, when staging exists.
- Too late: after launch, at which point it becomes a post-migration audit with a decaying baseline.
Frequently asked questions
Do we need this if we are keeping the same URLs?
Yes, though it is lighter. Templates, internal linking, content and directives can all change even when paths do not, and you still want a baseline to measure against.
How long does it take?
Typically one to three weeks depending on site size, with most of the time in reconciling URL sources rather than in the crawl itself. Large catalogues take longer.
Our developers already have a URL list. Is that enough?
Usually not. Development lists come from the CMS and describe what the site intends to have. They miss indexed URLs, parameter variants and old pages that still attract traffic and links.
What if the migration is next week?
Capture the inventory and baseline anyway, even if there is no time to act on findings. Without them, post-launch diagnosis becomes guesswork.
Consulting CTA
If you are planning a replatform, redesign or domain change, book an SEO consultation for a pre-migration audit while the structure can still be influenced.