SEO migration for a site redesign, domain change or CMS move

What does an SEO migration cover?

An SEO migration coordinates the technical and content changes needed to move a site without leaving important pages behind. It applies to redesigns, domain changes, rebrands and CMS moves.

The first decision is scope: list every hostname, language version and page group affected. Then identify the pages with search traffic, inbound links or business value. These are migration priorities, not pages to remove casually.

The Launch Spec records the move type, owners, launch sequence, URL sources and acceptance checks. It also notes what is not changing, so the team can separate migration issues from unrelated redesign work. If AI-assistant citations matter, include the currently cited URLs and important reference pages in the baseline. That gives the team a record to compare after release.

For broader AI search work beyond the migration itself, see AI search visibility and our GEO audit.

How should you map URLs and redirects?

A migration URL map should give every retained old URL one clear destination, and every removed URL a deliberate disposition. Build it before redirect rules are implemented.

• Export current URLs from a site crawl and available analytics or search data.
• Match each old page to the closest equivalent new page, not automatically to the home page.
• Mark pages with no successor for review; decide whether to retain, consolidate or retire them.
• Check that internal links, canonical references, language alternates and navigation use the final URLs.
• Test representative paths, including nested pages and changed URL patterns, on staging.

Keep the mapping in a shared file with source URL, destination URL, page owner and review status. Flag redirect chains, loops, inconsistent trailing slashes and mixed protocol or hostname versions before launch. A redirect is not a substitute for a relevant destination: if the new page answers a different need, revise the mapping or the content plan.

AEOTech checks the map against the crawl baseline during Spec Review, then records corrections in the Run Log. This makes it clear which URLs have been reviewed and which still need an owner decision. If you are also rebuilding technical AI-search signals, coordinate the migration with technical AEO rather than treating it as a separate launch.

What needs to pass before the new site goes live?

Staging is the place to confirm that the new site is ready to receive traffic and that key page signals have been carried across. The review should use representative templates as well as individual priority URLs.

Separate temporary staging controls from settings intended for production. Confirm who will remove or replace them at launch, and add that task to the release checklist. Compare old and new page templates for missing content, headings, navigation and important references; a technically valid redirect cannot restore information omitted from the destination page.

We document checks and open items in the Launch Spec, with a named owner for each unresolved issue. If your team maintains files intended to guide AI crawlers, treat them as a separate technical decision and review the llms.txt and crawler work alongside migration tasks. Do not use a new file as a replacement for sound redirects, accessible pages or accurate content.

How do we monitor a migration after launch?

Post-launch monitoring compares the live site with the pre-migration baseline and turns observed issues into assigned fixes. The purpose is to detect and correct problems while the release context is still clear.

1. Confirm that priority pages and the main site paths load on the production domain.
2. Recheck redirect destinations and the URL groups listed in the migration map.
3. Review crawl and traffic signals against the recorded baseline.
4. Log unexpected changes, affected URLs, evidence and the person responsible for the fix.
5. Recheck resolved items and record the outcome in the Readout.

Temporary fluctuations after launch are normal, so the review should focus on patterns and concrete errors rather than a single snapshot. For example, a drop across one template calls for a different investigation from a redirect error limited to a small URL group. The Run Log keeps those findings tied to specific pages and fixes.

The Readout summarizes completed checks, open issues and next actions in plain language for the marketing and technical owners. If you need ongoing visibility work after the migration period, compare this project with AI visibility monitoring. For a broader content plan, see content for AI answers.

What can change after a site relaunch?

A migration plan can control the implementation and verification work, but it cannot control how platforms process the changed site. Search engines choose when to recrawl and reassess URLs, and AI assistants choose which sources to cite; neither the timing nor continued citations are ours to set.

Use the Readout to separate delivery from platform outcomes. It should show which redirects and page signals were checked, which fixes were completed and what remains open. That evidence lets your team act on an identifiable technical issue instead of guessing from a broad visibility change.

For projects with a major rebrand, record the new organization and product names consistently across the site and supporting materials. Our entity and knowledge graph work can address that separate need. For a domain move with a substantial content rewrite, include both the URL map and the page-change list in the review; redirect coverage alone will not describe what changed for visitors.

To start, send AEOTech the current domain, planned domain or CMS move, an old URL export, staging access and your intended launch window. We will review the inputs, define the checks in a Launch Spec and confirm the migration scope before implementation begins.

Prices

Starting prices in USD. Custom bundles and volume discounts on request. Payment in USDT, USDC, BTC, ETH, SOL, TON or your project token.

How it works

1. Collect the migration inputsShare the current site, planned changes, URL export, analytics access and launch window. We confirm the affected domains, page groups and owners.
2. Set the baselineWe crawl the current site and record the traffic and URL signals available for comparison. Priority pages and known AI citations are included where supplied.
3. Build and review the mapWe match old URLs to intended destinations and review redirect, metadata and structured-data requirements in the Launch Spec.
4. Check staging and launchWe test agreed page groups and record open actions before release. At launch, the team follows the checklist and reports issues through the Run Log.
5. Monitor and reportWe compare post-launch checks with the baseline, track corrections and deliver a Readout with completed work and next actions.