As part of our efforts to make search results more useful to our users around the world, we’re announcing the international availability of rich snippets. If you’ve been following our blog posts, you already know that rich snippets let users see additional facts and data from your site in search results.

For example, we recently launched rich snippets for recipes which, for certain sites, lets users see quick recipe facts as part of the snippet and makes it easier to determine if the page has what they are looking for:

We’ve had a lot of questions on our blogs and forums about international support for rich snippets – and we know that many of you have already started marking up your content – so today’s announcement is very exciting for us.

In addition to adding support for rich snippets in any language, we have published documentation on how to mark up your sites for rich snippets in the following languages: simplified Chinese, traditional Chinese, Czech, Dutch, English, French, German, Hungarian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, and Turkish. (You can change the Help language by scrolling to the bottom of the help page and selecting the language you want from the drop-down menu.)

We encourage you to read the documentation to take advantage of the different types of rich snippets currently supported: people profiles, reviews, videos, events and recipes. You can also use our testing tool (in English only, but useful to test markup in any language) and start validating your markup to make sure results show as you would expect.

Finally and as you’ve probably heard by now (several times), we’re taking a gradual approach to surface rich snippets. This means that marking up your site doesn’t guarantee that we’ll show rich snippets for your pages. We’re doing this to ensure a good experience for our users; but rest assured we’re working hard to expand coverage and include more web pages.

Written by Kavi Goel, Pravir Gupta, and Yu Watanabe

I took a look around the web for a jQuery plugin for google gears as i would like to initialise gears on user input, and not as the web page loads, but could not find one anywhere.

So i have written the following plugin, based on googles own gears_init.js code which inits gears on page load.

/*
 * jQuery Gears Init by Darren Horrocks
 *
 * jQuery Plugin to init google gears at any point during a page
 *
 * code based on gears_init.js from http://code.google.com/apis/gears/gears_init.js
 *
 */
(function() {
  jQuery.initGears = function() {
    // We are already defined. Hooray!
    if (window.google && google.gears) {
      return;
    }

    var factory = null;

    // Firefox
    if (typeof GearsFactory != 'undefined') {
      factory = new GearsFactory();
    } else {
      // IE
      try {
        factory = new ActiveXObject('Gears.Factory');
        // privateSetGlobalObject is only required and supported on IE Mobile on
        // WinCE.
        if (factory.getBuildInfo().indexOf('ie_mobile') != -1) {
          factory.privateSetGlobalObject(this);
        }
      } catch (e) {
        // Safari
        if ((typeof navigator.mimeTypes != 'undefined') && navigator.mimeTypes["application/x-googlegears"]) {
          factory = document.createElement("object");
          factory.style.display = "none";
          factory.width = 0;
          factory.height = 0;
          factory.type = "application/x-googlegears";
          document.documentElement.appendChild(factory);
        }
      }
    }

    // *Do not* define any objects if Gears is not installed. This mimics the
    // behavior of Gears defining the objects in the future.
    if (!factory) {
      return;
    }

    // Now set up the objects, being careful not to overwrite anything.
    if (!window.google) {
      google = {};
    }

    if (!google.gears) {
      google.gears = {factory: factory};
    }
  };
})();

You can now initialise gears using the the jQuery class or the dollar shortcut.

jQuery.initGears();

$.initGears();

That is the question we hear often. Onward to the answers! Historically, it’s common for URLs with a trailing slash to indicate a directory, and those without a trailing slash to denote a file:

http://example.com/foo/ (with trailing slash, conventionally a directory)
http://example.com/foo (without trailing slash, conventionally a file)

But they certainly don’t have to. Google treats each URL above separately (and equally) regardless of whether it’s a file or a directory, or it contains a trailing slash or it doesn’t contain a trailing slash.

Different content on / and no-/ URLs okay for Google, often less ideal for users

