| 10:46 am on Jul 7, 2006 (gmt 0)|
The 126.96.36.199 went back to showing a number of sites top on a site:domain.com check again. (Not all effected by June 27th Bug)
And with a newer homepage cache for you on the 72s DCs.
| 10:50 am on Jul 7, 2006 (gmt 0)|
yep cheers I noticed that 1/7 - is this a sign LOL
| 10:52 am on Jul 7, 2006 (gmt 0)|
But 5/7 on the 72 dcs.
There is something about the 72s perhaps.
| 10:55 am on Jul 7, 2006 (gmt 0)|
we can live and hope as we've all been out in the cold for too long
| 11:57 am on Jul 7, 2006 (gmt 0)|
I notice that on 3 of the 72's - 188.8.131.52, 184.108.40.206 and 220.127.116.11, my site is at the top for the site:www.domain.com command. However, my rankings are not the same as pre June 27th - with the exception of one keyword I've checked, they're worse.
The only DC where my rankings remain unchanged is
Do your sites agree with this pattern, or are your rankings actually fully restored on the 72's?
| 12:28 pm on Jul 7, 2006 (gmt 0)|
My ranking are worse on all 72's - 18.104.22.168, 22.214.171.124 and 126.96.36.199
An Yes my site is at the top for the site:www.domain.com command as well.
My rankings also remain unchanged on
I have the same pattern and latest cache is from July 3
| 12:33 pm on Jul 7, 2006 (gmt 0)|
I still cant believe way those sites how got hurt by the 302 problem, still dont rank.
| 1:19 pm on Jul 7, 2006 (gmt 0)|
I am hopeful that 188.8.131.52 features new results that will stick rather than old results. Why? Because in the health sector it features something new that isn't seen on the other datacenters yet. The "refine results for cancer" thing.
| 2:24 pm on Jul 7, 2006 (gmt 0)|
My rankings are better for plural keywords and worse for singular keywords on 184.108.40.206.
But it is way better results then what Google is showing now.
| 3:02 pm on Jul 7, 2006 (gmt 0)|
this "refine results" thing is something I only noticed in the last week - is it new? It's very interesting, and I like it as I'm in some of the refined results but a long way down the list in the unrefined results
| 3:16 pm on Jul 7, 2006 (gmt 0)|
For me ...
Are providing a real ray of hope today, both the site:mysite.com and site:www.mysite.com are showing properly and I'm back on the first page for my best search term, in the 9 position instead of the 3 but much better than the 80 position I was in after the 27th changes.
Proper listings on site:www.mystore.com but not site:mystore.com, and listings improved only slightly, not indicative of a real fix.
Does everyone see the corrected 72's as a good sign just the same?
| 3:27 pm on Jul 7, 2006 (gmt 0)|
The 72 DC are not accurate for me. Both site: commands shows all suplimental as well as pages that I have NEVER had... I sell furniture and it shows a bunch of ringtone pages. Yikes!
| 5:53 pm on Jul 7, 2006 (gmt 0)|
Well. Here it is. The much anticipated response from Matt Cutts to all of the people concerned about the changes of the 27th June.
Ready? Here goes...
|I believe any changes on the 27th were refreshing data used by an existing algorithm. |
I guess they switched on an experimental buggy filter by mistake then? Hopefully in another six months or so they might accidentally switch it off again.
Anyway. Nice to know that they are working away feverishly behind the scenes investigating the cause of the problem.
| 6:08 pm on Jul 7, 2006 (gmt 0)|
ClintFC, you found it on his blog?
Anything more from him? (I took a quick look there, didn't see it)
| 6:21 pm on Jul 7, 2006 (gmt 0)|
Yep it is on his blog. And that is about all he said. Nothing more nothing less.
| 6:23 pm on Jul 7, 2006 (gmt 0)|
It's in a comment in his "Reminder: check your sites" blog.
| 6:46 pm on Jul 7, 2006 (gmt 0)|
thats it! oh I feel so much better now!
| 6:55 pm on Jul 7, 2006 (gmt 0)|
Could you'all please enlighten me as to what Matt Cutts' statement might mean.
If it was simply refreshing an existing algorithm then why would sites doing well before suddenly dissappear in the rankings?
Could they have accidently implemented an old algorithm from a few years ago?
Would love your take on what Matt said.
| 6:56 pm on Jul 7, 2006 (gmt 0)|
Somebody tell me whether I should freak out or not.
| 6:58 pm on Jul 7, 2006 (gmt 0)|
my view point like most of things he says means nothing - prior to 27th my site had been ranking well all year, so how far back was this rollback
| 7:10 pm on Jul 7, 2006 (gmt 0)|
|so how far back was this rollback |
My main site is stable since April 1997. Never a problem with search results...
...until June 27
| 7:14 pm on Jul 7, 2006 (gmt 0)|
cheers jetteroheller now I understand why my site vanished it only went live 2004
| 7:17 pm on Jul 7, 2006 (gmt 0)|
hmmm...well he basically said the same thing about the Dec. 27 changes - calling it a "data refresh". So, perhaps every 12/27 and 7/27, we can expect this.
| 7:30 pm on Jul 7, 2006 (gmt 0)|
Anyone have a definition for "data refresh"?
| 7:37 pm on Jul 7, 2006 (gmt 0)|
Data Refresh \DA-ta RE-fresh\, adjective:
[edited by: hvacdirect at 7:38 pm (utc) on July 7, 2006]
| 7:37 pm on Jul 7, 2006 (gmt 0)|
What happened after the Dec. 27 changes? Did they go back to "normal" or have they remained that way until now?
| 7:42 pm on Jul 7, 2006 (gmt 0)|
So hvacdirect, are you saying "data refresh" in this instance means a glitch in an existing algorithm? Is that what Matt Cutts meant? Thanks
| 7:57 pm on Jul 7, 2006 (gmt 0)|
From observations, i would call a data refresh as far as google is concerned:
Occasionaly a "roll back" of serps to a previous date
Occasionaly pages added to inflate the index size
I would also say that this happens 2 different ways;
Once at the end of every business quarter(usually not noticed on all data centers) and sometimes a month later ( maybe when the previous data refresh propagates)
Thats speculation on my part, but I have 1 year of daily historical data that shows me every ranking i have on a hunderd or so keywords for 2 different domains and its almost like clockwork since December 27th with the data refreshes.
| 8:23 pm on Jul 7, 2006 (gmt 0)|
I am so not understanding why a site: search that should exclude www pages returns thousands of www pages that are Supplemental Results.
I see this effect for most sites for several months now.
which shows normal www pages that are not Supplemental.
I asked Matt Cutts to comment on this, and the comment was deleted.
| 8:48 pm on Jul 7, 2006 (gmt 0)|
What gets me is what g1smd has stated.
What really gets me also is that we do a redirect from non-www to www and under the site command without the www shows results that have www which is the exact same as with the www. They are all non supplemental and it appears like it is the exact same dataset.
Now on some other sites I have checked having the redirect the opposite (www to no-www) the site: command shows two different sets. Searching with www will usually show supplementals with www and searchin without www will show correct non www results. Europeforvisitors site is a good example of this.
Now I have seen other sites who do the non www to www versions that are acting the same way as us and they are having problems just the same but I haven't looked at enough to make a judgement.
What I would like to know...Which is correct? Could there be problems here we should know about?
Keep in mind that doing a site command for www and non www versions of webmasterworld.com acts in a similar manner as us but they seem fine.
[edited by: arubicus at 8:58 pm (utc) on July 7, 2006]
| 8:49 pm on Jul 7, 2006 (gmt 0)|
So did MC's check your sites blog refer to 6/27? Maybe he was just irritated by some emails he got, and reacted to that.
| This 179 message thread spans 6 pages: < < 179 ( 1  3 4 5 6 ) > > |