Sometimes when you do a site redesign or a company rebranding, you also change your domain name. But sometimes publishers are simply changing the domain name, and everything else (except for perhaps branding changes) stays the same.
One of the more challenging aspects of a domain name switchover is the potential loss of trust the search engines attached to the old domain. The trust does not always shift that easily to the new domain when you make the move. Another issue is that the keywords present in the old domain name but not in the new domain name may negatively impact for search terms that include the keyword. For example, when Matt Mullenweg, founder of WordPress, switched domains on his personal site from http://photomatt.net to http://ma.tt, his position in Google for Matt dropped out of the #1 spot.
One danger is that the new domain may go through a scenario where the newness of the domain acts as a damper on the site’s rankings. In other words, the site relevance and inbound link profile may suggest a high ranking for some search queries, but because the site is not trusted yet, the rankings are suppressed, and traffic is much lower than it would otherwise be.
This is one reason for the recommendation we will make in the upcoming best practices list to get the most important links to your old domain switched over to your new domain. One other tactic you can try is to make the move to a different domain that has a history associated with it as well. Just make sure the history is a positive one! You don’t want to move to an old domain that had black marks against it. Of course, the tactic of moving to an old domain is viable only if it is compatible with the reasons you are making the domain move in the first place.
Unfortunately, lost traffic is common when you make such a move. If you do all the right things, you can and should recover, and hopefully quickly. You should, however, be prepared for the potential traffic impact of the switchover.
If you are using a new domain, buy it as early as you can, get some initial content on it, and acquire some links. The purpose of this exercise is to get the domain indexed and recognized by the engines ahead of time (to help avoid or shorten sandboxing).
Then, register the new domain with Google Webmaster Central, Bing Webmaster Tools, and Yahoo! Site Explorer. This is just another part of making sure Google knows about your new domain as early as possible and in as many ways as possible.
Once this is done, here are the best practices for handling a domain name change:
Create 301 redirects for all URLs from the old site pointing to the proper URLs on the new site. Hopefully you will be able to use mod_rewrite or ISAPI_Rewrite to handle the bulk of the work. Use individual rewrite rules to cover any exceptions. Have this in place at launch.
Review your analytics for the top 100 or so domains sending traffic to the old pages, and contact as many of these webmasters as possible about changing their links.
Review a Yahoo! Site Explorer report for your site and repeat the process in the preceding bulleted item with the top 200 to 300 results returned.
Make sure that both the old site and the new site have been verified and have Sitemaps submitted at Google Webmaster Central, Bing Webmaster Tools, and Yahoo! Site Explorer.
Launch with a media and online marketing blitz—your goals are to get as many new inbound links pointing to the site as quickly as possible, and to attract a high number of branded searches for the redesigned site.
Monitor your rankings for the content, comparing old to new over time. If the rankings fall, post in your thread at Google Groups with an update and specifics.
Monitor your Webmaster Central account for 404 errors and to see how well Google is doing with your 301s. When you see some 404s pop up, make sure you have a properly implemented 301 redirect in place. If not, fix it.
Monitor the spidering activity on the new domain. This can provide a crude measurement of search engine trust. Search engines spend more time crawling sites they trust. When the crawl level at the new site starts to get close to where it was with the old site, you are probably most of the way there.
Watch your search traffic referrals as well. This should provide you some guidance as to how far along in the process you have come.
You can also check your server logs for 404 and 500 errors. This will sometimes flag problems that your other checks have not revealed.
An additional idea comes from Matt Cutts, who suggested the following at PubCon 2009 (http://blog.milestoneinternet.com/web-development/faq-on-duplicate-content-and-moving-your-site-by-matt-cutts-at-pubcon-2009/):
So here’s the extra step. Don’t just move the entire domain from the old domain to the new domain. Start out and then move a sub-directory or a sub-domain. Move that first; if you’ve got a forum, move one part of your forum. Move that over to the new domain, and make sure that the rankings for that one part of your site don’t crash. Sometimes it takes a week or so for them to sort of equalize out, because we have to crawl that page to see that it’s moved. So if you move a part of your site first, and it goes fine, then you know that you’re pretty safe. So instead of doing one huge move, if you can break it down into smaller chunks and start out by moving a small part of your site first, you’ll know that you’ll be gold.
The value of this approach is that it reduces the risk associated with the move into more manageable chunks. Even if you use this approach, however, you should still follow the process we outlined in this section to implement the move of each site section, and check on its progress.