SEO migration from A to Z

A website migration can be a real minefield if you're not thorough in your approach. Make sure you don't miss anything important with the help of our comprehensive guide.

Go to section

• What is a website migration?
• Types of website migrations
• Website Migration Process
• Website Migration Tools
• Planning a website migration?

Migrating a website isn't the easiest task in the world, but proper planning can mitigate most risks.

We've put together the following website migration checklist to help you navigate your way through the process, avoid most of the typical pitfalls, and arrive on the other side with a clean and tidy site. and ready for SEO success.

What is a website migration?

When we talk about “website migration”, it usually means that a site has undergone a major change in one or more of the following aspects: the technology on which the site is built; where the site is hosted; the way the content of the site is structured.

Website migrations can dramatically change how your site is viewed by search engines and therefore potentially have a big impact on your organic visibility. The bigger the change, the more likely it is that your site will be re-evaluated from scratch, which could cause you to lose any ranking advantage.

It is therefore essential to have a solid plan, tailored to your specific needs and designed to make the process as smooth as possible, covering the activities that need to be carried out before, during and after the launch.

Types of website migrations

There are many different types of website migrations, with some being more common than others. Let's look at some examples and highlight context-specific issues.

Protocol migration (HTTP to HTTPS)

Example: http://www.example.com to https://www.example.com

One of the most common reasons for a website migration in the last two years is the change of protocol from HTTP to HTTPS.

The HTTPS protocol has become a requirement of modern web browsers because serving your site through the secure sockets layer provides a much better level of security and privacy for your users. As a result, if a site is hosted using HTTPS rather than HTTP, visitors don't need to be notified with the “not secure” message when they arrive at your site. This increases user trust and engagement, resulting in reduced bounce rate and increased dwell time, a positive ranking factor for search engines. Thus, HTTPS may lead to a better ranking than HTTP.

Related: Guest post: A powerful marketing tool

However, you have to be careful about some things.

The process of migrating from HTTP to HTTPS is largely done by configuring your hosting environment. This task is often assigned to a specialized IT vendor or a member of your team. The tasks usually consist of obtaining and installing an SSL certificate and reconfiguring the preferred host in a control panel such as Plesk or cPanel.

But there are also tasks that are more likely to be done by a webmaster or web designer. For example, updating all internal links on your site to ensure they point to HTTPS URLs and that assets such as images, CSS and JS files are referenced via https requests. If your site uses a standard CMS such as WordPress, there will likely be CMS configuration variables that need to be updated with the new protocol, and various places in the database where HTTP is referenced.

These items can have a serious impact on your SEO if not done as part of the migration.

Once these checks are done, an essential step is to ensure that all HTTP URLs return a 301 redirect to their HTTPS equivalent. A site crawler like Screaming Frog can help you crawl the entire site quickly and with minimal manual work, after which you can use the “response codes” or “redirect chains” reports to verify .

Domain migration

Example: https://www.example.com to https://www.newexample.com

A domain migration consists of changing the domain name by which a site is addressed. This is usually the case when a business rebrands or acquires a domain name that better matches its existing brand.

Migrating to a domain that was owned by another person or company carries some of the highest risks in terms of unintended organic impact.

Before you even buy a “used” domain, you should check its history.

If the domain has been used by another site for an extended period of time, chances are it has accumulated a variety of external signals that search engines use to decide who the site will be useful to.

If the purpose of the previous site was not the same as yours, serious work may be needed to change the way the domain is perceived by search engines.

This work may involve cleaning up and disavowing links that were once valuable to the previous owner, but will not be valuable to you because they are irrelevant to your business operations. Strong links and domain mentions that look like they could help your site rank will only have value if they're relevant to your vertical.

Another risk is that of a domain that has not been used for an extended period of time and may only show a waiting page or a “for sale” message. Google and other search engines often remove these domains from the public index because they offer little value to end users, and it can take a long time before they are “allowed” back into the public index.

In one case we saw last year, this process took nearly 12 months from migration.

