site migration checklist | Lillian Purge

site migration checklist

A site migration is one of the highest-risk activities in digital marketing. From experience, it is also one of the most misunderstood. I have seen migrations that looked visually perfect but destroyed years of SEO performance overnight. I have also seen migrations that were handled carefully, methodically, and calmly, where rankings dipped briefly and then recovered stronger than before.

I think the biggest mistake people make is assuming a site migration is a technical task rather than a strategic one. Changing a domain, redesigning a site, moving platforms, or restructuring URLs is not just about code. It is about how Google understands continuity, how users experience change, and how trust signals are preserved during disruption.

This article is a full site migration checklist, but not in the usual tick box sense. It is written from real world experience managing migrations for small businesses, large organisations, and sensitive industries. I will walk through what matters before, during, and after a migration, why each step exists, and what happens when it is skipped. The aim is not speed. The aim is safety, clarity, and long term performance.

what counts as a site migration

Before any checklist, it helps to define what we mean by migration.

From experience, a site migration is any significant change that affects how users or search engines access or interpret your site. This includes moving to a new domain, switching from http to https, changing CMS or platform, redesigning templates, restructuring URLs, merging sites, splitting sections, or even large scale content pruning.

Many people only think of migrations as domain changes. In reality, Google treats many structural changes as migrations because they alter signals it relies on to understand relevance and continuity.

If you are changing anything that affects URLs, internal linking, content structure, or crawl behaviour, you should treat it as a migration.

why migrations go wrong so often

Migrations fail for predictable reasons.

From experience, the most common causes are rushing, poor communication, lack of ownership, and treating SEO as an afterthought. Design and development decisions are made first, then SEO is asked to fix whatever happens next.

I think this happens because migrations are often driven by non-SEO goals. A rebrand, a new platform, improved UX, or internal pressure to modernise. SEO risk is underestimated because it is invisible until traffic drops.

A good migration checklist exists to slow things down at the right moments, not to speed things up.

defining ownership and responsibility early

Every migration needs a clear owner.

From experience, migrations go wrong when responsibility is fragmented. Developers assume SEO is someone else’s job. Marketers assume developers will handle redirects. No one owns the full picture.

Before anything else, define who is responsible for the migration end to end. This person does not need to do everything, but they need authority to coordinate decisions, challenge timelines, and stop the launch if critical risks are unresolved.

SEO migrations fail most often when no one is empowered to say not yet.

clarifying the reason for the migration

Not all migrations are worth the risk.

From experience, some migrations are driven by vague goals like modernising or improving performance without clear outcomes. Every migration carries risk, so the benefit needs to be clear.

Ask what problem the migration is solving. Is it technical debt, scalability, conversion issues, brand alignment, or security. If the benefit is unclear, the risk may not be justified.

This clarity matters because it shapes decisions later. If SEO performance is critical to the business, that must be explicit from the start.

auditing the existing site before any changes

Never migrate what you do not understand.

From experience, one of the biggest mistakes is failing to audit the current site properly. People redesign or rebuild without knowing which pages drive traffic, links, or conversions.

Before any design or development work begins, carry out a full audit of the existing site. This includes indexing status, top performing pages, keyword rankings, backlink profiles, internal linking, and crawl behaviour.

You need to know what must be protected. Otherwise, you will not realise what you have lost until it is gone.

identifying pages that matter most

Not all pages are equal.

From experience, a small percentage of pages usually drive the majority of organic traffic and links. These pages deserve special attention during a migration.

Identify high traffic pages, pages with strong backlinks, pages that rank for valuable queries, and pages that convert well. These should be mapped and protected with extreme care.

A migration that preserves structure but breaks one critical page can still cause serious damage.

creating a full URL inventory

A complete URL inventory is essential.

From experience, relying on sitemaps alone is not enough. Sitemaps are often incomplete or outdated.

