Here is the seven steps that you must follow before site migration.
1. Start Testing
The best you can do is run a little test on a subdirectory or subdomain to make sure all team members are on the same page. That way, if there is a chain of command failures or connection failures, it will only damage a small part of the site.
2. Make sure the new site is better than the old one
If you are going through the process of moving content from an old website to a new one, make sure the new website is faster, cleaner, and generally more SEO friendly than the one you left behind. Otherwise, even if you do everything perfectly, you may end up underperforming. Don’t do unnecessary work of yourself.
3. Set up tracking before migrating a website
Before touching anything on your old site, make sure you have the metrics to track your migration progress before, during, and after. All you have to do is list the target domain as a competitor and create a dashboard that compares the rankings, indexed pages, backlinks, and organic search traffic to the previous domain.
4. Create a complete 301 redirect map
This is the most important step in the migration process and I’ll tell you why – you need to inform the search engines that you have moved your site to a new home and that they need explicit instructions to change the address. Otherwise, all the links you have earned over the years will disappear and all the profitable keyword rankings you have earned will disappear. Take all the URLs from your site; Set it to the appropriate URL on the new site as best you can. Each URL should be mapped to a new relevant URL during migration based on the content on those pages. Put that in a spreadsheet.
You will use this document to apply permanent 301 redirects to all old pages, directing users and search engine bots to the new and improved version of the page. Warning: Your technical team may want to try temporary 302 redirects as they are often easier to implement. Don’t let them down! 302 redirects will tell search engines that you want to keep all rankings and links to old pages, and that you only want to send traffic to new pages for a short period. This is important during migration. The 301 redirects will ensure that all the keywords your old pages rank for will replace the old landing page with the new one. Setting the URLs this way also ensures that you won’t leave pages out and show 404 “Not found” errors on them. At the end of the website migration, any previous page on the site should not be 404, 302, or 5XX. They should redirect all 301s to a specific URL at the new address. Otherwise, you will not keep your old arrangements and have to start from scratch on the new range.
5. Start promoting your new website
The hard part about migrating a site is making the internet understand that you have moved. People have linked to your old site, bookmarked it, shared it on Facebook, and discussed it with their friends, but you have to get them to stop talking about the old URL and start talking about the new one. This is where the PR and social media team plays an important role before, during, and after migration. They need help spreading the word that their site will be moving soon. They should contact anyone who links to the site above and inform them that they may need to update their links. Don’t get me wrong, when applying the 301 redirect, the links will still technically work, but it will lose some of its effect and cause some confusion for your visitors who use these links. The best relays we’ve seen started with a pre-launch roadshow. They created a “soon” style landing page on the new domain while working on technical issues in the background, and worked hard to promote the new site to the press, their business partners, and any other fans of the old content. . Doing so helped them retain as much power as possible and started building enthusiasm for relaying the site early on, so when they finally flipped the switch, it increased the ranking.
6. No dilly in execution
You’ve run the test, you’ve set up your monitoring tools and dashboards, and your teams are up and running and you’ve been telling everyone for months how great your new site is. Now is the time to get the job done. The worst thing you can do is launch your new site slowly. We have seen in case studies that the ideal is to turn on the switch as quickly as possible and complete the migration in less than a day or two. Take more time and the search engines will start to get confused and start presenting a mixed batch of URLs in their index. Don’t miss out on too much organic search traffic by slowing down. Move this site quickly and move it properly. This is what to do:
Apply 301 redirects based on your mapping document.
Update all rel = canonical tags on your sites that point to new URLs.
Update all internal links on your sites to point to the new URLs.
Contact anyone who still has links to the old URL (influencers at least) and ask them to update their links well.
Update your XML sitemap and submit it to Google Search Console and Bing Webmaster Tools.
Do all of these things as fast as you can so search engines can quickly make adjustments and start indexing new URLs. Once you’ve completed all of these five steps, you should start to see your new site’s landing pages replace the old landing pages in the SERP within a week or two, depending on how often search engines crawl your pages.
7. Don’t forget about quality control and performance monitoring.
The new site has been published and the website migration is complete, but you are not out of line yet. We’ve seen migrations go well, only for traffic to drop a month later because Google noticed some redirect loops in the internal link structure. Do not get surprised. Make sure to create criteria for indexed pages and monitor backlinks, keyword rankings, and organic search traffic coming to the old site for at least 6 months. Ideally, you should see all of these numbers gradually decrease to 0 at the old site and balance out with the height of the new site. Make sure to check all these internal links and 301 redirects and watch the console look for server errors or bad index pointers.