It is therefore essential to check what a domain was used for before, as this can be the key to the success of your website in the short and medium term. The Internet Archive is a great tool for viewing iterations of the site over the years. SEO tools like Sistrix, Ahrefs, SEMrush, Majestic are great for checking backlinks, visibility, and which keywords the domain has appeared in the SERPs for. All of this can help paint a  picture  of how an area is perceived.

For example, say your website sells cars, but after doing some of the checks above, you discover that the domain name you just acquired was previously used by a site that sells watches. If all the external backlinks are to watches, it's very likely that search engines will continue to associate that domain name with watches until the backlink profile weighting changes to something more relevant. In the meantime, you will need to rely on other channels to make up for your organic performance deficit.

It also means that historical backlinks that have a high perceived value to your seller and therefore factored into the asking price for the domain, could actually be a major liability rather than an asset.

Is it worth reconsidering your choice of domain?

Migration of domain extensions

Example: https://www.example.co.uk to https://www.example.com

Domain extension migration is when a website moves from a ccTLD (country code top-level domain) to a gTLD (generic top-level domain) or vice versa. This is often the case when a company is looking to move to a more internationally oriented business model.

When the target domain is newly acquired, it is worth doing the same checks mentioned in the “domain migration” section above, as another company might have used the .com version of your domain for a completely different purpose. from yours.

International targeting is a topic in its own right, but when it comes to migration, there are a few key points to consider:

1. Configuring hreflang tags. Do you plan to use your new domain to target different language audiences? If so, you will need to implement a URL structure that allows crawlers to understand how to access different language variants of the same content, which involves the use of hreflang tags.
2. International targeting settings in Search Console. When a domain has a non-country-specific extension, Search Console allows webmasters to set a preferred target country. You will need to verify that this setting meets your needs. (This is now a legacy tool in Search Console).

Migration of subdomains

Example: https://blog.example.com to https://www.example.com/blog

Subdomain migrations can be done for a variety of reasons, like migrating a blog to your main website or merging separate mobile and desktop sites into one responsive site.

Site merger

Example: https://www.example1.com and https://www.example2.com to https://www.example3.com

Site mergers involving pre-existing sites on multiple domains can be very complicated. This can be merging multiple companies under a new domain or consolidating multiple international sites into one TLD with sub-folder structures.

URL structure change

Example: https://www.example.com/some-path/product-url en https://www.example.com/product-url

Structural changes to URLs or content can be an additional factor in many of the migration types above. You can switch platforms from Shopify to WordPress, or move your blog content from the root to a subfolder. By ensuring redirects are set up correctly, you will be able to transfer capital to new URLs.

Website Migration Process

Regardless of the type of website migration, the process can generally be broken down into three stages: pre-launch, launch-day checks, and post-launch.

Pre-launch

Domain name verification

As we mentioned earlier, if you're buying a domain to migrate your website to, do some background checks to establish the domain's history. Pay attention to anything that could be problematic, such as unrelated backlinks to the domain, historical rankings for keywords in a niche, or manual penalties.

Performance monitoring

Deciding what content to keep should be a key part of any site migration.

Do you plan to keep all of your content? If not, consider whether it would be easier to migrate the entire website and sort out the content at a later date, or take the bull by the horns and reduce beforehand.

Performing a detailed check of the pages that have value and then minifying them before migration can result in a faster and cleaner migration, as search engines won't have as many URLs to crawl during the migration herself.

By using Google Search Console to assess keyword rankings and preferred URLs, and Google Analytics to assess site performance across all channels, you can identify pages that do not have sufficient business value and can be pruned safely.

Once you have completed this step, before proceeding with the migration, give search engines time to recrawl your site, notice the changes and reduce the number of requests to these URLs.

Analysis of log files

Analyzing log files is a relatively technical activity, with a steep learning curve for some, but it can give you a deep understanding of what search engines are doing when they visit your website. This is very useful for site migrations because you can measure crawler behavior before, during, and after, giving you an accurate picture of migration success.