Use multiple sources to build a full list of URLs. Crawl the site, export indexed URLs from Search Console, review analytics landing pages, and check backlink data.

This inventory becomes the foundation for redirect mapping and post-launch checks.

Skipping this step almost guarantees missed redirects.

deciding what should and should not migrate

Not everything must be carried over.

From experience, migrations are often used as an opportunity to clean up low quality content. That can be beneficial, but only if done deliberately.

Decide which pages will be migrated, which will be consolidated, and which will be retired. Every decision should be intentional.

Removing pages without considering their traffic or links is one of the fastest ways to lose rankings.

planning URL structure changes carefully

URL structure is one of the most sensitive parts of a migration.

From experience, unnecessary URL changes cause far more harm than benefit. Clean URLs are nice, but stability is often more important.

If you are changing URLs, make sure the new structure is logical, consistent, and scalable. Avoid frequent pattern changes or overly complex paths.

Google can handle change, but it prefers continuity.

building a redirect strategy before launch

Redirects are the backbone of a safe migration.

From experience, redirects should be planned before anything goes live, not patched in afterwards.

Create a one to one redirect map wherever possible. Every old URL should point to the most relevant new URL, not just the homepage.

Avoid redirect chains. Avoid blanket redirects. Precision matters.

A migration without a complete redirect plan is not ready to launch.

using the correct redirect type

Redirect type matters.

From experience, 301 redirects should be used for permanent migrations. Temporary redirects send the wrong signal and slow down signal transfer.

Ensure redirects are implemented at server level where possible, not via JavaScript or meta refresh.

Incorrect redirect types are a common cause of prolonged ranking drops.

preserving internal linking logic

Internal links matter as much as external ones.

From experience, migrations often update templates but break internal linking patterns. Old URLs are still referenced, anchor text changes unintentionally, or key pages lose internal support.

Review internal linking structure on the new site carefully. Ensure important pages are still linked prominently and logically.

Internal links help Google understand priority and relevance after a migration.

handling canonical tags correctly

Canonical errors are a silent killer.

From experience, new sites often launch with incorrect canonical tags pointing to staging URLs, old domains, or inconsistent versions.

Check canonical tags carefully before launch. They should reference the correct live URLs consistently.

Incorrect canonicals can cause Google to ignore your new pages entirely.

managing staging and noindex settings

Staging environments need strict control.

From experience, staging sites are often indexed accidentally or left accessible to Google. This creates duplicate content and confusion.

Ensure staging sites are blocked via authentication or robots rules. Ensure noindex tags are removed from the live site before launch.

Many migrations fail because noindex tags remain in place unnoticed.

testing the migration before going live

Testing is not optional.

From experience, a proper pre-launch test environment is essential. Crawl the staging site, test redirects, check metadata, and simulate user journeys.

Compare old and new versions side by side. Look for missing content, broken links, and layout issues that affect crawlability.

A migration should never be a surprise to the SEO team on launch day.

aligning design and SEO priorities

Design choices affect SEO.

From experience, designers sometimes remove text, change heading structures, or hide content for visual reasons without realising the SEO impact.

Ensure design decisions are reviewed through an SEO lens. This does not mean compromising aesthetics, but it does mean understanding trade offs.

Beautiful sites that hide content behind interactions often struggle after migration.

handling JavaScript and rendering changes

Platform changes often introduce JavaScript.

From experience, moving to modern frameworks increases rendering risk. Content that was server rendered before may now depend on client side execution.

Test rendering using URL inspection tools before launch. Confirm that critical content appears in rendered HTML.

Rendering issues are one of the most common post-migration SEO problems.

preparing tracking and measurement

Measurement continuity matters.

From experience, migrations often break analytics, goal tracking, or conversion attribution.

Ensure analytics tags are implemented correctly on the new site. Verify events, goals, and ecommerce tracking before launch.

Without data, diagnosing post-migration issues becomes guesswork.

planning the launch timing strategically

