Website Migration: SEO Strategy and Best Practices

You may need to migrate your website/business for a specific reason. As SEOs, we call this “migration” or “site move”. An improperly prepared migration can result in a significant decrease in your organic traffic. In this guide, I will share how you can get through your site migration process in the most seamless way.

Why do you need to migrate your website? There may be one or more reasons for this.

First, let’s take a look at the migration types

  1. Domain Change:
    You may want to move your x.com site to y.com
  2. URL Structure Change:
    URLs with words that are relevant to your site’s content and structure are friendlier for visitors navigating your site. If the urls of the site are not SEO-friendly, you may want to change them.
  3. HTTP > HTTPS Migration:
    Security is a top priority for Google. If you migrate your site from HTTP to HTTPS, Google treats this as a site move with URL changes. This can temporarily affect some of your traffic numbers.
  4. Platform Change:
    Site platform is what our site is built on. You could have created your website on WordPress, Shopify, Wix, or any other platform. Also, you could have a custom site created by a dev team. You may want to switch to a better platform. When changing the platform on which your site is built, we should test the SEO functions of your new platform.
  5. Structure and Hierarchy Changes:
    Your website may start to serve in a completely different area. Or your site’s URL and category structure may not be SEO-friendly. Regardless of the reason, we can start to work on a completely new site.
  6. Server Change:
    Server migrations present risk primarily in terms of page load speed. Site speed is an SEO ranking factor, but more importantly, it’s a user experience & conversion rate issue. You may think to set up a staging site on the new server and test page speed on it. Also, don’t forget to check redirects to ensure they behave as expected.
  7. Separate Mobile Site Migration:
    Google recommends Responsive Web Design as the design pattern as it is the easiest to implement and maintain. So you can plan to redirect your m-dot version to the main responsive version. Doing a redirect there is absolutely the right thing. This is something that should be fairly straightforward and should be fairly easy to do.

If the whole structure remains the same, only the domain changes (1st migration type), it is possible to say that our job is easy. In other migration types or when more than one migration type is combined, things can be more complicated.

There are dozens of examples that experienced massive traffic loss during migration.

Some errors that cause traffic loss when moving a site:

  1. Lack of planning
  2. Low SEO and UX knowledge
  3. Low budget
  4. Redirection issues
  5. URL mapping errors
  6. Crawling errors
  7. Do not interfere with instant errors

In order not to encounter these problems, you will find the right planning strategy and the points to be considered in the continuation of the article.

Before I begin, I want to warn you about a few things:

[oc-redirect num=1]

Planning and Data Collection

A project plan that doesn’t skip any step of the move ensures that work progresses without errors. When the work plan is determined, the distribution of tasks will become clear. This plan needs to be made at least 30 days before the migration.

It is important to keep current visitor data. According to the size of your web project, it is necessary to group the pages and queries with the highest traffic.

Tip: Keeping log files covering 45 days before the migration date allows you to analyze Googlebot’s behavior and take immediate action if there is a difference.

Create Test Site and Disallow

The migration process starts with wireframes for SEOs. If the wireframes are checked and SEO comments are made during the creation of the wireframes, the changes to be made in the test site are reduced. This allows the project to progress faster. This also makes the work of UX/UI designers easier.

It is also important to turn off bot access to the test site. Otherwise, you can experience that your new pages are included in the Google index in a very short time.

How to disallow search engine bots by robots.txt file?

Create a robots.txt file: You can create a file named test.example.com/robots.txt and execute the following commands:

——

User-agent: *
Disallow: /
# This command blocks all bots from accessing my website.

——

User-agent: Oncrawl
Allow: /
# This command only allows the “Oncrawl bot to access my website.

—–

It is possible to decide which bots to test with and to define the trace to the user-agent through the robots.txt file. Oncrawl has features that will make things much easier.

IP restriction: If you are involved in the migration plan of a company’s website, you can only open access to the company IP and disable access to all other IPs in order to prevent the new project from being exposed. In this case, you will need to give private IP access to the agency or consultants you work with, if any. Even if you do the IP restriction, you must disallow bots by robots.txt file.

Password protection: An ID and password combination can be created to enter the test site. Crawling applications such as Oncrawl have password access features.

Noindex Tag: A noindex meta tag can be added to the head section of all pages in order to prevent the test site pages from being indexed by Google.

