{Nadeem Haddadeen}

Arabic SEO Consultant, Python for SEO From Jordan

SEO Checklist for a Site Migration: Don't Lose Visitors!

SEO Checklist for a Site Migration: Don't Lose Visitors!

Site migrations that aren't done well can hurt a brand's performance in search results faster than almost anything else.

Changing your domain name or putting in HTTPS can be good for business, but if you don't think about how search engines will react, you're almost certain to lose a lot of traffic from organic search results.

Use the SEO checklist below to get ready as you make a plan for moving your website.

Think Carefully About Whether Moving Is the Right Choice

Most of the time, when a site moves, traffic drops temporarily. This is because Google needs time to process the change and update its index. Traffic changes can be kept to a minimum with well-planned site migration, and in the best case, Google will eventually treat the new site as if it were the original.

Still, that's just the best-case scenario. In reality, site migrations usually don't help SEO much or at all and don't get rid of search engine penalties. (That's why SEOs often use site migrations as a chance to make SEO improvements, like streamlining the site's structure, fixing broken links, merging redundant pages, and making content improvements.)

With all this in mind, when is it worth it to move a site?

  • When it's time for a vital brand makeover.
  • When the move happens, there will be news and links.
  • When it's time to switch to HTTPS (one of the few cases in which migration alone offers an SEO gain).

Use a Staging Server

Use a Staging Server

You should never move a site without testing everything first on a test server. Make sure the redirects work and do all the other checks that follow before going public. If you try to do everything at once without testing, you're bound to make mistakes, and if they're bad enough, they can set your site back by weeks.

Plan to Move When Things Aren't Busy

If your migration is well-planned and closely watched, it shouldn't have a long-term effect on your traffic, but you should expect a short drop. Because of this, it's best to migrate during a slow time of the year, assuming that your site's traffic changes with the seasons. It's never a good idea to move a site before or during the holidays. The goal should always be not to lose any traffic, but if you do, it's essential to make sure it happens when business is already slow.

Before You Move Your Site, Crawl It

Use a tool like Screaming Frog to crawl your site, and make sure to save the crawl for later.

You should make sure you have a complete list of all the URLs on your old site so that nothing gets lost in the move.

Use this time to find any crawl errors and redirects on the old site. These things tend to get worse over time. I rarely find a website that doesn't have at least a few broken or redirected links.

You must remove or change any links that lead to 404 pages during the migration process. Also, any links that go to redirected pages should be changed so that they go to the final page. You don't want a chain of redirects after the move.

Keep in mind that a site crawl might not be able to find all of your site's pages. For instance, pages on your site that aren't linked to other pages won't show up in a crawl. You can use your records and databases to find these pages, but if that's not possible, you can use Google Analytics data or a link explorer-like Ahrefs.

If you find any orphan pages, make sure to update the site and link to them during the migration. If you don't link to these pages from the rest of your site, search engines are much less likely to send people to them.

Compare Your Statistics

Compare Your Statistics

Make a copy of your Google Analytics data. You'll need this to see if you quickly lose any traffic after the move.

If you lose traffic, you can export the Analytics data from your new site and compare it with the data from your old site to find out which pages lost traffic. Most of the time, a drop in traffic will only affect one page at a time instead of the whole site.

You might also want to use a tool like Ahrefs to find your most-linked-to pages and note them. After the move, you'll want to pay close attention to and keep an eye on these pages. If these lose traffic, it means that the authority from your old site isn't being moved to your new site properly. Most of your authority comes from these pages, so losing them could hurt how well your site works overall.

Map All Old URLs to Their New Ones

You should have a spreadsheet with all of the old URLs and all new ones.

During a site migration, it would be best if all of the old pages were on the new site. When you delete a page, search engines can no longer find it. On top of that, if you lose too many pages during the migration, Google might think that the new site isn't the same as the old one and drop you in the rankings.

Also, unless you have a good reason to change it, the URL structure should be the same as the old one. If you want to change it, a site migration may seem like the best time to do it, but you should know that Google may see it as a whole new site if you do. If you do both simultaneously, you won't be able to tell if traffic loss was caused by changing the site's architecture or by moving it.

Keeping the architecture the same also lets you use regular expressions in your .htaccess file to redirect your old pages to your new ones easily. This is easier on your server than naming each redirect one at a time, making setting up redirects much faster.