Timing matters more than people think.

From experience, avoid launching migrations during peak business periods, major campaigns, or seasonal spikes.

Choose a launch window where temporary volatility can be absorbed and monitored closely.

Launching on a Friday afternoon is almost always a bad idea.

communicating the migration internally

Internal teams need to know what is happening.

From experience, customer support, sales, and marketing teams should be briefed on the migration. They may receive enquiries related to broken links, missing pages, or confusion.

Clear communication reduces panic and speeds up issue resolution.

SEO is not just a technical concern. It affects the whole business.

executing the launch with control

Launch day should be calm, not chaotic.

From experience, migrations go best when launch is treated as a controlled operation. Changes are made deliberately, checks are run, and nothing else is deployed at the same time.

Avoid combining a migration with unrelated updates.

Focus on stability first.

immediate post-launch checks

The first hours after launch are critical.

From experience, check redirect functionality, crawl the live site, review robots rules, and verify indexing signals.

Check Search Console for crawl errors and indexing issues.

Catching problems early prevents them from compounding.

monitoring rankings without panic

Ranking changes are normal.

From experience, most migrations cause some ranking fluctuation. Panic reactions often make things worse.

Monitor trends, not individual keyword movements. Look for patterns across sections.

Overreacting to short term noise can introduce new errors.

monitoring crawl and indexation closely

Crawl behaviour changes after a migration.

From experience, Google may crawl more aggressively or more cautiously depending on signals.

Monitor crawl stats, index coverage, and page discovery. Ensure Google is finding and processing the new URLs as expected.

Unexpected crawl drops or spikes often point to deeper issues.

validating redirect performance over time

Redirects are not set and forget.

From experience, some redirects break under load, conflict with caching, or are overridden by later changes.

Periodically crawl old URLs to confirm redirects still work correctly.

Redirect decay is a common long term migration issue.

watching backlink signals post-migration

Backlinks take time to transfer.

From experience, 301 redirects pass most link equity, but not instantly.

Monitor backlink profiles and ensure key links resolve correctly.

Broken backlinks after migration can quietly harm performance.

updating external references where possible

Redirects help, but direct links are better.

From experience, updating key external links to point to new URLs improves long term stability.

This may include profiles, directories, partners, or owned properties.

This is often overlooked but adds resilience.

using URL inspection strategically after launch

URL inspection tools are powerful post-migration.

From experience, use them to verify rendering, indexing, and canonical selection for critical pages.

Do not inspect everything. Focus on priority URLs.

This targeted approach saves time and reduces noise.

allowing time for stabilisation

SEO recovery takes time.

From experience, even perfect migrations need weeks to fully stabilise. Expect gradual improvement rather than instant recovery.

Continue monitoring, but avoid constant changes unless there is clear evidence of a problem.

Patience is part of the checklist.

learning from the migration

Every migration teaches something.

From experience, document what worked, what did not, and what you would do differently next time.

This institutional knowledge reduces risk in future changes.

SEO maturity grows through reflection.

common migration mistakes to avoid

The most common mistakes include skipping audits, rushing redirects, ignoring rendering, and launching without testing.

From experience, avoiding these basics accounts for most successful migrations.

Complex tactics rarely compensate for missing fundamentals.

when to bring in specialist help

Not every migration needs external help, but many benefit from it.

From experience, migrations involving large sites, complex platforms, or high revenue dependency on SEO warrant specialist involvement.

The cost of expert guidance is often far less than the cost of recovery after a failed migration.

final thoughts from experience

A site migration checklist is not about ticking boxes. It is about protecting continuity.

From experience, successful migrations respect the fact that SEO is built over time and can be lost quickly.

I think the most important mindset is this. Treat migrations as risk management exercises, not just technical projects.

When you plan carefully, communicate clearly, and prioritise stability, migrations become opportunities rather than disasters.

SEO survives change when change is handled with respect.