| This 32 message thread spans 2 pages: 32 (  2 ) > > || |
|Are 302 redirects always bad for Google SEO?|
Pros and Cons of 302 Redirects
| 2:53 am on Nov 3, 2006 (gmt 0)|
A debate I am having with other webmaster friends:
Does Google still penalize the target page of GoDaddy 302 redirects (and also possibly the target pages of other "blackhat" 302 redirects)? I know it used to, at least until Big Daddy and subsequent algo changes earlier this year related to canonicalization.
My opinion: It doesn't look like it to me, and it seems the other opinions are primarily based on the old Googlebug 302 fiasco, since supposedly fixed, as well as other improper uses of 302 redirects that Google has since (or always) penalized. I may be wrong, and often am, but what I think I am hearing from other sources is primarily old SE dogma that may be correct in some cases, and may have been correct at one time, but does not seem to apply universally any more.
Proofs (or evidence if you prefer):
1) I have several GoDaddy 302 redirects from my Godaddy vanity domains to my primary home page, domain registered but not hosted at GoDaddy, and it is still indexed, and not supplemental, and has been at a very stable PR3 for all of two years.
2) Google doesn't seem to be confused, and doesn't list any redirects from any other domains to deeper pages on my main site, as shown with allinurl or inurl commands, including the several GoDaddy domain 302 redirects to deep pages that I know are in place.
3) Only the canonical target pages of my main site are listed in Google's indexes. Many are supplemental, and there are good reasons that I am OK with that, since they are at least crawlable and listed somewhere, and they are low content pages anyway, so I can see why Google doesn't include them in its main index.
Any other indications I should be looking for in this case?
I know that some 302 redirects in Java scripts and/or php scripts on a page can be interpreted by Google to be doorway pages, and that page penalized, but that is not the case here.
I also know that 301 redirects are generally preferred, and necessary in some cases, but GoDaddy (still) doesn't support them for its domain redirects, and I do not have access to .htaccess file on my GoDaddy domains to be making any changes there.
I really don't want the vanity/special domain names being indexed, and it seems that either Google is smart enough to not do that, or GoDaddy may have noindex set by default on the redirected domains. Since they point to my main domain and web site, it would only cause duplicate issues anyway.
Most of the Godaddy 302 domain redirects, those to the deep pages, are to a third level domain name at my web host's domain name servers that is aliased to the specific target page. That being the case, am I inadvertantly avoiding the issues that a 302 redirect may cause, because the DNS is handling filtering of the redirect and turning it into an alias as far as Google is concerned? That might explain no penalty for the deep pages, but not redirects to the home page, unless the fact that all of the redirect targets are to the www. version of my home page, so they get handled as DNS alias resolutions as well.
Help! I have spent hours in the last couple of days reading Matt Cutts blogs on this year's Google changes, and other forum sources on this subject, and cannot seem to find the "right" answer to this question. The "right" answer may determine if I need to move 90+ domains from GoDaddy to another registrar whos domain redirection uses 301s, which I really do not want to do unless there is no other alternative.
| 4:20 pm on Nov 3, 2006 (gmt 0)|
It should be easy to see if Google still penalizes a site for having a 302 pointed at it. If you have an expendable site you can use as an experiment and you also have an expendable domain that had reasonable keyword rank point a 302 at it and see what happens. The target site should dissapear from Google's index in a few weeks and traffic as well. I wouldn't adivse this for anyone trying to put a competitor out of business however as all one has to do is complain to goodle and the 302 site can be permanently banned from Google.
PS. Google has removed most methods of finding 302s in it's index (they no longer show up in the inurl command)--however that doesn't mean 302s no longer cause harm. I believe because they are easily spotted that other more sophisticated methods are now being used to destroy a site.
| 6:35 pm on Nov 3, 2006 (gmt 0)|
I am already in the "test" mode you proposed. As I stated in my original post, the domain with the 302 redirect is nowhere to be found in any Google index, while the target site has remained fully indexed, all pages unique, and PR3 for many months. So it is my opinion that most 302 hijacking is now being defeated, and innocent use of 302 domain name redirection is no longer being penalized by Google. Yes, improper use of 302 instead of 301 can cause existing pagerank and SERPs to be lost, but in this case, there was nothing to be lost, since it was simply a GoDaddy domain name redirect.
[edited by: RonnieG at 6:40 pm (utc) on Nov. 3, 2006]
| 8:05 pm on Nov 3, 2006 (gmt 0)|
There are also search engine friendly 302s and those that aren't.
That may be the reason your site is still ranking.
| 8:24 pm on Nov 3, 2006 (gmt 0)|
as this is a 302 thread i've got an enquiry as it seems when i click on a link in my site a 302 is occuring. By using live headers i've discovered the 'offending'? 302 is this:
GET /url/check?url=http%3A%2F%2Fwww.<<<MY WEBSITE>>>.com%2FSwimwear%2Ftabid%2F36*
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20060909 Firefox/220.127.116.11
HTTP/1.x 302 Found
Date: Fri, 03 Nov 2006 19:25:15 GMT
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
i cannot understand why, when i click on one of my internal links to go to an internal page, something is requesting "delicious"
can anyone help, or suggest whether this is harming?
<*means a line break was added to prevent side-scrolling>
[edited by: tedster at 12:59 am (utc) on Nov. 5, 2006]
| 8:31 pm on Nov 3, 2006 (gmt 0)|
302 [Temporary] Redirect to a DIFFERENT Domain
I've also been noticing less trouble from domain level 302 redirects. I don't know for sure how Google achieved this fix -- they may even be working from a "white list" of registrars and web hosts known to routinely use the 302 for a "vanity domain" redirect.
But if a company is hosting on its own servers, then there's no reason to risk using a 302 when a 301 is exactly right for the job. And if your host/registrar offers a 301, I would still choose that -- and I would ask for it if they currently do not offer it.
302 [Temporary] Redirect within the SAME Domain
A 302 Temporary Redirect within a domain is a different case. Even though the opening question is about a cross-domain 302, I thought a section on the intra-domain 302 would be helpful. This is especially so because so many .NET sites (and others hosted on IIS) get it wrong needlessly and that can have a bad effect on ranking.
If you have moved content to a different URL, how common is it that you plan to move it back? That's what temporary means, after all, and that's what search engines assume. So the OLD url would continue to show in the search results, but with the new URLs content. How often do we want that? Not very often. So make sure that intra-domain redirects are 301, not 302, in almost every case
-- One Exception --
I can think of one exception to this general rule that's worth noting. If, for some reason, you are redirecting to domain root to an interior url, the you should probably use a 302. If you use a 301, then you risk not having your domain root show at the top of searches done for your domain, and that's bad news. So a 302 is my redirect of choice when the domain root is redirected to an interior url on the same domain. That keeps the domain root in the index, and gives it the content of the target url.
[edited by: tedster at 9:28 pm (utc) on Nov. 3, 2006]
| 8:33 pm on Nov 3, 2006 (gmt 0)|
actually i think i've discovered the issue.
i've got the SEO Quake Plugin installed on firefox, and as it would seem that this is calling delicious in order to get page information.
sorry for the false alarm :D
| 9:02 pm on Nov 3, 2006 (gmt 0)|
Thanks, at least I know I am not crazy and not the only one noticing this! If some of Matt Cutts old blogs and many threads on this subject on here dating back to mid-2005 are any indication, it may be that Google has finally listened to all the feedback that essentially said they should treat 302s just like 301s, except don't transfer PR or SERPs. Since Google continuously goes back to sites/pages with 301s to see if anything has changed, at least until they return a 404 to start the delete clock, then from Google's point of view, at least in the canonicalization process, there really is no such thing as a permanent redirect, and in fact, 301s can be just as temporary as 302s, at the webmaster's whim.
BTW: GoDaddy still does 302s on all domain level redirects, and despite many customer requests, refuses to change. So if Google really does have a whitelist of registrars, it seems GoDaddy is probably on it.
[edited by: RonnieG at 9:03 pm (utc) on Nov. 3, 2006]
| 9:15 pm on Nov 3, 2006 (gmt 0)|
A 302 should not be treated just like a 301. They have distinct purposes for a reason and ought to be used accordingly. While I too am seeing less issues with 302s, I wont put my clients at risk when all that is needed is to simply do it right and employ a 301.
| 9:30 pm on Nov 3, 2006 (gmt 0)|
Just reading through and I think it is important to note:
301 = Permanent Redirect
"It's not here any more, I moved it there, get it from there."
The proper HTTP response is to request the document from there.
302 = Undefined Redirect
"Uh, it's not here, I moved it there, not sure why, not sure for how long, not sure if I will move it back."
The proper HTTP response is to continue requesting the document from here.
307 = Temporary Redirect
"It's not here right now, I moved it there, but it will be back, so keep checking for it."
The proper HTTP response is to continue requesting the document from here.
If you are moving a page temporarily, I would suggest using the proper status code when you have the ability.
404 = Not Found
"Oops! No file. Looking here on the desk but don't see it, maybe I put it somewhere else. I'll let you know."
The proper HTTP response is to continue requesting the document.
410 = Gone
"Stop asking, I threw it away."
The proper HTTP response is to stop requesting the document.
| 9:40 pm on Nov 3, 2006 (gmt 0)|
Just a note about the 410 response. The word a few months back from Vanessa Fox of the Google Sitemaps team, was that googlebot currently handles both 404 and 410 in an identical fashion.
Their job is not just to be technically correct, but to put together the best search results they can in the moment. For some reason, they do not always count on webmasters and server admins to be technically accurate. I think I'd be doing the same, if I had Google's job ;)
| 9:48 pm on Nov 3, 2006 (gmt 0)|
I absolutely agree. I just wanted to point out the differeces in status codes, because when you have people talking about setting status codes, it seems like it would be good to let them know they can probably help the SEs out by using the proper status.
If I knew there was a 307, I would never set a 302.
I also thought it might help people understand why there are some issues surrounding 'just do this...'
| 10:24 pm on Nov 3, 2006 (gmt 0)|
Thanks much Justin. The 307 status was new information for me - and it was apparently introduced with http version 1.1. A read through all the status codes is an eye-opener:
HTTP 1.1 Status Code Definitions [w3.org] from the W3C
| 10:46 pm on Nov 3, 2006 (gmt 0)|
I think that defining a code like 410 Gone Forever is a bad move.
You cannot guarantee than in a year, or decade, or century that such a URL is not going to come back into use under a new owner.
| 11:15 pm on Nov 3, 2006 (gmt 0)|
If I had a choice, and had access to the server files and could use a 301, I certainly would. However, GoDaddy does not give its users that choice, at least for non-hosted domain names, and so far has been inflexible on changing their policy and infrastructure, so I am stuck with a 302 or moving 90+ domains to another registrar. Keep in mind that not all of us are managing web server hosts. We just have domains that are registered and hosted by 3rd parties, so we don't always have all the flexibility you may have to do things the 100% correct way.
Now if anyone has any clout with GoDaddy to get this changed, I'm sure hundreds of webmasters would be eternally grateful!
| 12:46 am on Nov 4, 2006 (gmt 0)|
I completely understand, and obviously the issue you are referring to is an issue with more than one company. The people I was posting to were those who could set headers (IOW can set up an .htaccess file) and were wanting to temporarily redirect a page.
I think people need to remember just because something seems 'odd' or 'wrong' for one site, it may not be for another...
In a dynamic setting, when a database server fails, or you drop a connection for some reason the 'site' or 'page' still works but the information for the page is not there.
If I drop a db connection and there are no results for a query = main site navigation loads = duplicate content if I load the page on any requested pages = I better say 'Oops' to a SE requesting the page rather than 200 OK. The only correct header I can think to serve in this instance is a 404.
If I am updating a db at the same time a SE requests a 'page' I need the SE to check back later and see if the resource is still attached. Some of us rely on SEs following the rules to keep sites in the index. I think understanding why SEs take some of the actions they do can help define the 'fix' for (or at least the reason behind) the action on a particular site.
| 1:01 am on Nov 4, 2006 (gmt 0)|
If the database doesn't respond, then a 404 is not the correct response.
There was a post about this only days ago. I seem to remember that 503 or somesuch was the correct thing to send.
| 1:29 am on Nov 4, 2006 (gmt 0)|
I believe both are applicable, but the 404 gives me more flexibility in saying 'for some reason the requested resource is not available at this time...' and can be delivered on a number of 'bad' requests. (Just my opinion and reason for use.)
|This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. |
When I look at 302 threads closely I see Google (and other SEs) had to make adjustments to handle mis-use of, or mis-understood use of redirects and document requests (basic temp v. perm 'status codes') provided by many webmasters and hosts.
What I mostly see is webmasters not understand when Google follows the standard on a members website and when following the standard does not achieve the desired result of the webmaster.
I like the fact that SEs are helping people (and/or hosts) who do not have the ability to address these issues, by adding flexibility into the handling of certain requests, but think using the proper identification of (or at least communicating temp. OR perm. status of move, missing, etc.) resources when possible makes things more stable for webmasters and SEs.
Will 302s on a site hurt? I don't know. I know I have recently, successfully used 307s.
ADDED X 2: My desired result is the 2nd to last sentence of jdMorgan second post in the same thread... I would like SEs to continue requesting the resource.
| 3:25 am on Nov 4, 2006 (gmt 0)|
Back on topic:
Can anyone confirm or refute, with specific knowledge and/or evidence, that Google has recently, either with Big Daddy and/or other 2006 algo changes, significantly changed the way that 302 redirects WERE being handled and indexed BY GOOGLE, and that these changes APPEAR TO BE a "FIX" to many of the previously reported issues with pagejacking, dup content and lost SERPs that were being discussed ad-nauseum in many forums and threads since early 2005? If this is in fact the case, then it is a major and significant bit of news that negates, or at least moderates, previous SE advice to avoid 302s at all costs, and only use 301s. It also takes a lot of pressure off GoDaddy and other domain registrars who use 302s as a standard "vanity domain" redirect technique.
The discussion of additional and possibly similar response codes is certainly interesting, but I can also see that it could potentially cause new issues with Google and other spiders as they crawl about and try to figure out what the webmasters really mean :), and/or as some of the more progressive webmasters implement the newer codes. This also begs the question: How much dialog is/has been occuring between W3C and the SEs about how these newer codes should be handled in a SE context, and who will be the first to wail and moan because whatever Google and other SEs eventually decide to do with the new codes is not what they expected, and not how they were handled when the webmasters first started using them? And with this last question, I guess I should not be surprised to see this tread take on another tangent :) :).
[edited by: RonnieG at 3:32 am (utc) on Nov. 4, 2006]
| 8:13 pm on Nov 4, 2006 (gmt 0)|
I have been doing some experimenting with various techniques and work-arounds for my issue of GoDaddy vanity domain pointing and its 302 redirects, as described at the top of this thread.
A) GoDaddy domaina.com is redirected with basic GoDaddy domain redirection to domainb/targetpage.htm, on my primary site.
B) Header check for domaina returns Status : (302) Found as expected, and redirect occurs, taking the user (and spiders) to the appropriate target page, but may not be SE friendly.
Test Case 1:
A) Using .htaccess file in domainc, created a 301 redirect, coded like this:
redirect 301 /targetpage.htm domainb/targetpage.htm
B) Changed the domaina redirect to point to domainc.com/targetpage.htm
C) Header check for domaina still returns Status : (302) Found as expected, and redirect occurs, taking the user (and spiders) to the appropriate target page.
D) Header check for domainc/targetpage.htm returns: Status : (301) Moved Permanently, a SE friendly result.
Test Case 2:
A) Created domainc/targetpage.php with php 301 redirect script as suggested in GoDaddy help file on 301 redirects. i.e.:
header("HTTP/1.1 301 Moved Permanently");
No other page on domainc or anywhere else links to targetpage.php, so it should never be found or indexed by any SE spiders.
B) Changed the domaina GoDaddy redirect to point to domainc.com/targetpage.php
C) Header check for domaina still returns Status : (302) Found as expected, and redirect occurs, taking the user (and spiders) to the appropriate target page.
D) Header check for domainc/targetpage.php returns: Status : (301) Moved Permanently, a SE friendly result.
In all cases above, spiders and browsers will still encounter a 302 redirect at the original domain, but in test cases 1 and 2, at the target of the original redirect, they will encounter a 301 redirect, which will then take it to the correct target URL.
I fully realize that this approach will NOT accomplish the desired result of most webmasters to pass on the old PR and SERPs of old pages and sites to a new page/site, and that a 301 at the original location is absolutely the best way to go.
However, since there is no PR or other acquired ranking of a vanity domain to pass on, this convoluted approach should at least serve the purpose of avoiding potential dup page penalties at the target site, and protecting the target site from any other potential penalties that could result from a 302 redirect into that site.
Am I on target here? Can anyone see any holes in this theory and approach? Remember, I really don't care about domaina SERPs, and because the php page on domainc is unreachable, it should not affect domainc either. Protecting domainb is my main goal, and avoiding having to move 90+ domains out of GoDaddy is my secondary goal.
[edited by: RonnieG at 8:19 pm (utc) on Nov. 4, 2006]
| 8:27 pm on Nov 4, 2006 (gmt 0)|
|Can anyone confirm or refute, with specific knowledge and/or evidence, that Google has recently, either with Big Daddy and/or other 2006 algo changes, significantly changed the way that 302 redirects WERE being handled and indexed BY GOOGLE, and that these changes APPEAR TO BE a "FIX" to many of the previously reported issues with pagejacking, dup content and lost SERPs that were being discussed ad-nauseum in many forums and threads since early 2005? |
It seems to me that if Google had fixed the 302 problem then we would hear about it from Matt Cutts, et. al, and we haven't, other than they are working on it.
| 10:46 pm on Nov 4, 2006 (gmt 0)|
Yes, but Matt does specifically address HOW they are working on it in his 302 discussion blog:
Now the question is whether he will respond to my question/comment at the end of that blog today about where Google stands on that effort, for all of us to know.
| 10:50 pm on Nov 4, 2006 (gmt 0)|
i'll come back with my original request. where can i find what pages are causing 302's (as i'm not 100% sure its my plugin anymore)?
going through my website statistics i've found that tehre are some 302s happening. now i'm pretty sure this is badly affecting google rankings, as we are coming up high for yahoo/msn and absolutely nowhere for google.
| 12:47 am on Nov 5, 2006 (gmt 0)|
You can see the 302 status right in your raw web logs -- this is probably best place to look, because you will see exactly which requests get the 302 response. If you wat to see the http headres in action, you can install the "Live HTTP Headers" extension to Firefox.
|It seems to me that if Google had fixed the 302 problem then we would hear about it from Matt Cutts, et. al, and we haven't, other than they are working on it. |
I'm not sure there's a black and white "fixed or not-fixed" verdict possible. What kind of 302 issue are you concerned with, precisely? The target domain is the one indexed most of the time at present -- I have not heard complaints about the "old school" 302 hijacking in recent months. As Matt Cutts described, a 100% consistent handling is not what Google feels is best for their users.
I know that aggressive sites are always probing Google for loopholes they can exploit - is there still one causing trouble in the area of 302 handling?
| 1:21 am on Nov 5, 2006 (gmt 0)|
I doubt Matt will vouch for anything 100%. If you want a guarantee, use 301s.
| 4:04 am on Nov 5, 2006 (gmt 0)|
I have now converted all of the 302 redirects I had as a result of having all GoDaddy domains, to go through an intermediate site where they are all converted to 301s by .htaccess before they hit my primary site. I don't know if it will make any difference, since I really did not see any negative impacts from the 302s in the first place, but we'll see. Googlebots hit my sites pretty frequently, so I should know in a week or two if/how my sites are affected.
| 6:07 pm on Nov 8, 2006 (gmt 0)|
RonnieG you mention in one of your posts:
'Since Google continuously goes back to sites/pages with 301s to see if anything has changed, at least until they return a 404 to start the delete clock, then from Google's point of view, at least in the canonicalization process, there really is no such thing as a permanent redirect, and in fact, 301s can be just as temporary as 302s, at the webmaster's whim.'
Is this true? If it is why use any other type of redirect?
I'm torn between using a 301 and a 307 after reading this thread. I have a site which has recently moved from one domain to another but will be going back to it's original domain soon.
I am worried that if I use a 301 from the domain then Google will take it that the site has permanently moved and not visit the domain for a long period.
301 or 307?
| 7:34 pm on Nov 8, 2006 (gmt 0)|
The discussion of G going back to 301 URLs until they start returning 404s is from a discussion in one of Matt Cutts past blogs. But, as with anything G does, or did do at one point, or what anyone says it does or used to do, including Matt, I don't know absolutely whether it is true today or not. Now if that doesn't sound like "googlespeak", I don't know what does!
Technically speaking, 302 "Temporarily Moved" would seem like the correct redirect if a site will be coming back to its original domain. Except that, at least for Google, 302 supposedly does not retain the prior site's PR or other SERP enhancing attributes. Since most of the past discussion I have seen on redirects from most sources has been on 301/302, I have no idea what a 307 might do.
| 1:42 am on Nov 9, 2006 (gmt 0)|
Yahoo are/were doing it on some of their categories...
One thing to note is the Header function in PHP:
<?php header("Location: http://www.example.com/");?>
If you upload this and check the headers you will see a 302...
Only if you put a line before that one which will send a 301 status code:
<?php header("HTTP/1.1 301 Moved Permanently");?>
I think Google is still badly affected by 302s, as I've discovered too many identical domains/subdomains/subdirectories which are exactly identical, running the same script, having too similar text, same logos and promoting exactly the same sites.
Still on my bait domain I get hits from spammy sites. More and more and more and more... I've found IPs with over 700,000 domains (no idea how many subdomains) parked there and running identical scripts. Since the particular domain targetting me got actually sold and considering mine was keywordcompany.com and theirs keywordindustry.com I am worries that it was sold as a result of this site somehow stealing our google traffic.
For "keyword" this particular one was something like in the top 70, while mine was nowhere in the first 1000, despite being no 10 before getting targettes.
I can't say for sure if Google has fixed this problem. Since the October update (when I first saw the spam sites out of Google's index) things seem somehow different on this front.
It took about 4 months from my initial spam reports to get such a network kicked out of the index (I am pretty sure it was me). But it took too many spam/dissatisfied/support email reports to see them out of Google's index.
| 4:33 pm on Nov 14, 2006 (gmt 0)|
I found the following in regards to the 307 redirect:
| This 32 message thread spans 2 pages: 32 (  2 ) > > |