Server log files are full of information about pages and assets on your site that search engines and crawlers like to crawl. This information can help you troubleshoot internal linking issues and crawl errors, identify old URLs that are still crawled but not reported, and make it easier to map and test redirects along the way.

You can use the Screaming Frogs Log File Analyzer to simplify the process.

Fixed non-200 internal links

Fixing internal links that don't return a 200 response in the pre-launch phase can help conserve crawl budget, and also save you time by improving the signal-to-noise ratio in your post-launch logs .

A tidy crawl profile makes it easier for crawlers to understand your site, which can speed up your migration success because there are fewer URLs to crawl and re-evaluate.

If you do this manually, be sure to check desktop and mobile navigation menus, legacy content such as old blog posts, asset references such as images, and technical items that are hidden, such as canonical tags and XML sitemaps.

Analyzing log files can help you spot broken requests; crawlers such as Screaming Frog can help you identify broken links in your site content and spot the misconfiguration of technical elements en masse.

URL collection

Collecting a complete list of all known URLs is an essential pre-launch activity. This list can be used as a master file to test redirects after launch.

But how to collect all these URLs? You should use multiple sources to ensure you get the complete picture. Here are some suggestions:

1. Google Search Console (gather top performing pages, most linked pages).
2. Google Analytics (gather all landing page URLs from all channels in the last 12 months).
3. Landing page URLs in paid search accounts such as Google Ads and Bing Ads.
4. External sources such as Ahrefs, SEMrush, Moz, Majestic, and Sistrix are a good source of externally referenced URLs, including valuable backlinks.
5. A full website crawl using Screaming Frog.
6. Server log files will highlight URLs that search engines crawl but don't appear elsewhere.
7. Redirection instructions, for example in your site's .htaccess file, routes file or IIS configuration.

Once you've gathered the URLs from all of these places, you need to deduplicate them and then categorize them into two categories: those you want to keep and migrate, and those you want to delete.

Robots.txt

The robots.txt file affects how search engine robots crawl your site. Your current website should have one, but you should also consider the one for your staging/development website.

For the current site, it is good to check if the directives it contains are still necessary.

For your new test site, it is essential to ensure that search engines cannot crawl it before going live.

XML sitemaps

Your XML sitemaps should provide a comprehensive list of the content you want indexed. They can help crawlers discover your new URLs and track indexing coverage  – of your new and old URLs.

You can do this by dividing the sitemap into URL categories based on a common theme. For example, a particular type of content, such as blog posts, might be listed in one XML sitemap, while product URLs are listed in another.

By hosting an XML sitemap of your old URLs on your new website, you can speed up crawling of old URLs and control how many of them remain in the index over time. This can help you spot legacy content that continues to appear in the index long after migration and can give you clues on how to fix the problem.

Configuration hreflang

If you are migrating multiple domains to a new TLD with multiple target languages, it is essential to ensure that hreflang configuration is done at the staging site and tested before launch. This can be checking that the hreflang is implemented in the code of each page or in the XML sitemaps, that the html lang tag has been defined, or even that the content has been translated correctly.

You should check for hreflang tag coverage, canonical configuration of each page variant, inclusion of reciprocal tags between page variants, and whether all required language/locale pairs are present and correct.

Search Console checks and reconfiguration

Before launching, you should ensure that you have access to all Google Search Console properties that you need to perform the migration.

