| 10:42 am on Oct 2, 2006 (gmt 0)|
An engineer was tinkering with gfe-jc, 64.233.187.*, I think, just a few months ago.
Matt Cutts briefly mentioned it on his blog. I haven't seen that other one mentioned though.
Maybe soneone else is experimenting now?
| 3:25 pm on Oct 2, 2006 (gmt 0)|
|does anyone know if 188.8.131.52 is being used as a test server? |
This one's showing everything but the first 3 results as supplemental for me, whether its one of my own domains, a client's, cnn, target, imdb - everything.
| 10:35 pm on Oct 2, 2006 (gmt 0)|
yeah... checking the serps for this datacenter, it looks remarkably like it came from Yahoo! about 6 months ago!
| 8:19 am on Oct 3, 2006 (gmt 0)|
"184.108.40.206 is showing everything but the first 3 results as supplemental for me"
same here :'(
| 1:45 pm on Oct 3, 2006 (gmt 0)|
I see at the moment only few pages are listed when try site: operator on these 2 DCs.
Would you be kind to try site: and tell us what you see.
| 1:55 pm on Oct 3, 2006 (gmt 0)|
reseller, I see more pages listed for my site on those two locations than I ever have for my site.
| 1:56 pm on Oct 3, 2006 (gmt 0)|
site: return index page and two other pages. This is the same for all my websites
| 2:13 pm on Oct 3, 2006 (gmt 0)|
Mine are showing same as on other dc's. But then again, google has had mine statically messed up for a while now.
| 4:44 pm on Oct 3, 2006 (gmt 0)|
Thanks for feedback.
But there must be something wrong with those two DCs. Maybe that famous Google youngster engineer start his day today by his popular process:
Leaving some sites to show only few pages for site: operator
Anybody knows the name and physical address of that youngster engineer :-)
| 5:22 pm on Oct 3, 2006 (gmt 0)|
It seems the strange "shrinked" results of site: operator
have propagated to few other DCs. So now we have:
Does any of you have a qualified suggestion for whats going on?
| 5:49 pm on Oct 3, 2006 (gmt 0)|
What does this mean?
I get 2 pages, 3 good ones and the rest are supplemental.
| 6:04 pm on Oct 3, 2006 (gmt 0)|
Don't forget that one C-block is typically all ONE datacentre, so 66.102.7.x should all be the same as each other for all valid values of x (that's: 17, 18, 19, 44, 80, 81, 83, 84, 91, 93, 95, 98*, 99, 100, 101, 102, 103, 104, 105*, 106*, 107, 115, 133, 147, 184, 189, 210* and 214. (those with a * seem to be no longer accessible).).
| 6:28 pm on Oct 3, 2006 (gmt 0)|
reseller i can see the same weird results on thos datacenters. lots of supplementals.
| 6:57 pm on Oct 3, 2006 (gmt 0)|
my only comment is that i've been banned to 5th place on all the serps.
could be worse, could be better
| 9:01 pm on Oct 3, 2006 (gmt 0)|
Good evening Folks
Here is a late evenings analysis :-)
For those of us who see sites "shrink" when apply site: operator, there are two possibilities:
- The site: operator is broken on those DCs I mentioned. Which is very good news.
- There is an algo update underway and the said sites have been hit by the new algos and accordingly big part of their content is deindexed. Which is a very bad news.
Which possibility do you prefer ;-)
| 9:07 pm on Oct 3, 2006 (gmt 0)|
I think it's a glitch with the DC; every single site I can think of to put in there with a site: command returns the same thing - three results and the rest are supplemental.
| 9:13 pm on Oct 3, 2006 (gmt 0)|
Updating the "affected DCs"
| 9:17 pm on Oct 3, 2006 (gmt 0)|
|I think it's a glitch with the DC |
Yes, and I think that it applies to a couple of other DCs as well. Even more interesting, it sometimes says something like this:
"Results 1 - 2 of 0 ..." Yes, it says "0" But when you click for the omitted results, you get the count, this time with 3 results:
"Results 1 - 3 of n..."
| 9:18 pm on Oct 3, 2006 (gmt 0)|
| 9:42 pm on Oct 3, 2006 (gmt 0)|
| 9:45 pm on Oct 3, 2006 (gmt 0)|
|Yesterday, some of those URLs are back in the index when you search for the "removed" word. The "removed" word shows in the snippet too. The "removed" word is NOT on the real site, and has not been there for about two years. |
g1smd - I'm seeing something similar to what you're seeing, but not nearly as far back. But I'm definitely seeing older versions of pages appearing in place of versions that have since been cached... and the other day the cache links on one site that I've been updating and thus watching closely showed that the cache wasn't available. I've also had a home page on this site disappear completely from the index (and I do mean completely) and then reappear a day later.
In the past, when Google has reverted to old data, they were testing a new algo against an old one. The old data in this case, though, doesn't seem to be widespread enough to suggest that's what's happening, and not all that many of my rankings are changing. A few are, but most don't seem to be moving much.
One other curiosity... the reversion from new data to old data on one of the sites I mention appeared to happen in an order related to query difficult... happened first for a single word search, and little by little replaced the old data for all queries. Don't depend on this last observation... it was just a late night observation and I was too tired to rigorously follow it up... but that is what seemed to be going on.
| 9:47 pm on Oct 3, 2006 (gmt 0)|
if you look more carefully you will notice that all of those above DC's are the ones that PR has been updated ,therefore they have the new infrastructure as MC said "and I believe every data center that has that newer infrastructure has the recent snapshot of PageRank now. "
| 10:38 pm on Oct 3, 2006 (gmt 0)|
On the sites I am checking are still getting two different sets of PR on the IPs reseller listed.
| 11:17 pm on Oct 3, 2006 (gmt 0)|
[220.127.116.11...] is showing the correct number of pages for one of my sites if I do a site:domain.com search. I only bring it up because it's been a long time since I've seen the right number. When I click on the last page of results the number is still correct. Amazing.
| 11:20 pm on Oct 3, 2006 (gmt 0)|
Robert: if the results you see have fairly recent cache dates (~1 to ~9 months old) then those are normal "historical supplemental" results: where Google has a recent snapshot of a page in the normal index, and another much older snapshot of the same page at the same URL in the Supplemental database. You only see that one when you search for words that were on the old page and that are NOT on the new page.
These that I can currently see are not tagged as Supplemental now, and had been out of the index for THIS search for more than a year. They were Supplemental from two years ago until one year ago, before being deindexed a year ago - and now they are back. I see two in one search, and one more in another unrelated search.
[edited by: tedster at 11:30 pm (utc) on Oct. 3, 2006]
[edited by: g1smd at 11:32 pm (utc) on Oct. 3, 2006]
| 11:31 pm on Oct 3, 2006 (gmt 0)|
The Link:command shows a roll back in all of those data centres to what the links total was previously.
The first two data centres show improved results but the other eight i believe are what we are currently seeing from most other data centres currently.
Only time will tell but on the face of it, i dont think this update is concluded, looks like a lot of data is still not updated
| 12:40 am on Oct 4, 2006 (gmt 0)|
|Robert: if the results you see have fairly recent cache dates (~1 to ~9 months old) then those are normal "historical supplemental" results: where Google has a recent snapshot of a page in the normal index, and another much older snapshot of the same page at the same URL in the Supplemental database. You only see that one when you search for words that were on the old page and that are NOT on the new page. |
g1smd - Thanks. I understand the distinction you're making.
In my example, the cache is ~1 month old, and the searches don't involve words not on the new page. They're all the core terms the page ranks on, including the company name. What the examples might have in common, I feel, is that, for whatever reason, Google may (in some cases) be using old data.
In my case, I've been updating an existing site gradually, prior to launching a new version, and I've been observing effects of various changes along the way because it might give me some insights into the algo.
So, on the home page, I added new body copy... let it get indexed and ranked... and then I added a new title. Just as I was seeing the new title creep into the index and affect the rankings, the pages started reverting to the previous cache (with the new body text, but with the old title), with other glitches too as I'd described.
It appeared Google might be rolling back the data... something that they sometimes do when comparing old and new algos... but I don't see this on other sites I monitor, so I'm fishing for an explanation. I thought it might relate to what you're seeing, even if the particulars are way different, and perhaps shed some light on what's going on.
| 12:49 am on Oct 4, 2006 (gmt 0)|
I notice that google is in a number of cases showing serps from its own old cashed data rather than from the site concerned
For example, one of our sites had some old dynamic pages on it lets call them /widget/123/blue/23.asp linking from the index page.
The links on the site have been removed and static pages /widget-blue.html installed which are much better for the end user and contain up to date information.
Prior to the update, the newer statics were ranking fine in google, since the update the old dynamic pages that dont link from anywhere on the site now rank in the serps in their place - i just dont get this at all?
Its like google is not looking at sites as they are now, but looking at page history and ranking older pages within a site above more relevent newer pages in the same site
| 8:40 am on Oct 4, 2006 (gmt 0)|
Well I hope this update is not done, because I think it looks quite messy at the moment.
| This 175 message thread spans 6 pages: 175 (  2 3 4 5 6 ) > > |