One of the things we feel quite strongly about is that migration planning shouldn’t begin when the new website is ready to launch. By then, you’re too late.

Before making significant decisions about a new website, you need to understand the one that’s already there. Which pages bring people in? Which generate enquiries? Where are the strongest organic rankings? Which URLs have valuable backlinks? What content has performed consistently over time, and how does Google currently understand the structure of the website?

We’d normally combine several sources to build that picture. A website crawl can establish what URLs exist and identify titles, headings, canonicals, internal links and status codes. Google Search Console provides information about organic landing pages and searches, while analytics helps us understand what people actually do when they arrive. Backlink data adds another useful layer because a page with relatively little traffic may still have significant value if other authoritative websites link to it.

Don’t just look at the headline numbers either. Knowing that organic search generates 20,000 visits each month is useful, but knowing that five particular pages are responsible for 60% of your organic enquiries is considerably more useful when somebody suggests removing three of them from the new sitemap.

The point of this exercise isn’t to preserve everything. It’s to understand the difference between what has value and what merely exists.

There’s a big difference between deciding something no longer has value and simply not knowing that it had value in the first place.

Once you understand the existing website, you can start making much better decisions about what belongs on the new one.

Some pages will already be doing their job. They rank well, attract the right people, generate enquiries or have valuable backlinks. They might benefit from improved design and better content, but there’s little reason to completely reinvent them simply because the rest of the website is changing. Where the purpose of the page remains the same, keeping the existing URL can also remove an unnecessary migration risk.

Other pages have established value but aren’t performing as well as they could. Perhaps they’re sitting towards the bottom of page one for an important search, attracting plenty of visitors but converting poorly, or providing good information in a format that’s become difficult to use. Those pages can be some of the biggest opportunities in a redesign because you’re improving something that already has a foundation.

Then there’s the content that’s accumulated over the years. Most established websites have it: several articles covering roughly the same subject, old service pages that overlap with newer ones and sections created for campaigns nobody remembers running. A redesign is a good opportunity to consolidate that content into something stronger, provided you understand what the existing URLs have earned and deal with them appropriately.

And yes, sometimes things should simply disappear. Not every URL deserves eternal life. Outdated announcements, irrelevant content and pages with no traffic, links or useful purpose can often be removed completely.

We’re big believers in protecting existing value. That doesn’t mean preserving existing clutter.

This becomes particularly important when a business already works with an SEO agency or consultant.

We work alongside external SEO teams on plenty of website projects and, in our experience, the best results come when they’re treated as part of the project team rather than someone brought in shortly before launch to check a spreadsheet of redirects. Get them involved during discovery, while the new information architecture is being considered and while decisions are being made about existing content. They’ll know which areas of the website have been growing, what content has been invested in, where valuable rankings exist and what opportunities they’re currently working towards.

They know things we don’t, and that’s a good thing.

As the web agency, our job isn’t to ignore that knowledge because we’re responsible for designing and building the new website. It’s to make sure the right people are involved at the right points in the process.

SEO shouldn’t dictate the entire structure of a website either. User experience, business priorities and content strategy all matter, and there are perfectly good reasons to change pages that currently rank. What matters is that those decisions are made with an understanding of the consequences.

By the time a website is ready to go live, most of the decisions capable of affecting its organic performance have already been made.

A redesign is an opportunity to rethink how a website is organised, and you should use it. Navigation shouldn’t be dictated entirely by what existed before, while SEO shouldn’t become an excuse for preserving an information architecture that nobody can understand.

Equally, don’t throw away a structure that’s performing well purely because somebody wants a cleaner-looking navigation. The new architecture needs to balance users, search demand, content and commercial priorities. If an existing service page has spent five years establishing itself for an important search, folding it into a generic “Services” page should be a deliberate decision supported by evidence rather than an accidental consequence of simplifying the menu.

The same principle works in the other direction. Creating dozens of near-identical landing pages because an SEO tool has identified dozens of keyword variations doesn’t automatically create a useful website.

When we’re planning a new digital platform, we’re trying to understand how all of those requirements fit together. Search visibility matters, but so do the people actually trying to navigate the thing.

Build the website for people. Just make sure you understand what search engines already know about it.

A redesign doesn’t automatically mean every URL needs to change.

If an established page currently lives at /services/software-development/ and the new website will still have a software development page serving essentially the same purpose, it’s worth asking what you actually gain by changing its address.

Sometimes there are very good reasons. The existing URL structure might be genuinely poor, a rebrand may involve a different domain, or a substantial change to the architecture could make a new hierarchy more logical. That’s fine, but changing URLs for cosmetic reasons introduces work and risk without necessarily improving anything.