Separate properties are usually needed to monitor the performance of variations of a domain (http://, https://, http://www., and https://www.).

A “domain ownership” will cover all variations of your domain, including subdomains, but only by claiming the individual properties will you have access to all of the settings and reporting tools for each of them. .

If your migration involves changing domains, you will need to do this for both the current domain and the new domain.

Once you have access to all the required Search Console properties, you should check the different sections for major issues such as security issues and manual actions. Also check the “Coverage” tab to see if Google is having trouble crawling the current website.

It's also helpful to request your site's Bing Webmaster Tools profile and run the checks there. It is the equivalent of Google Webmaster Tools at Microsoft, which offers a different perspective on the same information.

If you take the time to fix these issues now, you'll get better results when migrating.

Google Analytics Setup

By default, Google Analytics is domain and protocol agnostic. If you install the same analytics snippet on different sites, data from both sites will be logged.

However, it's important to check your GA's configuration for any domain-specific configuration – for example, if tracking is limited only to a specific domain or domain property. This is sometimes done to prevent erroneous data from being recorded from transit sites, for example.

Depending on your situation, it may be useful to set up a separate profile for the new domain or site so that you can compare performance before and after the migration. This can be a useful diagnosis if things don't go as planned.

Other Marketing Channels

We won't go into detail on this, but considering the potential impact of the migration on other marketing channels is an important part of migrating a website. As part of your pre-launch checks, create a list of any elements of your broader marketing activities that might need updating. It can be the following

1. Landing pages used in your PPC and display advertising accounts.
2. Links in social media profiles and popular/top posts.
3. Listings in business directories such as Google My Business, Bing Places for Business and other directories.
4. Email Marketing Destination URL
5. URLs of products included in feeds for affiliate marketing and similar channels.
6. Traditional advertising such as print, radio and television.

For larger sites and companies with complex teams, it's important to have a conversation early on with marketing service providers and similar stakeholders to educate them about the migration and ask them what their concerns are. regarding the potential impact.

Mapping redirects

Mapping redirects is arguably the most important part of the pre-launch phase. We usually leave this step as late as possible in the migration preparations, as other activities (like pruning and restructuring) can impact the list of old and new URLs.

This avoids wasting time maintaining and updating redirect instructions to account for other changes that occur after the match.

When planning redirects, it should be taken into account that unless your migration is a simple “copy and paste” of a site from one domain to another without any structural changes, it is usually not not possible to take a “one size fits all” approach to redirect instructions.

Here are some types of redirects to consider:

• Page-to-page redirects (https://www.example.com/category/page/ to https://www.example1.com/category/page/). If you want to retain as much ranking equity as possible, the majority of your redirects should be page-to-page. For best results, the content on your new page should be at least as good as your existing page.
• Page redirects to parent (https://www.example.com/category/page/ to https://www.example1.com/category/). This type of redirect may be necessary if, during the pre-launch phase, you decide to prune lower-level content for which there is no suitable equivalent, but a parent page or container category closely linked.
• Redirects from the page to the root (https://www.example.com/category/page/ to https://www.example1.com/). This may be the best option if some pages on the current site don't have a direct or parent page to redirect to. Redirecting the URL to the root (homepage) is only worthwhile if it doesn't create too much of a disconnect for an unsuspecting user and doesn't result in a bounce.
• No redirect. Allowing a 404 URL may be the best solution if there really is no equivalent and your new site is of no value to users searching for your old content. For example, if you have decided to no longer sell an entire category of products.

Don't forget your pre-existing redirects either, making sure they don't get forgotten or conflict with the new redirect mapping. Even if some redirects have been in place for a long time (more than 12 months), they are still likely to be explored from time to time – analyzing the log files can help you verify whether this is the case or not .

Another important point to consider is that redirects should always take the shortest and most direct path possible. Rather than sending users from A to B to C, requiring 2 redirect instructions, you would ideally want them to go from A to C, requiring a single instruction. Screaming Frog's “Redirect Chains” report can be used to verify that your redirect rules do not contain entries that result in multiple steps.

Launch Day Checks

Launch day has finally arrived! Your test site is complete, your redirects are ready to go, and you have all your tracking systems in place to prepare. Without further ado, you launch your site.

Here is a list of things you need to check immediately:

1. Make sure your redirects are working. We like to do a few manual spot checks immediately, followed by a full crawl of all old URLs in the redirect mapping list to make sure they lead to a reasonable endpoint. A crawler such as Screaming Frog can be used in “list mode” to automate this operation.
2. Check the robots.txt file. If you had a disallow directive in place on your test environment, you should ensure that it has been removed now that the site is live. You should also check the guidelines there to make sure they are right for you. Google offers a robots.txt tester to help you check if the directives it contains work as expected.
3. Check your XML sitemaps. Make sure all the URLs you want indexed are there. This will help search engines discover and index your new URLs faster. Submitting XML sitemaps to places like Google Search Console will also help identify any issues. And finally, don't forget to include a sitemap directive in your robots.txt file!
4. Make sure your XML sitemaps are set up in Bing Webmaster Tools.
5. Run a full crawl. It's worth running a full crawl to ensure that all internal links return a 200 status; that all canonical URLs have canonical tags that match the request URL; that indexing guidelines aren't blocking key pages or if you missed a certain section that shouldn't be indexed; that the hreflang and lang tags are configured.
6. Verify that your tracking tools, such as Google Analytics, are working on the new domain. The real-time reporting feature can help you see what's going on with real users.
7. If your initial checks look good, remember to let Google know that you've changed domains. One of the most important things to do on launch day is to use Google's change of address tool to let them know that your old domain has moved to the new one. This will help Google verify the change and hopefully speed up the process of crawling and indexing the new domain.
8. Update target URLs on your paid advertising channels. For many businesses, paid advertising channels and paid social channels are key revenue drivers, so remember to update all your ad creatives with the new landing page addresses. Shopping feeds will also need to be checked to ensure that your product URLs are still valid. Pay particular attention to multi-variant products, which may include additional URL parameters to help crawlers access individual color/size variants. It gets even more complex when hreflang parameters are also used.
9. If your migration involves a change of domain (and company/brand name), remember to check for mentions of the old brand, company name or domain name. Commonly overlooked places are page meta titles, meta descriptions, structured data, image filenames, and alt text, as well as site-generated emails (e.g. order confirmation emails) . Also remember to check external links to your other web properties. For example, social profiles, the Google My Business listing, and external review sites.

Checks after launch

Post-launch checks should be done regularly in the days and weeks after launch. You should keep an eye on the areas covered during the pre-launch phase to ensure there are no emerging issues. Here are three key activities that could help you catch any issues and ensure a good migration outcome:

1. Check all areas of Search Console. It will take a few days for Search Console to start reporting meaningful data, but once it does, you should aim to resolve any issues that are highlighted as quickly as possible. The main areas of interest are: coverage issues, to fix crawl errors or areas that Google cannot index; the “Mobile Friendly” section, in case problems with the new site or new domain prevent Google from rendering the pages correctly; Core Web Vitals, for speed and user experience issues; the “Structured Data” section, for issues such as an incomplete product schema; the “Crawl Stats” section,
2. Check server log files. This is actually the "other side" of Search Console's crawl stats section - seeing what search engine crawlers are doing when they visit your site, but with a bigger twist. level of transparency and detail, which will help you solve any problem.
3. Start collecting backlinks. Contact the sites hosting your most important backlinks to request that they be updated to point to your new URLs. This task may take some time, but it may be easier to retrieve an existing high-level backlink than trying to place a new one. Tools like Ahrefs can help you identify the most valuable backlinks.

Website Migration Tools

Here is a list of tools that could help you with your website migration:

1. Google Search Console & Analytics – for internal tracking.
2. Sistrix, Ahrefs, SEMrush, Moz, Majestic – for external verifications of old and new domains.
3. Internet Archive – to check the history of new domains
4. Screaming Frog – for all your crawling and verification needs.
5. Screaming Frog Log File Analyzer – to simplify the process of checking your log files before and after migration.

Planning a website migration?

Every website migration is unique. The migration projects we work on usually involve multiple types of simultaneous migrations. In this case, we sometimes recommend that our client perform certain elements of the migration (such as site restructuring) in isolation before proceeding with the full migration. This may result in additional work in the short term, but it reduces the risks associated with the migration itself.

No matter what type of migration you are dealing with, following an orderly process like the one we outlined above will help you achieve a successful outcome.

If you need additional information or are considering a website migration project and would like assistance, please do not hesitate to contact us.