Forum Moderators: open
The site that is not doing so well has 150, 1000 word articles that are completely unique and took months to put together. It would make sense to bring that content over to the performing site.
Would it be best just to serve a 404 on the domain until all pages are completely out of the search engines (especially Google) then bring the content over or is it safe just to delete the files and bring the content straight over?
I don't want to damage the good site in anyway with dupe content issues or supps etc.
thanks
As for how to move the content, there was a time when I would have just 301'd them but that day is long gone.
While we don't often move pages between sites, we have done a little experimenting, and probably the most success came from first using noindex on the old URL, then moving the content, and then eventually serving a 404 or 410.
Happy to hear other experiences from those willling to share.
The way to do it safely, and with the best chance of transferring some SEO benefit, is to move all the copy to the 'new' site; initially, try to keep the folder setup the same (may be difficult with the merger, but worth trying), then set up a 301 from the 'old' domain to the 'new'.
There are occasions when 301s have failed spectacularly; but - no offense to the poster above - these are *usually* due to incorrect setup or host error. But I have heard of some that simply failed.
Then delete all the content from the 'old' site.
Domain to domain 301s are simplest, and if the structure is unchanged, people will go from whatever URL they went to on the old site, straight to the equivalent on the new. If the sites had similar navigation and significant duplication of folder names and file names, then you may need to think about folder-by-folder 301s to new ones on the new site.
However you manage the move, check the merger's navigation with xenu, and do be sure to have a useful and visitor-friendly 404 just in case.
Nothing on the web is totally risk-free; but there no safer way to move a site than a 301 - except not moving it at all :)
but if you have two domains with the same topic, then there is good logic to merge the two.
Case 1:
If the two sites are similar (and possibly not clearly identified as being from the same owner?), it's pretty well understood that the SE's don't love it when the same site owner cranks out multiple sites on one topic, especially if there's not much differentation between the two, so that more or less defines the situation IMO. That being the case, then 301's would be a very bad idea AFAIK. Once 301's are set up from the failing site to the new one, it would be relatively easy for a competitor to take a series of steps very likely to result in both sites being trashed. That is the last thing you want.
In this scenerio, personally, I'd modify the articles to some extent, move them, and assign error codes to the old URL's. That will prevent an automated dup filter from being triggered, and the old site just slowly gets phased out.
Case 2:
If the two sites are not similar, and serve clearly different purposes with different approaches, and therefore in theory are both very legitimate from the SE's standpoints, and if you still want to move the content, and if the sites are already clearly noted as being from the same owner, then yes, I'd consider Quadrille's suggestions and 301. But the larger the number of articles the more careful I'd be about that. See note 2 below.
Two notes about 301's:
1) It is not necessary to retain the file structures. 301's will be treated the same way regardless of whether the new URL's are similar in structure or not. In fact if moving to new URL's it's best to make sure that the new URL's are as kw friendlyl as possible, and if the old ones are not, that alone is enough reason to make new ones different.
2) It is not reflective of the real world to characterize 301's as safe, especially when referring to moving sites. They are not safe. Yes the SE's pick up the intent of the 301's but in the case of G, moving an entire site often has the effect of 'sandboxing' the site, potentially for as much as a year, depending upon all sorts of factors.
There are all sorts of mitigating factors, but generally speaking, the smaller the scale of use of 301's the less likely it is that there will be any issues. We don't hesitate to use them in certain situations. But we rarely use them on a large scale, or to move entire sites, unless we're willing to see our rankings tank for a period of up to 12 months or even longer. There are thousands of well documented cases of 301 sinking sites. We're not talking about obvious caveats like poor coding; we're talking about G algorithms. ;-)
Additionally, this is a special case (a merger); in most site moves, restructuring will inevitably trigger a 'new site' filter, thus giving you up to a year of pain; minimising change will always get the best of a 301, for people and SEs
The only way to totally avoid the risks of moving whole sites is not to move them. The vast majority of 301s go without a hitch, assuming they were set up right. In many of the 'documented cases' the sites were rebuilt at the time, thus getting new site problems for up to a year, or the code was wrong, or the host messed it. Many of those who complain had failed to even check the thing worked, others confused 301 and 302 redirects. And most of the reported 301 problems were before 2006.
If you decide the move is the best solution to a problem, "Nothing on the web is totally risk-free; but there is no safer way to move a site than a 301 - except not moving it at all ".
Don't forget the advantages of merging two similar sites; all incoming links to one domain, instead of two; no duplicate content issues, one marketing effort instead of two ...
And a bigger and better site than either single site, better placed to trash the opposition.
But it's an irreversible move, one you should consider very, very carefully. But simply abandoning the failing site is no solution at all; the 301 can often smooth the transition for SEs as well as visitors.
[edited by: Quadrille at 5:50 pm (utc) on Oct. 20, 2006]
