Website migration SEO belongs in the planning meeting before the new site is approved for launch. When I review a migration, I want to understand how the existing website earns its traffic and where those visitors will land afterwards.
In a recent project, the existing site had thousands of indexed pages. That immediately made the migration a mapping exercise as well as a development job. A cleaner design and a more convenient content system could be useful improvements, but we still needed to account for the pages people were already finding.
Get access to both versions
I asked to inspect the current website and the replacement. Without both, I could only take the migration plan so far. I needed to compare what existed with what was being built, rather than rely on a description of how the new platform would work.
That access also helps establish which work has already been done. A developer may have prepared some redirects or rebuilt part of the structure. The useful next step is to inspect it, identify the remaining gaps and make responsibility clear before the launch date arrives.
Account for the existing pages
During the meeting, I used a simple example: if a large site is replaced by a much smaller one, what happens to all the pages that are no longer there? Some may be redundant. Others may be attracting visitors who would never enter through the homepage.
I want an inventory and a destination plan. We discussed building that URL structure in a spreadsheet so the decisions could be reviewed and implemented systematically. The important point is that every significant old page has been considered.
This also gives the team a way to discuss consolidation. If several pages become one, we need to understand what that combined page is supposed to do for the visitors who previously arrived at each of them.
Where content has genuinely moved, permanent redirects should lead to the relevant replacement. Sending unrelated old pages to the homepage is not a useful substitute. If content has been removed without a suitable replacement, an appropriate not-found response may be the correct outcome.
Reference: Google guidance on site moves — https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Look at the links around the page
The URL list is only part of my review. I also want to understand the internal links: which pages point to each other, how visitors move through the site, and what changes in the new structure.
A page can still exist after the move while becoming much harder to reach. That is why I ask about the hierarchy and the links on individual pages, rather than only checking the navigation menu.
I also want to know which existing pages have links from other websites. In the migration discussion, I specifically asked to map those. They are established routes into the business, and they need to be considered when deciding where an old URL should lead.
Preserve the meaning of the important pages
Design changes can alter more than appearance. Page titles, descriptions, headings and the actual explanation of a service may all change during a rebuild. I want the team to recognise what each important page is meant to communicate before rewriting it.
There is room to improve that content. The question is whether the replacement still serves the same useful purpose and clearly explains the subject people came to find. I do not want those decisions to happen accidentally while someone is choosing a new layout.
Even a well-planned move can produce temporary fluctuations while search engines process it. Test the implementation and monitor the old and new URLs after launch; a migration plan reduces avoidable problems without guaranteeing unchanged traffic.
Reference: Google guidance on site moves — https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Make the migration review concrete
The deliverables I want to discuss are practical: the old URL inventory, the new destinations, the redirect plan, the important incoming links and the page elements being carried over. Those make the work reviewable. Before setting a launch date, ask the team to show how the existing routes into the business will work on the new website.