Where URLs do change, create a proper migration map showing each important old URL and its intended destination on the new website. For a small site that might be a relatively manageable spreadsheet; for a large site it can involve thousands of URLs, historical redirects, PDFs, images and content that’s being merged or removed.

Where an old page has a genuine equivalent, redirect it permanently to that new location. Where several pages have been combined into one stronger resource, redirecting them to the consolidated page may make sense. If a page has been removed and there really isn’t an appropriate replacement, allowing it to return a proper 404 or 410 can be more useful than sending visitors somewhere irrelevant.

What you shouldn’t do is redirect hundreds of unrelated pages to the homepage because it’s convenient. A redirect should take somebody somewhere that makes sense.

It’s also worth cleaning up redirect chains while you’re doing this. Websites that have been redesigned several times often end up with old URLs redirecting through several generations before eventually reaching the current page. Wherever possible, point the original URL directly to the final destination instead.

SEO is an important part of a migration, but it isn’t the only thing an existing website has accumulated. It has operational knowledge too.

Forms may feed a CRM, ecommerce orders might pass into an ERP, newsletter sign-ups can trigger automations and customer accounts might depend on an external authentication service. Tracking scripts, advertising platforms, consent management, downloadable resources and countless other dependencies can sit quietly behind the website.

We’ve worked on plenty of projects where the visible frontend is only one component of a much larger digital platform. Understanding the existing APIs and integrations therefore needs to happen alongside the SEO audit rather than after the build is complete.

The same applies to the content itself. Important page titles, headings, body copy, structured data, image alt text and internal links shouldn’t disappear accidentally during a redesign. None of that means blindly copying the old website; if something can be improved, improve it. Just make sure the change is intentional.

A beautifully redesigned service page containing 80 words of vague marketing copy isn’t necessarily an improvement on the ugly old page that explained the service properly and ranked for 150 relevant searches.

Design, content and development need to improve together.

By the time the new website is approaching launch, we want to be able to crawl and test it properly rather than discovering problems for the first time in production.

The staging website should be protected from public indexing while it’s being developed, but that protection needs to be understood rather than forgotten. noindex directives, robots.txt rules and authentication can all be perfectly sensible during development; they’re rather less useful when accidentally carried across to the live website.

Before launch, crawl the new site and look for broken internal links, unexpected 404s, incorrect canonicals, duplicate or missing titles, missing headings, references to the staging domain and anything else that doesn’t match the migration plan. The XML sitemap should contain the canonical URLs you actually want search engines to discover, while internal links should point directly to their final destinations rather than relying on redirects.

This is also the time to test the redirect map properly. Don’t click ten examples and assume the other 2,000 work. Test them at scale and check that old URLs return the expected status and reach the intended destination without unnecessary chains or loops.

The closer staging behaves to the eventual production website, the fewer surprises you’re likely to have on launch day.

It’s easy for migration testing to become dominated by crawls, status codes and spreadsheets. They’re important, but a technically immaculate migration isn’t much use if nobody can submit an enquiry.

Before launch, test the journeys that matter to the business. Submit the forms and check where the information actually arrives. Complete a purchase, create an account, make a booking, download the brochure and trigger whatever automations are supposed to happen next.

Analytics and conversion tracking need testing as part of that process too. Google Analytics, Tag Manager, advertising pixels, consent management and conversion events should all be collecting the information you expect before you need to rely on that information.

We’d also take appropriate backups of the existing website and agree how the team would respond if something serious went wrong during deployment. For larger or business-critical websites, knowing how to roll back is considerably more useful than discussing it for the first time while the live site is having problems.

Maintaining every Google ranking perfectly isn’t much consolation if all your enquiries are disappearing into a broken CRM integration.

After months of work, there’s understandably a huge amount of focus on the moment the new website becomes visible. From a migration perspective, that’s only part of what needs to happen.

Redirects should go live alongside the new website rather than being treated as tomorrow’s job. Any staging restrictions that shouldn’t exist in production need to be removed, the production site should be crawled again and important user journeys should be tested in the live environment.

Submit the new sitemap through Google Search Console and start checking the important pages. If the project involves moving to an entirely different domain, both the old and new properties should be correctly configured and Google’s Change of Address process used where appropriate.

Then test the redirects again. Staging working perfectly doesn’t guarantee production will, particularly when DNS, hosting, caching, CDNs and server configuration are changing at the same time.

There’s a temptation on launch day to see the homepage load, click around a few pages and declare victory. We’d rather spend that time checking the boring things. They tend to be the things that matter a week later.

