3 changes that shape the migration record
3 formats: redesign | domain change | CMS move.
A clean handoff starts by naming what changes. That choice sets the URL checks, content review, and release tasks. We record the existing site before development decisions become hard to reverse.
For a redesign, we check whether page purpose and important content survive the new templates. For a domain change, we connect old addresses with their planned destinations. For a CMS move, we look for changes to paths, metadata, structured data, and rendered pages.
The baseline is a working reference, not a promise about search outcomes. It covers the current crawl and traffic information available to the project. We use it to flag priority pages. It also makes later comparisons practical.
Send the current domain, the planned change, and the expected launch window first. Add the staging address and URL inventory when available. If the new structure is still changing, we mark open decisions in the migration record. For wider context, see AI search visibility and our GEO audit.
Which records should the new site carry forward?
3 records guide the move: the URL map, page signals, and implementation status. Each should be clear enough for developers and content owners to act without guessing.
| Change | Main check | When | What you send |
|---|---|---|---|
| Redesign | Page purpose, content, and metadata | Before release | Current URLs and new page types |
| Domain change | Old-to-new URL routes and redirects | Before launch | Current and planned domains |
| CMS move | Paths, structured data, and rendered pages | On usable staging | URL inventory and staging access |
The URL map should connect each important current page to a relevant new destination. Include the old URL, proposed destination, page purpose, and implementation status. If there is no suitable replacement, record that decision. Do not route unrelated pages to the homepage.
Keep the map current as decisions change. Review new URLs added late against the approved structure. Do not quietly fold them into the release. Page changes also need a content decision: retain, consolidate, or rewrite.
For pages being rewritten, content for AI answers can support the content work. The URL map still controls which old page leads to which new one.
4 checks for page signals that travel
4 checks cover page details often missed in a redesign. Review the visible page and its implementation together. A completed spreadsheet is not proof that a field appears correctly.
- Titles and descriptions: match each priority page’s new purpose.
- Structured data: retain only details that remain accurate and visible.
- Names and references: keep organization, product, and service details consistent.
- Internal links: update references to the new destinations.
Also compare representative staging pages with the approved content list. Ask developers which changes will differ between staging and production. Note access limits or release-only edits before treating the review as complete.
For technical implementation, Technical AEO can cover schema and crawler details. Entity building supports consistent organization and product references across the site.
Search engines decide how they process changed URLs. ChatGPT and Perplexity select their own sources. We can verify the agreed implementation and report observed changes. Nobody can promise a specific ranking or citation after a migration.
How do we check the migration before release?
5 steps take the migration from baseline to launch checks. We work from the release schedule. Each finding stays tied to a page or implementation decision.
- Share the change: Send current and planned domains, the change type, launch window, and any URL inventory.
- Set the baseline: We review available crawl and traffic information. Then we mark priority pages for comparison.
- Map the routes: We match current URLs to planned destinations. We prepare redirect, metadata, and structured-data checks.
- Review staging: We compare representative page types against the approved map. Then we record issues for project owners.
- Check launch: We compare the released site with the plan. We log findings and follow the agreed correction path.
A shared issue log makes the handoff usable. Each entry names the affected URL, what we observed, who owns the next action, and its status. That separates a route problem from a content decision or an implementation defect.
We agree who can approve corrections and how urgent findings reach the development team before release. While monitoring is live, you get a report every 24 hours. The work can sit alongside SEO services or AI visibility monitoring. Migration checks stay tied to this release.
What your release team gets from the migration
5 practical records give your team a usable handoff. The records are a baseline and URL map. They also include implementation checks, staging findings, and a recovery plan. The format keeps decisions attached to pages. They do not disappear into general recommendations.
- Baseline: crawl and traffic references for priority pages.
- URL map: old addresses, planned destinations, and status.
- Check list: redirects, metadata, and structured-data review.
- Issue log: affected URL, observed behavior, owner, and resolution status.
- Recovery plan: an agreed route for reviewing and correcting launch findings.
DigitalMedia1 keeps the review tied to your release record. Each finding points to a page or decision. Your team can see what to check and who needs to act. If you need ongoing visibility work after the move, AI visibility monitoring can track a separate workstream.
Send us the current domain, planned domain or CMS, target launch window, and URL inventory. Include staging access if it is ready. We’ll review the inputs and return a written quote within 2 working days.
How it works
- Share the changeSend current and planned domains, the change type, launch window, and any URL inventory. Add staging access if it is available.
- Set the baselineWe review available crawl and traffic information. Then we identify priority pages for comparison.
- Map the routesWe match current URLs to planned destinations. We prepare redirect, metadata, and structured-data checks.
- Review stagingWe compare representative page types with the migration record. We log findings for project owners.
- Check launchWe compare the released site with the agreed plan. We track issues and follow the correction path.
Frequently asked questions
When should we bring the migration map into the redesign?
Start before developers lock the new page structure. An early URL map gives the team time to match priority pages, settle missing destinations, and prepare redirect checks. Send the current URL inventory and target launch window first. We can mark unsettled decisions instead of treating them as approved.
Does a CMS move need a different SEO migration plan?
3 checks still matter when the domain stays put: paths, page signals, and rendered content. A CMS can change how URLs or metadata appear. We compare current pages with usable staging pages. Send the URL inventory and staging access. We’ll build the checks around the planned changes.
Can you keep our ChatGPT or Perplexity citations after a relaunch?
2 useful checks are carrying important page content forward and verifying the live implementation. ChatGPT and Perplexity choose their own sources, so a specific citation cannot be promised. We can document the site changes. We can also confirm whether the agreed URLs and page details are present after release.
What should we send for a migration review?
4 useful inputs are the current domain, planned domain or CMS, target launch window, and URL inventory. Add a staging link when ready. Also name the development and content owners. That gives findings a clear route to the people who can review or implement a correction.
How long does the migration work take?
3 project points set the sequence. Baseline and mapping come before implementation is locked. Staging review starts when the new site is usable. Monitoring starts at launch. The project schedule sets the exact calendar. We confirm the work plan after reviewing the change type, available materials, and target release window.
Can we redirect every old page to the homepage?
1 destination should reflect each important old page’s purpose. A blanket homepage route can send visitors to unrelated content. It can also make the migration record less useful. Where no suitable replacement exists, record that decision in the map. Ask the project owner to approve the intended treatment.
How is the quote for SEO migration set?
3 details shape the quote: change type, release window, and review materials. The review materials include your URL inventory and staging access. You get a fixed written quote within 2 working days, before payment. Send your current domain, planned change, and launch window. We can then identify any missing inputs.
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…