Forum Moderators: Robert Charlton & goodroi
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?
BTW:
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.
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.
[edited by: RonnieG at 6:40 pm (utc) on Nov. 3, 2006]
That may be the reason your site is still ranking.
http://del.icio.us/url/check?url=http%3A%2F%2Fwww.<<<MY WEBSITE>>>.com%2FSwimwear%2Ftabid*
%2F36%2FList%2F1%2FCategoryID%2F1%2FLevel%2F1%2FDefault.aspx&submit=check%20url
GET /url/check?url=http%3A%2F%2Fwww.<<<MY WEBSITE>>>.com%2FSwimwear%2Ftabid%2F36*
%2FList%2F1%2FCategoryID%2F1%2FLevel%2F1%2FDefault.aspx&submit=check%20url HTTP/1.1
Host: del.icio.us
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: BX=7n6kb0h2fipdv&b=3&s=uq
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"
Location: http:/[smilestoppper]/del.icio.us/url/fedfe7d5dd87d23e7bb423757f46cb1a
Connection: close
Content-Type: text/html
======================================
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]
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]
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
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]
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.
Similarly:
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.
Justin
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 ;)
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...'
Justin
HTTP 1.1 Status Code Definitions [w3.org] from the W3C
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.
Now if anyone has any clout with GoDaddy to get this changed, I'm sure hundreds of webmasters would be eternally grateful!
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.
Justin
There was a post about this only days ago. I seem to remember that 503 or somesuch was the correct thing to send.
[webmasterworld.com...]
ADDED:
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.
Justin
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.
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]
Baseline Case:
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.:
<?php
header("HTTP/1.1 301 Moved Permanently");
header("Location: domainc/targetpage.htm");
exit();
?>
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.
Conclusion:
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]
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.
[mattcutts.com...]
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.
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.
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?
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?
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.
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.
[google.com...]