Launch isn’t the finish line.

The days and weeks afterwards are when you find out whether all of that planning has worked. Organic traffic, important rankings, indexing, crawl errors, redirects, conversions and enquiries all need monitoring against the baseline you recorded before the migration.

Some fluctuation is inevitable after a significant website change while search engines crawl and process the new structure. A dramatic decline shouldn’t simply be accepted as the price of launching something new.

Pay particular attention to the pages and searches that mattered before the migration. If an established service page previously generated 30 organic enquiries every month and its replacement suddenly generates none, that’s a much more useful warning than a small movement in site-wide traffic.

Search Console can help identify indexing problems and old URLs that Google is still encountering, while analytics should tell you whether users are continuing to complete the journeys that matter. Server logs and backlink data can also uncover old URLs that weren’t included in the original migration plan.

Add sensible redirects where a relevant replacement exists, but don’t develop an obsession with eliminating every 404. Some URLs should return 404. That’s what 404 is for.

Finally, keep the redirects you’ve created. They’re not temporary scaffolding to remove as soon as the new website appears in Google. Old links can exist in bookmarks, emails, documents and other websites for years, and permanent redirects should be treated accordingly.

Once things have settled down, go back to the benchmarks you recorded at the beginning.

Did important pages retain their visibility? Has organic traffic recovered as expected? Are people still finding the website through the searches that matter, and are they converting when they arrive?

A successful migration doesn’t necessarily mean every number stays exactly the same. The whole reason for redesigning the website was presumably to improve something. You may have deliberately removed large amounts of low-value content, consolidated several weak pages into one strong resource or changed the journeys through the website. Overall organic traffic could conceivably fall while the number of qualified enquiries increases, and that may be a very good result.

SEO is part of the picture rather than the sole measure of success. The goal is to protect what was valuable about the old website while creating something better.

There’s quite a lot to think about, so here’s the shorter version we’d use as a starting point for an actual website migration.

Before the redesign

• Benchmark organic traffic, rankings and conversions
• Crawl the existing website and catalogue important URLs
• Identify valuable organic landing pages
• Review important backlinks and linked assets
• Understand existing forms, integrations and tracking
• Decide which content should be kept, improved, consolidated or removed
• Involve the existing SEO team or partner
• Agree how you’ll measure the success of the migration

During the redesign and build

• Use existing performance data to inform the new architecture
• Retain valuable URLs where there’s no good reason to change them
• Create an old-to-new URL migration map
• Plan permanent redirects for changed URLs
• Preserve or deliberately improve important content and metadata
• Rebuild internal links around the new structure
• Protect the staging website from indexing
• Test forms, APIs and third-party integrations

Before launch

• Crawl the staging website
• Test the full redirect map
• Check canonicals and indexing directives
• Check robots.txt
• Validate the XML sitemap
• Check analytics and conversion tracking
• Test critical user journeys
• Check for staging URLs and broken internal links
• Take appropriate backups
• Agree a rollback plan where necessary

At launch

• Deploy the new website and redirects together
• Remove inappropriate staging and noindex restrictions
• Crawl the production website
• Test redirects again
• Submit the new XML sitemap
• Check important pages in Google Search Console
• Complete Change of Address where a domain has changed
• Test forms, conversions and integrations in production

After launch

• Monitor organic traffic and important landing pages
• Monitor rankings for commercially valuable searches
• Monitor enquiries and conversions
• Check indexing and crawl errors
• Investigate unexpected 404s
• Add missing redirects where appropriate
• Keep permanent redirects in place
• Compare performance against your pre-launch benchmarks

We don’t think migration should sit somewhere towards the bottom of a website project plan as something to deal with shortly before launch. It should run through the project from the beginning.

Give it the same importance as design, UX, content and WordPress development. Bring existing SEO partners into the conversation early and keep them involved, and make sure you understand what has value before deciding what stays and what goes.

At the same time, don’t let SEO preservation become an excuse for being afraid to change anything. We’ve rebuilt enough websites to know that the old one usually contains plenty that should be improved, simplified or removed.

The point of migration planning isn’t to preserve the past exactly as it was. It’s to distinguish between the baggage you want to leave behind and the value you’d be mad to throw away.

A new website should move a business forward, but moving forward doesn’t need to mean starting again. After all, some of the most valuable parts of your new website might be the things your old one spent years earning.

If you’re planning a redesign, replatform or CMS move, our WordPress migration team can help plan and deliver the migration with the existing site’s content, integrations and search visibility in mind.