Moving house can be stressful. You’ve got to pack everything up, make sure nothing gets left behind, tell everyone your new address and hope that nothing expensive gets broken along the way. Website migrations aren’t all that different really.
Fortunately, just like moving house, a website migration doesn’t need to be a disaster. In fact, people like us can make the process remarkably straightforward.
At Peaco Marketing, we’ve worked on website migrations for enterprise clients down to local businesses and helped investigate problems that have appeared after new websites have launched. Some have been relatively simple fixes, while others have required a little more digging to understand what went wrong.
And although every migration is different, we’ve noticed that certain mistakes crop up time and time again.
Here are 12 of the most common website migration mistakes we’ve encountered or look out for, what they could mean for your business and how you can make sure they don’t happen to you.
First, What Actually Counts as a Website Migration?
When people hear the words website migration, they often think about moving from one domain to another. While that’s certainly one type, there are several other changes that can qualify.
Replatforming from WordPress to Shopify, redesigning an existing website, changing its URL structure or rebuilding a website using a different development framework can all involve migration work.
Some changes are relatively straightforward. Others can affect thousands of URLs, search engine accessibility and years of accumulated organic visibility. The important distinction is that a website redesign and an SEO migration aren’t necessarily the same project.
Your developers might be focused on building a faster, more attractive website, while your marketing team is concerned with preserving search rankings, enquiries and organic traffic.
Both have perfectly reasonable priorities, but they need to work together, otherwise, you can end up with a beautiful new website that nobody can find.
1. Forgetting About 301 Redirects
We’ll start with probably the most recognisable migration mistake, but one that’s still surprisingly easy to get wrong.
Imagine you run an accountancy firm and have spent years building visibility for a page targeting accountants in Hull. Google knows the page, other websites link to it and it regularly generates enquiries. You decide to launch a new website, and the URL changes from /accountants-hull/ to /services/accountancy/. There’s nothing inherently wrong with that change, provided you tell search engines where the page has moved.
Without a redirect, however, Google and anyone following the old URL could end up at a 404 error page. It’s effectively the digital equivalent of moving offices without leaving a forwarding address. Your business is still there, but the people trying to find it are being sent to the wrong place.
Another approach we sometimes encounter is redirecting absolutely everything to the homepage. Although this might seem like an easy way to deal with hundreds of old URLs, it doesn’t provide a particularly good experience. Someone searching for a specific service doesn’t necessarily want to land on a homepage and have to start looking again. Google can also treat irrelevant redirects as soft 404 errors, meaning they may not pass the intended signals to the replacement content.
Google recommends using permanent 301 or 308 redirects for URLs that have moved permanently. Importantly, it has also confirmed that correctly implemented permanent redirects don’t inherently cause a loss of PageRank. The problem isn’t redirects themselves, but rather poor redirect planning or forgetting to implement them altogether.
Before a migration, we’d recommend creating a complete list of existing URLs using a website crawler alongside data from Google Search Console. Each URL that’s changing should be mapped to the most relevant replacement, with the redirects tested before and after launch. It’s an extra piece of preparation, but considerably easier than trying to recover lost rankings once the website has gone live.
2. Changing From WWW to Non-WWW Without Realising
Here’s a mistake that can appear completely insignificant to someone outside SEO. Almost like SEO treason. Your old website uses www.example.com, but the developer launches the replacement at example.com. What’s the difference? Just four characters, surely?
Well, search engines treat www and non-www as different hostnames, so switching between them needs to be handled properly. The change itself isn’t an SEO problem, but it becomes one when both versions remain accessible or important signals point towards different versions of the website.
For example, the new website could use the non-www version while its canonical tags still reference www. Meanwhile, the XML sitemap might contain a mixture of both, with internal links pointing towards whichever version happened to be used during development. It’s a bit like having two different addresses printed across your business correspondence. People will probably figure out where you are eventually, but you’re making things unnecessarily complicated.
Google uses several signals to determine which URL should be treated as the preferred version, including redirects, canonical tags and sitemap references. When those signals are consistent, switching between www and non-www is generally manageable. When they’re inconsistent, the migration introduces problems that could easily have been avoided.
Our preference is to retain the existing hostname unless there’s a good reason to change it. If a switch is necessary, the old version should permanently redirect to the new one, and the website’s internal links, canonical tags and sitemaps should all reflect that decision.
3. Leaving Images Linked to a Temporary Development Website
This one deserves particular attention because we’ve encountered it firsthand, and it’s a great example of why migration checks shouldn’t finish on launch day.
When a new website is being developed, it’s common for it to be built on a temporary domain. The developer can work on the replacement without interfering with the existing live website, and once everything is ready, the new version is moved across. It’s a perfectly normal development process, but things can get messy when the replacement website continues loading resources from its temporary address.
For example, your live website could be running at example.com, but some of its images are still being loaded from example-development.com. Initially, everything works because the development environment is still available. The website launches, the images display correctly and everyone is happy. Then, a few weeks later, somebody removes the temporary environment and images across the live website suddenly start disappearing.
We’ve dealt with this on a WordPress website where portfolio images were still linked to an old development environment. Interestingly, the images appeared to have the correct URLs when inspected through WordPress, but the page builder was still holding onto outdated references. It wasn’t until the old environment stopped serving those images that the problem became obvious.
This isn’t necessarily a difficult issue to fix once you know where to look, but it can be particularly confusing for the client. From their perspective, a website that’s been working perfectly for weeks has suddenly started falling apart, despite nobody making any obvious changes.
The best way to prevent it is to check where the live website is actually loading its resources from before retiring the development environment. That means checking more than just the WordPress Media Library, particularly when page builders or hardcoded background images are involved. A full crawl and inspection of external resource requests can usually identify references that shouldn’t still exist.
4. Leaving the Development Website Live
On the other side of the coin, we’ve also come across temporary websites left publicly accessible long after the main website has launched.
This might not seem particularly worrying. After all, if nobody is using the development website, what’s the harm? The issue is that search engines can potentially discover it, leaving you with two versions of the same website available on different domains.
Google doesn’t automatically penalise websites simply for having duplicate content. Instead, it generally attempts to identify the preferred version and consolidate signals accordingly. However, leaving an unnecessary copy of your website publicly accessible creates indexing complications that really don’t need to exist, particularly if the temporary domain has already started appearing in search results.
There’s also a practical consideration. An abandoned development website may continue running outdated plugins, themes or software long after the live website has been updated. It’s a bit like forgetting to lock up your old premises after moving out. You might not be using the building anymore, but that doesn’t mean you want to leave it open.
During development, we’d generally recommend protecting staging environments with authentication rather than relying exclusively on robots.txt or noindex directives. Once the new website has launched successfully, the old environment should either be retired or kept securely restricted for future development. Of course, it’s important to confirm that the live website isn’t still depending on it for images or other resources before switching it off.
5. Disabling Server-Side Rendering
This is probably the most technical mistake on our list, but it’s becoming increasingly relevant as websites become more reliant on JavaScript.
When you visit a website, your browser needs to receive and display its content. On some websites, the server provides much of that content directly through the page’s HTML. On others, JavaScript is responsible for generating important parts of what you see, which means the browser has additional work to do before the page is fully displayed.
Think of it like ordering furniture. With server-side rendering (SSR), your furniture arrives assembled and ready to use. With certain client-side rendering approaches, it arrives as a flat-pack and requires some assembly before you can see the finished product. Google is generally pretty good at assembling the furniture, but not every search engine crawler or automated system has the same capabilities.
This becomes a concern when an established website uses SSR and the replacement website doesn’t. From a visitor’s perspective, the new website might look almost identical, but search engines could now need to execute JavaScript to access important content that was previously available immediately. Depending on the implementation, this can affect how readily that content is discovered and processed.
Google’s JavaScript SEO documentation explains that its indexing process can involve a separate rendering stage. It also recommends server-side rendering or pre-rendering as useful approaches because not every bot can execute JavaScript. That’s particularly worth considering as businesses look beyond traditional search engines towards AI-powered discovery, although rendering support varies between systems.
This doesn’t mean that client-side rendering is automatically bad for SEO, or that every website needs SSR. The important thing is making sure the decision is deliberate and its implications are understood. If you’re rebuilding a JavaScript-heavy website, ask your developers whether important content will still be available in the initial HTML and make sure rendering is tested before launch.
6. Leaving Noindex Settings Switched On
This is one of those tiny mistakes that can have enormous consequences, particularly because it’s almost impossible for an ordinary visitor to notice.
During development, it’s common to prevent a staging website from appearing in search results. In WordPress, for example, there’s a setting labelled Discourage search engines from indexing this site. That’s perfectly reasonable for a website that isn’t ready for the public, but considerably less useful when the finished website launches with the same restriction enabled.
The website could look fantastic, load quickly and provide a brilliant customer experience, but if it’s telling Google not to index its important pages, attracting organic traffic is going to be rather difficult. It’s similar to opening a brilliant new shop but forgetting to take the shutters down. Everything inside might be ready for customers, but you’re making it unnecessarily difficult for them to discover you.
The particularly frustrating part is that the consequences aren’t always immediate. Existing search results don’t necessarily disappear overnight, and it can take time for Google to recrawl pages and process new indexing instructions. By the time somebody notices a sustained decline in search visibility, the setting could have been in place for several weeks.
Fortunately, checking this is straightforward for an experienced SEO or developer. Before launch, and again immediately afterwards, important pages should be checked for noindex directives and unexpected robots.txt restrictions. Google Search Console’s URL Inspection tool is also useful for confirming whether Google can access and index the pages you want appearing in search results.
7. Removing Content That Was Actually Doing Its Job
We understand why businesses want cleaner websites. Nobody wants to spend thousands of pounds on a redesign only to end up with enormous blocks of text crammed into every available space. However, there’s a difference between removing unnecessary content and removing information that’s actively helping your website perform.
Imagine your existing service page ranks well for several relevant searches. It explains your offering in detail, answers common customer questions and generates consistent enquiries. During the redesign, that content gets reduced to a heading, two short paragraphs and a contact button because the new layout looks better with less text.
The finished page might look fantastic, but there’s a reasonable chance you’ve removed some of the information that made it valuable in the first place. Search engines use page content to understand relevance, and visitors often rely on that same content to decide whether a business is right for them. Removing useful information can therefore affect both organic visibility and conversion performance.
We’re certainly not suggesting that every paragraph from the old website needs to be preserved. Content should be reviewed during a migration, and sometimes removing or consolidating pages is absolutely the right decision. The important thing is making those decisions based on performance and usefulness rather than aesthetics alone.
Before redesigning important pages, review their existing performance in Google Search Console and GA4. Identify which pages generate organic traffic, what people search for to find them and whether they contribute to enquiries or sales. Your designers can then work with that information to create something visually appealing without accidentally removing the content that’s helping to bring customers through the door.
Good design and good SEO shouldn’t be competing priorities.
8. Changing Every URL Because the New Structure Looks Nicer
While we’re on the subject of redesigns, let’s talk about unnecessary URL changes.
Sometimes a website’s structure genuinely needs improving. Perhaps important services are buried several levels deep, the navigation has become confusing or the existing URLs no longer reflect how the business operates. In those situations, restructuring the website can make complete sense.
However, we’ve also seen website rebuilds where almost every URL changes for no particularly compelling reason. The existing URLs might already rank well, attract backlinks and make perfect sense to customers, yet they’re replaced because somebody prefers a different naming convention or folder structure.
There’s nothing inherently wrong with changing URLs when it’s done properly. Search engines can process those changes using redirects, and an improved structure may provide longer-term benefits. The question is whether you’re introducing additional migration work without gaining anything meaningful in return.
Google’s migration guidance recommends changing one major aspect of a website at a time where practical. If you’re changing domains, redesigning the website and migrating to a completely different platform simultaneously, that’s quite a few moving parts to investigate if performance declines. Keeping existing URLs wherever appropriate helps reduce that complexity.
Our approach would always be to understand why a URL needs changing before changing it. If there’s a genuine structural benefit, go ahead and plan the redirect properly. If it’s purely a cosmetic preference, it’s worth asking whether the change is really necessary.
9. Forgetting About Internal Links, Canonicals and XML Sitemaps
This is where the smaller technical details start to add up, and it’s one of the reasons we recommend carrying out a comprehensive technical crawl after a migration.
You might have implemented all your redirects correctly, but the new website could still contain hundreds of internal links pointing towards old URLs. Visitors may eventually reach the right pages, but they’re being sent through unnecessary redirects along the way. These links should generally be updated to point directly towards their final destinations, particularly when they’re part of your main navigation or important internal linking structure.
Canonical tags can create similar problems. They’re signals that help search engines understand which version of a page you consider to be the preferred one. If the new website still contains canonical tags pointing towards the old domain or development environment, you’re effectively giving Google directions to somewhere you’ve already moved away from.
Your XML sitemap can also become outdated if it contains redirected URLs, pages that no longer exist or content that shouldn’t be indexed. While Google doesn’t blindly follow everything in a sitemap, it uses that information as a signal when discovering and processing URLs.
Individually, these issues might not cause a dramatic traffic decline. Collectively, however, they introduce unnecessary complications that can make it harder for search engines to understand your replacement website.
This is precisely the sort of work covered by our technical SEO services. After a migration, we’d want to review the website’s internal linking, canonical configuration and sitemap alongside its wider crawlability and indexability, rather than assuming everything is fine because the redirects are working.
10. Losing Analytics and Conversion Tracking
Not every website migration mistake directly affects Google rankings. Sometimes the website continues attracting visitors and generating enquiries, but the business suddenly loses the ability to measure what’s working.
This can happen when tracking hasn’t been properly migrated or tested. For example, you might replace your existing contact form with a new plugin, only to discover that the GA4 event you previously used to measure enquiries no longer fires. Alternatively, your new website might use a different booking system, and Google Ads can no longer identify which visitors go on to make an appointment.
From a marketing perspective, that’s a significant problem, particularly when you’re running paid advertising alongside the migration. If you’re spending thousands of pounds bringing people to your website, you want to know whether those visitors are turning into customers. Otherwise, you’re effectively trying to manage your campaigns with half the dashboard missing.
There’s also the risk of inconsistent data. A developer might add a new analytics tag without realising the website already contains one, causing page views or events to be recorded twice. That can be just as misleading as missing data, especially when marketing decisions are being made based on reported conversion rates.
Before a migration, we’d recommend documenting how the existing website measures important actions, including form submissions, telephone clicks and completed bookings. Once the new website is ready, those journeys should be tested to confirm that events are being recorded correctly in GA4 and any relevant advertising platforms.
It’s a relatively small part of the wider development process, but one that can save considerable confusion when the next marketing performance report is due.
11. Forgetting to Test Mobile Performance
Most businesses will have experienced this at some point. A new website looks fantastic on a large desktop monitor, but the mobile version tells a slightly different story.
Buttons overlap, navigation becomes awkward, forms are difficult to complete and important content disappears behind poorly configured design elements. Even when everything technically works, a design that looks brilliant on desktop can be frustrating to use on a smaller screen.
These problems can also come with performance issues. A new website might introduce large images, excessive JavaScript or other resources that make it noticeably slower than the previous version. While a redesign should ideally improve the overall user experience, that isn’t guaranteed simply because the website looks more modern.
Google primarily uses the mobile version of a website’s content for indexing, which makes mobile accessibility particularly important during a redesign. However, we’d argue that the commercial consideration is just as significant. If potential customers struggle to navigate your website or complete an enquiry on their phone, you’re creating an unnecessary barrier between your marketing activity and a sale.
Mobile testing should therefore involve more than resizing a browser window and checking that the layout looks reasonable. We’d recommend testing important customer journeys on actual devices, reviewing Core Web Vitals and checking whether the replacement website introduces performance problems that weren’t present previously.
The objective isn’t just to build a website that looks good on mobile. It’s to build one that people can comfortably use.
12. Thinking the Job Is Finished on Launch Day
This is probably the biggest misconception about website migrations, and it’s where otherwise successful projects can start to unravel.
The new website goes live, everybody celebrates and the developer moves on to the next project. From a design and development perspective, much of the work might be complete, but search engines still need time to discover and process the changes.
According to Google’s official website migration guidance, it can take a few weeks or longer for a medium-sized website’s new URLs to replace the old ones in search results. Larger websites can take considerably longer, depending on the number of URLs involved and how quickly Google processes them.
Some ranking fluctuations during this period are entirely normal, so there’s no reason to panic simply because organic traffic looks a little different immediately after launch. However, that doesn’t mean you should ignore what happens next. A sustained decline in visibility, increasing crawl errors or important pages disappearing from search results could indicate an issue that needs investigating.
We’d want to know whether important pages are being indexed, whether redirects are working and whether organic traffic is behaving as expected. We’d also keep an eye on things such as temporary development environments and broken resources, particularly given how some of those problems can emerge weeks after the website goes live.
A good migration plan should include monitoring after launch, with clear responsibility for identifying and resolving anything unexpected. For established websites, we’d recommend comparing organic traffic, search impressions and conversions against a baseline recorded before the migration, while accounting for seasonality and normal changes in demand.
Launching the new website is an important milestone, but the migration isn’t really complete until you’ve confirmed that everything is working as intended.
Website Migration Checklist: What Should You Check Before Going Live?
If you’re a marketing manager or business owner preparing for a website migration, you don’t necessarily need to understand how to implement every technical change yourself. That’s what your developers and SEO specialists are there for. However, you should feel confident that the appropriate checks are being completed, particularly if organic search already generates a meaningful proportion of your business’s enquiries or sales.
We’ve put together a straightforward checklist covering the main things we’d want to see addressed before, during and after a migration. It’s something you can share with your development team or use when reviewing an agency’s proposed migration process.
Before the Migration
- Export existing website URLs and document the current site structure.
- Identify important pages using Google Search Console and GA4.
- Review pages attracting valuable backlinks.
- Decide which URLs and hostname format will be retained.
- Prepare a redirect map for URLs that need to change.
- Document existing analytics and conversion tracking.
- Take a complete website backup and agree on a recovery plan.
During Development and Launch
- Confirm important content and metadata have been preserved.
- Check that search engines can access and index the website.
- Test redirects and ensure they lead to relevant destinations.
- Review canonical tags, internal links and XML sitemaps.
- Check that images and other resources don’t depend on temporary domains.
- Test JavaScript rendering where relevant.
- Review mobile performance and important conversion journeys.
- Confirm GA4 and advertising conversion tracking are working.
After Launch
- Crawl the live website for technical errors.
- Submit the updated XML sitemap through Google Search Console.
- Monitor indexing, search visibility and conversions.
- Confirm the preferred domain version is being used consistently.
- Secure or retire the staging environment once it’s no longer needed.
- Investigate unexpected changes affecting important landing pages.
- Continue monitoring performance over the following weeks.
Not every website will require the same level of preparation, and a small brochure website is very different from an e-commerce business migrating thousands of products. Nevertheless, having a documented checklist makes it considerably easier to manage responsibilities and avoid important tasks being forgotten.
It’s also worth agreeing who will sign off the technical SEO side of the migration. Developers and designers have plenty to manage already, so having somebody specifically responsible for protecting organic visibility can be particularly valuable.
How Much Organic Traffic Should You Expect to Lose During a Migration?
One question businesses often have when planning a migration is whether they should expect to lose organic traffic.
The answer is that some fluctuations are normal, but there isn’t a universal percentage of traffic you should expect to lose. A well-managed migration may experience relatively little disruption, while more substantial changes can take longer for search engines to process. The outcome depends on the existing website, the changes being introduced and how effectively the migration has been managed.
Google’s own documentation provides some useful guidance.
| Google’s guidance | What it means for your migration |
|---|---|
| A medium-sized website move can take a few weeks or longer to process | Don’t judge the migration solely on the first few days of data |
| Permanent redirects don’t inherently lose PageRank | Correct redirects help preserve existing search signals |
| Redirects should remain for at least one year | Don’t remove old redirects immediately after launch |
| Search rankings can fluctuate temporarily | Some movement is normal, but sustained declines deserve investigation |
| Larger websites may take longer to migrate in search results | Allow enough time for post-launch monitoring |
Source: Google Search Central, Site Moves and Migrations.
We’d be cautious about anyone promising that a website migration will result in an immediate increase in organic traffic. A replacement website might create opportunities to improve SEO, especially if it addresses longstanding technical issues or introduces better content, but the act of migrating doesn’t automatically produce growth.
In many cases, the first objective should simply be to preserve what the business has already achieved. If you’ve spent several years building organic visibility, protecting those existing rankings and enquiries is a sensible priority before introducing more ambitious changes.
Once the replacement website is established and performing as expected, you can concentrate on improving its performance. A successful migration should provide a stronger foundation for future growth, rather than forcing the business to spend months recovering what it previously had.
Does Your Website Migration Need SEO Support?
Not every migration requires a major SEO project. If you’re updating a handful of pages on a small website without changing URLs or technical infrastructure, the process might be relatively straightforward. An experienced developer may be able to manage the necessary checks without extensive additional support.
However, the more established your website becomes, the more there is to protect. If organic search generates a significant proportion of your enquiries, losing important rankings could have a genuine commercial impact. The same applies when you’re moving domains, rebuilding a large website or changing how its content is delivered to search engines.
That’s where involving an SEO specialist can make a difference. Ideally, SEO should be considered before development begins, rather than brought in after launch to investigate why traffic has declined. Working alongside the development team means potential issues can be identified during planning, with appropriate checks built into the project from the start.
It’s also important to recognise that developers and SEO specialists bring different expertise to the table. A developer might be excellent at building fast, accessible websites without necessarily having detailed knowledge of historical search performance or migration-specific SEO requirements. Bringing those disciplines together usually produces a better result than expecting either one to manage everything independently.
Ultimately, the level of support should reflect the complexity of the migration and how much your business depends on its existing website performance.
Conclusion
We’ve covered quite a few things that can go wrong during a website migration, but the intention certainly isn’t to put you off launching a new website. Quite the opposite. Website migrations are normal projects, and most of the problems we’ve discussed are entirely manageable when they’re identified early.
The important thing is recognising that launching a website involves more than making sure it looks good and works when somebody clicks around it. There are existing rankings to protect, content to preserve and technical considerations that might not be immediately obvious to the people signing off the design.
And while we’ve encountered our fair share of migration headaches, the majority of the issues we’ve discussed can be prevented with proper planning and the right checks in place. In our experience, the best projects are those where developers, marketers and SEO specialists understand what the business needs to protect before making changes.
At Peaco Marketing, we provide technical SEO and website migration support to help businesses protect their existing visibility while moving forward with their websites.
If you’re planning a redesign or migration, we’d always recommend getting SEO involved early. After all, it’s much nicer to launch a new website and start planning how to grow its traffic than spend the following month trying to work out where the old traffic went.