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.
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:
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.
Here’s John Muellers take:
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.
Any site migration that involves URL changes needs to be very carefully considered. From domain name changes to tech stack updates, when you start changing your website's URLs you are basically throwing away your old ranking signals and hoping that with judicious use of redirects you can get search engines to associate those signals with your new URLs.
And even if you accomplish that, some value will be lost in the transfer. As a rule, I always advise against changing URLs unless you really need to. It can be easier to improve rankings on non-ideal URLs than to migrate to and rank optimised URLs.
Some of the best practices I follow are:
- Verify with all of the stakeholders the desired outcome and goals from the migration, its scope, as well as resources and timings to be able to plan ahead and coordinate with all of the involved areas and teams.
- Use as many data sources as possible to identify all the URLs that are needed to take into consideration for the migration: those identified from your own crawls, Google Analytics, Search Console pages, SEMrush, Ahrefs, Sistrix, pages with rankings and external links, URLs with activity from log files, etc. to avoid leaving anything out.
- Establish your priority pages -those with a higher traffic and conversion impact- to validate and monitor more closely during the migration process.
- Set a (closed) test environment to validate the website migration with enough time to check and solve any potential issues that arise before the public launch.
- Leave a monitoring system (to track crawling, indexing, rankings, traffic, conversions) set to start following up the new pages destinations as soon as they're released, to identify and fix important issues fast.
- Continue monitoring the website migration evolution overtime, avoiding to undo Web migration related configuration without checking that they're not required anymore.
The best way to approach website migrations is to avoid them completely.
We’re not kidding, it’s true. How can you achieve this?
Think long and hard about your website architecture when you initially launch a website. If that’s new to you, check out our article on website architectures.
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.
But when your rankings tank, where will you start diagnosing your ranking drop?
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.
Get a firm grip on all the changes on your site with ContentKing.
When website migrations fail, it’s usually because of:
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 kickass website migration checklist, and we’ll provide background information around important topics that you’ll have to deal with during the migration.
I've found that website migrations tend to fail when:
- There isn't a well-defined goal of what the purpose and the scope is of the website migration in order to achieve the desired result.
- Not all required URLs are taken into consideration for the migration (e.g. some resources or older pages are left out).
- Legacy crawling and indexing issues, that haven't been solved pre-migration, are carried over and become even more complex to solve.
- The migration is not well validated first in a test environment before its public release.
- The migration is not well validated right after the public release to fix important issues before they have a bigger negative impact.
- The most important pages from a traffic and conversion perspective are not prioritized to be validated and monitored more closely.
In my experience, website migrations work best when:
- Search demand for the brand/website is high
- There are a smaller + manageable # of URLs
- There is sufficient incoming link equity
Folks often overlook #1, but out of all of these, it may be one of the most correlated with successful migrations. If folks are looking for "Brand X" in Google search results, it's in everyone's best interest for Google to serve up the right website.
While it's no silver bullet, websites with high branded search volume seem to have an advantage here. That said, the less branded search volume you have, combined with an unmanageable number of page with low external link equity, the more you may be in for a potential headache with your migration.
We’ve come to see the website migration process as having these phases:
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.
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 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).
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 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.
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.
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.
Start working well ahead of any migration on getting the technical SEO of the current site into much better shape so that every time Google comes crawling, the quality is overall just a little bit better.
Don't let an existing site stagnate for a year with poor quality content and technical SEO whilst you build something better because the quality of the existing site will just be seen as lower and lower in Google's eyes. Keep working on the new site and the existing site in tandem, although this seems to be more effort. You'll get a better result when you ultimately switch over with a more robust platform and even better content.
Platform or framework migrations often involve Information Architecture improvements and changes in the URL structure - with the latter being generally advised against. What's worse is subsequently failing to transfer the acquired page authority onto the new URLs. Additionally, multinational websites often unnecessarily inflate the URL count by including many new, but in their case redundant geotargeted site variants. Add in failed hreflang implementation, and it can lead to its organic visibility plummeting.
The key aspect is preparation, gathering as much data about your current site structure as possible BEFORE you pull the plug on the old site. Fully crawling enterprise sites can take months, so rely on alternative URL list sources like GSC and server logs to create appropriate mapping between the old and new.
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.
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:
There’s much more to say about this—but that demands an article of its own.
The biggest problem we see with site migrations for dealers is that each platform is structured differently. The technology running the sites is different, default page URLs are different, each vendor has its own CMS, and goals and events are tracked differently in Google Analytics.
Most vendors don’t put in any effort to ease the transition, which inevitably causes traffic drops as Google tries to figure out what’s going on. Content changes, every URL is suddenly different, and schema markup might have even changed.
Ideally, you should always try to transfer content as-is. If you can’t keep your URLs the same, it’s imperative that you set up 301 redirects properly. You’ve got to make sure your schema markup is correct on the new site, and that your forms are submitting to the right places (and that they’re being tracked properly). Otherwise, you’re in for lots of problems…
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 content inventory, 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:
Let ContentKing do the heavy lifting!
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.
Pull up the KPIs for each page 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:
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.
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.
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.
Investigate how redirects are currently implemented. Are they configured on a web server level (e.g. .htaccess) or are they being handled by a CMS plugin? If the website is moving to an entirely different platform (e.g. different CMS or framework, then they are all going to break. Investigating the redirects are currently in place, and how they are implemented is an essential part of the migration. Conveniently this also gives you the opportunity to tackle redirect chains.
Make a list of the domains and URLs that are currently redirecting and put these in a spreadsheet with three columns:
A key thing to remember is to check what old domains you might have forgotten about, which should continue redirecting to the new site.
Check Google Analytics's hostname report (
Networkand choose 'Hostname' as primary dimension) to see if there are any strange domains or subdomains capturing traffic currently and make sure they are included in the redirect plan.
Let’s look at an example.
Let’s say there are three domains redirecting to a website:
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:
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 chained redirects. 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.
Don't presume that the redirection mapping will be straightforward. You need to know fully how the URLs are generated and whether they are generated on a parameter by parameter basis. Is there built-in contingency in the current platform, or custom build for URL clash, and if there is a clash what would the output be? These areas are often the beginning of infinite loops and circular dependency if you are not careful.
You also have to consider whether you can sensibly use wildcards and regex when you are mapping domains at scale, because they don't always work as you'd expect them to fully. Test everything in a staging environment beforehand. It may mean that you can't actually take everything with you when you switch over. If that's the case then bear in mind you will lose very likely some domain relevance at a topic level because the pages you lost will have contributed something. I've also seen cases where people use an opportunity such as a migration to "get rid of the cruft" while in reality some of that cruft (content wise) was likely adding to their overall topical relevance.
I've also seen a lot of cases where people seem to think that you can merely redirect / remap up to the nearest category. This is not the case, because unless the content is pretty much the same you're not going to have a doc / term map to doc / term map and this would be considered a soft 404. There is loss there. So, think wisely!
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.
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:
http://www.redirecting-domain.comshould 301-redirect directly to https
Pro tip: 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.
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.
It’s important to update the paid campaigns for two reasons in particular:
Please note: these updates shouldn’t be published until the launch.
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.
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.
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:
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)
Make sure your new environment is not accessible to the public. The best way to go about this is using HTTP Authentication. 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.
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.
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.
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.
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.
Now crawl the new environment with ContentKing and go through all of these checks to make sure the new website is SEO proof:
https://example.com, then you need to make sure
http://www.example.comall 301 redirect to
https://example.comwith just one hop. Read more on domain redirects.
Let ContentKing keep a watchful eye on your new site while you prepare for the migration!
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!
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.
Remove any limitations that you’ve set up there to keep out search engines and users prior to launching, such as:
Now update your DNS records to point them to the new environment.
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 sunk-cost fallacy, 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:
Disallow: /is added to the old domain’s robots.txt.
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!
Is everything still looking good? If so, you can move forward with the steps below:
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:
If you’ve migrated to a new domain, tell Google and Bing about this using the Change of Address feature.
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.
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 the old environment accessible through a subdomain, as described in the "Set up a separate environment" section.
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.
Get control of and monitor the renewal of the old domain, you don't want this to expire. Also decide how to bring this into your system whether you maintain the old server/hosting and redirects and renew the security certificate there (if it was https) or forward the domain and maintain the redirects in your current infrastructure and use a multi-domain/SAN certificate. Even if the certificates expire, Google still seems to follow the redirects but users will get a warning message. If you had left the old domain indexed by using a 302 for the purpose of warning people of a brand switch (this is useful if you haven't given users warning in advance of the switch), then an expired security certificate can be devastating as people coming from search will not reach your current website.
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.
Since migrations have a big impact on SEO results, zoom in on monitoring your SEO KPIs to check that the migration went well (i.e. that search engines understand the new site and what it should rank for).
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 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.
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:
It's never too late to fix redirects. Ahrefs' "Best by links" report is my go to for this. Filter by 404 to show what's not redirected, or 3xx to see what might be redirected to the wrong location.
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.
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.