Google - Another Bad Data Push?

19 comments

Looks like Google has been having anther fun week with site operators not functioning properly.

Sometimes search operators fail entirely, and other times even authority websites appear to have been completely supplementalled.

For example, Threadwatch is now only showing a single index page for a normal site search: site:www.threadwatch.org - yet clicking through for more results is missing the condemnation of " - Supplmental Result".

Another possible "bad data push", perhaps?

Comments

FWIW

And Matt Cutts comment is..

Quote:
this is the same data refresh from June 27th and July 27th, just being refreshed again. We’ve been doing it for ~1.5 years at this point, and I’d continue to expect that we’ll just keep refreshing the data to that algorithm every several weeks or so.

http://www.mattcutts.com/blog/frickin-cold/
Matt Cutts Said,
August 17, 2006 @ 2:20 pm

what say ye, cornwall?

what say ye, cornwall? what's G tweaked?

Seeing Big fluxes up AND

Seeing Big fluxes up AND down this time. We're trying to pinpoint exactly what the change is this time.

less double listings

I'm seeing a lot less double listing on the serps I monitor.

Duplicate Content

I am willing to bet that if the ThreadWatch script generated a unique meta description per page that the Supplemental status would soon be rescinded.

Additionally, get rid of one of the two base tags in the head: there are currently two on each page.

Drupal and Google

Google Hates drupal ... i made my meta tags reflect the title and main keywords of an article and goog loves my durpal site now ;-)

Just to explain....

When Google shows just one entry in the site: search, it follows it up with:

"In order to show you the most relevant results, we have omitted some entries very similar to the 1 already displayed. If you like, you can repeat the search with the omitted results included."

Next, click on that link, and look at the results. What do you see that is similar?

Of course, it's the snippet: they are all the same.

That happens when either every meta description on the site is the same or there is no meta description and Google uses the first dozen or so words from the on-page content (which will be the same every time).

The fix is to supply a unique meta description on each page to feed the snippet data.

Just to chime in, I agree

Just to chime in, I agree that the site:threadwatch.org is because of the meta description tag; it's got nothing to do with any data push. When all the snippet results look the same, we often collapse them together and show the "click here to see all the duplicates" message that turns on "&filter=0" as a url parameter. For TW, I think it's happening because of the meta description always being the same, and as soon as TW drops the meta tag or makes them all different, we'd immediately show plenty of TW results again.

So in summary, the power to show up how Aaron/Dave want for site: is entirely in the power of TW, and they can change it at any time and as soon as we crawl/index the results, more results will show up. No data pushes involved at all. ;)

eh, or you could have just

eh, or you could have just have read what g1smd or hopeseekr wrote. ;)

Yup, meta for sure

I checked a couple of my sites and only one has a universal meta tag across the site and sure enough, it went completely supplemental.

Off to fix the meta problem.

HTML Code Improvement - analytics tracking code placement

While we're on the topic of html code clean-up, consider moving the Google Analytics code to the bottom of the page to avoid usability issues, i.e. long page loading times if, by chance, Google Analytics tracking servers aren't responsive.

I believe you also get more accurate page counts as only fully loaded pages will be counted.

The one open issue is if JS onEvent code is added to download links, such as PDFs – in this case Google's current analytics help says to put the code before these events. I assume the tracking will still work if the code is at the bottom of the page, its just that clicks by users before the JS code loads won't be tracked. I have a test of this on my to do list.... Shameless plug: Embedded JavaScript Page Tracking Code: Place at the top or bottom of the page?

Thanks for the

Thanks for the clarification, Matt - seems a bit of an agressive filter, but I guess better to know that not. :)

I'll ask someone if they can

I'll ask someone if they can change the default behavior for site: queries, but in the grand scheme of things (since it's expected behavior), it might take a while until something like that changes. In the mean time, just click the link to add the "&filter=0" parameter.

I like the way it works...

I like the way that the site search currently works: it is a very good signpost for several title tag and meta description problems.

Only webmasters use the site search anyway.

It makes sense to you and

It makes sense to you and me, g1smd. But no need for increased webmaster blood pressure if it's a smallish change..

Update: 2006-10-07

I'm not sure if Matt made any suggestions or not, but for more than the last week now...

Search: site:domain.com

Result: FUBAR

Webmaster blood-pressure: off the bleedin' scale.

... and then ...

... and then, as if by magic, it was fixed.

Heh..

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.