What a migration plan covers for a relaunch
Quick test: Export your top 50 URLs from analytics today. Each one needs a named destination on the new site.
SEO migration is the coordinated transfer of a site's discoverability signals as its design, domain, or platform changes. The goal is to make important pages easy to find, connect old addresses to the right new pages, and catch avoidable issues before and after release.
This service is useful when a project is changing its domain or brand, consolidating pages, replacing a CMS, or rebuilding templates. It also suits teams whose organic search traffic or AI citations are important acquisition channels and who need a clear owner for migration checks.
We start by agreeing what must remain accessible and measurable. That includes priority landing pages, product and documentation pages, regional or language versions, and any pages regularly cited in AI answers. A baseline gives the team a reference for comparison rather than relying on memory after launch.
A migration can include:
- A crawl and traffic baseline for the current site.
- A source-to-destination URL map and redirect review.
- Checks for metadata and structured data on staging.
- Launch-day monitoring and a recovery plan.
- A focused review of priority AI citations and their source pages.
For broader discovery work beyond the move itself, see our AI search visibility services and GEO audit.
How do you map URLs and redirects before launch?
A useful URL map gives each important old page a clear destination—or a documented reason it will not be carried over. Build it before development is finished so the new site's information architecture can be reviewed while changes are still practical.
Begin with a crawl of the current site and combine it with available traffic data and business priorities. Mark URLs that earn organic visits, represent a product or service, support an important customer journey, or have been identified as sources for AI citations. Then record the matching new URL, the intended redirect, and the person responsible for confirming it.
Use these checks to assess the map:
- Every priority source URL has a destination or an explicit retirement decision.
- Destinations match the old page's purpose, not merely its nearest category.
- Redirects point to the final URL rather than through a chain of intermediate addresses.
- Internal links, navigation, canonical references, and sitemap entries use the new URLs.
- Removed pages have a considered replacement where one genuinely exists.
A spreadsheet is often enough, provided it is complete and maintained. We conduct a manual redirect review against the source and destination lists, flag unclear matches, and help the team resolve them before launch. This makes URL decisions reviewable by SEO, content, and development owners.
What to test on staging
Staging checks confirm that the new site presents the intended pages and information before the public launch. The review should cover technical access, page content, and the signals that help search and answer products identify what a page is about.
First, compare key templates and priority URLs with the approved migration plan. Check that page titles, descriptions, headings, canonical references, and structured data have been carried across or deliberately updated. Confirm that important content is present in the rendered page and that staging access controls will not accidentally remain on the public site.
For AI visibility, make a shortlist of real prompts connected to your products, expertise, and brand. Record which pages appear as sources in relevant answers before the move, then revisit those prompts after launch. This is a practical observation, not a claim that every assistant will show the same sources. If content needs rewriting to make facts clearer and easier to cite, our content for AI answers service can support that work. For technical implementation questions, see technical AEO.
Before approval, share a concise checklist with the CMS owner and developer: pages to test, expected destinations, metadata decisions, structured-data changes, and any open issue that could block release. Clear owners prevent last-minute uncertainty.
Launch monitoring and recovery
Common mistake: Redirecting every old page to the home page. Send each old URL to its closest new page.
Launch monitoring compares the live site with the approved plan and baseline so that problems are visible while the team can still act on them. The work begins before release, continues on launch day, and carries on through post-launch checks.
Before launch, agree who can pause a release, who can change redirects or templates, and where issues should be reported. Keep the final URL map, priority-page list, and known exceptions available to the people doing the work. On launch day, check that priority URLs resolve as intended, important pages are accessible, and the published metadata and structured data match the approved versions.
After release, compare crawl results and traffic with the baseline, then sort issues by impact and cause. A practical recovery plan identifies the steps for incorrect redirects, missing pages, accidental access restrictions, or template changes that remove important content. Record the issue, owner, fix, and verification result so that corrections are traceable.
We provide a readable findings and action log rather than an unexplained technical export. If you want ongoing observation of AI answers after migration, AI visibility monitoring can extend the review beyond the launch window. The review can also note whether priority source pages remain accessible and useful.
What can still shift after a move
A careful migration reduces avoidable disruption, but a relaunch does not give a team control over how quickly search engines revisit pages or which sources AI answer products select. Google may recrawl pages on its own schedule, and an AI answer may change or omit a source even when that page remains available; we cannot promise unchanged rankings or citations, but we can deliver the agreed mapping, checks, monitoring, and corrections within plan.
Make the launch decision with the outstanding risks visible. If priority redirects are untested, core content is missing from the new templates, or the team has no owner for post-launch fixes, resolve those issues before release where possible. If a fixed date makes that impractical, document the accepted risks and name who will handle each follow-up.
Keep the first review focused on observable facts: whether the new page loads, whether the old address reaches its intended destination, whether the key content is present, and whether measured search traffic has changed from the baseline. Investigate patterns rather than reacting to one isolated observation. A GEO audit can help assess broader AI visibility, while SEO services can address ongoing organic search priorities once the migration work is stable.
Your 7-point migration checklist
Tick these off in order. The first 3 happen before a single page is built. Print the list, tick each line with a pen, and keep it next to the brief so everyone works from the same page.
- Export all live URLs and mark the top 50 by traffic.
- Map each old URL to a new destination.
- Keep titles, headings and key copy where they ranked.
- Test every redirect on staging.
- Check metadata and structured data on staging.
- Submit the new sitemap on launch day.
- Watch crawl errors and traffic for 30 days.
Terms in one line
Redirect means an instruction that sends visitors and crawlers from an old URL to a new one.
Staging: a private copy of the site used for testing before launch.
Fitting migration into your wider visibility work
Migration work is most effective when search, content, development, and brand owners share the same destination map and release decisions. Treat the relaunch as a controlled handover of important pages, not as an isolated technical task.
If the company name, product description, or key facts are changing, align those updates across the site and the public sources your audience relies on. Our entity building for AI SEO service can help clarify how the brand and its offerings are represented beyond the site. For a project focused on one assistant, ChatGPT visibility and Perplexity optimization are related areas to consider after priority pages have been mapped.
To keep collaboration practical, share one working file with:
- The current and destination URLs for priority pages.
- The launch owner and technical contacts.
- Decisions on content, metadata, and structured data.
- Open issues, severity, owners, and verification notes.
- The baseline and the checks planned after release.
Send 3 things: your current sitemap, the planned new structure, and the launch date window.
How it works
- Set the baselineWe review the current site’s crawl and available traffic data, then identify priority pages and known AI citation sources. Your team confirms which pages and journeys matter most.
- Build the URL mapWe match priority source URLs to intended destinations and flag missing, unclear, or risky cases. Your SEO and development owners confirm redirect decisions.
- Review stagingWe check the agreed pages, metadata, and structured data against the migration plan before release. The team resolves blocking issues or records who owns follow-up.
- Check the launchWe verify priority URLs and agreed page elements on the live site, then document anything that needs correction. Your technical owner receives clear actions.
- Monitor and reportWe compare post-launch observations with the baseline and log issues, fixes, and verification. The review gives your team a practical recovery path.
Frequently asked questions
When is the right moment to call in migration support?
Bring support in while the new URL structure and templates can still be changed, not only when launch is imminent. Early review leaves time to map important pages, settle redirect decisions, and check staging. If the launch is already close, share the date and current migration materials so the work can be planned around the remaining decisions.
What do you send to start a migration review?
Share the current and planned domain or CMS, the expected launch window, any existing URL inventory, and available search traffic data. Include priority products, services, regions, or pages that must remain easy to find. If you have examples of AI answers citing your site, include those too; they help define what to check.
Can citations in ChatGPT or Perplexity survive a redesign?
We can record relevant prompts and citations before the move, map the cited pages to their intended destinations, and check those pages after launch. AI answer products may change or omit sources independently, so unchanged citations cannot be promised. Our item you receive is a documented review and practical corrections to the site elements within plan.
Is a CMS switch planned like a domain change?
The core work is similar, but the risks differ. A CMS move often needs closer checks of templates, metadata fields, structured data, and internal links; a domain change makes URL mapping and redirects especially important. A project that combines both should include checks for each change in one shared migration plan.
How many weeks does migration support run?
Timing follows the project’s launch schedule and the readiness of its URL map, staging site, and decision-makers. The review starts before release and includes launch and post-launch checks. Once we know the site size, planned changes, and launch window, we can describe the work sequence for your project.
What if traffic dips after launch?
We compare the change with the agreed baseline, check priority URLs and redirects, and record likely site issues for the responsible owner to investigate. Search engines revisit pages on their own schedule, so a traffic change does not by itself identify the cause. The migration review focuses on observable problems and the corrective actions available to your team.
Tell us about your project
Answer four quick questions and a manager will send you a plan, timing and a price range within the hour. Everything stays confidential.
Loading the form…