I have one 4+ years old domain too. Very stable IBL's, from very old websites. It has 500 pages indexed. G sucks.
This is very strange indeed. I have around 500 pages (588) indexed as well. I think the biggest and older high PR sites are growing like crazy right now at the expense of the smaller guys, like me! Are the rich just getting richer?
the only site I have not seen effected is a 8 year 8 month old site with 16 pages. All pages are still indexed and amazingly enough every single page ranks (top5) with lots of double results for its given keyword(s). All static HTML pages with a completely flat directory structure with every page inter linking to each other through graphic links. No keyword text links to any of the pages. Site wide PR3. Just one outbound link, no others. Content is 100% unique. Also the HTML code isn't the greatest either. PM me if you want the URL to take a look.
Expertu whats the PR of your 500 club-page site and how many pages were indexed prior to getting slammed? Mine was sitting at 151K PR4.
Both websites are PR5. One is 2 years old. The other one is about 3-4 years old. Both had aprox. 15.000 pages.
Today the site I work for has different index numbers depending on the data center. Some say ~800, some say ~900, some say ~9k and still more say ~14k. Something is definately messed up..lol. That's a pretty large discrepancy when there are over 30k pages.
Your website's PR is a direct result of your inbound link's PR. That's it. No domain age involved here.
I have sites now also with the problems minstrel commented on. I have july-august 2005 links showing in the site: command for pages no longer even in existance (and were only in existance for a few days because of a typo in my mod_rewrite). Amazing...
So .. have a look at this people. Those 130.000 pages were a DMOZ clone. Those pages are gone for a year now. Not one month. A YEAR. WTF ?
This problem predates BigDaddy. Regardless, Google will save the url if it is a 302 and follow it again. After all, you control the server header codes for your site and you are telling them it is only a temporary error page, not a permanent one. For your errored out pages, this means that they will cache the content of error.php again and again under the now non-existent url, resulting in a duplicate content penalty, which is exactly how your site appears when searching it out. It has always been my contention that Google should only follow or save 302 header producing pages if they are on the same site. They get to keep the 302 (for whatever reason), and any outside influence (from other domains) is killed. 302 hijacking your own error pages. Because of the high amount (a relative term) of duplicate pages (302 -> error.php) it does not wish to show all your pages. But since these other pages are spot on, relevant, etc. they will show them in the results for most searches. Until this has changed, minstrel, there is nothing more I can tell you. Unfortunately, you are the only one who has showed me a url that is for certain suffering these effects that I can search out. My own was cured early on (hyphenation), and I do suspect that insite 302 redirects of one type or another will explain many webmaster problems left. If you cannot change your pages to output a 404 directly, you can change them to 301 to a 404 and it should still solve the problem... ( For MarkHutch ) Every call to a script does not always produce different results. If the cache is still the same as the page visited, the proxy cache server does not get updated (304) until it is considered old and re-cached. This can take a long time if you do not have at least some random material. The page is seen as static - the same every visit. Google does not have your database, your script running on their system. They could care less (and should) if your page is .html, .shtml, .cgi, .php - they can all be rewritten, parsed etc. to produce the same effect. Look at the source of most php pages - what is machine readable is there. If that doesn't change, it is considered the same page, and produces a 304 - from the proxy cache servers.