Define what is changing before planning migration SEO
A technical SEO assessment distinguishes domain, platform, URL, content, and design changes. Each creates different tasks and risks. Changing the brand, category structure, and all copy at once can make a post-launch problem harder to diagnose. The team first identifies the value to preserve and the parts that need to change.
Bringing SEO into the project only after new URLs are finalised can create avoidable rework. Important pages and customer journeys are reviewed before those decisions are locked. Migration SEO does not automatically include the entire design project or data-transfer operation. Technical migration ownership, content approval, and the final release decision are assigned early. The aim is to control preventable errors, not to promise an absence of search fluctuations.
Save the existing URL and performance baseline before release
Assessing a possible organic traffic decline requires a reliable starting record. Existing URLs, important content, incoming links, and measurement conditions are collected from appropriate sources. A menu-only list can miss old campaign, product, or article destinations. Available sources are combined, and missing historical data is documented rather than assumed to exist.
Priority is broader than traffic volume. A low-traffic solution page that brings valuable enquiries may still matter commercially. Images, PDFs, and language versions enter the inventory according to scope. A copy of the baseline is kept independently from the migration. In an illustrative product catalogue, stock status and SEO value can be recorded separately, preventing a business decision to discontinue an item from accidentally becoming an inappropriate redirect decision.
URL record
Old address, page type, and content status. Investigate valuable pages that do not appear in the main navigation.
Commercial priority
Enquiry contribution, product continuity, and meaningful incoming links. Keep missing information visible.
Measurement baseline
Traffic, conversions, and tracking configuration, with an appropriate comparison period saved before changes begin.
FROM READING TO A NEXT STEP
Plan the move before locking the new URL structure
Share the current site, target platform, proposed structural changes and release schedule. We can define the critical decisions and checks.
Map URLs alongside the decisions about their content
During migration, content planning and redirect planning should not become disconnected documents. Each old page receives a retain, update, consolidate, or remove decision before the most appropriate new destination is chosen. Sending every old address to the new homepage does not help a visitor find what they requested. Irrelevant destinations are not chosen simply to make the redirect list shorter.
A common target may be appropriate when consolidated information is genuinely available on the new page. If a product or service has disappeared, that decision is recorded explicitly instead of returning a successful-looking response for nonexistent content. Internal links are updated and redirect chains reviewed. The mapping is delivered in a format the implementation team can use. Language relationships and important files are included when in scope. Every change should have a reason that can be reviewed.
Rehearse the release and agree the decision conditions
Migration SEO works alongside the release workflow. Protecting a test environment and making a live website accessible are different requirements. A release checklist helps ensure temporary access restrictions do not carry into production. New content, preferred URL signals, language relationships, sitemaps, and redirects are verified using representative examples.
Relevant teams also test critical business actions such as contact forms, carts, and accounts. Each check has an owner and a response when a problem appears. If a critical issue cannot be resolved for release, postponement or a limited launch is considered. A rollback plan is more than a copy of the previous design: new orders or enquiries created during cutover need an operational preservation plan. This is agreed with the team responsible for those records.
Select the rehearsal set
Include important templates, old destinations, and conversion paths. Use appropriate test data rather than sensitive customer records.
Separate critical issues
Assign owners to access failures, incorrect destinations, and broken commercial journeys that affect release readiness.
Record the release decision
Keep approval, version, and check results together. Technical and SEO teams verify the same agreed destinations.
Separate technical verification from performance interpretation
Post-release implementation follow-up starts with accessible new URLs and correct destinations for old links. If tracking fails, an apparent traffic decline does not by itself prove lost search visibility. Technical faults and reporting changes are separated while critical enquiry or purchase paths are verified.
Later monitoring reviews old and new URL groups, indexing observations, organic visits, and conversions together. Visibility can fluctuate while a move is processed. Instead of changing the URL architecture again after one daily ranking movement, the team gathers evidence. Redirect ownership and maintenance duration are planned. Google generally recommends keeping migration redirects for at least a year, with longer maintenance considered for users. That recommendation is not a recovery timeline or a ranking guarantee.
Define migration SEO deliverables before the launch date
The scope and cost depend on change type, test access, and release timing as well as URL count. An audit, coordinated migration, and investigation of an already completed traffic loss are different engagements. CMS data transfer, design production, and legal-content review may belong to separate teams. A last-minute start cannot promise complete access to historical evidence.
Outputs can include inventory, reasoned URL mappings, implementation tasks, a release checklist, and monitoring notes. Each has ownership and acceptance conditions. The old site is not closed before the replacement is ready; retirement and old-domain maintenance decisions are explicit. Sharing the target platform, planned structural changes, and proposed date makes the initial conversation concrete. Rather than guaranteeing zero traffic loss or rapid ranking growth, the process makes migration decisions and verification evidence visible.
Before release
Change scope, baseline record, URL decisions, and rehearsal findings.
At cutover
Joint verification of redirects, access, content, and critical customer actions.
After release
Prioritised errors, performance observations, and responsibility for maintaining old destinations.
BEFORE YOU DECIDE
Frequently asked questions
When should migration SEO begin?
Ideally before the new URL and content structure is finalised, so protected pages and mappings inform design decisions. Review is still possible later, but the implementation options and available schedule may be more limited.
Does a design-only change need SEO checks?
Yes. Design changes can alter headings, content, links, and important page components even when URLs remain the same. We compare the output and scale review to the actual change instead of treating every redesign as a complete domain migration.
Can all old URLs redirect to the homepage?
Irrelevant bulk redirects fail to answer the original request. Choose an appropriate destination for each old page; genuine consolidation may justify a shared target. Removed content needs an explicit decision. Ease of implementation is not sufficient reason to choose a destination.
Can you guarantee no traffic loss?
No. Visibility can fluctuate while search systems process a move, and other factors also influence performance. The commitment is a clear plan with accountable checks and implementation responsibilities, not guaranteed rankings or a loss-free result.
How long should redirects remain in place?
Google generally recommends at least a year. Users and external links may require longer maintenance. Old-domain, server, or platform costs should be planned together with redirect ownership. Reaching the minimum period is not an automatic reason to remove them.
What if traffic has already fallen after migration?
First verify tracking and technical access, then compare URL and content changes with the baseline. Identify the cause before another broad release. Missing historical evidence and changing demand are documented rather than hidden in the analysis.
LET’S DEFINE THE SCOPE
Plan the move before locking the new URL structure
Share the current site, target platform, proposed structural changes and release schedule. We can define the critical decisions and checks.
Discuss migration SEO scope