A 302 shouldn't be the issue -- What you're describing sound more like a penalty or technical error along the lines of robots.txt blocking gBot or noindex somehow being present on the pages.

A 302 is a temporary redirect, it could be hard to index a file that might not be there next month. A 301 sends the message that this file will always be found "here", a 301 redirect is a permanent redirect.

Is there a reason they chose to use a 302 or was it just leaving off the [R=301,L]? You might get more help with fixing redirects and htaccess files in the Apache Forum: [webmasterworld.com...]

Google's been breaking protocol for months on 301 redirects and sending people to the original location rather than the URL that is the target of the redirect -- They've also been handling 302's and meta refreshes with a "short time to refresh" very similar to 301's due to the "302 Hijacking Bug", so while it's "good form" to use a 301, using a 302 [that's redirecting like it should] is not the type of thing that would cause a site to be nearly completely deindexed.

Thanks for your help

The site has been getting G traffic since June when it was launched, so it is not a noindex or robots.txt file issue.

I am not privy to why it was a 302 and not a 301. This was previously a blog of the main site that was moved to its own domain in June. There was a 53% drop in traffic after the domain move, which they expected.

Disappearance of the site's pages particularly the homepage happened only today. And from the looks of it, Google traffic is tanking.

There are no messages in GWT. Index status in GWT shows a 34% drop 7/27 to 8/3, but recovered by 45% on 8/10. No sudden spikes in URL errors

Clean link profile; no link building done. Has a very strong social media profile (FB for new domain already has 300K likes) and gets regular links from high quality authoritative sites (including loads of .gov)

What other "under the hood" SEO should I look at?

IME It's not often they drop the home page of a site, even if there's a penalty, so this one's a bit odd.

---

I'd start by trying:

Fetch as Googlebot in WMT.

Check the server headers for the original location.
[freetools.webmasterworld.com...]

Then check the server headers for the new location you will see in the first response -- Look for "Location: [new URL here]"

See if the host has had any downtime in the last 24 hours or so.

Go from there.

Google's been breaking protocol for months on 301 redirects and sending people to the original location rather than the URL that is the target of the redirect -- They've also been handling 302's and meta refreshes with a "short time to refresh" very similar to 301's due to the "302 Hijacking Bug", so while it's "good form" to use a 301, using a 302 [that's redirecting like it should] is not the type of thing that would cause a site to be nearly completely deindexed.

I'm not understanding. How is that possible? A server-side redirect makes it possible for anyone to view the redirected page.

It's not often they drop the home page of a site, even if there's a penalty, so this one's a bit odd.

I searched for "URL" (without the .com) and now sees the Contact Us page at #10. No other pages from the domain in the top 100. That was better than this morning

When I do site://URL.com I see /page/1670 and other similar pages as well as author pages, but not any of the posts (articles)

One of the first things I did was to check the server headers of the original domain, and it is redirecting to the correct version of the new domain.

I also did the Fetch as Googlebot, and it were partial loading. What was not loading was Google Font and Doubleclick codes, showing as denied by robots.txt

The format for site search (non-www) is:
site:example.com
without the //

Don't get distracted by the oddities you're seeing in Webmaster Tools and when you use the site: operator. Your primary focus should be on making sure that the redirect is set to use a 301 response code for the redirects. The 302 just won't do the job, and until you fix this you're liable to continue to have ranking issues.

A server-side redirect makes it possible for anyone to view the redirected page.

I think you mean: "view the content of the destination URL when requesting a 301 redirected resource," exactly the same as anyone can [and will] view "destination" content if a 302, 303 or 307 status code is being used in the redirect, rather than a 301.

---

How it's possible Google is "breaking protocol" is RFC 2616 explicitly states when a 301 is encountered the client should send visitors directly to the destination URL, not the URL which is being 301 redirected to another location.

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

[w3.org...]
See: 10.3.2 301 Moved Permanently

Google has begun sending visitors to URLs that are 301 redirected to a different location at it's discretion, which is *not* what RFC 2616 states about how a 301 *should* be handled -- Google's handling of URLs in those situations is a breach of Internet Protocol.

---

From the "horse's mouth" -- [webmasterworld.com...]

The 302 just won't do the job, and until you fix this you're liable to continue to have ranking issues.

Sorry, but that's pure, complete, total SEO, "I need to justify my existence and paycheck", FUD!

