Welcome to WebmasterWorld Guest from 188.8.131.52
There is a clear branding problem leaving it like this - as soon as someone goes to the shopping cart, they see oldname.com instead of newname.com. We would like to switch things around so that newname.com is the primary domain name, and generates both the static e-store pages and the dynamic shopping cart/checkout pages. After the switch oldname.com will point to the newname.com pages. However, we don't want to lose our Google position during the 6 months or more that it will take to build up the ranking of newname.com.
I've read several articles on this, and see that this is a controversial area, in which "reasonable people can differ". It seems to me that the most technically thorough looking article that I read strongly discourages the idea of using a 302 redirect in almost any situation.
Another article also states that a 301 redirect is generally better, but suggests that using a 302 redirect from oldname.com to newname.com is the best way to retain search engine ranking position during the 6 month transition period. After the new name has achieved its own high rankings, I could then change it to a 301 redirect from oldname.com to newname.com.
As I understand it, what I would be doing in the second article is taking advantage of the bug in Google's handling of 302 redirects to highjack my own domain name for my own benefit. (I promise not to slap myself in the face for doing this. ;) ).
One difference between what I have in mind and what the second article says is that I plan to keep everything on the same server with the same pages. By contrast the second article talks about retaining the pages at the old domain until I am satisfied that newdomain.com has achieved a high ranking. This wording sounds to me as if the old domain described in the second article was on a different server.
Has anyone had experience with using the technique recommended in the second article?
For those with a strong technical background with this type of issue, do you agree that the recommendation in the second article is technically sound for my situation?
[edited by: tedster at 8:11 am (utc) on Mar. 28, 2006]
301 redirect is more search engine friendly as it recons to a Permanent Redirect and 302 redirect as a temporary redirect
302 redirect is considered as a black hat technique in Search Engine's as they were used by the illegal websites in the past for promotion
Try and have only and only 301 permanent redirect for your new brand name.
taking advantage of the bug in Google's handling of 302 redirects to highjack my own domain
And there lies the rub. Exploiting Google bugs for a branded domain is playing with fire, IMO.
What if the bug gets even more tangled as Google works to straighten it all out? What if the 302 "refuses" to shake off when you switch to 301 and you're getting all kinds of traffic to a domain you want to take offline? What if some general filter gets applied everywhere it looks like a 302 exploit was in place?
With an important branded domain, I would play it straight ahead and take the roller coaster ride for a bit. Of course, you may be more adventurous.
Thanks for the prompt replies. There seems to be a definite consensus here so far. I can think of a couple of follow up questions:
1) Are there any dissenters out there who favor the alternate method in the second article (initially use 302 redirect from old to new, then later switch to a 301 redirect from old to new)?
2) Has anyone heard of a company's Web site actually trying it the way that the second article recommended? If so what problems did they experience?
I tend to be pretty practical when it comes to making changes like this, and like to learn from specific examples of others' experience.
Thanks in advance.
Some do use 302's (it seems) intra-domain. For example, an affiliate (a legit one) wants to point one URL on their site (single domainm like foo.com/blah.htm to foo.com/affiliatelink.htm) to another - seems safe. However...
One day G**gle and some others will fix the hijacker problem and those with inter-domain 302's may get caught.
Just seems a better bet (If I were a betting man) ;)
I have one situation where they worked exactly as expected though.
I am aware of a site that used a domain name that simply redirected using a 302 redirect to webspace on a free server. Initially some pages showed under the domain name, and other pages appeared under the freespace URLs. Some were not indexed at all.
All of the pages on the free webspace then had a <base href="http://www.domain.com/"> tag added to them, and all links on the pages on the freespace also used relative URLs that started with a / and therefore counted from the root.
In combination with the base tag, then, all links pointed to www.domian.com/some.page.html. Whenever you clicked one of those you were then 302 redirected to the page on the freespace.
However all pages on the freespace have links that now only pointed to the proper domain name.
No pages actually reside at the domain name URLs. There is only a site-wide 302 redirect at the domain name, redirecting to the same requested page name on the free webspace.
Within weeks Google listed the entire site as if it resided at the proper domain name. It no longer indexed any URL on the free space at all.
I know one prominent SEO was suggesting this as a means of avoiding a possible sandboxing/aging delay, but haven't seen it recommended outside her forum....
I wrote an article back when the problems with Google was wery much worse than they are today, and I guess that's one of the two mentioned in the original post. Credit's due where credit's due, and Google has actually improved since I wrote that article, but, well...
There are two types of problem solving: Some problems you solve 100% and then they're solved. With others you do something else, and then you've still got the problem and it's not solved but it's no longer a problem because of something else.
I will maintain that there are only those two. Google has tried to invent a third type in this case. They've made some effort at solving the problem, yet not solved it 100%, and not put something else in it's place so that the problem is no longer a problem.
Anyway, Google has cleared away the possibilities for the most serious types of exploits. No doubt about that, and that is cool. They did that pretty fast as well, that is; just a few months after my article managed to make headlines a few places.
(credit's due, etc: ... which was years after those issues were first brought up here at WebmasterWorld)
Now, Google is a big company and around newyear they started implementing a new infrastructure, which -- as I understand - should help take some of the last issues away. I'm not convinced yet, especially as the use of 302's is less widespread in SEO aware circles than it used to be, so any decrease in problem reporting may be caused by that we're less inclined to hear about problems anyway, as we don't use that stuff like we used to.
Anyway, down to the nitty-gritty
What a certain Google engineer said -- I'm not sure if it was Googleguy on this board or if it was "that other guy with the blog" -- was that (I can't quote literally, but it went something like this):
... they would try to do it like Yahoo, except they would decide in each case which was the "prettier" URL
I'm not sure "pretty" was the word or if there were more words, but it was something like "the URL that people would probably like to see in the SERPS" ... So, there are some problems here as there are clearly interpretations, and that's exactly why g1smd hit the nail on the head.
So, should you do it?
The "it" being: Use a 302 for a while as you build a new site on a new URL and get backlinks to it, and then -- as the new site starts to rank on it's own -- change the 302 to a 301.
Well, you could. I don't think you'll risk anything as either one of your two sites will be linked in Google. Perhaps not the right one every time, but they would still both be yours and the visitor would end where you wanted.
So, try a few (5-10) pages or a minor section first - 302 it and see what URL it will get in the SERPS and what rankings those pages have after a month or so. If Google seems to get it right in your case you can try 302-ing the rest.
But... you could do exactly the same thing without the 302, and you could also use a simple text link or meta redirect in stead of the 302. So... no matter if you use it or not you will have one old site ranking, and one new site building up.
Last time I moved a section of one site to a new site of it's own was end of December 2005 so it was before the Big Daddy rollout. What I did was first to physically install the pages on the new domain, and do the related minor changes (new name, obviously), and launch. After that, I replaced the content of the old pages with a single text link saying essentially "... this page has moved to (new address link) - please update your bookmarks ..."
For two weeks the old pages were left like this, with just a link. Then I 301'ed them. All I wanted was basically to make sure that a search engine had "followed" those links to the new location before I did the 301. So, I 301'ed them around January 10 this year, and the new domain was brand new; bought just for this occasion, never registered before. I had SE referrals in January on the new site. Same month as I did the 301. URL was changed in SERPS after a day or two, IIRC.
The SE referrals come on lousy terms and it's a very low volume, but the site was only three months old before I moved it, so that's no surprise and no worse than before - and clearly that has nothing to do with the move. That's just because the SEO on the site is lousy, and I can attest to that as I've done next to nothing, basically ;)
If I was going to do it again tomorrow I would not feel a need to use a 302. I would use the same tactic I used in January - basic text link first, wait for spider, then 301.
But feel free to do a 302, I'm not going to warn against that, except for saying (well, agreeing with g1smd that said it first) that it could be unpredictable. I would not think it would directly harm you as you own both sites, and traffic will end up at your place anyhow.
Perhaps it's even better than my tactic in your case. Remember that the site I moved in January was just a baby - three months old, could hardly crawl. So if it's a thousand page site with lots of good ranking pages I understand that you may want to be more careful.
And, one of the steps I took was to remove the content from the original pages before the new pages had been spidered, and that may perhaps seem a bit too risky for your liking. With a 302 you always have the backup plan of removing the 302 again, and letting the pages return to their old URLs.
The <base> tag took care of that (perhaps moreso than the redirect - but both BOTH were needed to make it happen) [Summary: 302 redirect from "A" to "B". Pages really are located on server at "B" but all pages have a base tag that says that the pages are "located" at "A". "A" is what gets indexed.]
I would not like to predict what would happen if after 6 months or so, you changed the redirect to a 301, and at the same time changed the URLs in the base tag to be the other domain of the pair, in the hope of delisting one and relisting it as the other. I could not comment on that at all. You may well be in uncharted territories...
(The base tag - when it contains the same domain as where the pages are really located - also protects you against any people pointing malicious 302 redirects at your site too).
Thanks for the thorough replies. I'm not sure if I made one thing clear in my description of my situation: there are no separate Web servers here. Both oldname.com and newname.com reside on the same Web server. Currently newname.com is just a pointer, and oldname.com is the primary domain name for the Web server, but when I finish, I would like the situation to be reversed.
Given that, would the techniques that you described to use a 302 redirect still apply in my situation?
If not, what modifications would you suggest to your technique of using a 302 if both names reside on the same server?
In the meantime, slowly get people to change their links to point to the new site.
Any sites that already check their outgoing links on a regular basis will soon spot that your old site no longer returns a 200 status anyway, and can act on that.
Use Xenu LinkSleuth to check YOUR outgoing links too.
Here is my scenario, which throws a little variation into the mix due to server technology used... any insights much appreciated:
I'm helping a college relaunch their website. The site is currently located at three URLs, all on the same Microsoft IIS server at the same IP.
All three have good search engine saturation and link popularity for hundreds of their pages on all three domains.
For example (all fake URLs):
www.schoolsite.com/courses (preferred domain)
www.schoolweb.com/courses (non-preferred domain)
www.schoolfun.com/courses (non-preferred domain)
... all have the same content on their courses page.
Only one of them is found on Google. (I assume Google is probably penalizing the other two for duplicate content). Other pages of the two others can be found on Google too.
They want to redo the whole site and relaunch at www.schoolsite.com (the preferred domain) again.
I want to take the opportunity to try to get all their link pop and saturation to be at one url - schoolsite.com, so its not spread between 3 URLs.
I think that this is the solution that i have to recommend.... but I would love to have it vetted since its going to be a big pain to implement:
Key Assumption: since they are on Microsoft IIS, and Microsoft IIS only allows you to use a 301 redirect to redirect from the top level domain to another top level domain, we can't redirect from individual subpages to other individual subpages. (am i right?)
1. relaunch the new site.
2. every page on non-preferred domains should have content removed and replaced with a notice saying 'this page has moved to www.schoolsite.com/here'. At same time 'no-index, follow' code should be put on this page.
4. All links in to non-preferred domains should be contacted and notified that link has changed to new URL.
5. site logs should be monitored to make sure search & 3rd party traffic starts coming to the new pages, and stops going to old pages. once it looks like this is happening, the old pages can be removed.
6. 301 redirect put in place, redirecting to preferred URL.
Is this the right approach? Thanks in advance for any feedback on this...
The suggested advice is to utilize a 301 and map all of those old URIs to the new ones. You should be able to do this with pattern matching through a rewrite routine.
The typical process, as I've experienced, is the old pages will go supplemental within 30-60 days. The new pages will be getting indexed while the old ones are going supplemental. You'll see the new pages appear when doing site: searches and you'll also see the Supplementals moving to the back (at the end) of those searches. You'll still rank for some things but there may be a delay at some point when the two domains finally crossover and your 301 has taken effect at which time things start to go back to normal.
The indexing frequency of the old site will determine the timeframe you can expect to wait before the 301s take full effect. Once this occurs, you keep that 301 in place for as long as you can. I'm going to suggest at least 12-18 months (to keep the 301 in place) based on current trends.
Just be sure that those old URIs are returning the proper server responses when performing server header checks. The old ones should be returning a 301 to the new ones which should return a final status of 200 (the new ones).
Yeah, it seems quiet again now... nice :) But I think that -- except for the experimental types -- most people in SEO have just stepped away from using 302's so they dont have to think about it anymore. Which is a pity (and a pita) because they're both good and useful (and they really should be used where they should be used).
>> same server (box)
It does not really matter to any of the things I've written if your pages are served from one box or another. So, a 301 between two domains one the same physical box will not be any worse than one between two domains on separate boxes.
>> existing backlinks
What g1smd said. These will eventually transfer to the new domain with a 301, provided "a lot of things that are a bit speculative", but it will take time.
>> keep that 301 in place for as long as you can
I agree. Keep it there for as long as you can.
That six step plan sounds totally allright to me. Very nice and carefully planned sequence of events. I would see no problems in doing this, except labour and time. But, relaunches take labour and time.
You should look into something called "ISAPI filters" for IIS. I'm no expert but I think those may be set up to do redirects page-by page.
I replaced the content of the old pages with a single text link saying essentially "... this page has moved to (new address link) - please update your bookmarks ..."
For two weeks the old pages were left like this, with just a link. Then I 301'ed them.
That has also been successful for me (pre-BD). So many people don't take that almost naive first step of placing a text link to the new page, and that's all. The 301 can come later, after the new urls are getting their due.
This approach has always worked for me, and I will do the same the next time the situation comes up. Unless, of course, Google actually creates a Certified Domain Change program [webmasterworld.com]. (well, I can hope)