Update All Internal Links

Your new site's HTML links should go to your new site, not your old one.

This might seem like a no-brainer, but as you go through the process, you'll quickly see how tempting it might be to leave the same links since they'll automatically go to the new URL. Don't give in to this enticement. In addition to slowing down your site's performance because of the server load, the redirects may hurt your PageRank.

The best way to change the links is to use your database to do a "search and replace." If you want to keep your site's folder structure the same, the operation should be done so that it changes the domain name without changing the folder structure.

Carefully write your search and replace operations so that they only change the text that has a URL in it. In general, you shouldn't use search and replace to change your brand name and URLs simultaneously.

Set a Self-canonicalize All New Pages

Check to make sure that the canonicalization on the new site points to the new site and not the old one. Canonicalizing the old site can be disastrous because it could stop the new site from being indexed.

I think you should make all of your pages on the new site self-canonical (except, of course, for pages that should canonicalize to another page). Together with the redirects, this tells Google that the new site is where the old site is now. Even if you don't do sitewide self-canonicalization, you should do it anyway because URL parameters create duplicate content that always points to the URL without parameters.

Fix Duplicate Content Issues

Duplicate content problems can happen if something goes wrong during the migration process. Know about these problems and take steps to prevent them:

  • When both URL versions are made public, this is called "duplicate content." If self-canonicalization is set up correctly, this should solve the problem. Still, I recommend setting up redirect rules in .htaccess so that only one version of the page can be accessed. Ensure that the links are all the same so that internal links don't send you somewhere else.
  • The IP address should go to the URL.
  • Keep an eye out for "default" and other folders that lead to the same content.
  • Check to see that only HTTPS or HTTP is used and that you can only get to the www or non-www version of the site. The other sites should send people to the right one.
  • If your site has a search feature, the pages that show the search results should not be indexed.
  • I already said this, but self-canonicalization should be in place to stop URL query strings from making duplicate content.

Find and Fix Any Pages That Have Been Taken Down

I already said that, in general, you shouldn't delete any pages during the migration. If you need to get rid of some pages for branding reasons, do the following:

  • Write down all the pages.
  • Don't send the old pages over to the new site.
  • Take out every link on these pages.
  • Take the pages off the old site and let them go to the 404 page.
  • Set up a redirect and change all the links to point to the new page if there is a good replacement for the page. You should only do this if the new page is the same as the old one in what it does.
  • Do not send the pages that were taken down to the home page. This is called a "soft 404". If there is no good page to replace it with, it should say "404." Only if you link to the page is a 404 an error.

Make Sure You Have a Custom 404 Page

Make Sure You Have a Custom 404 Page

If a user lands on a page that no longer exists, a custom 404 page makes it easy for them to move around your site and find something useful.

Take Care of and Send Sitemaps

Keep your old sitemap in the Google Search Console and add the sitemap for your new site. An excellent way to speed up the process is to ask Google to crawl the old sitemap and find the redirects.

Always Have Analytics in Place

Install Google Analytics on the new domain and make sure it's working well before letting the public see the site. During the migration, you don't want to lose any data, and it's essential to keep an eye out for any changes in traffic.

Send All New Links to the Old Ones

As was said above, the best way to set up redirects is to use a regular expression in the.htaccess file of your old site. Change your domain name in the regex expression, or change HTTP to HTTPS if you switch to SSL.

You'll need to set up a separate redirect for pages where this can't be done. Make sure that this doesn't conflict with your regex and doesn't start a chain of redirects.

Check that there are no 404 errors when testing your redirects on a test server. I think you should do this before the redirects go public on your site.

Don't forget that your site has been moved once the redirects are live. Before setting up the redirects, the new site should be in great shape.

Continue to Run the Old Domain

I wouldn't recommend giving up control of the old domain unless the migration goal was to sell the old domain. The old domain should point to the new one, page by page, for as long as possible. If these redirects are lost, the old site will also lose all of the links that led to it.

Some people in the business world say that once Google stops indexing the old domain, you can give up control of it, but I would never recommend doing this. Even without the redirect, Google may point links to the old site to the new one. However, this puts a lot more trust in the search engine than I would ever suggest.

Keep an Eye on Traffic, Results, and Rankings

Keep an Eye on Traffic, Results, and Rankings