---

From *way* back in 2006:

Emphasis Added

Okay, back to our regular discussion. Now let’s talk about off-domain 302 redirects. By definition, those are redirects from one domain A.com to another domain B.com that are claimed to be temporary; that is, the web server on A.com could always change its mind and start showing content on A.com again. The vast majority of the time that a search engine receives an off-domain 302 redirect, the right thing to do is to crawl/index/return the destination page (in the example we mentioned, it would be B.com). In fact, if you did that 100% of the time, you would never have to worry about “hijacking”; that is, content from B.com returned with an A.com url. Google is moving to a set of heuristics that return the destination page more than 99% of the time. Why not 100% of the time? Most search engine reserve the right to make exceptions when we think the source page will be better for users, even though we’ll only do that rarely.

###

...Over the last year, Google has moved much more toward going with the destination url, for example, and the infrastructure in Bigdaddy continues in this direction.

[mattcutts.com...]

@not2easy ... yes, I needed coffee when I was typing the post!

It was a 60% drop in Google traffic yesterday. Still no messages in GWT. But we changed the 302 to 301 yesterday.

Google's handling of 302's has frequently changed over the years, but the bottom line is that the only reliable way to change your web address is to use a 301 redirect. From their article Best Practices When Moving Your Site [googlewebmastercentral.blogspot.com]:

Then use a 301 Redirect to permanently redirect those pages on your old site to your new site. This tells Google and other search engines that your site has permanently moved.

...the bottom line is that the only reliable way to change your web address is to use a 301 redirect...

That's not even reliable any more. See Above.

And the bottom line is it is absolutely *not* going to cause a site to be deindexed since they use a 302 rather than a 301, especially since the site was previously indexed via the 302, so everyone stating "Oh, you absolutely must change it...", is not even beginning to help solve the issue, they're just adding more confusion with nonsense.

The 302 just won't do the job, and until you fix this you're liable to continue to have ranking issues.

That is *absolute* BS, Period!

---

The redirect was in place.
The redirect was understood.
The site was indexed and ranking.
The redirect is still in place.
The site is mostly deindexed and not ranking.
The redirect status code is not the *bleeping* issue.

Let's think logically for about half a second -- With Google you can:

Use a rel=canonical on page to canonicalize.
OR
Set the canonical in the server header on a per page basis.
OR
Set the preferred version of the domain in WMT.
OR
Include the canonical but not the non-canonical URL in an XML Sitemap.
OR
Use a 301 redirect.

And they'll get it...

BUT

If you use a 302 redirect to canonicalize Google will recognize and use it at first, then one day not be able to figure out what's going on when the www is redirected to non-www with a 302, so they're going to almost completely deindex the site around 6 weeks after the redirect was put in place and recognized, because the algo just can't handle a 302 redirect from www to non-www anymore, so it's best to just dump almost the entire site from the index, including the home page, since the site used a 302 redirect, rather than a 301 or other alternative method above for canonicalization.

Are you kidding me?

I'd start by trying:

Fetch as Googlebot in WMT.

This is good advice, but...

Sometimes - and I don't understand how it can be - fetch as googlebot gets it wrong (wort of).

I had a 301 redirect in a php file and apparently I messed up the syntax ever so slightly.

When I looked at my analytics data, it said that the new (redirected) page was down about 35% of traffic.

I used the fetch as googlebot - and about four other header checkers - and it said that the 301 redirect was fine.

But I knew something was wrong because traffic was so far down.

So I checked the redirect out using Firefox, opera, chrome, dolphin mini browser... everything worked fine.

Then I tried using IE8...

Winner, Winner, Chicken Dinner!

IE8 Choked on that page like a chump.

Turns out I had an ever-so-slight syntax error in my php 301 redirect, and I lost all of my internet explorer users.

So, the lesson here is, sometimes fetch as googlebot gets it wrong.

Sometimes - and I don't understand how it can be - fetch as googlebot gets it wrong (wort of).

Thanks for sharing -- That's good to know.

Most of what I was thinking was to see if Googlebot could follow the redirect, get the correct content and making sure there wasn't some goofy firewall block by the host -- One "odd" thing that could also possibly do it is the Internet Outages [webmasterworld.com...] keeping Googlebot from access to the site, but not alika's or everyone's, which would make it look like the site disappeared from Google's end.