From a technical, search engine standpoint, it’s certainly permissible for these two URL versions to contain different content. Your users, however, may find this configuration horribly confusing — just imagine if www.google.com/webmasters and www.google.com/webmasters/ produced two separate experiences.

For this reason, trailing slash and non-trailing slash URLs often serve the same content. The most common case is when a site is configured with a directory structure:
http://example.com/parent-directory/child-directory/

Your site’s configuration and your options

You can do a quick check on your site to see if the URLs:

1. http://<your-domain-here>/<some-directory-here>/
   (with trailing slash)
2. http://<your-domain-here>/<some-directory-here>
   (no trailing slash)

don’t both return a 200 response code, but that one version redirects to the other.

• If only one version can be returned (i.e., the other redirects to it), that’s great! This behavior is beneficial because it reduces duplicate content. In the particular case of redirects to trailing slash URLs, our search results will likely show the version of the URL with the 200 response code (most often the trailing slash URL) — regardless of whether the redirect was a 301 or 302.
• If both slash and non-trailing-slash versions contain the same content and each returns 200, you can:
  • Consider changing this behavior (more info below) to reduce duplicate content and improve crawl efficiency.
  • Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay.
  • Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and can’t be redirected even if you’re Chuck Norris.

Steps for serving only one URL version

What if your site serves duplicate content on these two URLs:

http://<your-domain-here>/<some-directory-here>/
http://<your-domain-here>/<some-directory-here>

meaning that both URLs return 200 (neither has a redirect or contains rel=”canonical”), and you want to change the situation?

1. Choose one URL as the preferred version. If your site has a directory structure, it’s more conventional to use a trailing slash with your directory URLs (e.g., example.com/directory/ rather than example.com/directory), but you’re free to choose whichever you like.
2. Be consistent with the preferred version. Use it in your internal links. If you have a Sitemap, include the preferred version (and don’t include the duplicate URL).
3. Use a 301 redirect from the duplicate to the preferred version. If that’s not possible, rel=”canonical” is a strong option. rel=”canonical” works similarly to a 301 for Google’s indexing purposes, and other major search engines as well.
4. Test your 301 configuration through Fetch as Googlebot in Webmaster Tools. Make sure your URLs:
   http://example.com/foo/
   http://example.com/foo
   are behaving as expected. The preferred version should return 200. The duplicate URL should 301 to the preferred URL.
5. Check for Crawl errors in Webmaster Tools, and, if possible, your webserver logs as a sanity check that the 301s are implemented.
6. Profit! (just kidding) But you can bask in the sunshine of your efficient server configuration, warmed by the knowledge that your site is better optimized.

Written by Maile Ohye, Developer Programs Tech Lead

The single best way to make Google aware of all your videos on your website is to create and maintain a Video Sitemap. Video Sitemaps provide Google with essential information about your videos, including the URLs for the pages where the videos can be found, the titles of the videos, keywords, thumbnail images, durations, and other information. The Sitemap also allows you to define the period of time for which each video will be available. This is particularly useful for content that has explicit viewing windows, so that we can remove the content from our index when it expires.

Once your Sitemap is created, you can can submit the URL of the Sitemap file in Google Webmaster Tools or through your robots.txt file.

Once we have indexed a video, it may appear in our web search results in what we call a Video Onebox (a cluster of videos related to the queried topic) and in our video search property, Google Videos. A video result is immediately recognizable by its thumbnail, duration, and a description.

As an example, this is what a video result from CNN.com looks like on Google:

We encourage those of you with videos to submit Video Sitemaps and to keep them updated with your new content. Please also visit our recently updated Video Sitemap Help Center, and utilize our Sitemap Help Forum. If you’ve submitted a Video Sitemap file via Webmaster Tools and want to share your experiences or problems, you can do so here.

Posted by Nelson Lee, Product Manager Video Search

As you know, the close, maximize and minimize buttons belong on the right hand side of the window title bar. For some reason in recent history, ubuntu decided to move them to the left hand side to be more inline with Mac OSX windows. Considering ubuntu is supposed to be an operating system aimed at luring people away from windows, this is a bad choice.

