| 12:38 pm on Feb 25, 2013 (gmt 0)|
Keywords in a domain are still fairly weighty for non-competitive keywords, in that it's easier to rank them than branded names. But as far as the long term and keywords with any degree of competition, the effect quickly becomes unnoticeable, or at least easy to overcome.
I would anticipate a minimum 10% loss of traffic with a perfect migration, which you could recover over time. Any migration problems and that percentage can rise pretty rapidly. The most important mitigating factor is how many URLs involved.
Interestingly, at the time of switchover, you will often see an instant traffic rise, as Google discovers the new domain, but has not yet replaced the old one. This effect disappears quickly ;)
The real question here is why you are redirecting. If it's an inevitability (e.g. you've changed brand name) then you can bite the bullet and go ahead knowing that a correct implementation is likely to be relatively hassle-free. If it's because you think a new name is likely to improve rankings in and of itself, I think you're likely to be disappointed.
| 2:09 pm on Feb 25, 2013 (gmt 0)|
I have to agree with Andy on all points. If you DO decide to go ahead with the redirects, I would add that rather than simply redirecting all of the old domain's URLs to the new domain's home page, you should implement page-to-page redirects by redirecting each old domain's URLs to the URL on the new domain whose content (and targeted keyword phrases) most closely matches that of the old domain's URL being redirected.
| 2:21 pm on Feb 25, 2013 (gmt 0)|
ZydoSEO makes a good point - I was assuming a like-for-like redirect (i.e. the same content on a new name).
If you're redirecting to different content, each redirect will be evaluated on a case-by-case basis, as ZydoSEO implies. You would then lose value in each instance where Google did not believe the content was a good enough match. You may also be subject to additional filtering intended to avoid direct transfer of value for domain purchases and similar, although the key factor is the content.
| 2:20 am on Feb 28, 2013 (gmt 0)|
I completed the migration yesterday. Notable steps included:
1. 301 redirect of all URLs from from domain a to domain b in like for like.
2. Updated as many internal and external links as possible to the new address.
3. Create google analytics and webmaster tools accounts for the new domain including site maps and told google the web site had moved.
4. The old domain will remain indefinetely point to the new address.
5. Checking webmaster tools regularly for errors and so far no 404s.
6. Found a recent post form matt cutts or google stating categorically that the age of a domain was not a factor in the rankings but a change of ownership was (not the case here, this is a brand new domain).
| 3:27 am on Feb 28, 2013 (gmt 0)|
I'm not sure what platform you run on (Windows/IIS or Linux/Apache) but your web server logs are a great place to monitor for 404 errors (not to mention tons of other "stuff").
WMT has a delay before problems are reported, and I doubt that every 404 that occurs on your site is logged there. Users may be clicking on broken links days before Google crawls a broken link.
If your site's hosted on an IIS platform and you have access to the logs, Microsoft has a great utility that you can download for free call Log Parser that allows you to query IIS logs using SQL statements. It's actually pretty sweet. If you're on Apache, I'm not sure what utilities they might have that are similar... I guess there's always grep! ;)
It probably wouldn't be a bad idea to crawl the site w/ Xenu Sleuthe or some other utility to get a list of any broken links.
| 4:39 am on Feb 28, 2013 (gmt 0)|
Yes I know about watch apache's logs too. :)
| 8:04 am on Feb 28, 2013 (gmt 0)|
To repeat what ZydoSEO said... as it was an important point that came to my mind too when I read your post... crawl the site with Xenu or a spidering utility of some sort "to get a list of any broken links."
You really don't want to wait for Google to find your broken links.
The spider tool will also check http header responses for you.