Keep a close eye on your search and referral traffic for at least a week after the move. Check it every day. If traffic changes, go to the page level and compare traffic on the old site to traffic on the new site to see which pages have lost traffic. In particular, crawl errors and broken links should be looked for on these pages. If you can, you might try to change any outside links from the old version of the page to the new one.

It is just as important to keep a close eye on the pages that get the most links, both in authority and the number of links from outside your site. These pages have the most impact on how well your site ranks as a whole, so changes here show how well your site is doing.

Use a tool like SEMrush to keep track of your keyword rankings. In some cases, this will let you know if something is wrong before noticing a change in traffic. This will also let you know how quickly Google is indexing the new site and if it is dropping the old site from the index.

Put Dates in Google Analytics

Use annotations in Google Analytics to keep track of important dates during the migration. This will help you figure out what went wrong if something goes wrong during the process.

Make Sure That Google Search Console Is Set Upright

You will need to set up a new property in Google Search Console for the new domain. Make sure it is set up for the correct version, taking into account HTTP vs. HTTPS and www vs. not-www. Send both the old and the new sitemaps to show that the old site has been moved to the new one.

Submit a change of address in the Google Search Console, ask Google to crawl the new sitemap, and use "fetch as Google" to submit your new site to be indexed. Before you do this, you should make sure that all of your redirects, canonicalizations and links work correctly.

Update Your PPC Campaigns

Ensure that your PPC campaigns point to the right site by updating them. If your PPC campaigns send people to the old site, Analytics will not be able to figure out who sent them there.

Keep All Other Platforms Up-to-date

Update all of your social media profiles, bios you use as a guest publisher, other websites you own, forum signatures you use, and any other platforms you use so that the links point to the new site and not the old one.

Go After Your Most Important Links

Contact the most important sites that link to you to let them know about the move and suggest that they change the link to point to the new site. Not all of them will do this, but the ones that do will help Google figure out faster than a site move has happened.

I wouldn't suggest doing this with every link since it would take a lot of time for most sites, but it is good to do this with your most important links.

Keep Track of How Many Pages Are Indexed

Google won't index all of your new site's pages right away, but after a month, if the number of indexed pages isn't the same as it was on your old site, something is wrong.

Look for "404" Errors and "Redirects"

Check to see if there are any 404s or 301s on the new site (or any other 3xx, 4xx, or 5xx codes). Every link on the new site should go straight to a page that works. The most common errors are 404 and 501, so they should be fixed first. If there is a good alternative to a 404 page, change the link to point to the alternative, and make sure that a 301 is in place for anyone who gets to the missing page in another way.

Links to 301 pages that are still on the old site are the second worst thing. Even though these links go to the new site, the load on the server is bad for performance, and linking back to the old site could confuse people about the fact that the site has moved. Even though the other things you've done should clarify to Google and the other search engines, you shouldn't leave things like this to chance.

After this, you can take care of any other 301s. You should always change your internal links to go straight to the right page and not through a redirect.

Crawl Your Old URLs

Crawl Your Old URLs

Crawl all of your old URLs with Screaming Frog or a similar tool. Don't try to crawl the site directly because the 301s will only let it crawl on the first page. Make sure to crawl a list of URLs that you collected before the migration, and make sure that the list includes any URLs that could not be found by crawling.

Check if all of the old URLs lead to the new site. There shouldn't be any 404s unless the page was deleted during the migration. If there are any 404s, check to ensure they don't have any links to them. If you don't want the 404s, you should set up a proper redirect.

Check all of the external URLs to make sure that the redirects work. There shouldn't be any 301s or 404s in the external URLs. A 301 in the external URLs means a chain of redirects, which hurts performance. If you send your users to a 404 page, it will be very frustrating for them and may hurt your SEO in other ways.

Conclusion

If you want to move your site, remember all of the above, and it should go off without a hitch. If SEO isn't considered during a site migration, you can almost bet that you'll lose search engine traffic. Aside from clients who came to me after being punished by Google, the worst SEO problems I've seen were caused by professionals who didn't think about how search engines would react to site migration.

About the Author

Nadeem Haddadeen
From Amman - Jordan. 12 years of experience in web development, 7 years of experience in SEO. Currently, I am the SEO & Content Manager at OpenSooq.com. I am specialized in Arabic & Technical SEO with some Python automation and data analytics.