There is however a very simple way of moving these buttons back to the right hand side where they belong.

You first need to open up a terminal window “Applications > Accessories > Terminal” and type the following command:

sudo gconf-editor

This will load the gnome configuration editor. You will then need to navigate to “apps > metacity > general” in gconf-editor and find the “button_layout” setting.

Once you have found this, you need to change it from what it currently reads to:

close,minimize,maximize:

Once you have done this, you will see that the window buttons go back to where they belong and all is well with the world again.

We all know uploading things via ftp like Squirrel Mail or phpMyAdmin, or any application that has 100′s of small files takes a long time. This is mainly due to the overhead in the commands that have to be preformed to upload each file individually.

The first thing we need to do is to package all of our files into a single large file, this will allow us to massively reduce overhead, since there is only ever one send file command sent. How we do this, is simply add all the files (and the root directory if required) into a zip, so that when they are extracted to the directory on the server, they will appear on the server correctly.

Once we have zipped all of our files up, how do we then expect to be able to unzip them? We need a small bootstrap script (example below) to extract them to the server, which yes, is a second file that is small, but beats having to upload those over few 100 files.

$zip = new ZipArchive();
$r = $zip->open("myzip.zip");
if($r == TRUE) {
  $zip->extractTo("./");
}
$zip->close();

If you now upload and run your bootstrap script, you will notice (if you have the zip extension loaded in PHP) that your zip file has been extracted on the server, and was done a vast amount quicker than it would have taken to upload the individual files.

$package = "myadmin.zip";

$c = file_get_contents($package);

$content = base64_encode($c);
$bcontent = "";

for($i=0; $i<strlen($content); $i+=1024) {
  $c = substr($content, $i, 1024);
  $bcontent .= "\$content .= \"{$c}\";\r\n";
}

$f = fopen("installer.php", "w+");
if($f) {
  fwrite($f, "<?php\r\n");
  fwrite($f, "\$content = \"\";\r\n");
  fwrite($f, $bcontent);
  fwrite($f, "file_put_contents('{$package}', base64_decode(\$content));\r\n");
  fwrite($f, "\$zip = new ZipArchive();\r\n");
  fwrite($f, "\$zip->open('{$package}');\r\n");
  fwrite($f, "\$zip->extractTo('./');\r\n");
  fwrite($f, "\$zip->close();\r\n");
  fwrite($f, "?" . ">");
  fclose($f);
}

We’ve got good news for site owners who are frequent users of the Top search queries feature in Webmaster Tools: we’re now providing more detailed data for each individual search query. We previously just reported the average position at which your site’s pages appeared in the search results for a particular query. Now you can click on a given search query in the Top search queries report to see a breakdown of the number of impressions and the amount of clickthrough for each position that your site’s pages appeared at in the search results associated with that query. Impressions are the number of times that your site’s pages appeared in the search results for the query. Clickthrough is the number of times searchers clicked on that query’s search results to visit a page from your site. In addition to impressions and clickthrough numbers, you’ll also see a list of your site’s pages that were linked to from the search results for that search query. As we went about increasing the amount of data available, we also implemented measures to increase the detail of the data overall.

It used to be that you could only see Top search queries data for your site’s top 100 queries. We’ve significantly increased the number of queries we show. Now if your site ranks for more than 100 queries, you’ll see new pagination buttons at the bottom of the Top Search Queries table allowing you to page through a much larger sampling of the queries that return your site in search results.

Previously, if you wanted to visualize your Top search queries data you could download your site’s data and generate your own charts. To save you some time and effort, we’re now generating a chart for you, and displaying it right within the page.

The Top search queries chart includes a date range selector similar to what Google Analytics offers. So now if you really want to see what your site’s top search queries were for a particular week in the past, you can see the data for just that slice in time.

