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:

1. Changing URLs: you want to e.g. shorten URLs for readability, fix incorrect URLs, or future-proof URLs by removing the year from the URL slug.
2. Merging content: you've got multiple pages about the same topic that are cannibalizing each other, so you're merging them together.
3. Website redesign launch: you're changing the whole look and feel of your website—and often adding, changing, or removing content too.
4. 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.
5. Switching from HTTP to HTTPS: your website's going to be served over a secure connection, and so all of your URLs will change.
6. Switching hosting providers: for instance you're unhappy with your website's performance at your current hosting provider.
7. 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.
8. Switching domain names: you're changing your domain name.
9. 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 rankingsRankings
Rankings in SEO refers to a website’s position in the search engine results page.
Learn more 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.

How to successfully handle website migrations

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 optimized 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 Conductor Website Monitoring is monitoring on a daily basis. And they don't always go well. Lucky for them, Conductor Website Monitoring 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 Conductor Website Monitoring 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:

1. A lack of awareness of the risks involved in website migrations
2. Poor planning
3. A shaky migration checklist (or no checklist at all)
4. 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.

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:

1. Search demand for the brand/website is high
2. There are a smaller + manageable # of URLs
3. 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.

The website migration process

We've come to see the website migration process as having these phases:

1. Planning
2. Pre-migration preparation
3. Pre-migration testing
4. Launch
5. Post-migration review
6. Post migration follow-up
7. Post-migration monitoring
8. Evaluating the success of your website migration

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.

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.

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
• Hreflang
• 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.

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…

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 wireframeFrame
Frames can be laid down in HTML code to create clear structures for a website’s content.
Learn more drafts are made.

Content inventory

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 Conductor Website Monitoring, 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 Conductor Website Monitoring:

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 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:

• Conductor Website Monitoring: 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
  • Behavior > Landing Pages
  • Conversions > Goals
  • Conversions > E-commerce
• 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 ConsoleGoogle Search Console
The Google Search Console is a free web analysis tool offered by Google.
Learn more, Ahrefs, and SEMrush to verify that you're tracking all of the important queries.

Redirect plan

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:

• 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.

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 (Technology > Network and 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:

• Domain A 301-redirects to https://example.com
• Domain B 301-redirects to https://example.com
• Domain C 301-redirects to https://example.com/shop/

And there are redirects in place because of a URL change for the shop page: https://example.com/store/ 301-redirects https://example.com/shop/.

Then the domain changes from example.com to example-new.com. The new URL of the shop page is: https://example-new.com/shop/.

Then this is what the redirects need to look like:

• Domain A 301-redirects to https://example-new.com
• Domain B 301-redirects to https://example-new.com
• Domain C 301-redirects to https://example-new.com/shop/
• https://example.com/store/ 301-redirects to https://example-new.com/shop/

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!

Set up page redirects correctly

Always redirect old URLs to the most relevant new URLs, instead of just redirecting them to the new homepageHomepage
A homepage is a collection of HTML documents that can be called up as individual webpages via one URL on the web with a client such as a browser.
Learn more.

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:

• http://www.redirecting-domain.com 301-redirects to https://www.redirecting-domain.com
• Let's say you're going to move to https://example-new.com
• Then http://www.redirecting-domain.com should 301-redirect directly to https://example-new.com

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.

Some examples:

• 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:

1. If your redirects fail, you don't want your paid campaigns to suffer too.
2. 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 Conductor Website Monitoring 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.

Important
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.

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 redirects

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.

SEO checks

Now crawl the new environment with Conductor Website Monitoring and go through all of these checks to make sure the new website is SEO proof:

• URL structure: go through the list of URLs and check whether the URL structure is correct. Read more on URL structure.
• Titles, meta descriptions and headings: are they in line with your SEO strategy? Read more on titles, meta descriptions, and headings.
• 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? Read more on canonical URLs.
• Robots directives: are robots directives correctly used to prevent pages from getting indexed, preventing duplicate content in the process? Read more on robots directives.
• Crawler traps: does the new website suffer from the presence of crawler traps—a virtually infinite amount of URLs being generated? Read more about crawler traps.
• Structured data: is structured data such as Schema, Open Graph, and Twitter Cards set up correctly? Read more about Schema, Open Graph, and Twitter Cards.
• 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. Read more on HTTP status codes.
• Broken links: check the site for any broken links. 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. Read more on hreflang.
• 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. Read more on pagination.
• 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 Conductor Website Monitoring. 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 https://www.example.com, http://example.com and http://www.example.com all 301 redirect to https://example.com with just one hop. Read more on domain redirects.
• XML sitemap: does the new site contain a valid XML sitemap that only contains indexable pages? Read more on XML sitemaps.
• 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 Conductor Website Monitoring flags that. You can feel free to ignore this issue. Read more on robots.txt.

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 "Set up a separate environment" 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 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:

• 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 the SEO checks we discussed in Phase 3 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 Conductor Website Monitoring 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:

• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com

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.

Paid campaigns

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.

Update backlinks

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

Make the old environment accessible through a subdomain, as described in the "Set up a separate environment" section.

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.

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.

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.

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 4xx errors

Monitor the new website for 4xx errors with Conductor Website Monitoring. In particular, you should be on the lookout for 404 and 410 errors.

Additionally, check your server logs to find 4xx errors that Conductor Website Monitoring 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?

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.

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 Conductor Website Monitoring: 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.