Prepare the move
Understand the important URL set, map old and new destinations, review redirect rules, preserve page intent and identify launch risks.
Interweb Media · SEO Migration Audit
Move the website. Preserve the search signals.
An SEO Migration Audit establishes what needs to be protected before launch, what must be mapped during the change and what needs to be verified after the new site goes live.
For redesigns, replatforms, domain changes and major URL or architecture changes where organic visibility needs controlled transfer.
Controlled change
01Before launchMap and protect the signals that matter
02During changeKeep old and new states connected
03After launchVerify access, indexation and visibility
Migration risk
A website move changes more than the design.
URLs, redirects, canonicals, internal links, templates, metadata, rendering and indexation can all change at the same time. Search visibility is carried by the relationships between those signals, not by a single migration checklist.
The audit creates a controlled view of what is moving, what must remain discoverable and what needs proof after launch. It does not promise that rankings will remain unchanged.
Old state → new state
URL setRetain, redirect or retire with intent
ArchitectureMap relationships, depth and internal paths
MetadataPreserve meaning while templates change
Search signalsRecheck what the new site exposes
Pre-launch and post-launch investigation
The timing of the audit changes the work, not the need for evidence.
Before launch, the investigation protects the release by making the old and new states comparable. After launch, it reconstructs what changed and verifies whether the released site is exposing the signals the search journey depends on. If the move is primarily a redesign rather than a URL, platform or domain migration, the Redesign Recovery investigation provides the more specific context.
Control the change
Keep the migration plan connected to implementation owners, dependencies, release conditions and the evidence needed for validation.
Verify the new site
Check redirects, canonicals, internal links, rendering, indexation, affected pages and search performance against the migration baseline.
Migration mapping
- 01InventoryEstablish the pages, templates and signals that matter.
- 02MatchConnect old URLs to the right new destinations or decisions.
- 03TestCheck redirect behaviour, canonicals and internal discovery.
- 04RecheckVerify the released state and record what changed.
Investigation scope
Migration mapping is the bridge between old and new.
A redirect list is not the same as a migration map. The investigation considers whether the destination preserves the old page’s purpose, whether the new architecture can be discovered and whether the change creates avoidable loss or ambiguity.
The scope follows the site and migration plan. It can include URL changes, lost pages, redirect chains, canonicals, internal linking, architecture, metadata, rendering and indexation where those signals are relevant.
Preserve existing equity
A redirect can transfer a URL. It cannot solve every migration decision.
Redirects matter, but the destination, page intent, internal linking, canonical signals, content and discoverability still determine what the new site communicates. The audit looks for gaps between the old page, the new page and the path search engines and users take between them.
Old URLWhat did the page represent and how was it discovered?
New destinationDoes the new page carry the relevant purpose and evidence?
ConnectionDo redirects, canonicals and internal links agree?
VerificationWhat will prove the transfer was implemented as intended?
Post-launch verification
Launch is an event. Verification is the follow-through.
After the release, compare the new state with the migration plan and the pre-launch evidence. Check that important pages resolve, redirects behave as intended, canonical signals are coherent and the new architecture is discoverable.
If organic visibility has already fallen and the cause is unclear, the migration evidence becomes part of a broader Traffic Drop investigation. If the confirmed symptom is position loss, the Ranking Drop investigation can examine the affected queries and pages.
After migration
01ReconstructWhat changed between the old and new states?
02ConcentrateWhich pages, templates or search journeys moved?
03DiagnoseWhich explanation is supported by the evidence?
04ActWhat is the next useful repair or verification step?
Recovery investigation
When the migration is already live, start with what changed.
A post-migration loss does not prove that redirects failed, and it does not prove that the migration is the only cause. The investigation reconstructs the release, isolates the affected areas and tests the available evidence before recommending remediation.
This keeps the work migration-specific without assuming the answer in advance.
Audit deliverables
A migration record the whole team can use.
The output connects decisions made before launch with evidence observed after launch, so technical, product, content and leadership teams can work from the same account of the change.
Migration map
Important old URLs, new destinations, redirect decisions and unresolved gaps.
Risk register
Conditions that could affect discovery, indexation, page intent or search visibility.
Verification record
Post-launch checks, affected pages, implementation status and evidence retained.
Next action
A prioritised repair or investigation path based on what the evidence supports.
Team collaboration
Make the migration legible to the people shipping it.
Migration work crosses SEO, engineering, product, content and leadership. A useful audit makes dependencies visible, gives owners a shared reference and keeps the verification question close to the implementation work.
See how Interweb connects investigation to implementation and verification →
Platform evidence
The Interweb platform gives the migration memory.
Crawl evidence, affected page groups, issue status, implementation history and verification can remain connected to the old-to-new change rather than scattered across exports and release notes.
Start with the migration
Request a migration audit.
Begin with the move you are planning or the visibility change you are investigating. The public diagnostic journey is the starting point for deciding what needs to be mapped, protected or verified.