Finally, for sites that have numerous keywords that change frequently, we’ve added the ability to search through your site’s top search queries so that you can filter the data to exactly what you’re looking for in your query haystack.

We hope you enjoy these updates to the Top search queries feature and that it’s even more useful for understanding how your site appears and performs in our search results. If you’ve got feedback or questions about the new Top search queries, please share your thoughts in our Webmaster Help Forum.

Written by Jonathan Simon, Webmaster Trends Analyst

Anticipating the start of the season of barbecues and potlucks, we’ve added recipes as our newest rich snippets format. This means that for certain sites with recipe content, Google users will see quick facts when these recipe pages show up as part of the search results.

For example, if you were searching for an easy to make thai mango salad, you can now see user ratings, preparation time, and a picture of the dish directly in search result snippets.

Recipes is the fifth format we support, following the introduction of reviews, people, video and, most recently, events.

If you have recipe content on your site, you can get started now by marking up your recipes with microdata, RDFa, or the hRecipe microformat. To learn more, read our documentation on how to mark up recipe information or our general help articles on rich snippets for a more complete overview.

Please remember that to ensure a great user experience we’re taking a gradual approach to surface rich snippets. This means that we can’t guarantee that marking up your site will result in a rich snippet when your page shows up on our search results. However, we encourage you to get started, and once you’re done you can test your pages with our rich snippets testing tool.

Written by Jun Gong, Kosuke Suzuki, and Yu Watanabe

We’ve been hearing this question for many years from webmasters. That’s why we built features such as the Safe Browsing API, the malware review form, and our Malware details Labs feature.

As of today, once we notice your site is infected, we’ll do our best to send an e-mail to the address you have associated with your account in Webmaster Tools. We believe malware is such an important issue for site owners that being quickly informed is beneficial to you and your website’s visitors.

In addition, we’ve promoted our Malware details feature out of Labs and placed it under Diagnostics. The malware data is now updated four times faster than before, we’ve updated our algorithms for identifying injected content, and we’re now able to identify exploits which we were unable to catch earlier.

We hope this allows you to stay up-to-date with any malware issues we detect on your site, and to fix them quickly.

As always, please let us know if you have any feedback or questions about how to fix malware-related issues in our Webmaster Help Forum.

Posted by Sagar Kamdar, Product Manager, Webmaster Tools Team

You may have heard that here at Google we’re obsessed with speed, in our products and on the web. As part of that effort, today we’re including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.

Speeding up websites is important — not just to site owners, but to all Internet users. Faster sites create happy users and we’ve seen in our internal studies that when a site responds slowly, visitors spend less time there. But faster sites don’t just improve user experience; recent data shows that improving site speed also reduces operating costs. Like us, our users place a lot of value in speed — that’s why we’ve decided to take site speed into account in our search rankings. We use a variety of sources to determine the speed of a site relative to other sites.

If you are a site owner, webmaster or a web author, here are some free tools that you can use to evaluate the speed of your site:

• Page Speed, an open source Firefox/Firebug add-on that evaluates the performance of web pages and gives suggestions for improvement.
• YSlow, a free tool from Yahoo! that suggests ways to improve website speed.
• WebPagetest shows a waterfall view of your pages’ load performance plus an optimization checklist.
• In Webmaster Tools, Labs > Site Performance shows the speed of your website as experienced by users around the world as in the chart below. We’ve also blogged about site performance.

• Many other tools on code.google.com/speed.

While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation and the signal for site speed only applies for visitors searching in English on Google.com at this point. We launched this change a few weeks back after rigorous testing. If you haven’t seen much change to your site rankings, then this site speed change possibly did not impact your site.

We encourage you to start looking at your site’s speed (the tools above provide a great starting point) — not only to improve your ranking in search engines, but also to improve everyone’s experience on the Internet.

Posted by Amit Singhal, Google Fellow and Matt Cutts, Principal Engineer, Google Search Quality Team