The Ultimate Guide to Successful Website Migrations
We all have to deal with website migrations sooner or later. In this article we'll explain our phased approach to website migrations, including an in-depth website migration checklist, so you can ace your future migrations.
What we classify as a website migration
It's important that we outline what we classify as a website migration before moving forward.
Website migrations come in many flavors; some are tiny and others are massive.
The most common ones are:
- Changing URLs: you want to e.g. , fix incorrect URLs, or future-proof URLs by removing the year from the .
- Merging content: you've got multiple pages about the same topic that are cannibalizing each other, so you're merging them together.
- Website redesign launch: you're changing the whole look and feel of your website—and often adding, changing, or removing content too.
- Changing your website architecture and/or URL structure: for example you're adding new services and products to your site, or you're unhappy with your current information architecture, which brings you to redo it.
- Switching from HTTP to HTTPS: your website's going to be served over a secure connection, and so all of your URLs will change.
- Switching hosting providers: for instance you're unhappy with your website's performance at your current hosting provider.
- Switching to a new CMS: for example your website has grown massively in terms of pages, functionality, and visitors, and you're in need of a more robust CMS system.
- Switching domain names: you're changing your domain name.
- Merging websites: for example you're acquiring a business, and you're looking to consolidate its website into your existing one. Or you're switching from a multi-domain strategy to a single-domain strategy.
Why website migrations are tricky
When you're making changes to pages that are ranking in search engines, you're rocking the boat. There's always the chance that you'll lose your rankings when you start making changes. Yes, you understood right: there are absolutely no guarantees that your rankings will return to the same level after your migration.
That's a frightening thought, and one that demands that even the most seasoned SEOs bring in their A-game.
The good news is that by handling website migrations well, you can ensure that there's little to no negative effect on the website's rankings.
How to successfully handle website migrations
The best way to approach website migrations is to avoid them completely.
We're not kidding, it's true. How can you achieve this?
Even when a migration seems to be on its way, you need to ask yourself: "is this migration actually worth it?"
Besides the obvious SEO risks involved when you're changing URLs, website migrations also impact your social shares. You need to migrate these as well.
Since you probably came to this article looking for best practices regarding your impending website migration, the next piece of advice is to change as little as possible in one go.
All the changes you're going to make will have an impact on your rankings, so making the website migration a multi-stage process is a smart thing to do. Now, it certainly sounds attractive to just have one big bang that involves launching on a new domain while launching a new design and publishing a whole new SEO strategy too.
Successful website migrations are planned well, and executed with military precision.
We managed dozens of large-scale website migrations in our agency days, and nowadays we witness dozens of them going down on the websites that ContentKing is monitoring on a daily basis. And they don't always go well. Lucky for them, ContentKing spots issues quickly, as it monitors in real-time, which enables our customers to take action as issues unfold. But it's still frustrating and time-consuming, and it's often completely unnecessary.
This alert was sent by ContentKing right after a migration went wrong:
Remember, prevention is better than a cure: it's a lot easier and cheaper to prevent website migrations from going wrong in the first place than to recover from a failed website migration.
Why website migrations fail
When website migrations fail, it's usually because of:
- A lack of awareness of the risks involved in website migrations
- Poor planning
- A shaky migration checklist (or no checklist at all)
- A lack of knowledge by the parties involved
You might ask: "So how do I address this to make my migration successful?"
Hopefully, we've already given you enough inspiration in the previous sections to prevent a lack of awareness of the risks involved.
In the next sections we'll cover how to get the planning right and how to put together a kick-ass website migration checklist, and we'll provide background information around important topics that you'll have to deal with during the migration.
It's important to note that, even if you flawlessly execute a website migration, you may still be looking at a long road to organic traffic recovery. Simply because at some point, things are just out of your hands and it's Google's turn to work their magic.
Especially in case of domain migrations, the road to recovery can sometimes even take six to twelve months.
The website migration process
We've come to see the website migration process as having these phases:
Phase 1: Planning
Planning is essential to a successful website migration. Take the time you need to allocate enough resources to the website migration project, compose a solid migration checklist, educate people within the team, and make them aware of the risks involved.
The website migration's planning starts when it's first being discussed—even if that's just floating some ideas. From this moment on, SEO experts will need to be involved.
Scope the website migration
First you scope the website migration: what's going to change, and who's impacted? There's a difference between some content being moved within the website and a complete redesign being launched. The former is a lot less risky, and requires a lot less resources than the latter.
Build a website migration team
Build a website migration team that includes everyone whom the website migration impacts. This often include: system administrators, developers, designers, copywriters, project managers, SEOs, legal, and management. Plan a kick-off meeting with everyone in the room, so everyone's on the same page.
Clearly identify who's managing the website migration (this might be an SEO expert, but that's not absolutely necessary).
Identify concerns and define goals
Ask all the people involved what their concerns are, and what it takes for the website migration to be successful in their eyes. This is also where you define the goals for the website migration. Without these goals, you can't determine whether the migration was successful when you go on to evaluate it post-migration.
Explain the risks involved and what to expect
Explain to the whole team the risks involved in doing the migration, what to expect in terms of traffic drops after the migration, and why this happens. It's likely you'll see fluctuations in rankings and a (temporary) drop in traffic. This is common, so manage expectations.
Map out tasks
Create a list of what needs to be done before, during, and after the website migration, and assign it all to the right people. That's where the website migration checklist, which we'll cover in upcoming sections, will come in handy.
You can for instance use Google Spreadsheets or Trello to manage the planning and assign tasks.
Choose the best moment to launch
Now that you know what a website migration comprises, you can choose the best moment to launch. Avoid launching around holidays and peak times, and don't launch on Friday afternoon because "it's a great way to end the week."
Tuesdays and Wednesdays are usually good days to launch, because Mondays are notorious for meetings, and meanwhile you'll have a few days before the weekend to fix high-impact issues. Scheduling the launch at 10 AM gives people enough time to get to work and do their morning meetings / standups. Plus it gives you most of the day to focus on the migration.
Phase 2: Pre-migration preparation
During the pre-migration preparation phase, you prepare everything you're going to need along the way. This is where the heavy lifting is done.
Define SEO requirements
If the website migration involves a redesign or CMS change, be sure to define the SEO requirements that apply for the developers. Examples of things that need to be addressed:
- URL structure
- Meta information (titles and descriptions)
- Body content and headings
- XML Sitemaps
- Structured Data (e.g. Schema.org)
- Load time
There's much more to say about this—but that demands an article of its own.
Evaluate the design
If the website migration involves a redesign, it's essential that the redesign be evaluated by the SEO experts involved. Why? Because the design prescribes if and where content and links are positioned, and this has a massive impact on your SEO strategy.
Example: you may find out that the designer didn't find it necessary to include body content in the product category pages—and the detail pages.
To avoid frustration and wasted money, involve SEO experts from the moment the first wireframe drafts are made.
When doing a website migration, you need to know what content is impacted by the migration. The first step is to list what content you have. We call this running , and it's basically creating a full overview of your website's content.
Use every tool at your disposal to paint a full picture of all of your website's content. That includes crawling your site with ContentKing, exporting all the pages from your CMS, and using analytics software to find all the pages that are getting traffic.
Here's a screenshot of pages with their Google Analytics data in ContentKing:
Don't forget that other media types, such as images and PDF files, are also content, and these too play a role in your SEO success.
Audit your content and identify top-performing pages
Pull up on your site, and identify top-performing pages. Your top-performing pages are the pages that generate the most revenue and conversions and drive the most traffic. You need to prioritize your efforts, so it's essential that you know your top-performing pages.
Identify your top-performing pages using the KPIs you just pulled up and verify this list of top-performing pages using:
- ContentKing: Go to Pages and sort based on Importance, which takes into account a variety of factors that determine importance, including Google Analytics and Google Search Console data. You can filter on all of this data, as well as set up segments for it.
- Rank tracking tools
- Analytics software, e.g. in Google Analytics
- Backlink data from tools such as Google Search Console, Ahrefs, and Majestic
Indicate whether pages will still exist after the migration and whether they'll be moved, consolidated, or even removed. You'll need this information later on, when you'll be drafting your redirect plan.
Fit the new content into the information architecture
If you're going to be adding new content, it's important that you determine whether this new content can be part of the existing website architecture or not. If your existing website architecture isn't flexible enough to accommodate this new content, you need to rework your website architecture.
Update your rank-tracking tool
You've identified your key pages, and you've already touched on some of the keywords these pages are ranking for. Now it's time to update your rank-tracking tool to make sure you're tracking all of the queries you're ranking for. This is important, as you need to monitor these queries after the migration to make sure you're getting back on top.
Pull up your list of top-performing pages and make sure all the queries they're ranking for are being tracked in your rank-tracking tool. Use tools such as Google Search Console, Ahrefs, and SEMrush to verify that you're tracking all of the important queries.
Your redirect plan describes what domains and URLs need to be redirected when you launch. Keep in mind that you probably already have redirects in place within your existing website. If you don't migrate these, that can have a severe negative impact on your SEO performance.
Make a list of the domains and URLs that are currently redirecting and put these in a spreadsheet with three columns:
- Column A: the domain or URL of the URL that's being redirected currently.
- Column B: the destination of the existing redirect.
- Column C: the destination of the new redirect.
Let's look at an example.
Let's say there are three domains redirecting to a website:
- Domain A 301-redirects to
- Domain B 301-redirects to
- Domain C 301-redirects to
And there are redirects in place because of a URL change for the shop page:
Then the domain changes from
example-new.com. The new URL of the shop page is:
Then this is what the redirects need to look like:
- Domain A 301-redirects to
- Domain B 301-redirects to
- Domain C 301-redirects to
The next step here is to supplement this list of redirects with URLs that are going to changing due to the migration.
Please note that you need to avoid having . A chained redirect is when one URL is requested, and a redirect is used to redirect it to another URL and in turn this particular URL is redirected as well.
Set up page redirects correctly
Always redirect old URLs to the most relevant new URLs, instead of just redirecting them to the new homepage.
If you don't, these redirects can be seen by search engines as soft 404s, resulting in less link value passed on in general. Also, you'll see dramatic ranking drops for all of your pages that used to rank.
Set up domain redirects correctly
It's a common mistake to incorrectly configure domain redirects during a website migration, resulting in multiple redirect hops. For instance, when you request a domain that's currently redirected, you want it to redirect to the final destination URL right away, regardless of whether or not the right protocol and subdomain were requested.
Again, let's look at an example:
- Let's say you're going to move to
http://www.redirecting-domain.comshould 301-redirect directly to
If you'll be switching domain names and merging websites (scenarios eight and nine)—keep in mind that domain names can have a search engine penalty, and that this penalty may be carried over when the old domain is redirected to the new domain.
Update URLs in other places
URL changes don't just impact SEO. They impact all of your marketing efforts; from PPC campaigns to your email newsletter and brochures.
Inform everyone within your marketing team what URLs are going to change, so they can prepare appropriately.
- Google ads (and be sure to update Google Shopping feeds too)
- Twitter ads
- Facebook ads
- Reddit ads
- LinkedIn ads
- Social media accounts
- Newsletter templates
- Transactional emails
- Offline brochures
It's important to update the paid campaigns for two reasons in particular:
- If your redirects fail, you don't want your paid campaigns to suffer too.
- Paid campaigns may be paused by your advertising networks when the destination URLs used in the ads are redirected.
Please note: these updates shouldn't be published until the launch.
Prepare a paid campaign for rebranding and for the most important queries
If you're rebranding, it makes sense to set up paid campaigns for queries around both the old and new brand, to ensure that as many visitors as possible reach your site.
Also, when you start the migration, and search engines have to fully crawl and index your new site, there's a good chance you'll see a temporary drop in your rankings. If you can't afford to have less traffic on the site, you can prepare paid campaigns. This compensates for the loss of organic traffic with paid traffic to keep your revenue numbers on par.
XML sitemap containing old URLs
Contrary to popular belief, it's important to hold on to an XML sitemap that contains your old URLs when you're migrating, because this way you'll help search engines find your new URLs faster, by feeding them the redirected old URLs. Keep the XML sitemap with the old URLs present on your site until the new URLs are indexed well.
Set up a separate environment
It's a best practice to work with a separate environment where you do your testing. You just don't make technical changes to the live site, because it's very risky: if something goes wrong, that impacts your visitors directly.
For the website migration to go smoothly, it's essential that you have a separate environment next to the production environment where you can fill in content, test, and prepare for the launch. We'll call this environment the 'new' environment and the current environment the 'old' environment moving forward. Both the new and the old environment, meanwhile, themselves have a production and a staging environment. Testing is done in the staging environments.
Having separate environments has the following benefits:
- Prior to going live, you can test if all the functionality is working fine in the new environment.
- You can audit the new environment to check if all your content is set up correctly, and if the new website is SEO proof, i.e. optimized.
- The old environment can be used to quickly answer such questions as: "uhh, how did we do this again on the old site?". At some point, you'll end up asking yourself what features, content, CTA buttons and metadata you had on the old site. If you're changing domains, be sure to also keep your old site in ContentKing for a while so that you can retain your change history data. Move the old environment to a subdomain (example:
https://old.example.com) and make sure it's not accessible to search engines via HTTP authentication (whitelisting IPs and/or requiring a username and password)
- You can quickly roll back the launch, for example by changing the DNS records.
Make sure your new environment is not accessible to the public. The best way to go about this is . We recommend whitelisting the IP addresses at your office, and allowing external parties and remote team members access via username/password.
This is a better approach than to use robots.txt and the robots noindex directive, because these don't prevent other people from accessing them, and search engines will not always honor these directives.
Rolling back the launch
Being able to roll back the launch is great, but you need to have a plan in place for this scenario. It's important to define under what conditions you roll back a launch, and who calls the rollback.
In most cases, it's the project manager who decides to roll back a launch as he's the liaison among all the departments that are involved in the migration, but still, be sure to explicitly determine who can decide to roll back.
As for when to roll back a launch, you need to define that beforehand, so you don't have to define it in the heat of the moment.
Basically, roll back for anything that's going to severely impact revenue (more than you can afford) and that cannot be resolved quickly.
Lower the TTL for your DNS records
One important part of your pre-migration preparation is to lower the time-to-live (TTL) of your DNS records. The TTL states how long DNS servers should hold on to your domain's DNS records before requesting them again. The lower the TTL, the more frequently they'll request them and the more quickly a DNS change will be propagated. Having a low TTL enables you to migrate quickly and gives you the flexibility to roll back the migration in case issues arise.
When to lower the TTL in preparation for the migration depends on your current TTL, as that's how long it will take for the new TTL value to take effect everywhere.
We recommend lowering the TTL to 300 (the value is in seconds, so this equals 5 minutes) before the launch.
Phase 3: Pre-migration testing
You've made all the necessary arrangements and prepared well, and now it's time to put everything to the test and do pre-migration testing to make sure you're ready to hit the launch button on launch day.
Making sure you can access the new environment
If you're going to migrate to a domain name that's currently not in use, you don't need to do anything, because you can access it right away. If the migration will take place on an existing domain name, then you can adjust your host(s) file or go through a local DNS server.
Test whether the redirects from your redirect plan are actually implemented and working fine.
We recommend that you test them by checking some samples manually, and running the majority in bulk using a tool like Screaming Frog.
- URL structure: go through the list of URLs and check whether the URL structure is correct. .
- Titles, meta descriptions and headings: are they in line with your SEO strategy? Read more on , , and .
- Body content: do all your pages have content?
- Internal link structure: is your link structure in line with your SEO strategy, and do the most important pages have enough links from strong, related pages? Are internal links updated to point to new URLs instead of the old URLs?
- Canonical URLs: are your canonical URLs correctly used to point to the canonical variant of a page, to consolidate signals and prevent duplicate content? .
- Robots directives: are robots directives correctly used to prevent pages from getting indexed, preventing duplicate content in the process? .
- Crawler traps: does the new website suffer from the presence of crawler traps—a virtually infinite amount of URLs being generated? .
- Structured data: is structured data such as Schema, Open Graph, and Twitter Cards set up correctly? Read more about , , and .
- Correct status codes: are pages returning the correct status codes? Use only 301 redirects for redirects, 404 status code for pages that don't exist, and 410 status codes for un-migrated pages that have been removed and won't ever come back. .
- Broken links: check the site for any . In particular, look for links to old URLs and URLs used to preview unpublished pages.
- Hreflang: if your website is available in multiple languages, and you're using hreflang, make sure that your hreflang implementation is valid. .
- Pagination: if you're using pagination on the new site, for example for product category pages or blog archive pages, then make sure the new pagination implementation is valid. .
- Page speed: while after the launch you'll see how the website performs in practice, you can run page speed checks on the new site already at this stage, using for instance ContentKing. We recommend setting up segments for slow pages to easily track these.
- Domain redirects: are the domain redirects set up correctly? If your canonical domain is
https://example.com, then you need to make sure
http://www.example.comall 301 redirect to
https://example.comwith just one hop. .
- XML sitemap: does the new site contain a valid XML sitemap that only contains indexable pages? .
- Robots.txt: is there a robots.txt present on the new site, and does it contain all the necessary directives? If you've prevented others from accessing the new environment using robots.txt, don't be alarmed if ContentKing flags that. You can feel free to ignore this issue. .
Triaging any issues
When doing pre-migration testing, you'll always spot issues. Triage all the issues that come up and determine whether these issues are release-blocking, or whether they can be fixed after launch. Be pragmatic, and keep the migration goals that you defined at the start of the project in mind.
Pushing back a release is costly, so weigh the pros and cons carefully with each issue that you uncover.
If nothing serious comes up, or if you fix enough issues that you can remain comfortable with launching, then you can move on to the next phase: launching!
Phase 4: Launch!
Launch day is always exciting (and somewhat frightening). But you've prepared well, and you have performed pre-migration testing. Nothing major has come up, or it's been fixed already, so you're confident the migration will go well.
Make the new site accessible
Remove any limitations that you've set up there to keep out search engines and users prior to launching, such as:
- HTTP authentication (as discussed in the section.)
- Any robots noindex directives (both meta robots and X-Robots-Tag)
- Any Robots.txt disallows
Update DNS records
Now update your DNS records to point them to the new environment.
Phase 5: Post-migration review
Congratulations on the launch!
But, before you start high-fiving everyone: make sure everything is working properly in the new production environment. In this phase, you'll decide whether the launch went well, or whether you need to roll it back. It's important to prevent falling for the , meaning: if you've already been fixing issues for three hours and you're still not there yet, don't tell yourself you're "too far to go back"; you can still make the call to roll back the launch.
Work your way through this checklist of high-priority checks to make sure the website is in good shape:
- Test top-performing pages: test your top-performing pages to ensure they're working properly and contain the right content.
- New robots.txt: does the new website's robots.txt provide the right access to the right crawlers?
- Old robots.txt: if you're dealing with domain name changes, does the old website's robots.txt provide search engines access so that they can follow the redirects? More often than you think, a damaging
Disallow: /is added to the old domain's robots.txt.
- Robots directives: are the robots directives set up correctly (check both meta robots and X-Robots-Tag).
- Redirects: are all redirects in place and working properly?
- SEO checks: go through and make sure everything is in order.
- XML sitemaps: as part of your SEO check, you made sure that the new XML sitemap would be correct. As discussed, you also need to make sure the XML sitemap with the old URLs is accessible on the old domain, so that search engines can discover the new pages quickly. Keep the XML sitemaps containing old URLs online for a month.
- Analytics: make sure all required analytics software is working properly and the right tracking IDs are present. Often during migrations, either they're left inactive, or staging IDs are present. These are problems, as you're losing out on valuable data—the first signs of your new website's performance. Luckily ContentKing checks both the presence of analytics software and its tracking IDs on all pages by default. You want to keep using the same tracking IDs, as you want to easily compare the previous performance of the website with its current performance.
With such a massive undertaking as a website migration, you're bound to encounter issues. That's normal. You'll likely end up with a list of small issues that you need to address. But because you thought ahead and allocated development resources to post-migration fixes, there's no trouble there—they can be addressed right away!
Phase 6: Post-migration follow-up
Is everything still looking good? If so, you can move forward with the steps below:
Registering new website properties in Google Search Console and Bing Webmaster Tools
If you migrated to a new domain, be sure to register the new domain in Google Search Console (GSC) and Bing Webmaster Tools (BWT) and tell them about your XML sitemap.
Be sure to register all the versions of the domain:
GSC and BWT: change of address
If you've migrated to a new domain, tell Google and Bing about this using the Change of Address feature.
GSC: Fetch and Render
Use Google Search Console's Fetch and Render feature to make sure Google can request and render your pages. This is a useful feature to make sure you didn't miss anything.
Now push the updated paid campaigns you prepared live, so that the destination URLs point to your new URLs (and if there's a brand change, so that the ad texts mention the new brand).
If you've prepared paid campaigns around rebranding and your most important queries, this is the time to activate these too.
Reach out to websites that are linking to your old websites to update their links to point to the new site. This lowers load time for your visitors, passes on more link value, and in the case of a new brand, helps boost its visibility.
Increase TTL of DNS records
A few days after the migration, you can safely increase the TTL of the site's DNS records. What value you'll be increasing it to depends; if you're using a CDN they are often still quite low, while if you're not, they're usually higher (anywhere from a few hours to a few days). But in any case, set it to the pre-migration value.
Make old environment accessible
Remove the old staging environment
Now is also the time to remove the old staging environment, as the old environment only serves as a reference and is no longer being developed.
Phase 7: Post-migration monitoring
Monitor your KPIs
Monitor your KPIs to make sure the new website is performing well. This goes beyond SEO of course, as SEO is often just one of the main sources for traffic, conversions, and revenue.
One part of monitoring is checking the number of pages that are indexed for the old website (this should go down) and the new website (this should go up if you've published more content!) using Google Search Console. The XML Sitemaps come in handy here if you've split them up per website section. That way you can easily track the indexing process per website section.
Monitor 4xx errors
Monitor the new website for 4xx errors with ContentKing. In particular, you should be on the lookout for 404 and 410 errors.
Additionally, check your server logs to find 4xx errors that ContentKing may not be monitoring, and check Google Search Console to see if Google has hit any 4xx errors.
If these 4xx errors are unexpected, fix them by redirecting these URLs or by updating the links to the URLs that return 4xx errors.
Phase 8: Evaluating the success of your website migration
During the migration's planning phase, all the people that the migration would impact shared their concerns and goals. This made it clear what it would take to make the migration a success.
Now is it similarly time to look back on the migration:
- Were all the concerns addressed? If not, why not?
- Were all the goals met? If not, why not?
- What were the most important things learned?
- What do you need to improve next time?
A final note on website migrations
As you've seen: website migrations can be really tricky. In order to ace your website migration you need to have a solid plan that's executed with military precision.
Monitor both the new staging environment and the new production environment with ContentKing: you'll always have fresh data, you'll be able to easily keep track of on-page SEO changes. and you'll be alerted proactively of any high-impact changes and issues.
Website migrations are hard enough as it is; there's no need to make them harder and add work due to a lack of alerts and a need for manual checks.
How did your migration go? Let us know 🙂
When you use the website migration checklist, do let us know how it went. If there's anything we haven't covered, let us know, and we'll be happy to expand our website migration guide.