Tip: One of the most common mistakes is forgetting to remove the noindex tag after migrating to the new website. Remember to confirm that the tags are updated to index, follow at the time of migration.

Performance Tracking with Google Analytics

One of the most important points for performance tracking is to continue from the same Google Analytics account without data loss. Therefore, the existing GA and GTM code must be active on the new site with the migration.

Generating a new GA code makes it harder for you to measure your web performance.

Adding a reminder to your Google Analytics dashboard on the day of the move will make it easier for you to compare performance later.

Creating Existing URL List

I mentioned at the beginning of my article that if we are only changing our domain name, our job is easy. We can apply this in bulk from the .htaccess file with the following or a similar code.

* The .htaccess file is a configuration file located on Apache servers.

RewriteEngine On RewriteCond %{HTTP_HOST} ^oldsitee\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.newsite\.com$
RewriteRule (.*)$ https://newsite.com/$1 [R=301,L]

This ruleset will ensure that the domain address automatically 301 redirects to https://newsite.com when any url is reached at oldsite.com or www.oldsite.com.

However, if your job is to fix an incorrect URL structure, things get complicated here. I explained this situation later in the article.

Now we are at one of the most important points of the migration process. Getting the full list of important URLs for the current site is key. If you forget a URL with a lot of visitors and a high PageRank, and leave it out of migration, be prepared for a drop in your organic traffic.

Tip: By exporting URLs from more than one source, you can ensure that no URL is left out.

Starting with XML Sitemap is always the right step. To simply transfer the URLs in your XML file onto the spreadsheet, you can copy the link here and write your own sitemap url instead of https://www.sinanyesiltas.com/post-sitemap.xml in the first line.

After obtaining all the URLs, you will have a grouped data similar to the one below in a single Excel document.

We got many different excel sheets with available URLs. It’s time to combine them all into one file and make it unique. We continue on our way with a document where there are no matching URLs, your current URLs are listed and no important URLs are left out. The ALL tab in the image represents the area I’m talking about.

URL Mapping (Old – New URL Mapping)

In the project where the URL structure has changed, the existing URLs need to be matched with the new URLs. An SEO that will do this in the best way can ensure that the migration process goes smoothly and without loss.

It is necessary to match the new URL against each of the existing URLs in the document we created in the previous step. You can directly share this document you will complete with the IT team, and request the identification of redirections via the .htaccess file. Or you can do it yourself.

There are critical things to consider in this step:

Image Redirections

Images are also included in site migration and redirection mappings. One of the most common mistakes we see is that image orientations are not included in the migration. In order not to lose the rankings and values obtained in Google Images, it is important to prepare a separate URL mapping for the images. Migration work should be looked at URL-based, not page-based.

How to do?

  1. Crawl your image files with Oncrawl.
  2. You can analyze your image sources that obtain backlinks with Ahrefs, Semrush and Majestic.
  3. You can parse the pages with your images via Search Console > Search Type > Image.
  4. Collect all the URLs you get in the same excel format that we did for the pages, eliminate the duplicates and complete your mapping setup.

(If Domain is Changing) Google Address Change Tool

After completing all the preliminary work and activating the redirects, there is a tool that allows us to specify the site move to Google and makes things easier: Address Change Tool. Signals will be handled in less time after selecting old site and new sites in this tool.

Link Updates

The website will now have a new URL structure. In this case, all links on the site should work in the new version. If the old URLs continue to be used in the links within the site, many pointless redirects will work. Therefore, the following links must be checked:

Tip: If you have changed your entire URL structure, I recommend keeping your XML sitemap file with the old URLs for a while. Create a separate XML sitemap with your new URL structure. Keep sending old URLs to Googlebot for a while. In this way, Googlebot will speed up the process of seeing and indexing the redirect on old urls. Depending on the site size, I recommend keeping your XML sitemap file active at least 1 month old.

Controls

After the redirects are applied, it is necessary to confirm that the status code of each URL is 301 by crawling the old URLs obtained before. Here, it is very important to take quick action when URLs with status code other than 301 are detected.

Other checkpoints to watch out for:

Also note these:

Google handles the routing setup between the old and new site for 180 days. After the 180-day period, it does not recognize any association between the old and new sites and treats the old site as an irrelevant site if it is still present and crawlable.