Site icon RankWatch Blog

Migrating Domains Without Losing Your Website’s Ranking

migrating-domains-without-losing-your-websites-rankings

There are a few reasons why a site owner might choose to migrate their website to a new domain, and regardless of what a digital marketing agency might tell you, it’s not an impossible task. It’s just an incredibly complicated one with no room for error, but plenty of opportunities for mistakes that can severely hamper your site’s ranking.

Reasons for executing a domain migration may include:

  1. A need for a more relevant domain name that adequately reflects the services or products that the website has to offer.
  2. A desire to localise a website by giving it a ccTLD which is relevant to its target country (for example: .co.uk; .co.za; .au) – So if Quikclicks Australia is the choice web design company in Sydney, then it stands to reason that the site would benefit more from a com.au ccTLD than a .com.
  3. A site owner wants to use a more authoritative TLD for their website. So changing from a .biz to a .com would give the website a better standing, for instance.

But knowing the reason why a domain change is desirable is not enough to help the process go smoothly, as I said before, migration is a complicated procedure, one where rankings can take a beating if anything is left out, so what is the best way in which an agency can make sure it is done properly to ensure a minimal loss in ranking and revenue?

1. The Planning Stage

With most complicated procedures in life, it is generally unwise to enter into production without having a decent plan of action in place first, and so a considerable amount of time and effort should be put into this first step. This is an opportunity for you to communicate with the site owner to determine the following:

  1. The objectives with regard to minimum traffic loss, minimum ranking drops, maintaining key rankings, and the heading of traffic maintenance.
  2. A realistic measure of the required time and effort involved in conducting the move. Communicating the challenges and risks with the client will help establish an understanding of just how much time a migration takes if it is done properly; and if it is not communicated early on, it can lead to bigger problems later.
  3. Drawing up a plan of the migration process which takes into account the architecture on the new and old sites with regards to their technical limitations and benefits so that there is a clear agreement on the migration’s capabilities.
  4. The ideal time to conduct the move. Usually, migrating is best done at quiet times when there is less traffic expected on the site. The beginning of the year is typically the best for most sites when the market quietens down.

2. Auditing the old site

There are a few elements involved in the migration which can complicate the procedure and they include changes in the hosting address, the domain name, the structure of the URLs, the site’s architecture, the available content, and the design. The more changes that need to be incorporated into the move, the more finicky the move will be.

  1. Start by crawling the old site with tools like Xenu Link Sleuth to ensure that redirects are properly identified and reported to the search engine.
  2. Export all URLs with existing inbound links to easily manage and maintain your current standing link juice after the move. These URLs are valuable to your rating and you don’t want to lose them to a 404.
  3. Export 404 (missing link pages) so that they can be easily tidied up at a later stage. Some of these URLs could have useful links pointing to them, so you don’t want them going to waste.
  4. Measure the performance of the old site so that you can benchmark the success of the new site at a later stage.

This is a perfect opportunity to clean house before the big move. If your old site’s rankings have been suffering due to bad backlinks, or duplicate or shallow content, then this is the time to rectify this by detecting a Panda or Penguin hit.

3. Mapping URL redirects

This is one of the more tedious parts of the migration, and it requires a lot of time and tedious attention. During this stage, the URLs from the old site needs to be mapped to those of the new one. Depending on the size and complexity of the site, this step can be done manually or it can be automated, but a mixture of the two usually provides a checksum to make sure there are no errors.

Relevant or authoritative pages on the old site should be mapped to the new one using 301 redirects (indicating a pages permanent move) wherever possible to avoid further problems.

Extra attention should be paid to websites with the highest traffic, but by no means should any single URL be ignored in this process, or you could be losing out on valuable link juice and compromise the authority of the domain as a whole.

4. Put the new site on a test server

We are all humans, and therefore with tasks as complicated as these, errors can easily be overlooked. It is best to have these rectified on your new site before it goes live. The best way to do this is to host it on a test server for a while in order to carry out a number of checks.

First, the site should be blocked from being accessed by crawlers using the robot.txt, the ‘noindex’ meta command, a password-protected test server, or allowing access to an agency’s internet IP address which limits crawler access.

Next, the Robot.txt file should be prepared to allow access to crawlers and indicate the path of the XML sitemap. Certain parts of the site should be left out for now, particularly those that would be duplicated by the old site.

Generate an XML sitemap using one of many available tools to index the site’s HTML pages only. For exceptionally large sites, it may be necessary to do multiple XML sitemaps.

Check every 301 redirect to make sure they are working properly and are in place or not and then optimise them for the best performance. A high number of redirects can have a bad effect on performance, so keeping a short list of them will hasten the web server’s response to your links. Take this opportunity to resolve any duplicate content issues which could hamper optimal crawling, indexation and link equity.

5. Getting the new site live

Once the site is live, Google should start indexing it fairly quickly. Start by notifying them using their Webmaster tools where you can add and verify the new domain name. Run the crawler tool again at this stage to check for:

  1. Artefacts in the robots.txt file
  2. noindex tags in the head and source code
  3. That 301 redirects are used instead of 302 ones
  4. XML sitemap errors
  5. Missing page titles and descriptions
  6. Correctly functioning 404 responses
  7. Analytic tracking codes on all pages
  8. Adequate site performance in comparison to the old site

6. Measuring the success of the move

The last thing to do is to closely monitor the success of the move on a weekly basis. This might take a specialist digital marketing agency a few weeks to process. Expect a slight drop in rating at first, as it can take up to a few weeks for crawlers to properly index a site depending on its size and complexity.

Rankings usually fluctuate for the first few weeks but are bound to return to close to normal if the process has been done properly and there haven’t been any mistakes. Check the site’s explorer metrics, the Google cache and timestamp of cached pages for different page types, and monitor its performance using the Webmaster tools to see how Google ranks your site’s performance. If you see any spikes in loading time, then something has been done wrong and the webmaster will need to get to work.

If you have been looking at doing a migration, or you need to do it for a customer’s website, then hopefully this guide has helped you understand a little bit more. This is by no means an extensive guide, nor a textbook one since there are no clear and definitive lines to follow when it comes to getting a move right. The trick is to take your time, leave nothing to chance, and keep it simple and tidy; then the chances are that your move will be a successful one.

Exit mobile version