SEO News » Items by Maile Ohye

Items by Maile Ohye

More Options for Google+ Badges

Posted: January 26th, 2012, 2:53pm CET by Maile Ohye

Tags: products and services

Webmaster Level: All

Update on February 2, 2012: The new Google+ badge is now out of preview and available to all users on all sites.

When we launched Google+ pages in November, we also released Google+ badges to promote your Google+ presence right on your site. Starting today in developer preview (and soon available to all your users), we're adding more options for integrating the Google+ badge into your website. You can configure a badge with a width that fits your site design and choose a version that works better on darker sites. You'll also see that Google+ badges now include the unified +1 and circle count that we added to Pages last month.

If you’re still considering whether to add a Google+ badge on your website, consider this: We recently looked at top sites using the badge and found that, on average, the badge accounted for an additional 38% of followers. When you add the badge visitors to your website can discover your Google+ page and connect in a variety of ways: they can follow your Google+ page, +1 your site, share your site with their circles, see which of their friends have +1’d your site, and click through to visit your Google+ page.

The Google+ Badge makes it easy for your fans to find and follow you on Google+. With these additional options, we hope it's even easier to create a badge that fits your website.

Follow the conversation on Google+.

Posted by Lucy Hadden, Software Engineer, Google+

Making form-filling faster, easier and smarter

Posted: January 25th, 2012, 11:00am CET by Maile Ohye

Tags: products and services

Webmaster Level: Intermediate

One of the biggest bottlenecks on any conversion funnel is filling out an online form – shopping and registration flows all rely on forms as a crucial and demanding step in accomplishing the goals of your site. For many users, online forms mean repeatedly typing common information like our names and addresses on different sites across the web – a tedious task that causes many to give up and abandon the flow entirely.

Chrome’s Autofill and other form-filling providers help to break down this barrier by remembering common profile information and pre-populating the form with those values. Unfortunately, up to now it has been difficult for webmasters to ensure that Chrome and other form-filling providers can parse their form correctly. Some standards exist; but they put onerous burdens on the implementation of the website, so they’re not used much in practice.

Today we’re pleased to announce support in Chrome for an experimental new “autocomplete type” attribute for form fields that allows web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’. With this attribute, web developers can drive conversions on their sites by marking their forms for auto-completion without changing the user interface or the backend.

Just add an attribute to the input element, for example an email address field might look like:

<input type=”text” name=”field1” x-autocompletetype=”email” />

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Posted by Ilya Sherman, Software Engineer

Page layout algorithm improvement

Posted: January 19th, 2012, 4:00pm CET by Maile Ohye

Tags: Search results

Webmaster Level: All

In our ongoing effort to help you find more high-quality websites in search results, today we’re launching an algorithmic change that looks at the layout of a webpage and the amount of content you see on the page once you click on a result.

As we’ve mentioned previously, we’ve heard complaints from users that if they click on a result and it’s difficult to find the actual content, they aren’t happy with the experience. Rather than scrolling down the page past a slew of ads, users want to see content right away. So sites that don’t have much content “above-the-fold” can be affected by this change. If you click on a website and the part of the website you see first either doesn’t have a lot of visible content above-the-fold or dedicates a large fraction of the site’s initial screen real estate to ads, that’s not a very good user experience. Such sites may not rank as highly going forward.

We understand that placing ads above-the-fold is quite common for many websites; these ads often perform well and help publishers monetize online content. This algorithmic change does not affect sites who place ads above-the-fold to a normal degree, but affects sites that go much further to load the top of the page with ads to an excessive degree or that make it hard to find the actual original content on the page. This new algorithmic improvement tends to impact sites where there is only a small amount of visible content above-the-fold or relevant content is persistently pushed down by large blocks of ads.

This algorithmic change noticeably affects less than 1% of searches globally. That means that in less than one in 100 searches, a typical user might notice a reordering of results on the search page. If you believe that your website has been affected by the page layout algorithm change, consider how your web pages use the area above-the-fold and whether the content on the page is obscured or otherwise hard for users to discern quickly. You can use our Browser Size tool, among many others, to see how your website would look under different screen resolutions.

If you decide to update your page layout, the page layout algorithm will automatically reflect the changes as we re-crawl and process enough pages from your site to assess the changes. How long that takes will depend on several factors, including the number of pages on your site and how efficiently Googlebot can crawl the content. On a typical website, it can take several weeks for Googlebot to crawl and process enough pages to reflect layout changes on the site.

Overall, our advice for publishers continues to be to focus on delivering the best possible user experience on your websites and not to focus on specific algorithm tweaks. This change is just one of the over 500 improvements we expect to roll out to search this year. As always, please post your feedback and questions in our Webmaster Help forum.

Posted by Matt Cutts, Distinguished Engineer

Rich Snippets Instructional Videos

Posted: December 16th, 2011, 10:59am CET by Maile Ohye

Tags: intermediate

Webmaster level: All

When users come to Google, they have a pretty good idea of what they’re looking for, but they need help deciding which result might have the information that best suits their needs. So, the challenge for Google is to make it very clear to our users what content exists on a page in both a useful and concise manner. That’s why we have rich snippets.

Essentially, rich snippets provide you with the ability to help Google highlight aspects of your page. Whether your site contains information about products, recipes, events or apps, a few simple additions to your markup can result in more engagement with your content -- and potentially more traffic to your site.

To help you get started or fine tune your rich snippets, we’ve put together a series of tutorial videos for webmasters of all experience levels. These videos provide guidance as you mark up your site so that Google is better able to understand your content. We can use that content to power the rich snippets we display for your pages. Check out the videos below to get started:

For more information on how to use rich snippets markup for your site, visit our Help Center.

Posted by Alejandro Goyen, Product Manager

Grow your audience with Google+

Posted: November 7th, 2011, 11:40am CET by Maile Ohye

Tags: products and services

Webmaster Level: All

At Google, we help grow your audience by connecting you with new users. We introduced the +1 button so your site would stand out on search and your users could easily share your content on Google+. But, sometimes you want to join the conversation and post content directly to where people are sharing.

Today we’re introducing Google+ for Business, a collection of tools and products that help you grow your audience. At the core of this is Google+ Pages, your site’s identity on Google+.

Google+ Pages: Have real conversations with the right people
To get your site on Google+, you first need to create a Google+ Page. On your page, you can engage in conversations with your visitors, direct readers back to your site for the latest updates, send tailored messages to specific groups of people, and see how many +1’s you have across the web. Google+ Pages will help you build relationships with your users, encouraging them to spend more time engaging with your content.

Google+ Pages are at the heart of Google+ for Business
Hangouts
Sometimes you might want to chat with your users face-to-face. For example, if you run a food blog, you may want to invite a chef to talk about her favorite recipe, or if you manage a fashion review site, beauty specialists might want to hold how-to sessions with makeup tips. Hangouts make this easy, by letting you have high-quality video chats with nine people with a single click. You can use Hangouts to hold live forums, break news or simply get to know people better, all in real time.

Hangouts let you meet your customers, face-to-face
Circles
Circles allow you to group followers of your Page into smaller audiences. You can then share specific messages with specific groups. For example, you could create a Circle containing your most loyal readers and offer them exclusive content.
The Google+ badge: Grow your audience on Google+

To help your users find your page and start sharing, there are two buttons you can add to your site by visiting our Google+ badge configuration tool:

The Google+ icon, a small icon that directly links to your Page.
The Google+ badge, which we’re introducing in the coming days. This badge lets people add your page to their circles without leaving your site, and allows them to get updates from your site via Google+.

Extend the power of +1, stand out in Google search
You can also link your site to your Google+ page so that all your +1s -- from your Page, your website, and search results -- will get tallied together and appear as a single total. Potential visitors will be more likely to see the recommendations your site has received, whether they’re looking at a search result, your website, or your Page, meaning your +1’s will reach not only the 40 million users of Google+, but all the people who come to Google every day. You can link your site to your Page either using the Google+ badge or with a piece of code. To set this up, visit our Google+ badge configuration tool.

Bringing Google+ to the rest of Google
Our ultimate vision for Google+ is to transform the overall Google experience -- weaving identity and sharing into all of our products. Beginning today, we’re rolling out a new experimental feature to a small group of eligible publishers, Google+ Direct Connect -- an easy way for your audience to find your Google+ Page on Google search. If you’ve linked your Page to your site and you qualify, when someone searches for your website’s name with the ‘+’ sign before it Direct Connect will send them directly to your Page. For example, try searching for ‘+YouTube’ on Google. Users will also be prompted to automatically add Pages they find through Direct Connect to their circles.

Direct Connect suggestions start populating as you type on Google.com
Just the beginning
We want to help you get your site on Google+ as soon as possible, so we’re opening the field trial for Google+ Pages to everyone today. Creating a Google+ Page only takes a few minutes. To get started, you’ll need a personal Google+ profile. If you don’t have a Google account, it’s very quick and easy to join. And if you’re looking for inspiration, check out some of the sites that are already starting to set up their Pages:

To learn more about how Google+ works for your site, check out the Google+ Your Business site. We’re just getting started, and have many more features planned for the coming weeks and months. To keep up to date on the latest news and tips, add the Google+ Your Business page to your circles. If you have ideas on how we can improve Google+ for your site, we’d love to hear them.

Posted by Dennis Troper, Product Management Director, Google+ Pages

GET, POST, and safely surfacing more of the web

Posted: November 1st, 2011, 4:53pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Intermediate to Advanced

As the web evolves, Google’s crawling and indexing capabilities also need to progress. We improved our indexing of Flash, built a more robust infrastructure called Caffeine, and we even started crawling forms where it makes sense. Now, especially with the growing popularity of JavaScript and, with it, AJAX, we’re finding more web pages requiring POST requests -- either for the entire content of the page or because the pages are missing information and/or look completely broken without the resources returned from POST. For Google Search this is less than ideal, because when we’re not properly discovering and indexing content, searchers may not have access to the most comprehensive and relevant results.

We generally advise to use GET for fetching resources a page needs, and this is by far our preferred method of crawling. We’ve started experiments to rewrite POST requests to GET, and while this remains a valid strategy in some cases, often the contents returned by a web server for GET vs. POST are completely different. Additionally, there are legitimate reasons to use POST (e.g., you can attach more data to a POST request than a GET). So, while GET requests remain far more common, to surface more content on the web, Googlebot may now perform POST requests when we believe it’s safe and appropriate.

We take precautions to avoid performing any task on a site that could result in executing an unintended user action. Our POSTs are primarily for crawling resources that a page requests automatically, mimicking what a typical user would see when they open the URL in their browser. This will evolve over time as we find better heuristics, but that’s our current approach.

Let’s run through a few POSTs request scenarios that demonstrate how we’re improving our crawling and indexing to evolve with the web.

Examples of Googlebot’s POST requests

Crawling a page via a POST redirect
<html>
  <body onload="document.foo.submit();">
    <form name="foo" action="request.php" method="post">       <input type="hidden" name="bar" value="234"/>
    </form>
  </body>
</html>
Crawling a resource via a POST XMLHttpRequest
In this step-by-step example, we improve both the indexing of a page and its Instant Preview by following the automatic XMLHttpRequest generated as the page renders.
1. Google crawls the URL, yummy-sundae.html.
2. Google begins indexing yummy-sundae.html and, as a part of this process, decides to attempt to render the page to better understand its content and/or generate the Instant Preview.
3. During the render, yummy-sundae.html automatically sends an XMLHttpRequest for a resource, hot-fudge-info.html, using the POST method.
  <html>
    <head>
      <title>Yummy Sundae</title>
      <script src="jquery.js"></script>
    </head>
    <body>
      This page is about a yummy sundae.
      <div id="content"></div>
      <script type="text/javascript">
        $(document).ready(function() {
          $.post('hot-fudge-info.html', function(data)
            {$('#content').html(data);});
        });
      </script>
    </body>
  </html>
4. The URL requested through POST, hot-fudge-info.html, along with its data payload, is added to Googlebot’s crawl queue.
5. Googlebot performs a POST request to crawl hot-fudge-info.html.
6. Google now has an accurate representation of yummy-sundae.html for Instant Previews. In certain cases, we may also incorporate the contents of hot-fudge-info.html into yummy-sundae.html.
7. Google completes the indexing of yummy-sundae.html.
8. User searches for [hot fudge sundae].
9. Google’s algorithms can now better determine how yummy-sundae.html is relevant for this query, and we can properly display a snapshot of the page for Instant Previews.

Improving your site’s crawlability and indexability

General advice for creating crawlable sites is found in our Help Center. For webmasters who want to help Google crawl and index their content and/or generate the Instant Preview, here are a few simple reminders:

Prefer GET for fetching resources, unless there’s a specific reason to use POST.
Verify that we're allowed to crawl the resources needed to render your page. In the example above, if hot-fudge-info.html is disallowed by robots.txt, Googlebot won't fetch it. More subtly, if the JavaScript code that issues the XMLHttpRequest is located in an external .js file disallowed by robots.txt, we won't see the connection between yummy-sundae.html and hot-fudge-info.html, so even if the latter is not disallowed itself, that may not help us much. We've seen even more complicated chains of dependencies in the wild. To help Google better understand your site it's almost always better to allow Googlebot to crawl all resources.

You can test whether resources are blocked through Webmaster Tools “Labs -> Instant Previews.”
Make sure to return the same content to Googlebot as is returned to users’ web browsers. Cloaking (sending different content to Googlebot than to users) is a violation of our Webmaster Guidelines because, among other things, it may cause us to provide a searcher with an irrelevant result -- the content the user views in their browser may be a complete mismatch from what we crawled and indexed. We’ve seen numerous POST-request examples where a webmaster non-maliciously cloaked (which is still a violation), and their cloaking -- on even the smallest of changes -- then caused JavaScript errors that prevented accurate indexing and completely defeated their reason for cloaking in the first place. Summarizing, if you want your site to be search-friendly, cloaking is an all-around sticky situation that’s best to avoid.

To verify that you're not accidentally cloaking, you can use Instant Previews within Webmaster Tools, or try setting the User-Agent string in your browser to something like:

Mozilla/5.0 (compatible; Googlebot/2.1;
+http://www.google.com/bot.html)
Your site shouldn't look any different after such a change. If you see a blank page, a JavaScript error, or if parts of the page are missing or different, that means that something's wrong.
Remember to include important content (i.e., the content you’d like indexed) as text, visible directly on the page and without requiring user-action to display. Most search engines are text-based and generally work best with text-based content. We’re always improving our ability to crawl and index content published in a variety of ways, but it remains a good practice to use text for important information.

Controlling your content

If you’d like to prevent content from being crawled or indexed for Google Web Search, traditional robots.txt directives remain the best method. To prevent the Instant Preview for your page(s), please see our Instant Previews FAQ which describes the “Google Web Preview” User-Agent and the nosnippet meta tag.

Moving forward

We’ll continue striving to increase the comprehensiveness of our index so searchers can find more relevant information. And we expect our crawling and indexing capability to improve and evolve over time, just like the web itself. Please let us know if you have questions or concerns.

Written by Pawel Aleksander Fedorynski, Software Engineer, Indexing Team, and Maile Ohye, Developer Programs Tech Lead

Permalink for 'Official_Google_Webmaster_Central_Blog/2011/09/15/Pagination_with_rel_%e2%80%9cnext%e2%80%9d_and_rel_%e2%80%9cprev%e2%80%9d'

Pagination with rel=“next” and rel=“prev”

Posted: September 15th, 2011, 7:00am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster level: Intermediate to Advanced

Much like rel=”canonical” acts a strong hint for duplicate content, you can now use the HTML link elements rel=”next” and rel=”prev” to indicate the relationship between component URLs in a paginated series. Throughout the web, a paginated series of content may take many shapes—it can be an article divided into several component pages, or a product category with items spread across several pages, or a forum thread divided into a sequence of URLs. Now, if you choose to include rel=”next” and rel=”prev” markup on the component pages within a series, you’re giving Google a strong hint that you’d like us to:

Consolidate indexing properties, such as links, from the component pages/URLs to the series as a whole (i.e., links should not remain dispersed between page-1.html, page-2.html, etc., but be grouped with the sequence).
Send users to the most relevant page/URL—typically the first page of the series.

The relationship between component URLs in a series can now be indicated to Google through rel=”next” and rel=”prev”.
There’s an exception to the rel=”prev” and rel=”next” implementation: If, alongside your series of content, you also offer users a view-all page, or if you’re considering a view-all page, please see our post on View-all in search results for more information. Because view-all pages are most commonly preferred by searchers, we do our best to surface this version when appropriate in results rather than a component page (component pages are more likely to surface with rel=”next” and rel=”prev”).

If you don’t have a view-all page or you’d like to override Google returning a view-all page, you can use rel="next" and rel="prev" as described in this post.

For information on paginated configurations that include a view-all page, please see our post on View-all in search results.
Outlining your options

Here are three options for a series:

Leave whatever you have exactly as-is. Paginated content exists throughout the web and we’ll continue to strive to give searchers the best result, regardless of the page’s rel=”next”/rel=”prev” HTML markup—or lack thereof.
If you have a view-all page, or are considering a view-all page, see our post on View-all in search results.
Hint to Google the relationship between the component URLs of your series with rel=”next” and rel=”prev”. This helps us more accurately index your content and serve to users the most relevant page (commonly the first page). Implementation details below.

Implementing rel=”next” and rel=”prev”

If you prefer option 3 (above) for your site, let’s get started! Let’s say you have content paginated into the URLs:

http://www.example.com/article?story=abc&page=1
http://www.example.com/article?story=abc&page=2
http://www.example.com/article?story=abc&page=3
http://www.example.com/article?story=abc&page=4

On the first page, http://www.example.com/article?story=abc&page=1, you’d include in the <head> section:
<link rel="next" href="http://www.example.com/article?story=abc&page=2" />

On the second page, http://www.example.com/article?story=abc&page=2:
<link rel="prev" href="http://www.example.com/article?story=abc&page=1" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3" />

On the third page, http://www.example.com/article?story=abc&page=3:
<link rel="prev" href="http://www.example.com/article?story=abc&page=2" />
<link rel="next" href="http://www.example.com/article?story=abc&page=4" />

And on the last page, http://www.example.com/article?story=abc&page=4:
<link rel="prev" href="http://www.example.com/article?story=abc&page=3" />

A few points to mention:

The first page only contains rel=”next” and no rel=”prev” markup.
Pages two to the second-to-last page should be doubly-linked with both rel=”next” and rel=”prev” markup.
The last page only contains markup for rel=”prev”, not rel=”next”.
rel=”next” and rel=”prev” values can be either relative or absolute URLs (as allowed by the <link> tag). And, if you include a <base> link in your document, relative paths will resolve according to the base URL.
rel=”next” and rel=”prev” only need to be declared within the <head> section, not within the document <body>.
We allow rel=”previous” as a syntactic variant of rel=”prev” links.
rel="next" and rel="previous" on the one hand and rel="canonical" on the other constitute independent concepts. Both declarations can be included in the same page. For example, http://www.example.com/article?story=abc&page=2&sessionid=123 may contain:

<link rel="canonical" href="http://www.example.com/article?story=abc&page=2”/>
<link rel="prev" href="http://www.example.com/article?story=abc&page=1&sessionid=123" />
<link rel="next" href="http://www.example.com/article?story=abc&page=3&sessionid=123" />
rel=”prev” and rel=”next” act as hints to Google, not absolute directives.
When implemented incorrectly, such as omitting an expected rel="prev" or rel="next" designation in the series, we'll continue to index the page(s), and rely on our own heuristics to understand your content.

Questions?
More information can be found in our Help Center, or join the conversation in our Webmaster Help Forum!

Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team

View-all in search results

Posted: September 15th, 2011, 7:00am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster level: Intermediate to Advanced

User testing has taught us that searchers much prefer the view-all, single-page version of content over a component page containing only a portion of the same information with arbitrary page breaks (which cause the user to click “next” and load another URL).

Searchers often prefer the view-all vs. paginated content with arbitrary page breaks and worse latency.
Therefore, to improve the user experience, when we detect that a content series (e.g. page-1.html, page-2.html, etc.) also contains a single-page version (e.g. page-all.html), we’re now making a larger effort to return the single-page version in search results. If your site has a view-all option, there’s nothing you need to do; we’ll work to do it on your behalf. Also, indexing properties, like links, will be consolidated from the component pages in the series to the view-all page.

However, high latency can make the view-all less preferred

Interestingly, the cases when users didn’t prefer the view-all page were correlated with high latency (e.g., when the view-all page took a while to load, say, because it contained many images). This makes sense because we know users are less satisfied with slow results. So while a view-all page is commonly desired, as a webmaster it’s important to balance this preference with the page’s load time and overall user experience.

Best practices for a series of content

If your site includes view-all pages

We aim to detect the view-all version of your content and, if available, its associated component pages. There’s nothing more you need to do! However, if you’d like to make it more explicit to us, you can include rel=”canonical” from your component pages to your view-all to increase the likelihood that we detect your series of pages appropriately.

rel=”canonical” can specify the superset of content (i.e. the view-all page, in this case page-all.html) from the same information in a series of URLs.
Why does this work?
In the diagram, page-2.html of a series may specify the canonical target as page-all.html because page-all.html is a superset of page-2.html's content. When a user searches for a query term and page-all.html is selected in search results, even if the query most related to page-2.html, we know the user will still see page-2.html’s relevant information within page-all.html.

On the other hand, page-2.html shouldn’t designate page-1.html as the canonical because page-2.html’s content isn’t included on page-1.html. It’s possible that a user’s search query is relevant to content on page-2.html, but if page-2.html’s canonical is set to page-1.html, the user could then select page-1.html in search results and find herself in a position where she has to further navigate to a different page to arrive at the desired information. That’s a poor experience for the user, a suboptimal result from us, and it could also bring poorly targeted traffic to your site.

However, if you strongly desire your view-all page not to appear in search results: 1) make sure the component pages in the series don’t include rel=”canonical” to the view-all page, and 2) mark the view-all page as “noindex” using any of the standard methods.
If you’d like to surface individual, component pages (or there’s no view-all available)

It may be the case that one or both of the situations below apply to your site:
- The view-all page is undesirable as a search result (e.g., load time too high or too difficult for users to navigate).
- Your users prefer the multi-page experience and to be directed to a component page in search results, rather than the view-all page.
If so, you can use standard HTML rel=”next” and rel=”prev” elements to specify a relationship between the component pages in your series of content. If done correctly, Google will generally strive to:
- Consolidate indexing properties, such as links, between the component pages/URLs.
- Send users to the most relevant page/URL from the component pages. Typically, the most relevant page is the first page of your content, but our algorithms may point users to one of the component pages in the series.

It’s not uncommon for webmasters to incorrectly use rel=”canonical” from component pages to the first page of their series (e.g. page-2.html with rel=”canonical” to page-1.html). We recommend against this implementation because the component pages don’t actually contain duplicate content. Using rel=”next” and rel=”prev” is far more appropriate.

Summary

Because users generally prefer the view-all option in search results, we’re making more of an effort to properly detect and serve this version to searchers. If you have a series of content, there’s nothing more you need to do. If you’d like to hint more to Google how best to serve users your information:

To better optimize your view-all page, you can use rel=”canonical” from component pages to the single-page version; otherwise,
If a view-all page doesn’t provide a good user experience for your site, you can use the rel=”next” and rel=”prev” attributes as a strong hint for Google to identify the series of pages and still surface a component page in results.

Questions?

As always, feel free to ask in our Webmaster Help Forum.

Written by Benjia Li & Joachim Kupke, Software Engineers, Indexing Team

Making the most of improvements to the +1 button

Posted: August 24th, 2011, 12:22pm CEST by Maile Ohye

Tags: products and services

Webmaster level: All

For the past few months, you might have used +1 buttons to help visitors recommend your content on Google Search and on their Google Profiles. We’ve just announced a few changes that make +1 even more useful.

First, the +1 button now lets visitors share links to your pages on Google+. If someone wants to start a conversation about your content, it’s easy for them to do so. Second, you can use +Snippets to customize the name, image and description that appear when your content is shared. Finally, new inline annotations help increase engagement after users see a friend’s recommendation right on your page.

Here are a couple of tips to help you take full advantage of these improvements:

+Snippets
The +1 button opens up your site to a valuable new source of traffic with sharing on Google+. +Snippets let you put your best face forward by customizing exactly what appears when your content is shared.

For example, if you’re running a movie review site, you might want visitors to share posts containing the title, movie poster, and a brief synopsis:

You may already be using this markup to build rich annotations for your pages on Google Search. If not, marking up your pages is simple. Just add the correct schema.org attributes to the data already present on your pages. You’ll set a name, image, and description in your code:

<body itemscope itemtype="http://schema.org/Article">

<h1 itemprop="name">This is the article name</h1>

<img itemprop="image" src="thumbnail.jpg" />

<p itemprop="description">This is the description of the article.</p>

</body>

Example code containing each of the +Snippet attributes

For more details on alternate markup types, please see our technical documentation.

Inline annotations
Now, when a person visits a page that someone they know has +1’d, they can see a name and face reminding them to pay special attention to your content. Here’s how it looks:

Inline annotations let people see which of their friends +1’d your content

To add inline annotations, you need to update your +1 button code. Visit the configuration tool, select ‘inline’ from the ‘Annotation’ menu, and grab a new snippet of code.

Both sharing from +1 and inline annotations are rolling out fully over the next few days. To test these improvements right now, join our Platform Preview group.

Update later the same day, August 24, 2011: If you have any thoughts or feedback you'd like to share, continue the conversation on Google+.

Posted by Daniel Dulitz, Group Product Manager

Introducing new and improved sitelinks

Posted: August 16th, 2011, 2:15pm CEST by Maile Ohye

Tags: webmaster tools

Webmaster level: All

This week we launched an update to sitelinks to improve the organization and quality of our search results. Sitelinks are the two columns of links that appear under some search results and ads that help users easily navigate deeper into the site. Sitelinks haven’t changed fundamentally: they’re still generated and ranked algorithmically based on the link structure of your site, and they’ll only appear if useful for a particular query.

Sitelinks before today’s changes
Here’s how we’ve improved sitelinks with today’s launch:

Visibility. The links have been boosted to full-sized text, and augmented with a green URL and one line of text snippet, much like regular search results. This increases the prominence of both the individual sitelinks and the top site overall, making them easier to find.

Flexibility. Until now, each site had a fixed list of sitelinks that would either all appear or not appear; there was no query-specific ranking of the links. With today’s launch, sitelink selection and ranking can change from query to query, allowing more optimized results. In addition, the maximum number of sitelinks that can appear for a site has been raised from eight to 12, and the number shown also varies by query.

Clarity. Previously, pages from your site could either appear in the sitelinks, in the regular results, or both. Now we’re making the separation between the top domain and other domains a bit clearer. If sitelinks appear for the top result, then the rest of the results below them will be from other domains. One exception to this is if the top result for a query is a subpart of a domain. For instance, the query [the met exhibitions] has www.metmuseum.org/special/ as the top result, and its sitelinks are all from within the www.metmuseum.org/special section of the site. However, the rest of the results may be from other parts of the metmuseum.org domain, like store.metmuseum.org or blog.metmuseum.org/alexandermcqueen/about.

Quality. These user-visible changes are accompanied by quality improvements behind the scenes. The core improvement is that we’ve combined the signals we use for sitelinks generation and ranking -- like the link structure of your site -- with our more traditional ranking system, creating a better, unified algorithm. From a ranking perspective, there’s really no separation between “regular” results and sitelinks anymore.

Sitelinks after today’s changes
These changes are also reflected in Webmaster Tools, where you can manage the sitelinks that appear for your site. You can now suggest a demotion to a sitelink if it’s inappropriate or incorrect, and the algorithms will take these demotions into account when showing and ranking the links (although removal is not guaranteed). Since sitelinks can vary over time and by query, it no longer makes sense to select from a set list of links -- now, you can suggest a demotion of any URL for any parent page. Up to 100 demotions will be allowed per site. Finally, all current sitelink blocks in Webmaster Tools will automatically be converted to the demotions system. More information can be found in our Webmaster Tools Help Center.

It’s also worth mentioning a few things that haven’t changed. One-line sitelinks, where sitelinks can appear as a row of links on multiple results, and sitelinks on ads aren’t affected. Existing best practices for the link structure of your site are still relevant today, both for generating good quality sitelinks and to make it easier for your visitors. And, as always, you can raise any questions or comments in our Webmaster Help Forum.

Written by Harvey Jones, Software Engineer, & Raj Krishnan, Product Manager, Sitelinks team

Preview the latest +1 button changes

Posted: July 29th, 2011, 5:55pm CEST by Maile Ohye

Tags: intermediate

Webmaster level: All

Want to test the latest +1 features? Today we’re introducing a new option for webmasters who want to be the first to know about changes to the +1 button. Enroll in the Google+ Platform Preview, available globally, to test updates before they launch to all users on your site. When you’re logged into the account you’ve enrolled with and you visit a page with the +1 button, you’ll see the latest preview release.

If you join now, you’ll be able to test the first set of updates we’ve released to Platform Preview: hover and confirmation bubbles.

If you hover your mouse over a +1 button, you’ll see a bubble letting you know what will happen when you click:

After you click, you’ll receive confirmation that the +1 has been applied:

This will give your site’s users an extra reminder of the account they’re using to +1, as well as the fact that their +1 is public.
If you have any questions, please join us in the Webmaster forum. To receive updates about the +1 button, please subscribe to the Google Publisher Buttons Announce Group. And for advanced tips and tricks, check our Google Code site.

Posted by Joshua Ganderson, Software Engineer

Announcing Instant Pages

Posted: June 14th, 2011, 12:30pm CEST by Maile Ohye

Tags: Search results

Webmaster level: All

Earlier today we announced Instant Pages, a new feature to help users get to their desired search results even faster--in some cases even instantly! The Instant Pages feature is enabled by prerendering technology that we are building into Chrome and then is intelligently triggered by web search when we're very confident about which result is the best answer for the user's search.

This prerendering technology is currently in the Chrome Dev Channel and will be going to Beta later this week.

You can see Instant Pages in action in this video:

At Google we're obsessed with speed. We've seen time and time again how an increase in apparent speed leads to a direct increase in user happiness and engagement. Instant Pages helps visitors arrive at your site faster. When we trigger Instant Pages for your site, users can start interacting with your site almost immediately, without having to wait for text and images to load. We'll only trigger Instant Pages when we have very high confidence that your site is the exact result users are looking for. Search traffic will be measured in Webmaster Tools just like before this feature, with only results the user visited counted. We'll take the time this summer before the feature launches in stable versions of Chrome to collect your feedback.

The vast majority of sites will automatically work correctly when prerendered in Chrome. Check out the prerendering post on the Chromium blog if you want to learn more about how prerendering works in Chrome or how you can detect that your site is being prerendered.

Written by Ziga Mahkovec, Software Engineer

Authorship markup and web search

Posted: June 7th, 2011, 2:49pm CEST by Maile Ohye

Tags: crawling and indexing

Webmaster level: Intermediate

Today we're beginning to support authorship markup—a way to connect authors with their content on the web. We're experimenting with using this data to help people find content from great authors in our search results.

We now support markup that enables websites to publicly link within their site from content to author pages. For example, if an author at The New York Times has written dozens of articles, using this markup, the webmaster can connect these articles with a New York Times author page. An author page describes and identifies the author, and can include things like the author’s bio, photo, articles and other links.

If you run a website with authored content, you’ll want to learn about authorship markup in our Help Center. The markup uses existing standards such as HTML5 (rel=”author”) and XFN (rel=”me”) to enable search engines and other web services to identify works by the same author across the web. If you're already doing structured data markup using microdata from schema.org, we'll interpret that authorship information as well.

We wanted to make sure the markup was as easy to implement as possible. To that end, we’ve already worked with several sites to markup their pages, including The New York Times, The Washington Post, CNET, Entertainment Weekly, The New Yorker and others. In addition, we’ve taken the extra step to add this markup to everything hosted by YouTube and Blogger. In the future, both platforms will automatically include this markup when you publish content.

We know that great content comes from great authors, and we’re looking closely at ways this markup could help us highlight authors and rank search results.

Posted by Othar Hansson, Software Engineer

Introducing schema.org: Search engines come together for a richer web

Posted: June 2nd, 2011, 2:10am CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

Today we’re announcing schema.org, a new initiative from Google, Bing and Yahoo! to create and support a common set of schemas for structured data markup on web pages. Schema.org aims to be a one stop resource for webmasters looking to add markup to their pages to help search engines better understand their websites.

At Google, we’ve supported structured markup for a couple years now. We introduced rich snippets in 2009 to better represent search results describing people or containing reviews. We’ve since expanded to new kinds of rich snippets, including products, events, recipes, and more.

Example of a rich snippet: a search result enhanced by structured markup. In this case, the rich snippet contains a picture, reviews, and cook time for the recipe.
Adoption by the webmaster community has grown rapidly, and today we’re able to show rich snippets in search results more than ten times as often as when we started two years ago.

We want to continue making the open web richer and more useful. We know that it takes time and effort to add this markup to your pages, and adding markup is much harder if every search engine asks for data in a different way. That’s why we’ve come together with other search engines to support a common set of schemas, just as we came together to support a common standard for Sitemaps in 2006. With schema.org, site owners can improve how their sites appear in search results not only on Google, but on Bing, Yahoo! and potentially other search engines as well in the future.

Now let’s discuss some of the details of schema.org relevant to you as a webmaster:

1) Schema.org contains a lot of new markup types.
We’ve added more than 100 new types as well as ported over all of the existing rich snippets types. If you’ve looked at adding rich snippets markup before but none of the existing types were relevant for your site, it’s worth taking another look. Here are a few popular types:

Creative works: CreativeWork, Book, Movie, MusicRecording, Recipe, TVSeries
Embedded non-text objects: AudioObject, ImageObject, VideoObject
Event
Organization
Person
Place, LocalBusiness, Restaurant
Product, Offer, AggregateOffer
Review, AggregateRating

Or, view a full list of all schema.org types. The new markup types may be used for future rich snippets formats as well as other types of improvements to help people find your content more easily when searching.

2) Schema.org uses microdata.
Historically, we’ve supported three different standards for structured data markup: microdata, microformats, and RDFa. We’ve decided to focus on just one format for schema.org to create a simpler story for webmasters and to improve consistency across search engines relying on the data. There are arguments to be made for preferring any of the existing standards, but we’ve found that microdata strikes a balance between the extensibility of RDFa and the simplicity of microformats, so this is the format that we’ve gone with.

To get an overview of microdata as well as the conventions followed by schema.org, take a look at the schema.org Getting Started guide.

3) We’ll continue to support our existing rich snippets markup formats.
If you’ve already done markup on your pages using microformats or RDFa, we’ll continue to support it. One caveat to watch out for: while it’s OK to use the new schema.org markup or continue to use existing microformats or RDFa markup, you should avoid mixing the formats together on the same web page, as this can confuse our parsers.

4) Test your markup using the rich snippets testing tool.
It’s very useful to test your web pages with markup to make sure we’re able to parse the data correctly. As with previous rich snippets markup formats, you should use the rich snippets testing tool for this purpose. Note that while the testing tool will show the marked up information that was parsed from the page, rich snippets previews are not yet shown for schema.org markup. We’ll be adding this functionality soon.

The schema.org website and the rich snippets testing tool are in English. However, Google shows rich snippets in search results globally, so there’s no need to wait to start marking up your pages.

To learn more about rich snippets and how they relate to schema.org, check out the Rich snippets schema.org FAQ.

By Kavi Goel and Pravir Gupta, Search Quality team

Troubleshooting Instant Previews in Webmaster Tools

Posted: May 18th, 2011, 3:21pm CEST by Maile Ohye

Tags: webmaster tools

Webmaster level: All

In November, we launched Instant Previews to help users better understand if a particular result was relevant for a their search query. Since launch, our Instant Previews team has been keeping an eye on common complaints and problems related to how pages are rendered for Instant Previews.

When we see issues with preview images, they are frequently due to:

Blocked resources due to a robots.txt entry
Cloaking: Erroneous content being served to the Googlebot user-agent
Poor alternative content when Flash is unavailable

To help webmasters diagnose these problems, we have a new Instant Preview tool in the Labs section of Webmaster Tools (in English only for now).

Here, you can input the URL of any page on your site. We will then fetch the page from your site and try to render it both as it would display in Chrome and through our Instant Preview renderer. Please keep in mind that both of these renders are done using a recent build of Webkit which does not include plugins such as Flash or Silverlight, so it's important to consider the value of providing alternative content for these situations. Alternative content can be helpful to search engines, and visitors to your site without the plugin would benefit as well.

Below the renders, you’ll also see automated feedback on problems our system can detect such as missing or roboted resources. And, in the future, we plan to add more informative and timely feedback to help improve your Instant Previews!

Please direct your questions and feedback to the Webmaster Forum.

Posted by Michael Darweesh, Software Engineer

Flash support in Instant Previews

Posted: May 6th, 2011, 8:00am CEST by Maile Ohye

Tags: intermediate

Webmaster level: All

With Instant Previews, users can see a snapshot of a search result before clicking on it. We’ve made a number of improvements to the feature since its introduction last November, and if you own a site, one of the most relevant changes for you is that Instant Previews now supports Flash.

An Instant Preview with rich content rendered

In most cases, when the preview for a page is generated through our regular crawl, we will now render a snapshot of any Flash components on the page. This will replace the "puzzle piece" icon that previously appeared to indicate Flash components, and should improve the accuracy of the previews.

However, for pages that are fetched on demand by the "Google Web Preview" user-agent, we will generate a preview without Flash in order to minimize latency. In these cases the preview will appear as if the page were visited by someone using a browser without Flash enabled, and "Install Flash" messages may appear in the preview, depending on how your website handles users without Flash.

To improve your previews for these on-demand renders, here are some guidelines for using Flash on your site:

Make sure that your site has a reasonable, seamless experience for visitors without Flash. This may involve creating HTML-only equivalents for your Flash-based content that will automatically be shown to visitors who can't view Flash. Providing a good experience for this case will improve your preview and make your visitors happier.

If Flash components are rendering but appear as loading screens instead of actual content, try reducing the loading time for the component. This makes it more likely we'll render it properly.

If you have Flash videos on your site, consider submitting a Video Sitemap which helps us to generate thumbnails for your videos in Instant Previews.

If most of the page is rendering properly but you still see puzzle pieces appearing for some smaller components, these may be fixed in future crawls of your page.

If you have additional questions, please feel free to post them in our Webmaster Help Forum.

As always, we'll keep you updated as we continue to make improvements to Instant Previews.

Posted by Raj Krishnan, Product Manager

Permalink for 'Official_Google_Webmaster_Central_Blog/2011/04/01/Our_SEO_Guide_%e2%80%94_now_available_in_ten_more_languages'

Our SEO Guide — now available in ten more languages

Posted: April 1st, 2011, 7:00pm CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Beginner

We’re very glad to announce that our recently updated SEO guide is now available in ten more languages: Spanish, French, German, Russian, Turkish, Finnish, Swedish, Hungarian, Traditional Chinese and Simplified Chinese.

For this new version, we’ve thoroughly reviewed and updated the content; we’ve also added a brand new section on best practices for mobile websites.

You can download each PDF file in its full 32-page glory from goo.gl/seoguide and print it to have it as a useful resource.

Posted by Esperanza Navas and Mariya Moeva, Search Quality Team

Permalink for 'Official_Google_Webmaster_Central_Blog/2011/03/30/Mo%e2%80%99_better_to_also_detect_%e2%80%9cmobile%e2%80%9d_user_agent'

Mo’ better to also detect “mobile” user-agent

Posted: March 30th, 2011, 4:45pm CEST by Maile Ohye

Tags: intermediate

Webmaster Level: Intermediate to Advanced

Here’s a trending User-Agent detection misstep we hope to help you prevent: While it seems completely reasonable to key off the string “android” in the User-Agent and then redirect users to your mobile version, there’s a small catch... Android tablets were just released! Similar to mobile, the User-Agent on Android tablets also contains “android,” yet tablet users usually prefer the full desktop version over the mobile equivalent. If your site matches “android” and then automatically redirects users, you may be forcing Android tablet users into a sub-optimal experience.

As a solution for mobile sites, our Android engineers recommend to specifically detect “mobile” in the User-Agent string as well as “android.” Let’s run through a few examples.

With a User-Agent like this:

Mozilla/5.0 (Linux; U; Android 3.0; en-us; Xoom Build/HRI39) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13

since there is no “mobile” string, serve this user the desktop version (or a version customized for Android large-screen touch devices). The User-Agent tells us they’re coming from a large-screen device, the XOOM tablet.

On the other hand, this User-Agent:

Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

contains “mobile” and “android,” so serve the web surfer on this Nexus One the mobile experience!

You’ll notice that Android User-Agents have commonalities:

While you may still want to detect “android” in the User-Agent to implement Android-specific features, such as touch-screen optimizations, our main message is: Should your mobile site depends on UA sniffing, please detect the strings “mobile” and “android,” rather than just “android,” in the User-Agent. This helps properly serve both your mobile and tablet visitors.

For questions, please join our Android community in their developer forum.

Written by Maile Ohye, Developer Programs Tech Lead

Tag Your TV Shows!

Posted: March 24th, 2011, 3:00pm CET by Maile Ohye

Tags: intermediate

Webmaster Level: All

If your website is the authoritative source for the video of a particular TV show, make sure we know about it! Hopefully, you already submit Video Sitemaps or mRSS feeds to inform us about video content on your website. We now support additional fields in both video Sitemaps and mRSS feeds where you can specify metadata specific to television or episodic content. This includes the series’ title, the season and episode numbers for the video in question, the premiere date, as well as other additional information. The metadata from your video feed helps us provide more detailed, relevant results to users wanting to view your show.

Here’s an example Video Sitemap entry that includes all the required and some optional TV metadata in the <video:tvshow> element:

<video:video>
  <video:title>The Sample Show, Season 1, Episode 2</video:title>
 &nbsp<!-- other required root level video tags omitted -->
 &nbsp<video:tvshow>
    <video:show_title>The Sample Show</video:show_title&gt
    <video:video_type>full</video:video_type>
    <video:episode_title>A Sample Episode Title</video:episode_title>
    <video:season_number>1</video:season_number>
    <video:episode_number>2</video:episode_number>
  </video:tvshow>
</video:video>

The full documentation for the tags for both mRSS and Video Sitemaps can be found in our Webmaster Tools Help Center. As always, if you have any questions about Video Sitemaps or mRSS feeds, feel free to reach out to us in the Sitemaps section of the Webmaster Help Forum.

Written by Jeff Posnick, Video Search Team

Page Speed for Chrome, and in 40 languages!

Posted: March 22nd, 2011, 11:30am CET by Maile Ohye

Tags: products and services

Webmaster Level: All

This article is cross-posted on the Google Code Blog.

Today we’re launching the most requested feature for Page Speed, Page Speed for Chrome. Now Google Chrome users can get Page Speed performance suggestions to make their sites faster, right inside the Chrome browser. We would like to thank all our users for your great feedback and support since we launched. We’re humbled that 1.4 M unique users are using the Page Speed extension and finding it useful to help with their web performance diagnosis.

Google Chrome support has always been high on our priority list but we wanted to get it right. It was critical that the same engine that powers the Page Speed Add-On for Firefox be used here as well. So we first built the Page Speed SDK, which we then integrated into the Chrome extension.

Page Speed for Chrome retains the same core features as the Firefox add-on. In addition, there are two major improvements appearing in this version first. We’ve improved scoring and suggestion ordering to help web developers focus on higher-potential optimizations first. Plus, because making the web faster is a global initiative, Page Speed now supports displaying localized rule results in 40 languages! These improvements are part of the Page Speed SDK, so they will also appear in the next release of our Firefox add-on as well.

If your site serves different content based on the browser’s user agent, you now have a good method for page performance analysis as seen by different browsers, with Page Speed coverage for Firefox and Chrome through the extensions, and Internet Explorer via webpagetest.org, which integrates the Page Speed SDK.

We’d love to hear from you, as always. Please try Page Speed for Chrome, and give us feedback on our mailing list about additional functionality you’d like to see. Stay tuned for updates to Page Speed for Chrome that take advantage of exciting new technologies such as Native Client.

By Matthew Steele and Richard Rabbat, Page Speed Team

Beyond Times and Arial - The New Web Safe Fonts

Posted: February 18th, 2011, 12:00pm CET by Maile Ohye

Tags: intermediate

Webmaster level: All

In the past, when you created a website or web app, you were largely limited to a few select “web safe” fonts such as Times and Arial. If you deviated from these fonts, you were required to use Adobe Flash or to embed text in images, which introduced a whole new set of trade offs. For example, images aren’t semantic, cannot be translated into other languages automatically, and can be much larger in file size than text. In addition, text in images cannot be copied to a user’s clipboard, read with screen-reading software, or easily indexed by search engines.

The good news is, with Google Web Fonts it is now possible to use hundreds of web safe fonts on your web pages. Launched last May, Google Web Fonts allows you to simply choose the font(s) you’d like to use on your webpage, blog, or web app, and embed the snippet of HTML and CSS. In about 30 seconds, you can have beautiful fonts on your pages that will render correctly in the large majority of popular modern web browsers. No longer will you need to use images or Flash to embed the font of your choice.

Unlike Times and Arial, which are references to fonts installed on a user’s local machine, web fonts are served via a browser request (much like an image would be served). That means you can push any web font to a user’s machine. Users will be delighted when they realize these fonts behave just as any other text in Arial would behave.

Some example web fonts, offered by the Google Web Fonts service

The adoption of the web font technology has been rapid. Google Web Fonts now serves roughly 50 million daily requests[1], across roughly 800,000 unique websites[2], and is growing at about 30% each month. Here at Google, we’re excited about the potential for web fonts to change the very fabric of the web. Beautiful typography makes the web more pleasant to browse, expressive, and interesting.

Here’s to a beautiful Web!

Written by David Wurtz, Product Manager, Google Web Fonts

[1] A request is a single call to the Google Font API for one or more fonts.
[2] We count a unique website as unique domains, except that “www” subdomains are not counted. For example, www.myblog.com and myblog.com would count as one domain. However, sam.myblog.com and sally.myblog.com would count as two domains.

Sending Video Sitemaps Q&A holiday cheer

Posted: December 25th, 2010, 1:20am CET by Maile Ohye

Tags: sitemaps

Webmaster Level: Intermediate to Advanced

To the fabulous, savvy audience that attended our Video Sitemap webinar several months ago, please accept our re-gift: a summary of your questions from the Video Sitemaps Q&A!

To those who were unable to attend the webinar, please enjoy our gift of the summarized Q&A -- it’s like new!

Either way, happy holidays from all of us on the Webmaster Central Team. :)

Our entire webinar covers the basics of Video Sitemaps and best practices -- nearly everything you’d need to know when submitting a video feed.

Can the source/content of the video (perhaps a third-party vendor) be hosted on another site? For example, can I host my videos on YouTube and still be eligible for Video Search traffic?

Yes, you can use a third party to host videos. Only the play page--the URL within the <loc> tag--needs to be on your site. <video:content_loc> and <video:player_loc> can list URLs on a different site or subdomain.

For example, here’s a snippet from a valid Video Sitemap that shows content hosted on a different subdomain from the play page:

<url> <loc>http://www.example.com/videos/some_video_landing_page.html</loc> <video:video> <video:thumbnail_loc>http://www.example.com/thumbs/123.jpg</video:thumbnail_loc> <video:title>Grilling steaks for summer</video:title> <video:description>Alkis shows you how to get perfectly done steaks every time</video:description> <video:content_loc>http://video-hoster.example.com/video123.flv</video:content_loc> <video:player_loc allow_embed="yes" autoplay="ap=1">http://www.example.com/videoplayer.swf?video=123</video:player_loc> </video:video> </url>

If I’m using YouTube to host my videos, can Google verify that I’m the legitimate owner?

Currently, there doesn’t exist functionality that allows you, as the uploader, to verify that you’re the owner of a video. The issue of authorship is a hard problem on the web, not just for videos, but nearly all types of content.

Because Google owns YouTube, should users who embed YouTube videos still submit Video Sitemaps or is it unnecessary?

Google treats YouTube as just another source for video content -- though you don’t need to submit a Video Sitemap if you only want your YouTube-hosted videos indexed. If, however, you’re using YouTube as a online video platform (i.e., with play pages on your own site), then we do recommend Sitemap submission.

How long does it take for Google to accept and verify a Video Sitemap?

Video Sitemap submission is a two-part process:
1. We fetch the Sitemap and parse it for syntax errors. This happens within minutes.
2. We fetch the assets referenced in the Sitemap, perform checks, validate metadata, do more cool stuff, and last, index the video. This step can require varied amounts of time depending on your site and our system load.
What tags and categories are most important in Video Sitemaps or mRSS? Should I create my own categories or is there a list that I should conform to?

Currently, the most important metadata to include is title and description -- both are required. The category tag is optional, and there isn’t a list from which to select.

Do I have to use HTML5 to use Video Sitemaps?
Does HTML5 help with discovery?
Or, if my site is HTML5 compliant, do I still need to submit a Video Sitemap?

None of the Video Search principles change with HTML5. We still recommend using a Video Sitemap regardless of the markup on your site. HTML5 can be helpful, though, because tags like <video> make it easier for our systems to verify that video exists on the page.

If I use an iframe rather than embedding my videos, can Google still find it?

We do not recommend using iframes to embed video content on your pages.

Can I have multiple videos on one URL?

You can. We’ve found, however, that users may not consider it the best experience. When users click on a video search result, they most often don’t like being forced to locate the correct video among multiple videos on the resulting page.

Do I need to specifically create a robots.txt file that allows Googlebot, or do I just need to make sure Googlebot isn’t blocked?

Just make sure that Googlebot isn’t blocked.

I provided a thumbnail, but it’s not being used. Does Google create their own thumbnails from my videos?

We try to use the thumbnail you provide if it’s valid. If not, we’ll try to generate a thumbnail ourselves. We recommend that you provide thumbnails that are at least 120x90 pixels. We also accept many thumbnail formats, such as PNG and JPEG.

Any video filesize limitations?

At this time, there aren’t video filesize limitations on content submitted through VIdeo Sitemaps.

Is there any way to indicate a transcript or closed captioning for a video?

Currently there isn’t, but perhaps down the road.

What if I’m using Lightbox or a popup to display a video; can it still be indexed?

Depends on the use case and how it’s rendered, but if indexing by search engines is important to you, it’s not the safest method. In the Webmaster Help Center, we explain that “When designing your site, it's important to configure your video pages without any overly complex JavaScript or Flash setup.” Most often, for bots, simpler is safer.

Have a safe and happy holiday!

Written by Maile Ohye, Developer Programs Tech Lead

Video Sitemaps & mRSS vs. Facebook Share & RDFa

Posted: December 23rd, 2010, 12:41am CET by Maile Ohye

Tags: sitemaps

Webmaster Level: Intermediate to Advanced

What are the benefits of submitting feeds like Video Sitemaps and mRSS vs. the benefits of Facebook Share and RDFa? Is one better than the other? Let’s start the discussion.

Functionality of feeds vs. on-page markup

Google accepts information from both video feeds, such as Video Sitemaps and mRSS, as well as on-page markup, such as Facebook Share and RDFa. We recommend that you use both!

If you have limited resources, however, here’s a chart explaining the pros and cons of each method. The key differentiators include:

While both feeds and on-page markup give search engines metadata, Video Sitemaps/mRSS also help with crawl discovery. We may find a new URL through your feed that we wouldn’t have easily discovered otherwise.

Using Video Sitemaps/mRSS requires that the search engine support these formats and not all engines do. Because on-page markup is just that -- on the page -- crawlers can gather the metadata through organic means as they index the URL. No feed support is required.

	Feeds (Video Sitemaps & mRSS)	On-page markup (Facebook Share & RDFa)
Accepted by Google	⎷	⎷
Helps search engines discover new URLs with videos (improves discovery and coverage)	⎷
Provides structured metadata (e.g. video title and description)	⎷	⎷
Allows search engines without sitemap/mRSS support to still obtain metadata information (allows organic gathering of metadata)		⎷
Incorporates additional metadata like “duration”	⎷

If you’re further wondering about the benefits of specific feeds (Video Sitemaps vs. mRSS), we can help with clarification there, too. First of all, you can use either. We’re agnostic. :) One benefit of Video Sitemaps is that, because it’s a format we’re actively enhancing, we can quickly extend it to allow for more specifications.

All this said, if you’re going to start from scratch, Video Sitemaps is our recommended start.

	Video Sitemaps	mRSS
Accepted by Google	⎷	⎷
Been around for a long, long time and pretty widely accepted		⎷
Extremely quick for Google Video Search team to extend	⎷

“Starving” to start conversation about feeds or on-page markup? Join us in the Sitemaps section of the Webmaster discussion forum.

Written by Maile Ohye, Developer Programs Tech Lead

New hacked site notifications in search results

Posted: December 17th, 2010, 11:00am CET by Maile Ohye

Tags: intermediate

Webmaster level: All

Today we’ve added a new notification to our search results that helps people know when a site may have been hacked. We’ve provided notices for malware for years, which also involve a separate warning page. Now we’re expanding the search results notifications to help people avoid sites that may have been compromised and altered by a third party, typically for spam. When a user visits a site, we want her to be confident the information on that site comes from the original publisher.

Here’s what the notification looks like:

Clicking the “This site may be compromised” link brings you to an article in our Help Center which explains more about the notice. Meanwhile, clicking the result itself brings you to the target website, as expected.

We use a variety of automated tools to detect common signs of a hacked site as quickly as possible. When we detect something suspicious, we’ll add the notification to our search results. We’ll also do our best to contact the site’s webmaster via their Webmaster Tools account and any contact email addresses we can find on the webpage. We hope webmasters will also appreciate these notices, because it will help you more quickly discover when someone may be abusing your site so you can correct the problem.

Of course, we also understand that webmasters may be concerned that these notices are impacting their traffic from search. Rest assured, once the problem has been fixed, the warning label will be automatically removed from our search results, usually in a matter of days. You can also request a review of your site to accelerate removal of the notice.

If you see this notification appearing on your site’s listing, please take a look at the instructions in our Help Center to learn how you can begin to address the problem. Together, we can make the web a safer place.

Posted by Gideon Wald, Associate Product Manager

Petits fours in your search results

Posted: November 17th, 2010, 6:00pm CET by Maile Ohye

Tags: Search results

Webmaster Level: All

Recently we made a change to show more results from a domain for certain types of queries -- this helped searchers get to their desired result even faster. Today we’re expanding the feature so that, when appropriate, more queries show additional results from a domain. As a webmaster, you’ll appreciate the fact that these results may bring targeted visitors directly to the pages they’re interested in.

Here’s an example: in the past, the query [moma] (the Museum of Modern Art), might have triggered two results from the official site:

With this iteration, our search results may show:

Up to four web results from each domain (i.e., several domains may have multiple results)
Single-line snippets for the additional results, to keep them compact

As before, we still provide links to results from a variety of domains to ensure people find a diverse set of sources relevant to their searches. However, when our algorithms predict pages from a particular site are likely to be most relevant, it makes sense to provide additional direct links in our search results.

Like all the hundreds of changes we make a year, we’re trying to help users quickly reach their desired result. Even though we’re constantly improving our algorithms, our general advice still holds true: create compelling, search-engine friendly sites in order to attract users, buzz, and often targeted traffic!

Written by Harvey Jones, Software Engineer

What a feeling! Even better indexing of SWF content

Posted: November 11th, 2010, 6:20pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

We often get questions from webmasters about how we index content designed for Flash Player, so we wanted to take a moment to update you on some of our latest progress.

About two years ago we announced that through a collaboration with Adobe we had significantly improved Google’s capability to index Flash technology based content. Last year we followed up with an announcement that we had added external resource loading to our SWF indexing capabilities. This work has allowed us to index all kinds of textual content in SWF files, from Flash buttons and menus to self-contained Flash technology based websites. Currently almost any text a user can see as they interact with a SWF file on your site can be indexed by Googlebot and used to generate a snippet or match query terms in Google searches. Additionally, Googlebot can also discover URLs in SWF files and follow those links, so if your SWF content contains links to pages inside your website, Google may be able to crawl and index those pages as well.

Last month we expanded our SWF indexing capabilities thanks to our continued collaboration with Adobe and a new library that is more robust and compatible with features supported by Flash Player 10.1. Additionally, thanks to improvements in the way we handle JavaScript, we are also now significantly better at recognizing and indexing sites that use JavaScript to embed SWF content. Finally, we have made improvements in our video indexing technology, resulting in better detection of when a page has a video and better extraction of metadata such as alternate thumbnails from Flash technology based videos. All in all, our SWF indexing technology now allows us to see content from SWF files on hundreds of millions of pages across the web.

While we’ve made great progress indexing SWF content over the past few years, we’re not done yet. We are continuing to work on our ability to index deep linking (content within a Flash technology based application that is linked to from the same application) as well as further improving indexing of SWF files executed through JavaScript. You can help us improve these capabilities by creating unique links for each page that is linked from within a single Flash object and by submitting a Sitemap through Google Webmaster Tools.

We’re excited about the progress we’ve made so far and we look forward to keeping you updated about further progress.

Written by Jifeng Situ and Sverre Sundsdal, Software Engineers

A Chrome extension for reporting webspam

Posted: November 8th, 2010, 4:08pm CET by Maile Ohye

Tags: feedback and communication

Webmaster Level: All

At Google, we continually strive to improve our algorithms to keep search results relevant and clean. You have been supporting us on this mission by sending spam reports for websites that violate our Webmaster Guidelines, using the spam report form in Google Webmaster Tools. While you might not see changes right away, we take your reports seriously and use them to fine-tune our algorithms -- the feedback is much appreciated and helps us to protect the integrity of our search results. We also take manual action on many of these spam reports. A recent blog post covers more information on how to identify webspam.

For those of you who regularly report spam, or would like to do so, we’ve now published a Chrome extension for reporting spam that makes the process more convenient and simple. The extension adds “Report spam” links to search results and your Web History, taking you directly to the spam report form and autocompleting some form fields for you. With this extension, Google’s spam report form is always just one click away.

The Google Webspam Report Chrome extension provides further tools to help you quickly fill out a spam report:

a browser button to report the currently viewed page
an option to retrieve recent Google searches from your Chrome history
an option to retrieve recently visited URLs from your Chrome history

As before, you need to be logged into your Google Account to report spam. You can find a more detailed walkthrough of the use cases and features in this presentation and on the Chrome Extensions Gallery page, where you can also provide feedback and suggestions. We hope that you find this extension useful and that you continue to help us fight spam.

The extension is available in 16 languages. If your Chrome browser is set to a language supported by the extension, it will automatically use the localized version, otherwise defaulting to English.

Note: We care about your privacy. The Google Webspam Report Chrome extension allows you to access your personal Chrome history for the purpose of reporting spam, but does not send data retrieved from it to our servers. The source code of the extension has been published under an open source license.

Posted by Manuel Holtz, Support Engineer, Search Quality team

How to help Google identify web spam

Posted: November 4th, 2010, 3:00pm CET by Maile Ohye

Tags: feedback and communication

Webmaster level: All

Everyone who uses the web knows how frustrating it is to land on a page that sounds promising in the search results but ends up being useless when you visit it. We work hard to make sure Google’s algorithms catch as much as possible, but sometimes spammy sites still make it into search results. We appreciate the numerous spam reports sent in by users like you who find these issues; the reports help us improve our search results and make sure that great content is treated accordingly. Good spam reports are important to us. Here’s how to maximize the impact of any spam reports you submit:

Why report spam to Google?

Google’s search quality team uses spam reports as a basis for further improving the quality of the results that we show you, to provide a level playing field for webmasters, and to help with our scalable spam fighting efforts. With the release of new tools like our Chrome extension to report spam, we’ve seen people filing more spam reports and we have to allocate appropriate resources to the spam reports that are mostly likely to be useful.

Spam reports are prioritized by looking at how much visibility a potentially spammy site has in our search results, in order to help us focus on high-impact sites in a timely manner. For instance, we’re likely to prioritize the investigation of a site that regularly ranks on the first or second page over that of a site that only gets a few search impressions per month. A spam report for a page that is almost never seen by users is less likely to be reviewed compared to higher-impact pages or sites. We generally use spam reports to help improve our algorithms so that we can not only recognize and handle this particular site, but also cover any similar sites. In a few cases, we may additionally choose to immediately remove or otherwise take action on a site.

Which sites should I report?

We love seeing reports about spammy sites that our algorithms have missed. That said, it’s a poor use of your time to report sites that are not spammy. Sites submitted through the spam report form are reviewed for spam content only. Sites that you think should be tackled for other reasons should be submitted to us through the appropriate channels: for example, for those that contain content which you have removed, use our URL removal tools; for sites with malware, use the malware report form; for paid links that you find on sites, use the paid links reporting form. If you want to report spammy links for a page, make sure that you read how to report linkspam. If you have a complaint because someone is copying your content, we have a different copyright process--see our official documentation pages for more info. There’s generally no need to report sites with technical problems or parked domains because these are typically handled automatically.

The same applies to redirecting legitimate sites from one top level domain to another, e.g. example.de redirecting to example.com/de. As long as the content presented is not spammy, the technique of redirecting one domain to another does not automatically violate the Google Webmaster Guidelines.

If you happen to come across a gibberish site similar to this one, it’s most likely spam.
The best way to submit a compelling spam report is to take a good look at the website in question and compare it against the Google Webmaster Guidelines. For instance, these would be good reasons to report a site through the spam report form:

the cached version contains significantly different (often keyword-rich) content from the live version
you’re redirected to a completely different domain with off-topic, commercial content
the site is filled with auto-generated or keyword-stuffed content that seems to make no sense

These are just a few examples of techniques that might be potentially spammy, and which we would appreciate seeing in the form of a spam report. When in doubt, please feel free to discuss your concerns on the Help Forum with other users and Google guides.

What should I include in a spam report?

Some spam reports are easier to understand than others; having a clear and easy-to-understand report makes it much easier for us to analyze the issue and take appropriate actions. Here are some things to keep in mind when submitting the spam report:

Submit the URLs of the pages where you see spam (not just the domain name). This makes it easy for us to verify the problem on those specific pages.
Try to specify the issue as clearly as possible using the checkboxes. Don’t just check every single box--such reports are less likely to be reviewed.
If only a part of the page uses spammy techniques, for example if it uses cloaking or has hidden text on an otherwise good page, provide a short explanation on how to look for the spam you’re seeing. If you’re reporting a site for spammy backlinks rather than on-page content, mention that.

By following these guidelines, your spam reports will be reproducible and clear, making them easier to analyze on our side.

What happens next?

After reviewing the feedback from these reports (we want to confirm that the reported sites are actually spammy, not just sites that someone didn’t like), it may take a bit of time before we update our algorithms and a change is visible in the search results. Keep in mind that sometimes our algorithms may already be treating those techniques appropriately; for instance, perhaps we’re already ignoring all the hidden text or the exchanged links that you have reported. Submitting the same spam report multiple times is not necessary. Rest assured that we actively review spam reports and take appropriate actions, even if the changes are not immediately visible to you.

With your help, we hope that we can improve the quality of and fairness in our search results for everyone! Thank you for continuing to submit spam reports and feel free to post here or in our Help Forum should you have any questions.

Written by Kaspar Szymanski, Search Quality Strategist & John Mueller, Webmaster Trends Analyst

Make your websites run faster, automatically -- try mod_pagespeed for Apache

Posted: November 3rd, 2010, 10:00am CET by Maile Ohye

Tags: intermediate

Webmaster Level: All

Last year, as part of Google’s initiative to make the web faster, we introduced Page Speed, a tool that gives developers suggestions to speed up web pages. It’s usually pretty straightforward for developers and webmasters to implement these suggestions by updating their web server configuration, HTML, JavaScript, CSS and images. But we thought we could make it even easier -- ideally these optimizations should happen with minimal developer and webmaster effort.

So today, we’re introducing a module for the Apache HTTP Server called mod_pagespeed to perform many speed optimizations automatically. We’re starting with more than 15 on-the-fly optimizations that address various aspects of web performance, including optimizing caching, minimizing client-server round trips and minimizing payload size. We’ve seen mod_pagespeed reduce page load times by up to 50% (an average across a rough sample of sites we tried) -- in other words, essentially speeding up websites by about 2x, and sometimes even faster.

Comparison of the AdSense blog site with and without mod_pagespeed

Here are a few simple optimizations that are a pain to do manually, but that mod_pagespeed excels at:

Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

We’re working with Go Daddy to get mod_pagespeed running for many of its 8.5 million customers. Warren Adelman, President and COO of Go Daddy, says:

"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”

We’re also working with Cotendo to integrate the core engine of mod_pagespeed as part of their Content Delivery Network (CDN) service.

mod_pagespeed integrates as a module for the Apache HTTP Server, and we’ve released it as open-source for Apache for many Linux distributions. Download mod_pagespeed for your platform and let us know what you think on the project’s mailing list. We hope to work with the hosting, developer and webmaster community to improve mod_pagespeed and make the web faster.

Richard Rabbat, Product Manager, ‘Make the Web Faster’ initiative

Rich snippets for shopping sites

Posted: November 2nd, 2010, 2:50pm CET by Maile Ohye

Tags: intermediate

Webmaster Level: All

In time for the holiday season, we now support rich snippets for shopping (e-commerce) sites! As many of you know, rich snippets are search results that have been enhanced using structured data from your web pages. Our new format shows price, availability, and product reviews on pages offering a product for sale. Here’s a result for [office lava lamp]:

As a webmaster, there are two ways that you can provide the information needed for product rich snippets to show up for your site, both described on the Product rich snippets help page:

Option 1: Provide a Merchant Center feed.

Many sites already provide Merchant Center feeds for use in Google Product Search, which means that most of the work needed for rich snippets is already done. For Google to make use of Merchant Center feeds for rich snippets, you should also use the rel=”canonical” link element on your product pages. By adding rel=”canonical” to your pages, Google can match the URLs in your feed to the pages found by our crawler.

Update on November 4, 2010: In order to have your product review information in your rich snippets, you can submit your product ratings directly in your feed, or you can work with one of our reviews partners to submit this information. If you work with a partner, your reviews information will appear in rich snippets, and shoppers on Google Product Search will be able to see your full-length reviews on relevant product pages, branded with your logo.

Option 2: Add markup to your site.

If prices for your products tend to change only infrequently, then adding markup is an alternative method to provide product data for rich snippets. We’ve updated our product markup format to allow a variety of different types of shopping sites to participate. In addition to the Google format, we support two other standards: the hProduct microformat and GoodRelations. You can use the rich snippets testing tool to test your markup and make sure it’s being parsed correctly.

This feature is currently available to merchants located in the US, but we will be rolling it out in more markets soon. Additionally, there are a number of rich snippets formats that can be used world-wide in various languages—make your snippets compelling and useful! Should you have any questions about the use of rich snippets, check out our FAQs and feel free to post in our Webmaster Help Forum.

Q&A

Which should I provide -- a Merchant Center feed or markup?

For most merchants, providing a Merchant Center feed is the best bet. That way your product prices and availability are updated quickly, and the data can be shown in rich snippets as well as in other applications like Google Shopping and Product Ads. If prices and availability change only infrequently, and you don’t want to set up a feed, then adding markup is also a valid option.

If I add markup to my site, will Google show product rich snippets for my pages?

We can’t guarantee that providing a feed or adding markup will result in rich snippets being shown. Note also that it may take a few weeks after providing data for rich snippets to be shown. If you mark up your pages, we encourage you to make sure that the data is parsed correctly by Google by using the rich snippets testing tool. The testing tool updates are rolling out over the next few days, so in this interim period the testing tool may not show previews for some types of markup.

I’ve already done reviews markup for my product offer pages. Should I add product/offer markup as well?

Yes, absolutely. Rich snippets are shown if the information provided accurately represents the main focus of the page. Therefore, for product pages you should add markup using the relevant offer/product fields which can include nested reviews.

Written by Nitin Shetti and Mircea Ciurumelea, Search Quality team

Optimizing sites for TV

Posted: October 20th, 2010, 11:51pm CEST by Maile Ohye

Tags: general tips

Webmaster Level: All

Just as mobile phones make your site accessible to people on the go, Google TV makes your site easily viewable to people lounging on their couch. Google TV is a platform that combines your current TV programming with the web and, before long, more apps. It’s the web you love, with the TV you love, all available on the sofa made for you. Woohoo!

Because Google TV has a fully functioning web browser built in, users can easily visit your site from their TV. Current sites should already work, but you may want to provide your users with an enhanced TV experience -- what's called the “10-foot UI” (user interface). They'll be several feet away from the screen, not several inches away, and rather than a mouse on their desktop, they'll have a remote with a keyboard and a pointing device.

For example, here’s YouTube for desktop users versus what we’re calling “YouTube Leanback” -- our site optimized for large screens:

YouTube desktop version on the left, YouTube Leanback on the right
See our Spotlight Gallery for more examples of TV-optimized sites.

What does "optimized for TV" mean?

It means that, for the user sitting on their couch, your site on their TV is an even more enjoyable experience:

Text is large enough to be viewable from the sofa-to-TV distance.
Site navigation can be performed through button arrows on the remote (a D-pad), rather than mouse/touchpad usage
Selectable elements provide a visual queue when selected (when you’re 10 feet away, it needs to be really, really obvious what selections are highlighted)
and more...

How can webmasters gain a general idea of their site’s appearance on TV?

First, remember that appearance alone doesn't incorporate whether your site can be easily navigated by TV users (i.e. users with a remote rather than a mouse). With that said, here’s a quick workaround to give you a ballpark idea of how your site looks on TV. (For more in-depth info, please see the “Design considerations” in our optimization guide.)

On a large monitor, make your window size 1920 x 1080.
In a browser, visit your site at full screen.
Zoom the browser to 1.5x the normal size. This is performed in different ways with different keyboards. For example, in Chrome if you press ctrl+ (press ctrl and + at the same time) twice, that’ll zoom the browser to nearly 1.5x the initial size.
Move back 3 x (the distance between you and the monitor).
Check out your site!

And don’t forget, if you want to see your site with the real thing, Google TV enabled devices are now available in stores.

How can you learn more?

Our team just published a developer site, with TV optimization techniques, at code.google.com/tv/web/.

Written by Maile Ohye, Developer Programs Tech Lead

Finding Places on the Web: Rich Snippets for Local Search

Posted: September 22nd, 2010, 1:08pm CEST by Maile Ohye

Tags: intermediate

Webmaster Level: All
Cross-posted from the Lat Long Blog.

We’re sharing some news today that we hope webmasters will find exciting. As you know, we’re constantly working to organize the world’s information - be it textual, visual, geographic or any other type of useful data. From a local search perspective, part of this effort means looking for all the great web pages that reference a particular place. The Internet is teeming with useful information about local places and points of interest, and we do our best to deliver relevant search results that help shed light on locations all across the globe.

Today, we’re announcing that your use of Rich Snippets can help people find the web pages you’ve created that may reference a specific place or location. By using structured HTML formats like hCard to markup the business or organization described on your page, you make it easier for search engines like Google to properly classify your site, recognize and understand that its content is about a particular place, and make it discoverable to users on Place pages.

You can get started by reviewing these tips for using Rich Snippets for Local Search. Whether you’re creating a website for your own business, an article on a newly opened restaurant, or a guide to the best places in town, your precise markup helps associate your site with the search results for that particular place. Though this markup does not guarantee that your site will be shown in search results, we’re excited to expand support for making the web better organized around real world places.

Posted by Carter Maslan, Director of Product Management, Local Search

Video Sitemaps: Is your video part of a gallery?

Posted: September 17th, 2010, 5:45pm CEST by Maile Ohye

Tags: sitemaps

Webmaster Level: All

Often a website which hosts videos will have a common top-level page that groups conceptually related videos together. Such a page may be of interest to a user searching on that subject. Sites with many videos about a single subject can group these videos together on a top-level page, often known as a gallery. This can make it easier for users to find exactly what they're looking for. In this case, you can use a Sitemap to tell Google the URL of the gallery page on which each video appears.

You can specify the URL of the gallery level page using the optional tag <video:gallery_loc> on a per-video basis. Note that only one gallery_loc is allowed per video.

For more information on Google Videos, including Sitemap specifications, please visit our Help Center. To post questions and search for answers, check out our Help Forum.

Posted by Nelson Lee, Product Manager, Video Search

Unifying content under multilingual templates

Posted: September 9th, 2010, 2:56am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Advanced

If you have a global site containing pages where the:

template (i.e. side navigation, footer) is machine-translated into various languages,
main content remains unchanged, creating largely duplicate pages,

and sometimes search results direct users to the wrong language, we’d like to help you better target your international/multilingual audience through:

<link rel=”alternate” hreflang="a-different-language" href="http://url-of-the-different-language-page" />

As you know, when rel=”canonical” or a 301 response code is properly implemented, we become more precise in clustering information from duplicate URLs, such as consolidating their linking properties. Now, when rel=”alternate” hreflang=”x” is included in conjunction with rel=”canonical” or 301s, not only will our indexing and linking properties be more accurate, but we can better serve users the URL of their preferred language.

Sample configuration that’s prime for rel=”alternate” hreflang=”x”

How does this all work? Imagine that you’re the proud owner of example.com, a site called “The Network” where you allow users to create their very own profile. Let’s say Javier Lopez, a Spanish speaker, makes his page at http://es.example.com/javier-lopez:

Because you’re trying to target a multilingual audience, once Javier hits “Publish,” his profile becomes immediately available in other languages with the translated templates. Also, each of the new language versions is served on a separate URL.

Two localized versions, http://en.example.com/javier-lopez in English and http://fr.example.com/javier-lopez in French
Background on the old issue: duplicate content caused by language variations

The configuration above allowed visitors speaking different languages to more easily interpret the content, but for search engines it was slightly problematic: there are three URLs (English, French, and Spanish versions) for the same main content in Javier’s profile. Webmasters wanted to avoid duplicate content issues (such as PageRank dilution) from these multiple versions and still ensure that we would serve the appropriate version to the user.

A new solution for localized templates

First of all, just to be clear, the strategy we’re proposing isn’t appropriate for multilingual sites that completely translate each page’s content. We’re trying to specifically improve the situation where the template is localized but the main content of a page remains duplicate/identical across language/country variants.

Before we get into the specific steps, our prior advice remains applicable:

Have one URL associated with one piece of content. We recommend against using the same URL for multiple languages, such as serving both French and English versions on example.com/page.html based on user information (IP address, Accept-Language HTTP header).

When multiple languages are at play, it’s best to include the language or country indication in the URL, e.g., example.com/en/welcome.html and example.com/fr/accueil.html (which specify “en” and “fr”) rather than example.com/welcome.html and example.com/accueil.html (which don’t contain an explicit country/language specification). More suggestions can be found in our blog posts about designing localized URLs and multilingual sites.

For the new feature:

Step 1: Select the proper canonical.
The canonical designates the version of your content you’d like indexed and returned to users.
The first step towards making the right content indexable is to pick one canonical URL that best reflects the genuine locale of the page’s main content. In the example above, since Javier is a Spanish-speaking user and he created his profile on es.example.com, http://es.example.com/javier-lopez is the logical canonical. The title and snippet in all locales will be selected from the canonical URL.

Once you have the canonical URL picked out, you can either:
A. 301 (permanent redirect) from the language variants to the canonical

As an example, if a French speaker visits fr.example.com/javier-lopez (not the canonical), have this page include a cookie to remember the user's language preference of French. Then permanently redirect from fr.example.com/javier-lopez to the canonical at es.example.com/javier-lopez. Because of the cookie, es.example.com/javier-lopez will still render its boilerplate in French (even on the es.example.com subdomain!). Similarly, en.example.com/javier-lopez would set the value of this cookie to English and then 301 redirect to es.example.com/javier-lopez.

Including a language selection link is also helpful should a multilingual user prefer a different experience of your site.

B. Use rel=”canonical”

On the other language variants, include a link rel=”canonical” tag pointing to your chosen canonical. In our example, since the canonical for Javier’s profile is the Spanish version, the English and French pages (and optionally even the Spanish page itself) would include <link rel=”canonical” href="http://es.example.com/javier-lopez" />.

Cookies are not involved in this setup. Therefore, a French speaker will be served es.example.com/javier-lopez with a Spanish template. Implement step 2 if you want the French speakers to be served the French version at fr.example.com/javier-lopez in Google search results.
Step 2: In the canonical URL, specify the various language versions via the rel=”alternate” link tag, using its hreflang attribute.

rel=”alternate” URLs can be displayed in search results in accordance with a user’s language preference. The title and snippet, however, remain generated from the canonical URL (as is customary with rel=”canonical”), not from the content of any rel=”alternate”.
You can help Google display the correctly localized variant of your URL to our international users by adding the following tags to http://es.example.com/javier-lopez, the selected canonical:

<link rel=”alternate” hreflang="en" href="http://en.example.com/javier-lopez" />

<link rel=”alternate” hreflang="fr" href="http://fr.example.com/javier-lopez" />

rel=”alternate” indicates that the URL contains an alternate version located at the URI of the href value. hreflang identifies the language code of the alternate URL and can be specified with ISO-639.

Please note: If your site supports many languages and you’re worried about the increased file size when declaring numerous rel=”alternate” URLs, please see our Help Center article about configuring rel=”alternate” with file size constraints.

Once the steps are completed, the configuration on “The Network” would look like this:

http://en.example.com/javier-lopez
either 301s with a language cookie or contains <link rel=”canonical” href=”http://es.example.com/javier-lopez” />
http://fr.example.com/javier-lopez
either 301s with a language cookie or contains <link rel=”canonical” href=”http://es.example.com/javier-lopez” />
http://es.example.com/javier-lopez
is the canonical and contains
<link rel=”alternate” hreflang="en" href="http://en.example.com/javier-lopez" />
and
<link rel=”alternate” hreflang="fr" href="http://fr.example.com/javier-lopez" />

Results of the above implementation

When your content is returned in search results, users will likely see the URL that corresponds to their language preference, whether or not it’s the canonical. (Good news!) This is because with with rel=”canonical” or a 301 redirect, we can cluster the language variations with the canonical. With rel=”alternate” hreflang=”x” at serve-time we can deliver the URL of the most appropriate language to the user: English speakers will be served en.example.com/javier-lopez as the result for the URL in Javier’s profile, French speakers will see fr.example.com/javier-lopez, Spanish speakers will see es.example.com/javier-lopez.

By implementing step 1, only content from the canonical version will be available for users in search results (i.e. content from the duplicate versions won’t be searchable). Because the Spanish version es.example.com/javier-lopez is the canonical, queries that include template content from this page, e.g. [Javier Lopez familia] -- when using any language preference -- may return his profile (content from the canonical version). On the other hand, queries that include template content of the “duplicate” version, e.g. [Javier Lopez family], are less likely to return his profile page. If you would like the other language versions indexed separately and searchable, avoid using rel=”canonical” and rel=”alternate”.

Indexing properties, such as linking information, from the duplicate language variants will be consolidated with the canonical.

To recap (one more time, with feeling!)

For sites that have their template localized but the keep their pages’ main content untranslated:

Step 1: Once you have the canonical picked out you can use either rel=”canonical” or a 301 (permanent redirect) from the various localized pages to the canonical URL.

Step 2: On the canonical URL, specify the language-specific duplicated content with different boilerplate via the rel=”alternate” link tag, using its hreflang attribute. This way, Google can show the correctly-localized variant of your URLs to our international users.

We realize this can be a little complicated, so if you have questions, please ask in our webmaster forum!

Written by Surabhi Gupta, Joachim Kupke & Jayesh Vyas, Search Localization and Indexing Teams

Google Instant: Impact on Search queries

Posted: September 8th, 2010, 12:15pm CEST by Maile Ohye

Tags: webmaster tools

Webmaster Level: All

Webmasters, you may notice some changes in you Search queries data due to the launch of Google Instant. With Google Instant, the page updates dynamically to show results for the top completion of what the user has typed, so this means people could be seeing and visiting your website much faster than before, and often without clicking the search button or hitting “enter.”

While the presentation of the search results may change, our most important advice to webmasters remains the same: Users want to visit pages with compelling content and a great user experience.
With Google Instant, you may notice an increase in impressions because your site will appear in search results as users type.

Impressions are measured in three ways with Google Instant:

Your site is displayed in search results as a response to a user’s completed query (e.g. by pressing “enter” or selecting a term from autocomplete). This is the traditional model.

With Google Instant, we also measure impressions in these new cases:

The user begins to type a term on Google and clicks on a link on the page, such as a search result, ad, or a related search.

The user stops typing, and the results are displayed for a minimum of 3 seconds.

To give an example, let’s say your site has lots of impressions for [hotels] and [hotels in santa cruz]. Now, because Instant is quickly fetching results as the user types, the user could see your site in the search results for [hotels] after typing only the partial query [hote]. If a user types the partial query [hote] and then clicks on any result on the page for [hotels], that counts as an impression for your site. That impression will appear in Webmaster Tools for the query [hotels]. The term 'hotels' would also be included in the HTTP referrer when the user clicks through to visit your website.

It’s likely that your site will still see impressions for queries like [hotels in santa cruz], but because Instant is helping the user find results faster, your site may see an increase in impressions for shorter terms as well.

Let us know if we can help you better understand how these changes impact Webmaster Tools, measured Search queries and impressions, CTR, or anything else. We’d love to hear from you in our blog comments or Webmaster Help Forum.

Guest post by Doantam Phan, Instant Search Team

Rich snippets: testing tool improvements, breadcrumbs, and events

Posted: September 2nd, 2010, 6:57pm CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

Since the initial roll-out of rich snippets in 2009, webmasters have shown a great deal of interest in adding markup to their web pages to improve their listings in search results. When webmasters add markup using microdata, microformats, or RDFa, Google is able to understand the content on web pages and show search result snippets that better convey the information on the page. Thanks to steady adoption by webmasters, we now see more than twice as many searches with rich snippets in the results in the US, and a four-fold increase globally, compared to one year ago. Here are three recent product updates.

Testing tool improvements

Despite the healthy adoption rate by webmasters so far, implementing the rich snippets markup correctly can still be a major challenge. To help address this, we’ve added new error messages to the rich snippets testing tool to help you better identify and fix any problems with the markup.

If you’ve added markup in the past but haven’t seen rich snippets appear for your site, we encourage you to take a few minutes to try testing the markup again on the updated testing tool.

Rich snippets markup for breadcrumbs

Last year, Google announced a modification to search results to begin showing site hierarchies (typically referred to as "breadcrumbs") rather than standard URLs in cases where it helped users to better understand a website:

We are now adding support for a Breadcrumbs markup format that allows webmasters to explicitly identify the breadcrumb hierarchy on their pages.

If the breadcrumbs UI is already showing for your site, we'll continue to show it even if you don't do the markup, so don't worry about any existing UI disappearing. Note that this new format is experimental. Based on feedback and on other available standards, this format may be modified or replaced in the future. As with other rich snippet types, while markup helps us to better understand the content on your site, it does not guarantee that the breadcrumbs UI will be shown for your web pages in search results.

Events

In January, we added support for rich snippets for events. If a web page containing events listings showed up in search results, up to three links to specific events could be shown in the search result snippet.

This works well for general queries like [concerts in seattle], but we also wanted to improve the search experience when searching for a specific event. We will now show rich snippets when pages containing a single event show up in search results. Single event rich snippets now contain the date and location of the event:

For instructions on adding events markup, refer to the events page in the rich snippets documentation.

Posted by Kavi Goel and Pravir Gupta, Search Quality team

Google now indexes SVG

Posted: September 1st, 2010, 1:30am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

You can now use Google search to find SVG documents. SVG is an open, XML-based format for vector graphics with support for interactive elements. We’re big fans of open standards, and our mission is to organize the world’s information, so indexing SVG is a natural step.

We index SVG content whether it is in a standalone file or embedded directly in HTML. The web is big, so it may take some time before we crawl and index most SVG files, but as of today you may start seeing them in your search results. If you want to see it yourself, try searching for [sitemap site:fastsvg.com] or [HideShow site:svg-whiz.com]

If you host SVG files and you wish to exclude them from Google’s search results, you can use the “X-Robots-Tag: noindex” directive in the HTTP header.

Check out Webmaster Central for a full list of file types we support.

Posted by Bogdan Stanescu and John Sarapata, Software Engineers

To err is human, Video Sitemap feedback is divine!

Posted: August 17th, 2010, 12:06am CEST by Maile Ohye

Tags: webmaster tools

Webmaster Level: All

You can now check your Video Sitemap for even more errors right in Webmaster Tools! It’s a new Labs feature to signal issues in your Video Sitemap such as:

URLs disallowed by robots.txt
Thumbnail size errors (160x120px is ideal. Anything smaller than 90x50 will be rejected.)

Video Sitemaps help us to better crawl and extract information about your videos, so we can appropriately feature them in search results.

Totally new to Video Sitemaps? Check out the Video Sitemaps center for more information. Otherwise, take a look at this new Labs feature in Webmaster Tools.

Written by Jackie Lai, Video Search Team

Video Sitemaps: Understanding location tags

Posted: August 16th, 2010, 12:41am CEST by Maile Ohye

Tags: sitemaps

Webmaster Level: All

If you want to add video information to a Sitemap or mRSS feed you must specify the location of the video. This means you must include one of two tags, either the video:player_loc or video:content_loc. In the case of an mRSS feed, these equivalent tags are media:player or media:content, respectively. We need this information to verify that there is actually a live video on your landing page and to extract metadata and signals from the video bytes for ranking. If one of these tags is not included we will not be able to verify the video and your Sitemap/mRSS feed will not be crawled. To reduce confusion, here is some more detail about these elements.

Video Locations Defined

Player Location/URL: the player (e.g., .swf) URL with corresponding arguments that load and play the actual video.

Content Location/URL: the actual raw video bytes (e.g., .flv, .avi) containing the video content.

The Requirements

One of either the player video:player_loc or content video:content_loc location is required. However, we strongly suggest you provide both, as they each serve distinct purposes: player location is primarily used to help verify that a video exists on the page, and content location helps us extract more signals and metadata to accurately rank your videos.

URL extensions at a glance:
.nobrtable br { display: none }

Sitemap: mRSS: Contents:
<loc> <link> The playpage URL
<video:player_loc>

<media:player> (url attribute) The SWF URL
<video:content_loc> <media:content> (url attribute) The FLV or other raw video URL

NOTE: All URLs should be unique (every URL in your entire Video Sitemap and mRSS feed should be unique)

If you would like to better ensure that only Googlebot accesses your content, you can perform a reverse DNS lookup.

For more information on Google Videos please visit our Help Center, and to post questions and search for answers check out our Help Forum.

Posted by Nelson Lee, Product Manager, Video Search

Video Sitemaps 101: Making your videos searchable

Posted: July 16th, 2010, 11:20am CEST by Maile Ohye

Tags: sitemaps

Webmaster Level: All

We know that some of you, or your clients or colleagues, may be new to online video publishing. To make it easier for everyone to understand video indexing and Video Sitemaps, we’ve created a video -- narrated by Nelson Lee, Video Search Product Manager -- that explains everything in basic terms:

Also, last month we wrote about some best practices for getting video content indexed on Google. Today, to help beginners better understand the whys and hows of implementing a Video Sitemap, we added a starting page to the information on Video Sitemaps in the Webmaster Help Center. Please take a look and share your thoughts.

Posted by Amy MacIsaac, Content Partnerships

Quality links to your site

Posted: June 21st, 2010, 12:00pm CEST by Maile Ohye

Tags: webmaster guidelines

A popular question on our Webmaster Help Forum is in regard to best practices for organic link building. There seems to be some confusion, especially among less experienced webmasters, on how to approach the topic. Different perspectives have been shared, and we would also like to explain our viewpoint on earning quality links.

If your site is rather new and still unknown, a good way marketing technique is to get involved in the community around your topic. Interact and contribute on forums and blogs. Just keep in mind to contribute in a positive way, rather than spamming or soliciting for your site. Just building a reputation can drive people to your site. And they will keep on visiting it and linking to it. If you offer long-lasting, unique and compelling content -- something that lets your expertise shine -- people will want to recommend it to others. Great content can serve this purpose as much as providing useful tools.

A promising way to create value for your target group and earn great links is to think of issues or problems your users might encounter. Visitors are likely to appreciate your site and link to it if you publish a short tutorial or a video providing a solution, or a practical tool. Survey or original research results can serve the same purpose, if they turn out to be useful for the target audience. Both methods grow your credibility in the community and increase visibility. This can help you gain lasting, merit-based links and loyal followers who generate direct traffic and "spread the word." Offering a number of solutions for different problems could evolve into a blog which can continuously affect the site's reputation in a positive way.

Humor can be another way to gain both great links and get people to talk about your site. With Google Buzz and other social media services constantly growing, entertaining content is being shared now more than ever. We've seen all kinds of amusing content, from ASCII art embedded in a site's source code to funny downtime messages used as a viral marketing technique to increase the visibility of a site. However, we do not recommend counting only on short-lived link-bait tactics. Their appeal wears off quickly and as powerful as marketing stunts can be, you shouldn't rely on them as a long-term strategy or as your only marketing effort.

It's important to clarify that any legitimate link building strategy is a long-term effort. There are those who advocate for short-lived, often spammy methods, but these are not advisable if you care for your site's reputation. Buying PageRank-passing links or randomly exchanging links are the worst ways of attempting to gather links and they're likely to have no positive impact on your site's performance over time. If your site's visibility in the Google index is important to you it's best to avoid them.

Directory entries are often mentioned as another way to promote young sites in the Google index. There are great, topical directories that add value to the Internet. But there are not many of them in proportion to those of lower quality. If you decide to submit your site to a directory, make sure it's on topic, moderated, and well structured. Mass submissions, which are sometimes offered as a quick work-around SEO method, are mostly useless and not likely to serve your purposes.

It can be a good idea to take a look at similar sites in other markets and identify the elements of those sites that might work well for yours, too. However, it's important not to just copy success stories but to adapt them, so that they provide unique value for your visitors.

Social bookmarks on YouTube enable users to share content easily

Finally, consider making linking to your site easier for less tech savvy users. Similar to the way we do it on YouTube, offering bookmarking services for social sites like Twitter or Facebook can help spread the word about the great content on your site and draw users' attention.

As usual, we'd like to hear your opinion. You're welcome to comment here in the blog, or join our Webmaster Help Forum community.

Written by Kaspar Szymanski, Search Quality Strategist, Dublin

Google Videos best practices

Posted: June 11th, 2010, 7:00pm CEST by Maile Ohye

Webmaster Level: All

We'd like to highlight three best practices that address some of the most common problems found when crawling and indexing video content. These best practices include ensuring your video URLs are crawlable, stating what countries your videos may be played in, and that if your videos are removed, you clearly indicate this state to search engines.

Best Practice 1: Verify your video URLs are crawlable: check your robots.txt
- Sometimes publishers unknowingly include video URLs in their Sitemap that are robots.txt disallowed. Please make sure your robots.txt file isn't blocking any of the URLs specified in your Sitemap. This includes URLs for the:
  - Playpage
  - Content and player
  - Thumbnail
  More information about robots.txt.
Best Practice 2: Tell us what countries the video may be played in
- Is your video only available in some locales? The optional attribute “restriction” has recently been added (documentation at [www.google.com]), which you can use to tell us whether the video can only be played in certain territories. Using this tag, you have the option of either including a list of all countries where it can be played, or just telling us the countries where it can't be played. If your videos can be played everywhere, then you don't need to include this.
Best Practice 3: Indicate clearly when videos are removed -- protect the user experience
- Sometimes publishers take videos down but don't signal to search engines that they've done so. This can result in the search engine's index not accurately reflecting content of the web. Then when users click on a search result, they're taken to a page either indicating that the video doesn't exist, or to a different video. Users find this experience dissatisfying. Although we have mechanisms to detect when search results are no longer available, we strongly encourage following community standards.
  
  To signal that a video has been removed,
  1. Return a 404 (Not found) HTTP response code, you can still return a helpful page to be displayed to your users. Check out these guidelines for creating useful 404 pages.
  2. Indicate expiration dates for each video listed in a Video Sitemap (use the <video:expiration_date> element) or mRSS feed (<dcterms:valid> tag) submitted to Google.

For more information on Google Videos please visit our Help Center, and to post questions and search answers check out our Help Forum.

Posted by Nelson Lee, Product Manager, Video Search

Chrome Extensions for web development

Posted: May 27th, 2010, 12:00pm CEST by Maile Ohye

Tags: general tips

Webmaster Level: All

The Chrome Developer Tools are great for debugging HTML, JavaScript and CSS in Chrome. If you're writing a webpage or even a web app for the Chrome Web Store, you can inspect elements in the DOM, debug live JavaScript, and edit CSS styles directly in the current page. Extensions can make Google Chrome an even better web development environment by providing additional features that you can easily access in your browser. To help developers like you, we created a page that features extensions for web development. We hope you’ll find them useful in creating applications and sites for the web.

For example, Speed Tracer is an extension to help you identify and fix performance issues in your web applications. With Speed Tracer, you can get a better idea of where time is being spent in your application and troubleshoot problems in JavaScript parsing and execution, CSS style, and more.

Another useful extension is the Resolution Test that changes the size of the browser window, so web developers can preview websites in different screen resolutions. It also includes a list of commonly used resolutions, as well as a custom option to input your own resolution.

With the Web Developer extension, you can access additional developer tools such as validation options, page resizing and a CSS elements viewer; all from an additional button in the toolbar.

Another extension you should check out is the Chrome Editor that allows you to easily code within your browser, so you don’t have to flip between your browser and code editor. You can also save a code reference locally to your computer for later use.

These are just a few of the extensions you can find in our extensions for web development page. You can also look for more in the extensions gallery.

Written by Koh Kim, Google Chrome Team

Call for webspam reports in Thai, Indonesian, Romanian, Czech and Farsi

Posted: May 5th, 2010, 1:12pm CEST by Maile Ohye

Tags: feedback and communication

Webmaster Level: All

Update on May 19, 2010: We have several translated versions of this post! If you're more comfortable reading Thai, Indonesian, Romanian, Czech, or Farsi, the links above will take you to your preferred version. Thanks again for your help.

We pay attention to dozens of different languages in our spam fighting, but sometimes we really want to drill down and concentrate on a small number of languages. We’d like to ask for your help to identify webspam in Thai, Indonesian, Romanian, Czech and Farsi. If you know of sites that violate our webmaster guidelines in these languages, please send us a spam report. We use this information not only to look at the sites listed in reports, but also to improve our effectiveness in the rest of your language on the web.

Thanks in advance for any data you send our way about spam in these languages. Of course, you’re always welcome to submit spam reports in other languages too!

Written by Viktor Nebehaj and Matt Cutts, Search Quality Team

You and site performance, sitting in a tree...

Posted: May 2nd, 2010, 11:17pm CEST by Maile Ohye

Tags: performance

Webmaster Level: Beginner to Intermediate

...k, i, s, s, i, n, g! Perhaps you heard our announcement that speed is a signal in rankings, but didn’t know where to start. We’d like to help foster a lasting relationship between you and a responsive experience for your users. Last week I filmed my updated presentation from "The Need For Speed: Google Says It Matters" which includes three first steps to understanding site performance. So grab headphones and some popcorn, then verify ownership of your website and download a plugin, and we’ll all be comfy with site performance in no time.

Just curious about the Q&A? No problem! Here you go:

Is it possible to check my server response time from different areas around the world?

Yes. WebPagetest.org can test performance from the United States (both East and West Coast—go West Coast! :), United Kingdom, China, and New Zealand.

What's a good response time to aim for?

First, if your competition is fast, they may provide a better user experience than your site for your same audience. In that case, you may want to make your site better, stronger, faster...

Otherwise, studies by Akamai claim 2 seconds as the threshold for ecommerce site "acceptability." Just as an FYI, at Google we aim for under a half-second.

Does progressive rendering help users?

Definitely! Progressive rendering is when a browser can display content as it’s available incrementally rather than waiting for all the content to display at once. This provides users faster visual feedback and helps them feel more in control. Bing experimented with progressive rendering by sending users their visual header (like the logo and searchbox) quickly, then the results/ads once they were available. Bing found a 0.7% increase in satisfaction with progressive rendering. They commented that this improvement compared with full feature rollout.

How can you implement progressive rendering techniques on your site? Put stylesheets at the top of the page. This allows a browser to start displaying content ASAP.

Page speed plugin, videos, articles, and help forum are all found at code.google.com/speed/.

Written by Maile Ohye, Developer Programs Tech Lead

Rich snippets go international

Posted: April 26th, 2010, 6:51pm CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

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

To slash or not to slash

Posted: April 21st, 2010, 11:05am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Intermediate

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:

http://<your-domain-here>/<some-directory-here>/
(with trailing slash)
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?

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.

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).

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.

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.

Check for Crawl errors in Webmaster Tools, and, if possible, your webserver logs as a sanity check that the 301s are implemented.

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

Help Google index your videos

Posted: April 19th, 2010, 7:12pm CEST by Maile Ohye

Webmaster Level: All

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

Webmasters - configure Google services at your hosting panel

Posted: April 15th, 2010, 10:34am CEST by Maile Ohye

Tags: products and services

Webmaster Level: All

Today, as announced on the Official Google Blog, we’ve taken an additional step to improve access to Google webmaster services. Parallels, one of the leading providers of control panel software to hosting companies, has integrated Google Services for Websites into Parallels Plesk Panel, used by millions of website owners globally to manage their websites.

If you use Plesk for managing your hosting and website services, you can easily configure Webmaster Tools, Custom Search, Site Search, Web Elements and AdSense for your website right from within Plesk.

Since Plesk knows what domains you own, it automatically registers your domains to Webmaster Tools and allows you to automatically login to the Webmaster Tools console to verify your sites, as shown below.

We’re always trying to make our tools easier to use and easier to access. Since you’re probably visiting your hosting control panel on a regular basis, we hope that you find this integration convenient. If you have feedback please let us know in the Webmaster Forum.

Posted by Jonathan Simon, Webmaster Trends Analyst

Better recipes on the web: Introducing recipe rich snippets

Posted: April 13th, 2010, 7:50pm CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

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

Using site speed in web search ranking

Posted: April 9th, 2010, 1:00pm CEST by Maile Ohye

Tags: performance

Webmaster Level: All

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

Adding Images to your Sitemaps

Posted: April 7th, 2010, 3:30pm CEST by Maile Ohye

Tags: sitemaps

Webmaster Level: All

Sitemaps are an invaluable resource for search engines. They can highlight the important content on a site and allow crawlers to quickly discover it. Images are an important element of many sites and search engines could equally benefit from knowing which images you consider important. This is particularly true for images that are only accessible via JavaScript forms, or for pages that contain many images but only some of which are integral to the page content.

Now you can use a Sitemaps extension to provide Google with exactly this information. For each URL you list in your Sitemap, you can add additional information about important images that exist on that page. You don’t need to create a new Sitemap, you can just add information on images to the Sitemap you already use.

Adding images to your Sitemaps is easy. Simply follow the instructions in the Webmaster Tools Help Center or refer to the example below:

<?xml version="1.0" encoding="UTF-8"?>
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
   xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>http://example.com/sample.html</loc>
    <image:image>
        <image:loc>http://example.com/image.jpg</image:loc>
    </image:image>
  </url>
</urlset>

We index billions of images and see hundreds of millions of image-related queries each day. To take advantage of that traffic most effectively, take a moment to update your Sitemap file with information on the images from your site. Let us know in the Sitemaps forum if you have any questions.

Posted by Alkis Evlogimenos, Software Engineer

A word on site clinics

Posted: April 2nd, 2010, 5:50pm CEST by Maile Ohye

Webmaster Level: All

We try to communicate with webmasters in lots of different places. For example, when we send representatives to conferences we’re happy to participate in public site clinics where we share best practices on how to improve the crawlability and site architecture of websites suggested by the audience.

However, we also want to help users who can’t or don’t want to attend search conferences. To reach more people, we started doing free virtual site clinics in languages other than English. These site clinics help site owners make websites in such a way that they are more easily crawled, indexed, and returned by search engine crawlers, which in turn helps webmasters gain more visibility on the web.

We did a series of free virtual site clinics in Spanish last year which spanned 5 blog posts. The clinics covered real problems on real sites, and we posted the results on the Spanish Webmaster Central blog. If you read Spanish, I recommend you go read the different posts covering everything from issues with framed sites, to more technical domain setup.

In some countries we don’t have dedicated webmaster-focused blogs, but we still want to help webmasters in those countries. That means that you might occasionally see site clinic or webmaster-related posts on AdWords blogs such as the forthcoming ones on the Nordic AdWords blogs (which cover Danish, Finnish, Norwegian and Swedish). Recently when we posted some advice for webmasters on one of our AdWords blogs, we received questions about the relationship between Google’s search and advertising programs. We wanted to again reassure our users that the ranking of Google’s organic search results is entirely separate from our advertising programs. Furthermore, we do not give any preference to AdWords customers in our site clinics - everybody is welcome to participate. We’re simply posting this on local “AdWords” blogs because it’s the best way for us to reach webmasters in those communities and languages.

Written by Jonas Voss, Search Quality Team

Sharing advice from our site clinic

Posted: March 15th, 2010, 9:55am CET by Maile Ohye

Tags: events

Webmaster Level: All

Members of the Google Search Quality Team have participated in site clinic panels on a number of occasions. We receive a lot of positive feedback from these events and we've been thinking of ways to expand our efforts to reach even more webmasters. We decided to organize a small, free of charge pilot site clinic at Google in Dublin, and opened the invitation to webmasters from the neighborhood. The response we received was overwhelming and exceeded our expectations.

Meet the Googlers who hosted the site clinic: Anu Ilomäki, Alfredo Pulvirenti, Adel Saoud, Fili Wiese, Kaspar Szymanski and Uli Lutz.

It was fantastic to see the large turnout and we would like to share the slides presented as well as the takeaways.

These are some questions we came across, along with the advice shared:

I have 3 blogs with the same content, is that a problem?

If the content is identical, it's likely only one of the blogs will rank for it. Also, with this scattered of an effortwith this scattered of an effort chances are your incoming links will be distributed across the different blogs, instead of pointing to one source. Therefore you're running the risk of both users and search engines not knowing which of your blogs is the definitive source. You can mitigate that by redirecting to the preferred version or using the cross domain canonical to point to one source.

Should I believe SEO agencies that promise to make my site rank first in Google in a few months and with a precise number of links?

No one can make that promise; therefore the short answer is no, you should not. However, we have some great tips on how to find a trustworthy SEO in our Help Center.

There are keywords that are relevant for my website, but they're inappropriate to be shown in the content e.g. because they could be misunderstood, slang or offensive. How can I show the relevance to Google?

Depending on the topic of your site and expectations of the target group, you might consider actually using these keywords in a positive way, e.g. explaining their meaning and showing your users you're an authority on the subject. However if the words are plain abusive and completely inappropriate for your website, it's rather questionable whether the traffic resulting from these search queries is interesting for your website anyway.

Would you advise to use the rewrite URL function?

Some users may like seeing descriptive URLs in the search results. However, it's quite hard to correctly create and maintain rewrites that change dynamic URLs to static-looking URLs. That's why, generally speaking, we don't recommend rewriting them. If you still want to give it a try, please be sure to remove unnecessary parameters while maintaining a dynamic-looking URL and have a close look at our blog post on this topic. And if you don't, keep in mind that we might still make your URLs look readable in our search results no matter how weird they actually are.

If I used the geo-targeting tool for Ireland, is Northern Ireland included?

Google Webmaster Tools geo-targeting works on a country basis, which means that Northern Ireland would not be targeted if the setting was Republic of Ireland. One possible solution is to create a separate site or part of a website for Northern Ireland and to geo-target this site to the United Kingdom in Webmaster Tools.

Is there any preference between TLDs like .com and .info in ranking?

No, there is none. Our focus is on the content of the site.

I have a website on a dot SO (.so) domain name with content meant for the Republic of Ireland. Will this hurt my rankings in the Irish search results?

.so is the Internet country code top-level domain for Somalia. This is one factor we look into not pointing to the desired destination. But we do look at a larger number of factors when ranking your website. The extension of the domain name is just one of these. Your website can still rank in the Irish search results if you have topic-specific content. However, keep in mind that it may take our algorithms a little bit longer to fully understand where to best serve your website in our search results.

We would like to thank all participants for their time and effort. It was a pleasure to help you and we hope that it was beneficial for you, too. For any remaining questions, please don't hesitate to join the community on our GWHF.

Posted by Kaspar Szymanski, Search Quality Strategist, Dublin

Microdata support for Rich Snippets

Posted: March 9th, 2010, 6:51pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

HTML5 is the fifth major revision of HTML, the core language of the World Wide Web. The HTML5 specification includes a description of microdata, a new markup standard for specifying structured information within web pages.

Today, we’re happy to announce support for microdata for use in rich snippets in addition to our existing support for microformats and RDFa. By using microdata markup in your web pages, you can specify reviews, people profiles, or events information on your web pages that Google may use to improve the presentation of your pages in Google search results.

Here is a simple HTML block showing a section of a review of “L’Amourita Pizza”:

Here is the same HTML with microdata added to specify the restaurant being reviewed, the author and date of the review, and the rating:

Microdata has the nice property of balancing richness with simplicity. As you can see, it’s easy to add markup to your pages using a few HTML attributes like itemscope (to define a new item), itemtype (to specify the type of item being described), and itemprop (to specify a property of that item). Once you’ve added markup to a page, you can test it using the rich snippets testing tool to make sure that Google can parse the data on your page.

As with microformats and RDFa, the vocabulary that we support -- including which item types and item properties are understood by Google -- is specified in our rich snippets documentation as well as on data-vocabulary.org. Marking up your content does not guarantee that rich snippets will show for your site; Google will expand the use of microdata markup gradually to ensure a great user experience.

To get started, here are some helpful links:

Written by Siddhartha Chattopadhyay, Kavi Goel, Ramanathan V. Guha, Pravir Gupta, Othar Hansson

Google's SEO Report Card

Posted: March 2nd, 2010, 5:02pm CET by Maile Ohye

Tags: feedback and communication

Webmaster Level: All

How many of Google's web pages use a descriptive title tag? Do we use description meta tags? Heading tags? While we always try to focus on the user, could our products use an SEO tune up? These are just some of the questions we set out to answer with Google's SEO Report Card.

Google's SEO Report Card is an effort to provide Google's product teams with ideas on how they can improve their products' pages using simple and accepted optimizations. These optimizations are intended to not only help search engines understand the content of our pages better, but also to improve our users' experience when visiting our sites. Simple steps such as fixing 404s and broken links, simplifying URL choice, and providing easier-to-understand titles and snippets for our pages can benefit both users and search engines. From the start of the project we also wanted to release the report card publicly so other companies and webmasters could learn from the report, which is filled with dozens of examples taken straight from our products' pages.

The project looked at the main pages of 100 different Google products, measuring them across a dozen common optimization categories. Future iterations of the project might look at deeper Google product web pages as well as international ones. We released the report card within Google last month and since then a good number of teams have taken action on it or plan to.

We hope you find our SEO Report Card useful and we'd love to hear your feedback in the comments below or in the Webmaster Central Help Forum. And if you'd like to do your own SEO tune up, a good place to start is by reading our free SEO Beginner's Guide.

Written by Brandon Falls, Adi Goradia, and Charlene Perez, Search Quality Team

Introducing a new Rich Snippets format: Events

Posted: January 22nd, 2010, 11:20am CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

Last year we introduced Rich Snippets, a new feature that makes it possible to surface structured data from your pages on Google's search results. So far, user reaction to Rich Snippets has been enthusiastic -- after all, Rich Snippets help people make more informed clicks and find what they need even faster.

We originally introduced Rich Snippets with two formats: reviews and people. Later in the year we added support for marking up video information which is used to improve Video Search. Today, we're excited to kick off the new year by adding support for events.

Events markup is based off of the hCalendar microformat. Here's an example of what the new events Rich Snippets will look like:

The new format shows links to specific events on the page along with dates and locations. It provides a fast and convenient way for users to determine if a page has events they may be interested in.

If you have event listings on your site, we encourage you to review the events documentation we've prepared to help you get started. Please note, however, that marking up your content is not a guarantee that Rich Snippets will show for your site. Just as we did for previous formats, we will take a gradual approach to incorporating the new event snippets to ensure a great user experience along the way.

Stay tuned for more developments in Rich Snippets throughout the year!

Written by Mike Danylchuk and Nitin Shetti

Google SEO resources for beginners

Posted: January 22nd, 2010, 12:30am CET by Maile Ohye

Tags: webmaster tools

Webmaster Level: Beginner

Want to eat healthier and exercise more in 2010? That's tough! Want to learn about search engine optimization (SEO) so you can disregard the rumors and know what's important? That's easy! Here's how to gain SEO knowledge as you go about your new start to 2010:

Step 1: Absorb the basics

If you like to learn by reading, download our SEO Starter Guide for reading while you're on an exercise bike, training for Ironman.
Or, if you're more a video watcher, try listening to my "Search Friendly Development" session while you're cleaning your house. Keep in mind that some parts of the presentation are a little more technical.

For good measure, and because at some point you'll hear references to them, check out our webmaster guidelines for yourself.

Step 2: Explore details that pique your interest
Are you done with the basics but now you have some questions? Good for you! Try researching a particular topic in our Webmaster Help Center. For example, do you want more information about crawling and indexing or understanding what links are all about?

Step 3: Verify ownership of your site in Webmaster Tools
It takes a little bit of skill, but we have tons of help for verification. Once you verify ownership of your site (i.e., signal to Google that you're the owner), you can:

See more confidential information about your site, like crawl errors or messages from Google about your site
Run through the Webmaster Tools checklist and learn new ways to monitor and manage your site
Forward your Google messages to your personal email address

A sample message regarding the crawlability of your site

Step 4: Research before you do anything drastic
Usually the basics (e.g., good content/service and a crawlable site with indexable information) are the necessities for SEO. You may hear or read differently, but before you do anything drastic on your site such as robots.txt disallow'ing all of your directories or revamping your entire site architecture, please try:

Researching material in our Help Center
Checking for related posts in our Webmaster Forum
Asking for feedback from the webmaster community -- we've got a super skilled group of Google employees, members, and Bionic Posters.

Written by Maile Ohye, Developer Programs Tech Lead

Region Tags in Google Search Results

Posted: December 1st, 2009, 5:25pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

Country-code top-level domains (or ccTLDs) can provide people with a quick and valuable clue about the location of a website—for example, ".fr" for France or ".co.jp" for Japan. However, for certain top level domains like .com, .info and .org, it's not as easy to figure out the location. That's why today we're adding region information supplied by webmasters to the green address line on some Google search results.

This feature is easiest to explain through an example. Let's say you've heard about a boxing club in Canada called "Capital City Boxing." You try a search for [capital city boxing] to find out more, but it's hard to tell which result is the one you're looking for. Here's a screen shot:

None of the results provide any location information in the title or snippet, nor do they have a regional TLD (such as .ca for Canada). The only way to find the result you're looking for is to refine your search ([capital city boxing canada] works) or click through the various links to figure it out. Clicking through the first result reveals that there's apparently another "Capital City Boxing" club in Alabama.

Region tags improve search results by providing valuable information about website location right in the green URL line. Continuing our prior example, here's a screen shot of the new region tag (circled in red):

As you can see, the fourth result now includes the region name "Canada" after the green URL, so you can immediately tell that this result relates to the boxing club in Canada. With the new display, you no longer need to refine your search or click through the results to figure out which page is the one you're looking for. In general, our hope is that these region tags will help searchers more quickly identify which results are most relevant to their queries.

As a webmaster, you can control how this feature works by adjusting your Geographic Targeting settings. Log in to Webmaster Tools and choose Site configuration > Settings > Geographic Target. From here you can associate a particular country/region with your site. These settings will determine the name that appears as a region tag. You can learn more about using the Geographic Target tool in a prior blog post and in our Help Center.

We currently show region tags only for certain domains such as .com and .net where the location information would otherwise be unclear. We don't show region tags for results on domains like .br for Brazil, because the location is already implied by the green URL line in our default display. In addition, we only display region tags when the region supplied by the site owner is different from the domain where the search was entered. For example, if you do a search from the Singapore Google domain (google.com.sg), we won't show you region tags for all the websites webmasters have targeted to Singapore because we'd end up tagging too many results, and the tag is really most relevant for foreign regions. For the initial release, we anticipate roughly 1% of search results pages will include webpages with a region tag.

We hope you'll find this new feature useful, and we welcome your feedback.

Written by Piyush Prahladka, Software Engineer

Hard facts about comment spam

Posted: November 25th, 2009, 8:17pm CET by Maile Ohye

Tags: general tips

Webmaster Level: Beginner

It has probably happened to you: you're reading articles or watching videos on the web, and you come across some unrelated, gibberish comments. You may wonder what this is all about. Some webmasters abuse other sites by exploiting their comment fields, posting tons of links that point back to the poster's site in an attempt to boost their site's ranking. Others might tweak this approach a bit by posting a generic comment (like "Nice site!") with a commercial user name linking to their site.

Why is it bad?

FACT: Abusing comment fields of innocent sites is a bad and risky way of getting links to your site. If you choose to do so, you are tarnishing other people's hard work and lowering the quality of the web, transforming a potentially good resource of additional information into a list of nonsense keywords.

FACT: Comment spammers are often trying to improve their site's organic search ranking by creating dubious inbound links to their site. Google has an understanding of the link graph of the web, and has algorithmic ways of discovering those alterations and tackling them. At best, a link spammer might spend hours doing spammy linkdrops which would count for little or nothing because Google is pretty good at devaluing these types of links. Think of all the more productive things one could do with that time and energy that would provide much more value for one's site in the long run.

Promote your site without comment spam

If you want to improve your site's visibility in the search results, spamming comments is definitely not the way to go. Instead, think about whether your site offers what people are looking for, such as useful information and tools.

FACT: Having original and useful content and making your site search engine friendly is the best strategy for better ranking. With an appealing site, you'll be recognized by the web community as a reliable source and links to your site will build naturally.

Moreover, Google provides a list of advice in order to improve the crawlability and indexability of your site. Check out our Search Engine Optimization Starter Guide.

What can I do to avoid spam on my site?

Comments can be a really good source of information and an efficient way of engaging a site's users in discussions. This valuable content should not be replaced by gibberish nonsense keywords and links. For this reason there are many ways of securing your application and disincentivizing spammers.

Disallow anonymous posting.
Use CAPTCHAs and other methods to prevent automated comment spamming.
Turn on comment moderation.
Use the "nofollow" attribute for links in the comment field.
Disallow hyperlinks in comments.
Block comment pages using robots.txt or meta tags.

For detailed information about these topics, check out our Help Center document on comment spam.

My site is full of comment spam, what should I do?

It's never too late! Don't let spammers ruin the experience for others. Adopt security measures discussed above to stop the spam activity, then invest some time to clean up the spammy comments and ban the spammers from your site. Depending on you site's system, you may be able to save time by banning spammers and removing their comments all at once, rather than one by one.

If I spammed comment fields of third party sites, what should I do?

If you used this approach in the past and you want to solve this issue, you should have a look at your incoming links in Webmaster Tools. To do so, go to the Your site on the web section and click on Links to your site. If you see suspicious links coming from blogs or other platforms allowing comments, you should check these URLs. If you see a spammy link you created, try to delete it, else contact the webmaster to ask to remove the link. Once you've cleared the spammy inbound links you made, you can file a reconsideration request.

For more information about this topic and to discuss it with others, join us in the Webmaster Help Forum. (But don't leave spammy comments!)

Written by Adel Saoud and Paolo Petrolini

'New software version' notifications for your site

Posted: November 20th, 2009, 10:30am CET by Maile Ohye

Tags: webmaster tools

Webmaster level: All

One of the great things about working at Google is that we get to take advantage of an enormous amount of computing power to do some really cool things. One idea we tried out was to let webmasters know about their potentially hackable websites. The initial effort was successful enough that we thought we would take it one step further by expanding our efforts to cover other types of web applications—for example, more content management systems (CMSs), forum/bulletin-board applications, stat-trackers, and so on.

This time, however, our goal is not just to isolate vulnerable or hackable software packages, but to also notify webmasters about newer versions of the software packages or plugins they're running on their website. For example, there might be a Drupal module or Joomla extension update available but some folks might not have upgraded. There are a few reasons a webmaster might not upgrade to the newer version and one of the reasons could be that they just don't know a new version exists. This is where we think we can help. We hope to let webmasters know about new versions of their software by sending them a message via Webmaster Tools. This way they can make an informed decision about whether or not they would like to upgrade.

One of the ways we identify sites to notify is by parsing source code of web pages that we crawl. For example, WordPress and other CMS applications include a generator meta tag that specifies the version number. This has proven to be tremendously helpful in our efforts to notify webmasters. So if you're a software developer, and would like us to help you notify your users about newer versions of your software, a great way to start would be to include a generator meta tag that tells the version number of your software. If you're a plugin or a widget developer, including a version number in the source you provide to your users is a great way to help too.

We've seen divided opinions over time about whether it's a good security practice to include a version number in source code, because it lets hackers or worm writers know that the website might be vulnerable to a particular type of exploit. But as Matt Mullenweg pointed out, "Where [a worm writer's] 1.0 might have checked for version numbers, 2.0 just tests [a website's] capabilities...". Meanwhile, the advantage of a version number is that it can help alert site owners when they need to update their site. In the end, we tend to think that including a version number can do more good than harm.

We plan to begin sending out the first of these messages soon and hope that webmasters find them useful! If you have any questions or feedback, feel free to comment here.

Posted by Patrick Chapman, Search Quality Team

Running desktop and mobile versions of your site

Posted: November 18th, 2009, 11:15pm CET by Maile Ohye

Tags: crawling and indexing

(This post was largely translated from our Japanese version of the Webmaster Central Blog )

Recently I introduced several methods to ensure your mobile site is properly indexed by Google. Today I'd like to share information useful for webmasters who manage both desktop and mobile phone versions of a site.

One of the most common problems for webmasters who run both mobile and desktop versions of a site is that the mobile version of the site appears for users on a desktop computer, or that the desktop version of the site appears when someone finds them from a mobile device. In dealing with this scenario, here are two viable options:

Redirect mobile users to the correct version

When a mobile user or crawler (like Googlebot-Mobile) accesses the desktop version of a URL, you can redirect them to the corresponding mobile version of the same page. Google notices the relationship between the two versions of the URL and displays the standard version for searches from desktops and the mobile version for mobile searches.

If you redirect users, please make sure that the content on the corresponding mobile/desktop URL matches as closely as possible. For example, if you run a shopping site and there's an access from a mobile phone to a desktop-version URL, make sure that the user is redirected to the mobile version of the page for the same product, and not to the homepage of the mobile version of the site. We occasionally find sites using this kind of redirect in an attempt to boost their search rankings, but this practice only results in a negative user experience, and so should be avoided at all costs.

On the other hand, when there's an access to a mobile-version URL from a desktop browser or by our web crawler, Googlebot, it's not necessary to redirect them to the desktop-version. For instance, Google doesn't automatically redirect desktop users from their mobile site to their desktop site, instead they include a link on the mobile-version page to the desktop version. These links are especially helpful when a mobile site doesn't provide the full functionality of the desktop version -- users can easily navigate to the desktop-version if they prefer.

Switch content based on User-agent

Some sites have the same URL for both desktop and mobile content, but change their format according to User-agent. In other words, both mobile users and desktop users access the same URL (i.e. no redirects), but the content/format changes slightly according to the User-agent. In this case, the same URL will appear for both mobile search and desktop search, and desktop users can see a desktop version of the content while mobile users can see a mobile version of the content.

However, note that if you fail to configure your site correctly, your site could be considered to be cloaking, which can lead to your site disappearing from our search results. Cloaking refers to an attempt to boost search result rankings by serving different content to Googlebot than to regular users. This causes problems such as less relevant results (pages appear in search results even though their content is actually unrelated to what users see/want), so we take cloaking very seriously.

So what does "the page that the user sees" mean if you provide both versions with a URL? As I mentioned in the previous post, Google uses "Googlebot" for web search and "Googlebot-Mobile" for mobile search. To remain within our guidelines, you should serve the same content to Googlebot as a typical desktop user would see, and the same content to Googlebot-Mobile as you would to the browser on a typical mobile device. It's fine if the contents for Googlebot are different from the one for Googlebot-Mobile.

One example of how you could be unintentionally detected for cloaking is if your site returns a message like "Please access from mobile phones" to desktop browsers, but then returns a full mobile version to both crawlers (so Googlebot receives the mobile version). In this case, the page which web search users see (e.g. "Please access from mobile phones") is different from the page which Googlebot crawls (e.g. "Welcome to my site"). Again, we detect cloaking because we want to serve users the same relevant content that Googlebot or Googlebot-Mobile crawled.

Diagram of serving content from your mobile-enabled site

We're working on a daily basis to improve search results and solve problems, but because the relationship between PC and mobile versions of a web site can be nuanced, we appreciate the cooperation of webmasters. Your help will result in more mobile content being indexed by Google, improving the search results provided to users. Thank you for your cooperation in improving the mobile search user experience.

Posted by Jun Mukai, Software Engineer, Mobile Search Team

Pros and cons of watermarked images

Posted: November 17th, 2009, 12:40pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All
What's our take on watermarked images for Image Search? It's a complicated topic. I talked with Peter Linsley—my friend at the 'plex, video star, and Product Manager for Image Search—to hear his thoughts.
Maile: So, Peter... "watermarked images". Can you break it down for us?

Peter: It's understandable that webmasters find watermarking images beneficial.
Pros of watermarked images
Photographers can claim credit/be recognized for their art.
Unknown usage of the image is deterred.
If search traffic is important to a webmaster, then he/she may also want to consider some of our findings:
Findings relevant to watermarked images
Users prefer large, high-quality images (high-resolution, in-focus).
Users are more likely to click on quality thumbnails in search results. Quality pictures (again, high-res and in-focus) often look better at thumbnail size.
Distracting features such as loud watermarks, text over the image, and borders are likely to make the image look cluttered when reduced to thumbnail size.
In summary, if a feature such as watermarking reduces the user-perceived quality of your image or your image's thumbnail, then searchers may select it less often. Preview your images at thumbnail size to get an idea of how the user might perceive it.

Maile: Ahh, I see: Webmasters concerned with search traffic likely want to balance the positives of watermarking with the preferences of their users -- keeping in mind that sites that use clean images without distracting artifacts tend to be more popular, and that this can also impact rankings. Will Google rank an image differently just because it's watermarked?

Peter: Nope. The presence of a watermark doesn't itself cause an image to be ranked higher or lower.

Do you have questions or opinions on the topic? Let's chat in the webmaster forum.
Written by Maile Ohye, Developer Programs Tech Lead

Help Google index your mobile site

Posted: November 13th, 2009, 2:48pm CET by Maile Ohye

Tags: crawling and indexing

(This post was largely translated from our Japanese Webmaster Central Blog.)
It seems the world is going mobile, with many people using mobile phones on a daily basis, and a large user base searching on Google’s mobile search page. However, as a webmaster, running a mobile site and tapping into the mobile search audience isn't easy. Mobile sites not only use a different format from normal desktop site, but the management methods and expertise required are also quite different. This results in a variety of new challenges. As a mobile search engineer, it's clear to me that while many mobile sites were designed with mobile viewing in mind, they weren’t designed to be search friendly. I'd like to help ensure that your mobile site is also available for users of mobile search.
Here are troubleshooting tips to help ensure that your site is properly crawled and indexed:
Verify that your mobile site is indexed by Google
If your web site doesn't show up in the results of a Google mobile search even using the 'site:' operator, it may be that your site has one or both of the following issues:

Googlebot may not be able to find your site
Googlebot, our crawler, must crawl your site before it can be included in our search index. If you just created the site, we may not yet be aware of it. If that's the case, create a Mobile Sitemap and submit it to Google to inform us to the site’s existence. A Mobile Sitemap can be submitted using Google Webmaster Tools, in the same way as with a standard Sitemap.

Googlebot may not be able to access your site
Some mobile sites refuse access to anything but mobile phones, making it impossible for Googlebot to access the site, and therefore making the site unsearchable. Our crawler for mobile sites is "Googlebot-Mobile". If you'd like your site crawled, please allow any User-agent including "Googlebot-Mobile" to access your site. You should also be aware that Google may change its User-agent information at any time without notice, so it is not recommended that you check if the User-agent exactly matches "Googlebot-Mobile" (which is the string used at present). Instead, check whether the User-agent header contains the string "Googlebot-Mobile". You can also use DNS Lookups to verify Googlebot.

Verify that Google can recognize your mobile URLs
Once Googlebot-Mobile crawls your URLs, we then check for whether the URL is viewable on a mobile device. Pages we determine aren't viewable on a mobile phone won't be included in our mobile site index (although they may be included in the regular web index). This determination is based on a variety of factors, one of which is the "DTD (Doc Type Definition)" declaration. Check that your mobile-friendly URLs' DTD declaration is in an appropriate mobile format such as XHTML Mobile or Compact HTML. If it's in a compatible format, the page is eligible for the mobile search index. For more information, see the Mobile Webmaster Guidelines.
If you have any question regarding mobile site, post your question to our Webmaster Help Forum and webmasters around the world as well as we are happy to help you with your problem.
Posted by Jun Mukai, Software Engineer, Mobile Search Team

New personalization features in Google Friend Connect

Posted: November 4th, 2009, 8:40am CET by Maile Ohye

Tags: products and services

Webmaster Level: All
Just a few weeks ago, we made Google Friend Connect a lot easier to use by dramatically simplifying the setup process. Today, we're excited to announce several new features that make it possible for website owners to get to know their users, encourage users to get to know each other, and match their site content (including Google ads) to visitors' interests.

To learn more about these new features, check out the Google Social Web Blog.
Posted by Mussie Shore, Product Manager, Google Friend Connect

Permalink for 'Official_Google_Webmaster_Central_Blog/2009/11/03/Get_your_site_ready_for_the_holidays__Webmasters___make_your_list_and_check_it_twice_'

Get your site ready for the holidays: Webmasters - make your list and check it twice!

Posted: November 3rd, 2009, 3:25pm CET by Maile Ohye

Tags: events

Webmaster Level: All

Are the holidays an important season for your website or online business? We think so! And to help make sure you're in good shape, we wanted to invite you to our Holiday Webmaster Webinar.

This Webex will be hosted by Senior Search Quality Engineer Greg Grothaus, and AdWords Evangelist Fred Vallaeys. They'll be discussing a range of webmaster best practices and useful Google tools followed by a Q&A session to make sure you and your site are well primed for the holiday rush!

Topic: Holiday Webmaster Webinar
Date: Friday, November 13, 2009
Time: 10:00 am, Pacific Standard Time (GMT -08:00, San Francisco)
Meeting Number: 574 659 815
Meeting Password: webmaster

Please click the link below to see more information, or to join the meeting.

-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to https://googleonline.webex.com/googleonline/j.php?ED=133402392&UID=0&PW=db339c4e641e0f525412171e5646
2. Enter your name and email address.
3. Enter the meeting password: webmaster
4. Click "Join Now".

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll-free number (US/Canada): 866-469-3239
Call-in toll number (US/Canada): 1-650-429-3300
Toll-free dialing restrictions: [www.webex.com]

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to [https:]
2. On the left navigation bar, click "Support".

Written by Lauren Dolmyer, Evan Tang, and Derrick Djang

Using RSS/Atom feeds to discover new URLs

Posted: October 29th, 2009, 6:50pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Intermediate

Google uses numerous sources to find new webpages, from links we find on the web to submitted URLs. We aim to discover new pages quickly so that users can find new content in Google search results soon after they go live. We recently launched a feature that uses RSS and Atom feeds for the discovery of new webpages.

RSS/Atom feeds have been very popular in recent years as a mechanism for content publication. They allow readers to check for new content from publishers. Using feeds for discovery allows us to get these new pages into our index more quickly than traditional crawling methods. We may use many potential sources to access updates from feeds including Reader, notification services, or direct crawls of feeds. Going forward, we might also explore mechanisms such as PubSubHubbub to identify updated items.

In order for us to use your RSS/Atom feeds for discovery, it's important that crawling these files is not disallowed by your robots.txt. To find out if Googlebot can crawl your feeds and find your pages as fast as possible, test your feed URLs with the robots.txt tester in Google Webmaster Tools.

Written by Raymond Lo, Guhan Viswanathan, and Dave Weissman, Crawl and Indexing Team

Help us make the web better: An update on Rich Snippets

Posted: October 26th, 2009, 3:00pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

In May this year we announced Rich Snippets which makes it possible to show structured data from your pages on Google's search results.

We're convinced that structured data makes the web better, and we've worked hard to expand Rich Snippets to more search results and collect your feedback along the way. If you have review or people/social networking content on your site, it's easier than ever to mark up your content using microformats or RDFa so that Google can better understand it to generate useful Rich Snippets. Here are a few helpful improvements on our end to enable you to mark up your content:

Testing tool. See what Google is able to extract, and preview how microformats or RDFa marked-up pages would look on Google search results. Test your URLs on the Rich Snippets Testing Tool.

Google Custom Search users can also use the Rich Snippets Testing Tool to test markup usable in their Custom Search engine.

Better documentation. We've extended our documentation to include a new section containing Tips & Tricks and Frequently Asked Questions. Here we have responded to common points of confusion and provided instructions on how to maximize the chances of getting Rich Snippets for your site.

Extended RDFa support. In addition to the Person RDFa format, we have added support for the corresponding fields from the FOAF and vCard vocabularies for all those of you who asked for it.

Videos. If you have videos on your page, you can now mark up your content to help Google find those videos.

As before, marking up your content does not guarantee that Rich Snippets will be shown for your site. We will continue to expand this feature gradually to ensure a great user experience whenever Rich Snippets are shown in search results.

Written by Kavi Goel, Pravir Gupta, and Othar Hansson

Tips for News Search

Posted: September 1st, 2009, 1:22pm CEST by Maile Ohye

Tags: sitemaps

Webmaster Level: All

During my stint on the "How Google Works Tour: Seattle", I heard plenty of questions regarding News Search from esteemed members of the press, such as The Stranger, The Seattle Times and Seattle Weekly. After careful note-taking throughout our conversations, the News team and I compiled this presentation to provide background and FAQs for all publishers interested in Google News Search.

Along with the FAQs about News Sitemaps and PageRank in the video above, here's additional Q&A to get you started:

Would adding a city name to my paper—for example, changing our name from "The Times" to "The San Francisco Bay Area Times"—help me target my local audience in News Search?

No, this won't help News rankings. We extract geography and location information from the article itself (see video). Changing your name to include relevant keywords or adding a local address in your footer won't help you target a specific audience in our News rankings.

What happens if I accidentally include URLs in my News Sitemap that are older than 72 hours?

We want only the most recently added URLs in your News Sitemap, as it directs Googlebot to your breaking information. If you include older URLs, no worries (there's no penalty unless you're perceived as maliciously spamming -- this case would be rare, so again, no worries); we just won't include those URLs in our next News crawl.

To get the full scoop, check out the video!

Written by Maile Ohye, Developer Programs Tech Lead
Filmed by Michael Wyszomierski, Search Quality Team

New tools for Google Services for Websites

Posted: August 11th, 2009, 1:05pm CEST by Maile Ohye

Tags: products and services

Webmaster Level: All
(A nearly duplicate version :) cross-posted on the Official Google Blog)

Earlier this year, we launched Google Services for Websites, a program that helps partners, e.g., web hoster and access providers, offer useful and powerful tools to their customers. By making services, such as Webmaster Tools, Custom Search, Site Search and AdSense, easily accessible via the hoster control panel, hosters can easily enable these services for their webmasters. The tools help website owners understand search performance, improve user retention and monetize their content — in other words, run more effective websites.

Since we launched the program, several hosting platforms have enhanced their offerings by integrating with the appropriate APIs. Webmasters can configure accounts, submit Sitemaps with Webmaster Tools, create Custom Search Boxes for their sites and monetize their content with AdSense, all with a few clicks at their hoster control panel. More partners are in the process of implementing these enhancements.

We've just added new tools to the suite:

Web Elements allows your customers to enhance their websites with the ease of cut-and-paste. Webmasters can provide maps, real-time news, calendars, presentations, spreadsheets and YouTube videos on their sites. With the Conversation Element, websites can create more engagement with their communities. The Custom Search Element provides inline search over your own site (or others you specify) without having to write any code and various options to customize further.
Page Speed allows webmasters to measure the performance of their websites. Snappier websites help users find things faster; the recommendations from these latency tools allow hosters and webmasters to optimize website speed. These techniques can help hosters reduce resource use and optimize network bandwidth.
The Tips for Hosters page offers a set of tips for hosters for creating a richer website hosting platform. Hosters can improve the convenience and accessibility of tools, while at the same time saving platform costs and earning referral fees. Tips include the use of analytics tools such as Google Analytics to help webmasters understand their traffic and linguistic tools such as Google Translate to help websites reach a broader audience.

If you're a hoster and would like to participate in the Google Services for Websites program, please apply here. You'll have to integrate with the service APIs before these services can be made available to your customers, so the earlier you start that process, the better.

And if your hosting service doesn't have Google Services for Websites yet, send them to this page. Once they become a partner, you can quickly configure the services you want at your hoster's control panel (without having to come to Google).

As always, we'd love to get feedback on how the program is working for you, and what improvements you'd like to see.

Posted by Rajat Mukherjee, Group Product Manager

Help test some next-generation infrastructure

Posted: August 10th, 2009, 6:14pm CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

To build a great web search engine, you need to:

Crawl a large chunk of the web.
Index the resulting pages and compute how reputable those pages are.
Rank and return the most relevant pages for users' queries as quickly as possible.

For the last several months, a large team of Googlers has been working on a secret project: a next-generation architecture for Google's web search. It's the first step in a process that will let us push the envelope on size, indexing speed, accuracy, comprehensiveness and other dimensions. The new infrastructure sits "under the hood" of Google's search engine, which means that most users won't notice a difference in search results. But web developers and power searchers might notice a few differences, so we're opening up a web developer preview to collect feedback.

Some parts of this system aren't completely finished yet, so we'd welcome feedback on any issues you see. We invite you to visit the web developer preview of Google's new infrastructure at [www2.sandbox.google.com] and try searches there.

Right now, we only want feedback on the differences between Google's current search results and our new system. We're also interested in higher-level feedback ("These types of sites seem to rank better or worse in the new system") in addition to "This specific site should or shouldn't rank for this query." Engineers will be reading the feedback, but we won't have the cycles to send replies.

Here's how to give us feedback: Do a search at [www2.sandbox.google.com] and look on the search results page for a link at the bottom of the page that says "Dissatisfied? Help us improve." Click on that link, type your feedback in the text box and then include the word caffeine somewhere in the text box. Thanks in advance for your feedback!

Update on August 11, 2009: [ If you have language or country specific feedback on our new system's search results, we're happy to hear from you. It's a little more difficult to obtain these results from the sandbox URL, though, because you'll need manually alter the query parameters.

You can change these two values appropriately:
hl = language
gl = country code

Examples:
German language in Germany: &hl=de&gl=de
[www2.sandbox.google.com]

Spanish language in Mexico: &hl=es&gl=mx
[www2.sandbox.google.com]

And please don't forget to add the word "caffeine" in the feedback text box. :) ]

Posted by Sitaram Iyer, Staff Software Engineer, and Matt Cutts, Principal Engineer

Google Friend Connect - Now in 47 new languages

Posted: July 14th, 2009, 1:05am CEST by Maile Ohye

Tags: products and services

Have you been holding off on using Google Friend Connect because your site isn't in English? Starting today, Friend Connect is available in 47 new languages, including French, Italian, German, Spanish, Chinese, Japanese, Hindi and Portuguese. Now you can easily add social features that match the language of other content on your site.

Most Google-created gadgets (such as the members, comments, and recommendation gadgets) are now available in these new languages. Some developers have also created gadgets that support additional languages and we hope that there will be more to come in the future. To see a list of gadgets available in your language, visit the gadget gallery.

When you add Friend Connect to a new site, it will default to your primary language. But if your site is in another language, simply select it on the site settings tab and Friend Connect will automatically render the gadgets in that language. And if have multiple sites in different languages, you can select a different language for each of your sites.

To learn more or see the full list of languages, check out the Social Web Blog.

Posted by Mendel Chuang, Product Marketing Manager, Google Friend Connect

Google Maps gadget: Help customers find their way

Posted: July 7th, 2009, 6:30pm CEST by Maile Ohye

Tags: products and services

Webmaster Level: All

With the new directions gadget from Google Maps, any business can offer customized Google Maps directions to their business locations. With the directions gadget, you no longer need to type and update multiple sets of text directions. Let's face it: customers are only looking for directions from their specific location.

Last week, I looked up directions to the hotel in Sacramento that I had booked for the 4th of July weekend. As I had never been to that part of the state before, I was puzzled by the limited directions offered by their website - I had no idea whether I was approaching from the North, South, East or West or where the major highways were. What I needed were step-by-step directions from my exact starting point to the hotel that I could easily print and go.

Google has made this process easy for you. By copying and pasting a single line of code, any website can offer customized door-to-door directions powered by Google Maps to their users.

The gadget allows you to pre-fill the "To" field with one or multiple addresses. Customers are able to print their directions with a single click. And for those who prefer not to drive, the gadget also provides walking and public transit directions.

If someone enters a vague starting address, they have the option to specify a more exact address, which will then fly into the "From" field.

Providing directions from Google Maps is very flexible; in addition to run-of-the-mill addresses, you can give your customers directions to everything from a generic ZIP code to a specific set of latitude-longitude coordinates for any of your locations.

Example destinations:
123 River St, Woods, MA
90210
42.06782° N, 71.756963° W

You can also give your address an alias, or a name that everyone will understand. You can do this by putting the alias in parentheses just after the address:

42.06782° N, 71.756963° W (Grandma's House)

Take a look at how Legoland California, Emeril Lagasse, and Harvard University are using the gadget. And then test and create your own directions gadget here. For the many locations outside of the US, the gadget is available in 23 different languages.

Written by Julie Zhou, Product Marketing Manager, Google Maps

Flash indexing with external resource loading

Posted: June 19th, 2009, 1:27am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All
We just added external resource loading to our Flash indexing capabilities. This means that when a SWF file loads content from some other file—whether it's text, HTML, XML, another SWF, etc.—we can index this external content too, and associate it with the parent SWF file and any documents that embed it.
This new capability improves search quality by allowing relevant content contained in external resources to appear in response to users' queries. For example, this result currently comes up in response to the query [2002 VW Transporter 888]:

Prior to this launch, this result did not appear, because all of the relevant content is contained in an XML file loaded by a SWF file.

To date, when Google encounters SWF files on the web, we can:

Index textual content displayed as a user interacts with the file. We click buttons and enter input, just like a user would.
Discover links within Flash files.
Load external resources and associate the content with the parent file.
Support common JavaScript techniques for embedding Flash, such as SWFObject and SWFObject2.
Index sites scripted with AS1 and AS2, even if the ActionScript is obfuscated. Update on June 19, 2009: We index sites with AS3 as well. The ActionScript version isn't particularly relevant in our Indexing process, so we support older versions of AS in addition to the latest.

If you don't want your SWF file or any of its external resources crawled by search engines, please use an appropriate robots.txt directive.

Written by Janis Stipins, Software Engineer

Best practices for Product Search

Posted: June 17th, 2009, 10:27am CEST by Maile Ohye

Tags: products and services

Webmaster Level: Beginner to Intermediate

If you run an e-commerce site and you'd like your products to be eligible to be shown in Google search results, then check out our "Product Search for Webmasters" video. In addition to the basics on Product Search, I cover:

Attributes to include in your feed
FAQs

Will my products' rankings improve if I include custom attributes in my feed?
Do product listings expire after 30 days?
How often should I submit my feed?

More information can be found in the Product Search Help Center.

Written by Maile Ohye, Developer Programs Tech Lead

Best practices for Product Search

Posted: June 17th, 2009, 10:27am CEST by Maile Ohye

Tags: products and services

Attributes to include in your feed
FAQs

Will my products' rankings improve if I include custom attributes in my feed?
Do product listings expire after 30 days?
How often should I submit my feed?

More information can be found in the Product Search Help Center.

Written by Maile Ohye, Developer Programs Tech Lead

SEO Starter Guide now available in 40 languages

Posted: June 5th, 2009, 9:10am CEST by Maile Ohye

Tags: crawling and indexing

Webmaster Level: Beginner

Since the release of our Search Engine Optimization Starter Guide last November, we've steadily been adding localized versions for our international users. Today, we're happy to announce that the guide is now available in 40 languages, which covers 98% of the global Internet audience. We hope that webmasters around the world can use the guide to improve their sites' crawlability and indexing in search engines.

We'd also like to thank everyone for their continued feedback on the guide. We're taking notes on what you liked and what you thought was missing for use in future updates and possibly a version for advanced users.

Here's a list of the languages available:

Written by Brandon Falls, Search Quality Team

Let visitors recommend your content

Posted: May 15th, 2009, 8:20pm CEST by Maile Ohye

Tags: general tips

Webmaster Level: All

We recently posted about some of the engaging gadgets you can add to your site with Google Friend Connect. Here's one more that may be of interest if you're looking for another way to get feedback from your site's visitors:

The new Recommendation gadgets make it easy for your visitors to let you and the world know which parts of your site they like best. By placing recommendation buttons next to photos, articles or other content, visitors can recommend specific items to others with the click of a button. Your most popular items will surface to the top of the recommendation list.

To install a recommendation gadget on your site, or to check out the other gadgets that are available, please visit www.google.com/friendconnect.

Posted by Mendel Chuang, Product Marketing Manager

Introducing Rich Snippets

Posted: May 12th, 2009, 2:00pm CEST by Maile Ohye

Tags: Search results

Webmaster Level: All

As a webmaster, you have a unique understanding of your web pages and the content they represent. Google helps users find your page by showing them a small sample of that content -- the "snippet." We use a variety of techniques to create these snippets and give users relevant information about what they'll find when they click through to visit your site. Today, we're announcing Rich Snippets, a new presentation of snippets that applies Google's algorithms to highlight structured data embedded in web pages.

Rich Snippets give users convenient summary information about their search results at a glance. We are currently supporting data about reviews and people. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name. It's a simple change to the display of search results, yet our experiments have shown that users find the new data valuable -- if they see useful and relevant information from the page, they are more likely to click through. Now we're beginning the process of opening up this successful experiment so that more websites can participate. As a webmaster, you can help by annotating your pages with structured data in a standard format.

To display Rich Snippets, Google looks for markup formats (microformats and RDFa) that you can easily add to your own web pages. In most cases, it's as quick as wrapping the existing data on your web pages with some additional tags. For example, here are a few relevant lines of the HTML from Yelp's review page for "Drooling Dog BarBQ" before adding markup data:

and now with microformats markup:

or alternatively, use RDFa markup. Either format works:

By incorporating standard annotations in your pages, you not only make your structured data available for Google's search results, but also for any service or tool that supports the same standard. As structured data becomes more widespread on the web, we expect to find many new applications for it, and we're excited about the possibilities.

To ensure that this additional data is as helpful as possible to users, we'll be rolling this feature out gradually, expanding coverage to more sites as we do more experiments and process feedback from webmasters. We will make our best efforts to monitor and analyze whether individual websites are abusing this system: if we see abuse, we will respond accordingly.

To prepare your site for Rich Snippets and other benefits of structured data on the web, please see our documentation on structured data annotations.

Now, time for some Q&A with the team:

If I mark up my pages, does that guarantee I'll get Rich Snippets?

No. We will be rolling this out gradually, and as always we will use our own algorithms and policies to determine relevant snippets for users' queries. We will use structured data when we are able to determine that it helps users find answers sooner. And because you're providing the data on your pages, you should anticipate that other websites and other tools (browsers, phones) might use this data as well. You can let us know that you're interested in participating by filling out this form.

What about other existing microformats? Will you support other types of information besides reviews and people?

Not every microformat corresponds to data that's useful to show in a search result, but we do plan to support more of the existing microformats and define RDFa equivalents.

What's next?

We'll be continuing experiments with new types (beyond reviews and people) and hope to announce support for more types in the future.

I have too much data on my page to mark it all up.

That wasn't a question, but we'll answer anyway. For the purpose of getting data into snippets, we don't need every bit of data: it simply wouldn't fit. For example, a page that says it has "497 reviews" of a product probably has data for 10 and links to the others. Even if you could mark up all 497 blocks of data, there is no way we could fit it into a single snippet. To make your part of this grand experiment easier, we have defined aggregate types where necessary: a review-aggregate can be used to summarize all the review information (review count, average/min/max rating, etc.).

Why do you support multiple encodings?

A lot of previous work on structured data has focused on debates around encoding. Even within Google, we have advocates for microformat encoding, advocates for various RDF encodings, and advocates for our own encodings. But after working on this Rich Snippets project for a while, we realized that structured data on the web can and should accommodate multiple encodings: we hope to emphasize this by accepting both microformat encoding and RDFa encoding. Each encoding has its pluses and minuses, and the debate is a fine intellectual exercise, but it detracts from the real issues.

We do believe that it is important to have a common vocabulary: the language of object types, object properties, and property types that enable structured data to be understood by different applications. We debated how to address this vocabulary problem, and concluded that we needed to make an investment. Google will, working together with others, host a vocabulary that various Google services and other websites can use. We are starting with a small list, which we hope to extend over time.

Wherever possible, we'll simply reuse vocabulary that is in wide use: we support the pre-existing vCard and hReview types, and there are a variety of other types defined by various communities. Sites that use Google Custom Search will be able to define their own types, which we will index and present to users in rich Custom Search results pages. Finally, we encourage and expect this space to evolve based on new ideas from the structured data community. We'll notice and reach out when our crawlers pick up new types that are getting broad use.

Written by Kavi Goel, Ramanathan V. Guha, and Othar Hansson

Google Trends for your website

Posted: May 9th, 2009, 4:30pm CEST by Maile Ohye

Tags: general tips

Webmaster Level: All

In a recent post on the Official Google Blog, we mentioned our Google Trends gadget, and we thought it made sense to also post something here for all the webmasters that might be interested in having Trends on their website. Google Trends is a great way to see what's popular on the web -- people tend to search for what they care about -- and the Trends gadget makes it easy for you to put Trends on your website. Just cut and paste a small snippet of code, input your search terms, and you can show your readers how searches for Obama have changed during the last 30 days or who's the most popular American Idol contestant. So take a little piece of Google with you, and show your readers what's hot on the web.

Posted by Matt Ghering, Product Marketing Manager

More ways to engage your community

Posted: May 8th, 2009, 2:10pm CEST by Maile Ohye

Tags: general tips

Webmaster Level: All

Over the last few weeks, Google Friend Connect has added several new ways for you to strengthen the community that visits your site. These gadgets help to make your site more engaging and gives your visitors a new way to interact with your content and other visitors.

Here is a quick overview of these new gadgets:

Event gadget - Have an upcoming event you want to promote to your community? Embed this gadget on your site to let members get details about the event, see a map, indicate if they're coming, and see who else is attending. They can even add the event to their personal Google Calendars with just a click.

Polls gadget - Polls are a fun and easy way for your visitors to express themselves and a great tool for you to see what your users like. This gadget makes it easy to publish opinion polls and adds a social element by displaying the faces of the community members and friends who voted on each answer.

Get Answers gadget - Add the Get Answers gadget to your site to encourage visitors to ask questions of the community and answer questions posed by other community members. This gadget lets visitors browse questions, submit answers, and vote on answers they think are the best.

Comments gadget - Bring your site to life by adding the comments gadget to your pages. This gadget enables visitors to post comments and links to videos on your site. Visitors can even use the new translation feature to read comments in their preferred language.

Check out the Friend Connect gallery to see these gadgets along with all the other features Friend Connect has to offer. And keep an eye on the Social Web Blog for additional gadgets we'll soon be launching.

Posted by Mendel Chuang, Product Marketing Manager

Survey says...

Posted: May 1st, 2009, 2:00pm CEST by Maile Ohye

Tags: webmaster tools

Webmaster Level: All

Many thanks to the more than 1,600 people who filled out our survey in February. You gave us your feedback on the Webmaster Central Blog, Google Webmaster Tools, the Webmaster Help Forum, and our Webmaster Central videos on YouTube.

You told us what you like and want to see more of:

Webmaster Central gives users insight into Google: "[I like] being able to access, communicate, and see how my sites relate to Google."
Webmaster Central provides high quality information: "What I have enjoyed most of all, is reading Google's guidelines for webmasters, which is on-point with what I have been telling customers about SEO."
Webmaster Central collects several useful tools in one place: "It's an innovative central hub for all the tools supported and provided by the industry leader Google, for free."

We also learned about what you don't like and where we could be doing better. Our top finding is that beginner webmasters (about 20% of the survey respondents) are less satisfied than intermediate or advanced webmasters with Webmaster Central. Open-ended comments suggested that new webmasters want basic, less technical information from us. A common feedback that we received: "Many users like myself are not of the hi-tech, IT-savvy variety and prefer simplicity, whether we create a website for information or to generate revenue." Based on your responses, we've planned some new resources like a series of how-to videos especially for new webmasters (coming soon to YouTube).

We take your feedback seriously and will continue improving Webmaster Central and our other webmaster sites. Again, thanks for your participation in the survey. We want Webmaster Central to continue being a useful resource for you.

Written by Carolyn Wei, User Experience Researcher

Research study of Sitemaps

Posted: April 27th, 2009, 3:20pm CEST by Maile Ohye

Tags: sitemaps

We've been tracking the growth of Sitemaps on the web. It's been just 2 years since Google, Yahoo and Microsoft co-announced the Sitemaps directive in robots.txt, and it is already supported in many millions of websites including educational and government websites! At the WWW'09 conference in Madrid, Uri Schonfeld presented his summer internship work studying Sitemaps from a coverage and freshness perspective. If you're interested in how some popular websites are using Sitemaps, and how Sitemaps complement "classic" webcrawling, take a look:

Sitemaps: Above and Beyond the Crawl of Duty

At Google, we care deeply about getting increased coverage and freshness of the content we index. We are excited about open standards that help webmasters open up their content automatically to search engines, so users can find relevant content for their searches.

Written by Narayanan Shivakumar, VP Engineering

One-line sitelinks

Posted: April 16th, 2009, 1:00pm CEST by Maile Ohye

Tags: webmaster tools

Webmaster Level: All

You may be familiar with sitelinks, the links that show up underneath the first search result and which lead to specific pages deeper within the site. Sitelinks enable users to jump directly to important parts of a site, which is often useful for large, complex websites. Sitelinks have the additional advantage of giving users an overview of a website's content by highlighting some of the popular parts of the site. For webmasters, sitelinks are also beneficial because they help to expose parts of your site that users may not know about. For instance, a search for NASA provides links to a gallery of images, a page about Space Shuttle and ISS missions, and so on:

Until now, sitelinks have only ever appeared on the first search result, and so at most one site could have sitelinks per query. We're now launching an expansion of sitelinks: a single row of links can now appear for results that didn't show sitelinks before, even for results that aren't in the first position. This means multiple results on one query can now have sitelinks. Up to four sitelinks can show up right above the page URL, instead of the usual two columns below the URL of the first result. Here's an example where the first three results each have one-line sitelinks:

These one-line sitelinks have many of the same benefits as the full two-column sitelinks, but on a smaller scale: they show users some relevant sub-pages in the site and give an idea of what the site is about. Comparing the sitelinks that appear for each result can even illustrate the difference between the sites. Just like regular sitelinks, one-line sitelinks are generated algorithmically and the decisions on when to show them and which links to display are entirely based on the expected benefit to users.

For webmasters, this new feature means it's possible that your site will start showing sitelinks for a number of queries where it previously didn't. We expect this will increase the visibility of and traffic to your site, while also improving the experience of users. If, however, you absolutely would prefer not to have a particular sitelink show up, remember that you can always block a page from appearing as a sitelink for 90 days through Webmaster Tools. In fact, as part of our ongoing efforts at improving the Webmaster Tools experience, we're speeding up our response time to blocked pages, so you should see a blocked page get dropped as a sitelink even faster than before. If you need a quick refresher on how to use the sitelink blocking tool, take a look at this previous blog post. Currently you can only block sitelinks on your site's home page, but we're working on expanding this capability so you'll soon be able to remove them from any other page as well.

We hope you find these improvements to sitelinks and Webmaster Tools helpful for both your site and your visitors!

Posted by Doantam Phan, Software Engineer, and Raj Krishnan, Product Manager, Sitelinks Team

Helping your site look great with Google Chrome

Posted: March 26th, 2009, 6:35pm CET by Maile Ohye

Tags: general tips

Webmaster Level: Intermediate to Advanced
Since launching Google Chrome last September, we received a number of questions from webmasters and web developers about how to make their sites look great in Google Chrome. The questions were very insightful and illuminating for the Chrome team, and I want to respond with a few helpful tips for making your site look stellar in Google Chrome.

Detecting Google Chrome

Most sites will render the same in both Safari and Google Chrome, because they're both WebKit-based browsers. If your site looks right in Safari, then it should look right in Google Chrome, too.

Since Chrome is relatively new, many sites have confused Google Chrome with another browser. If your site doesn't look quite right in Chrome but works fine in Safari, it's possible your site may just not recognize Chrome's user-agent string.

As platforms and browsers adopt WebKit as their rendering engine, your site can detect and support them automatically with the right JavaScript checks. Commonly, sites use JavaScript to 'sniff' the navigator.userAgent property for "Chrome" or "Safari", but you should use proper object detection if possible. In fact, Gmail has been detecting WebKit properly in Chrome since day one!

If you must detect the user-agent type, you can use this simple JavaScript to detect WebKit:

var isWebkit =
  navigator.userAgent.indexOf("AppleWebKit") > -1;

Or, if you want to check that the version of WebKit is at least a certain version—say, if you want to use a spiffy new WebKit feature:

var webkitVersion =
  parseFloat(navigator.userAgent.split("AppleWebKit/")[1]) ||
  undefined;
if (webkitVersion && webkitVersion > 500 ) {
  // use spiffy WebKit feature here
}

For reference, here are a few browser releases and the version of WebKit they shipped:

Browser	Version of WebKit
Chrome 1.0	525.19
Chrome 2.0 beta	530.1
Safari 3.1	525.19
Safari 3.2	525.26.2
Safari 4.0 beta	528.16

We do not recommend adding "Google" or "Apple" to your navigator.vendor checks to detect WebKit or Google Chrome, because this will not detect other WebKit or Chromium-based browsers!

You can find more information about detecting WebKit at webkit.org.

Other helpful tips

Google Chrome doesn't support ActiveX plug-ins, but does support NPAPI plug-ins. This means you can show plug-in content like Flash and Java in Google Chrome the same way you do with Firefox and Safari.
If text on your site looks a bit off, make sure you provide the proper content type and character encoding information in the HTTP response headers, or at the beginning of your pages, preferably near the top of the <head> section.
Don't put block elements inside inline elements.

Wrong: <a><div>This will look wrong.</div></a>

Right: <div><a>This will look right!</a></div>

If your JavaScript isn't working in Google Chrome, you can debug using Chrome's built-in JavaScript debugger, under the "page" menu -> 'Developer' -> 'Debug JavaScript' menu option.

To help webmasters and web developers find more answers, we created a support center and forum specifically to answer your questions. Of course, if you find something you think is really a bug in Chrome, please report it to us!

Help us improve Google Chrome!

If you'd like to help even more, we're looking for sites that may be interested in allowing Google to use their site as a benchmark for our internal compatibility and performance measurements. If you're interested in having Google Chrome development optimized against a cached version of your site, please contact us about details at chrome-webmasters@google.com.

Please keep the feedback coming, and we'll keep working to improve Google Chrome!

Written by Glenn Wilson, Product Manager, Google Chrome

Get up-to-date on Image Search

Posted: March 10th, 2009, 6:13pm CET by Maile Ohye

Tags: crawling and indexing

Webmaster Level: All

Recently at SMX West, I gave an Image Search presentation that I'd like to share with our broader webmaster community. The goal of the presentation was to provide insights into how image search is used, how it works, and how webmasters can optimize their pages for image searchers.

You'll see more information about:

Some background on the reach of Image Search
Interesting findings on the behavior of image searchers
Our efforts at handling multiple image referrers
How to best feature images (image quality and placement, relevant surrounding text, etc.)

Take a look and let us know your thoughts in the comments. We'd love to hear from you.

Posted by Peter Linsley, Product Manager

Specify your canonical

Posted: February 12th, 2009, 1:30pm CET by Maile Ohye

Tags: crawling and indexing

Carpe diem on any duplicate content worries: we now support a format that allows you to publicly specify your preferred version of a URL. If your site has identical or vastly similar content that's accessible through multiple URLs, this format provides you with more control over the URL returned in search results. It also helps to make sure that properties such as link popularity are consolidated to your preferred version.

Let's take our old example of a site selling Swedish fish. Imagine that your preferred version of the URL and its content looks like this:

http://www.example.com/product.php?item=swedish-fish

However, users (and Googlebot) can access Swedish fish through multiple (not as simple) URLs. Even if the key information on these URLs is the same as your preferred version, they may show slight content variations due to things like sort parameters or category navigation:

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
Or they have completely identical content, but with different URLs due to things such as a tracking parameters or a session ID:

http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678
Now, you can simply add this <link> tag to specify your preferred version:

<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish" />

inside the <head> section of the duplicate content URLs:

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678

and Google will understand that the duplicates all refer to the canonical URL: http://www.example.com/product.php?item=swedish-fish. Additional URL properties, like PageRank and related signals, are transferred as well.

This standard can be adopted by any search engine when crawling and indexing your site.

Of course you may have more questions. Joachim Kupke, an engineer from our Indexing Team, is here to provide us with the answers:

Is rel="canonical" a hint or a directive?
It's a hint that we honor strongly. We'll take your preference into account, in conjunction with other signals, when calculating the most relevant page to display in search results.

Can I use a relative path to specify the canonical, such as <link rel="canonical" href="product.php?item=swedish-fish" />?
Yes, relative paths are recognized as expected with the <link> tag. Also, if you include a <base> link in your document, relative paths will resolve according to the base URL.

Is it okay if the canonical is not an exact duplicate of the content?
We allow slight differences, e.g., in the sort order of a table of products. We also recognize that we may crawl the canonical and the duplicate pages at different points in time, so we may occasionally see different versions of your content. All of that is okay with us.

What if the rel="canonical" returns a 404?
We'll continue to index your content and use a heuristic to find a canonical, but we recommend that you specify existent URLs as canonicals.

What if the rel="canonical" hasn't yet been indexed?
Like all public content on the web, we strive to discover and crawl a designated canonical URL quickly. As soon as we index it, we'll immediately reconsider the rel="canonical" hint.

Can rel="canonical" be a redirect?
Yes, you can specify a URL that redirects as a canonical URL. Google will then process the redirect as usual and try to index it.

What if I have contradictory rel="canonical" designations?
Our algorithm is lenient: We can follow canonical chains, but we strongly recommend that you update links to point to a single canonical page to ensure optimal canonicalization results.

Can this link tag be used to suggest a canonical URL on a completely different domain?
No. To migrate to a completely different domain, permanent (301) redirects are more appropriate. Google currently will take canonicalization suggestions into account across subdomains (or within a domain), but not across domains. So site owners can suggest www.example.com vs. example.com vs. help.example.com, but not example.com vs. example-widgets.com.

Sounds great—can I see a live example?
Yes, wikia.com helped us as a trusted tester. For example, you'll notice that the source code on the URL http://starwars.wikia.com/wiki/Nelvana_Limited specifies its rel="canonical" as: http://starwars.wikia.com/wiki/Nelvana.

The two URLs are nearly identical to each other, except that Nelvana_Limited, the first URL, contains a brief message near its heading. It's a good example of using this feature. With rel="canonical", properties of the two URLs are consolidated in our index and search results display wikia.com's intended version.

Feel free to ask additional questions in our comments below. And if you're unable to implement a canonical designation link, no worries; we'll still do our best to select a preferred version of your duplicate content URLs, and transfer linking properties, just as we did before.

Updated: This link-tag is currently also supported by Ask.com, Microsoft Live Search and Yahoo!.

Written by Joachim Kupke, Senior Software Engineer, and Maile Ohye, Developer Programs Tech Lead

Google Friend Connect introduces the social bar

Posted: February 11th, 2009, 12:46pm CET by Maile Ohye

In our previous Google Friend Connect posts, we've enjoyed connecting with you, the webmasters, and hearing your feedback about Friend Connect. We're now standing on our own two feet -- find us over at the new Social Web Blog where we just announced the new social bar feature.

The social bar packages many of the basic social functions -- sign-in, site activities, comments, and members -- into a single strip that appears at the top or bottom of your website. You can use it alone, or use it to complement your existing social gadgets, by putting it on the top or bottom of as many of your webpages as you want.

For anyone visiting your site, the social bar offers a snapshot of the activity taking place within your website's community. One click on any these features produces a convenient, interactive drop-down gadget, so users get all the functionality of the Friend Connect gadgets, while you save real estate on your website. With the social bar, visitors can:

Join or sign in to your site, view and edit their profiles, and change their personal settings.
View recent activity on your website, including new members and posts on any of your pages.
Post on your wall or read and reply to others' comments.
See the other members of your site, check out other peoples' profiles, and become friends. Users can also find out if any of their existing friends are members of your site.

Watch this quick video to learn how easy it is to add a social bar to your website:

To try out the social bar before deciding whether to add it to your website, visit:
[www.ossamples.com]

Posted by Mussie Shore, Product Manager, Google Friend Connect

Adding a social playlist to your site

Posted: January 15th, 2009, 12:00pm CET by Maile Ohye

Tags: general tips

As you're building your site, you may be looking for a simple way to provide fresh content that captures the attention of first time visitors and loyal users alike. They say that music brings people together, so what better way to engage your visitors than by inviting them to help build a unique, collaborative soundtrack for your website? Now, social application creator iLike has built a special version of their social playlist gadget for sites using Google Friend Connect.

Visitors can add their favorite songs
iLike's playlist gadget lets you and your visitors shape the site's "musical footprint" as a group. With this application, anyone visiting your website can listen to songs on the playlist, and if they sign in using Friend Connect, they can add their own favorites to the list. Of course, you can also add songs to the playlist, and as the site administrator, you have the ability to remove songs or change the order.

If you already have Friend Connect running on your website, you can add some musical flair in a matter of minutes with just a few clicks. Sign in at www.google.com/friendconnect, click "Social Gadgets," and you'll find the iLike "Playlist gadget" in the gallery.

Select the "Playlist gadget," and Friend Connect will automatically generate a snippet of code for you to copy-and-paste into your website's HTML. While you're there, you may also consider adding the "Wall gadget"—music can be a great conversation starter!

This iLike gadget is fully integrated with your existing Friend Connect account, so you can edit your website's playlist, moderate wall posts, and manage membership all from a single interface.

Like all of the social applications that work with Friend Connect, iLike's application is built using OpenSocial, and it's a great example of how a social application can foster a sense of community around a website. Any site using Friend Connect can host gadgets created by the OpenSocial developer community.

If you're a site owner who wants to begin adding social features to your website, visit Google Friend Connect. No programming is required!

If you're a developer interested in building a social application to run on the tens thousands of websites that are now using Google Friend Connect, learn more at www.opensocial.org.

Posted by Mussie Shore, Product Manager - Google Friend Connect

Preventing Virtual Blight: my presentation from Web 2.0 Summit

Posted: January 12th, 2009, 2:13pm CET by Maile Ohye

Tags: general tips

One of the things I'm thinking about in 2009 is how Google can be even more transparent and communicate more. That led me to a personal goal for 2009: if I give a substantial conference presentation (not just a question and answer session), I'd like to digitize the talk so that people who couldn't attend the conference can still watch the presentation.

In that spirit, here's a belated holiday present. In November 2008 I spoke on a panel about "Preventing Virtual Blight" at the Web 2.0 Summit in San Francisco. A few weeks later I ended up recreating the talk at the Googleplex and we recorded the video. In fact, this is a "director's cut" because I could take a little more time for the presentation. Here's the video of the presentation:

And if you'd like to follow along at home, I'll include the actual presentation as well:

You can also access the presentation directly. By the way thanks to Wysz for recording this not just on a shoestring budget but for free. I think we've got another video ready to go pretty soon, too.

Written by Matt Cutts, Search Quality Team

Japanese WMC Blog launched

Posted: December 27th, 2008, 1:37am CET by Maile Ohye

Konnichiwa! Hajimemashite! *Hello, Nice to meet you!

We just launched a new Webmaster Central Blog in Japanese. For those of you who feel more comfortable reading Japanese, and are interested in webmaster-related information from Google, and even learning about issues specific to our region and language, we hope you enjoy on our Japanese version of the Webmaster Central Blog :D

Written by Naoko Imai, Search Quality Team

Feliz Navidad from the Spanish Webmaster Central team!

Posted: December 25th, 2008, 2:50am CET by Maile Ohye

About three and a half months ago we kicked off the Spanish Webmaster Central blog hoping to reach many webmasters. Given the time of the year, we would like to say a big ¡Muchas Gracias! to all our readers.

It's been both a pleasure and a great opportunity for us to share our knowledge and hear your feedback. A few of this year's highlights:

For the blog, we had:

Matt Cutts talking to us in a 3 part interview (see part 1, part 2, and part 3).
A series of videos explaining how to use Webmaster Tools (See all parts: 1, 2, 3, 4, 5, and 6)
The links series and the 404 series.
Google's SEO Starter Guide in Spanish.

As for conferences, we had the chance to talk to some of you in:

SMX Madrid 2008.
Google Search Masters 2008 in Mexico. We even have some video footage from this conference, including a session about the Help Group :)
Congreso de Webmasters 2008.

And last, but not least, the Spanish Help Group, with lots of interesting stories.

This is us, several members of the Spanish Webmaster Central team:

From left to right: Cristina, Alvar, Rebecca, and Esperanza in Google's Dublin office, with a holiday touch :)
Written by Alvar López, Search Quality Team

Wishing you and your site a happy holiday!

Posted: December 23rd, 2008, 1:15pm CET by Maile Ohye

Your presence is our favorite present -- thanks for joining us for another year of making your site, and therefore the web, a better place.

Every day we see new people commenting and joining the discussion. This holiday season we'll try to update our blog to accommodate your growing needs. Always feel free to let us know how we're doing (especially if we publish a typo! :), because first and foremost and everywhere in the middle, we're trying to improve for you.

Happy holidays from all of us at Webmaster Central.

Written by Maile Ohye, Developer Programs Tech Lead

Quick and easy tips for the holiday rush

Posted: December 22nd, 2008, 2:04am CET by Maile Ohye

Tags: Search results

Season's greetings, webmasters! We've compiled a list of quick and simple tips for websites preparing for the holiday rush. For online and offline retailers, we understand that your website is a big part of your business, especially this time of year. Whether it's to make the sale online or to increase foot traffic to your brick-and-mortar location, your web presence is a critical part of your business plan. The tips below are fast, free, and can make a big difference.

Verify that your site is indexed by Google (and is returned in search results)
Check your snippet content and page titles with the site: command [site:example.com] -- do they look accurate and descriptive for users? Ideally, each title and snippet should be unique in order to reflect that each URL contains unique content. If anything is missing or you want more details, you can also use the Content Analysis tool in Webmaster Tools. There you can see which URLs on your site show duplicate titles or meta descriptions.

Label your images accurately
Don't miss out on potential customers! Because good 'alt' text and descriptive filenames help us better understand images, make sure you change non-descriptive file names [001.jpg] to something more accurate [NintendoWii.jpg]. Image Search is one of our largest search properties, so you should take advantage of it.

Know what Google knows (about your site)
Check for crawl errors and learn the top queries that bring traffic to your site through Webmaster Tools. See our diagnostics checklist.

Have a plan for expiring and temporary pages
Make sure to serve accurate HTTP status codes. If you no longer sell a product, serve a 404. If you have changed a product page to a new URL, serve a 301 to redirect the old page to the new one. Keeping your site up-to-date can help bring more targeted traffic your way.

Increase foot traffic too
If your website directs customers to a brick-and-mortar location, make sure you claim and double check your business listing in Google Local.

Usability 101
Test the usability of your checkout process with various browsers. Ask yourself if a user can get from product page to checkout without assistance. Is your checkout button easy to find?

Tell us where to find all of your web pages
If you upload new products faster than Google crawls your site, make sure to submit a Sitemap and include 'last modification' and change frequency' information. A Sitemap can point Googlebot to your new or hard-to-find content.

Manage your sitelinks
Your site may be triggering Sitelinks in the search results, so check the links and make sure the destination pages are fully functional. Remember: in Webmaster Tools you can remove any sitelinks that you don't think users will find useful.

Don't forget to check out these additional resources:

Read our recently released SEO Starter Guide.
Watch our Tutorials for Webmasters.
Find out what information Google has about your website in Webmaster Tools.
Get your other questions answered in our Webmaster Help Center.
Ask your last-minute questions in the Webmaster Help Forum.
Countdown to 2009!

Written by Matt Dougherty, Search Quality Team

Webmaster Tools in 40 languages!

Posted: December 16th, 2008, 6:06pm CET by Maile Ohye

Tags: webmaster tools

(Инструменти за уеб администратори, Eines per a administradors web de Google, Webmaster Tools, Googlen Verkkovastaavan työkalut, Εργαλεία για Webmasters, Alat WebMaster, Tīmekļa pārziņa rīki, Žiniatinkli valdytojo įrankiai, Ferramentas para o webmaster do Google, Алатке за вебмастере, Nástroje správcu webu, Orodja za spletne skrbnike, Інструменти для веб-майстра, Công cụ Quản trị Trang Web)

In our recent Webmaster Tools launch, we went live in 14 new languages, bringing our total language support count to 40! With the launch of Bulgarian, Catalan, Croatian, Filipino, Greek, Indonesian, Lithuanian, Latvian, Portuguese (Portugal), Slovak, Slovenian, Serbian, Ukrainian and Vietnamese, Webmaster Tools joins Google products such as Google.com, AdWords, Gmail and Toolbar to reach the 40 Language Initiative (Google's company-wide initiative to make sure Google products are available in the 40 languages read by more than 98% of Internet users).

Our team is very excited to reach so many of you by offering our tools in 40 languages. At the same time, both the Google Localization and Webmaster Tools teams know that there's more room for improvements in the features and quality of our service. We hope to hear your input in the comments below, especially on the linguistic quality of our new languages.

Written by Kidus Asfaw, Google Localization

Friend Connect now available in beta to everyone

Posted: December 5th, 2008, 4:38am CET by Maile Ohye

Tags: products and services

If you've been looking for a way to grow traffic and make your site more interactive, check out Google Friend Connect -- now in beta and available to all webmasters. Remember that with Friend Connect, you can easily add social features to your site by just copying and pasting a few snippets of code, no programming necessary! Your visitors will be able to join your site, create or link to a profile, interact with other visitors, and invite friends to visit your site. Best of all, your visitors won't be required to create yet another username and password -- Friend Connect lets them sign in using an existing Google, Yahoo, AOL, or OpenID account. To learn more, watch the video below:

So for any of you who were interested in Friend Connect after our first announcement, and also to all of the newer readers out there, go ahead and give Friend Connect a try.

Written by Mendel Chuang, Product Marketing Manager

Better targeting your indic language site

Posted: November 13th, 2008, 9:50pm CET by Maile Ohye

Tags: general tips

A lot has been said about how to start a multi-lingual site and how to better target content through meta tags. Our users have raised a number of interesting questions about creating websites in different languages, like the one below.

‘ganex':
> How does one do for INDIA.
> As there are many languages spoken here.
> My Site is primarily in English, but my site targets different cities in INDIA.
> For Hyderabad - I want in Urdu & Telugu and for Chennai I want in Tamil
> for Bengaluru I want in Kannada.
> For North I want in Hindi.’

We’d like to introduce the transliteration API for Indic languages (languages spoken in India) in addition to our Ajax API for languages. With this API at your disposal, content creation is simplified because it not only helps integrating transliteration in your websites but also allows users visiting your site to type in Indic languages.

To include the transliteration API, first you need the AJAX script.

<script type="text/javascript" src="http://www.google.com/jsapi"></>

This script tag will load the google.load function, which lets you load the individual Google APIs. For loading Google Transliteration API, call to google.load looks like this:

<script type="text/javascript">
google.load("elements", "1", {
packages: "transliteration"
});
</script>

When it comes to targeting, don't forget to add meta tags in your local language. And for your questions, we have a new addition to our already existing communication channels like the webmaster help groups and webmaster tools (available in 26 languages!). We also have our own official Orkut webmaster community! Here users can share thoughts and discuss webmaster related issues.

Sign up for our Orkut community now and if you have any additional thoughts we'd love to hear about them.

Cheers,
Jayashree and Zareen, Search Quality Team, Google India

On-Demand Sitemaps for Custom Search

Posted: November 13th, 2008, 11:31am CET by Maile Ohye

Tags: sitemaps

Since we launched enhanced indexing with the Custom Search platform earlier this year, webmasters who submit Sitemaps to Webmaster Tools get special treatment: Custom Search recognizes the submitted Sitemaps and indexes URLs from these Sitemaps into a separate index for higher quality Custom Search results. We analyze your Custom Search Engines (CSEs), pick up the appropriate Sitemaps, and figure out which URLs are relevant for your engines for enhanced indexing. You get the dual benefit of better discovery for Google.com and more comprehensive coverage in your own CSEs.

Today, we're taking another step towards improving your experience with Google webmaster services with the launch of On-Demand Indexing in Custom Search. With On-Demand Indexing, you can now tell us about the pages on your websites that are new, or that are important and have changed, and Custom Search will instantly schedule them for crawl, and index and serve them in your CSEs usually within 24 hours, often much faster.

How do you tell us about these URLs? You guessed it... provide a Sitemap to Webmaster Tools, like you always do, and tell Custom Search about it. Just go to the CSE control panel, click on the Indexing tab, select your On-Demand Sitemap, and hit the "Index Now" button. You can tell us which of these URLs are most important to you via the priority and lastmod attributes that you provide in your Sitemap. Each CSE has a number of pages allocated within the On-Demand Index, and with these attributes, you can us which are most important for indexing. If you need greater allocation in the On-Demand index, as well as more customization controls, Google Site Search provides a range of options.

Some important points to remember:

You only need to submit your Sitemaps once in Webmaster Tools. Custom Search will automatically list the Sitemaps submitted via Webmaster Tools and you can decide which Sitemap to select for On-Demand Indexing.
Your Sitemap needs to be for a website verified in Webmaster Tools, so that we can verify ownership of the right URLs.
In order for us to index these additional pages, our crawlers must be able to crawl them. You can use "Webmaster Tools > Crawl Errors > URLs restricted by robots.txt" or check your robots.txt file to ensure that you're not blocking us from crawling these pages.
Submitting pages for On-Demand Indexing will not make them appear any faster in the main Google index, or impact ranking on Google.com.

We hope you'll use this feature to inform us regularly of the most important changes on your sites, so we can respond quickly and get those pages indexed in your CSE. As always, we're always listening for your feedback on Custom Search.

Written by Rajat Mukherjee, Group Product Manager, Search

Google's SEO Starter Guide

Posted: November 12th, 2008, 12:55pm CET by Maile Ohye

Tags: crawling and indexing

Webmasters often ask us at conferences or in the Webmaster Help Group, "What are some simple ways that I can improve my website's performance in Google?" There are lots of possible answers to this question, and a wealth of search engine optimization information on the web, so much that it can be intimidating for newer webmasters or those unfamiliar with the topic. We thought it'd be useful to create a compact guide that lists some best practices that teams within Google and external webmasters alike can follow that could improve their sites' crawlability and indexing.

Our Search Engine Optimization Starter Guide covers around a dozen common areas that webmasters might consider optimizing. We felt that these areas (like improving title and description meta tags, URL structure, site navigation, content creation, anchor text, and more) would apply to webmasters of all experience levels and sites of all sizes and types. Throughout the guide, we also worked in many illustrations, pitfalls to avoid, and links to other resources that help expand our explanation of the topics. We plan on updating the guide at regular intervals with new optimization suggestions and to keep the technical advice current.

So, the next time we get the question, "I'm new to SEO, how do I improve my site?", we can say, "Well, here's a list of best practices that we use inside Google that you might want to check out."

Update: The guide is now available in Chinese, German, Portuguese (Brazil, Portugal), Spanish, and Turkish.

Written by Brandon Falls, Search Quality Team

Spookier than malware

Posted: October 31st, 2008, 8:47pm CET by Maile Ohye

Tags: events

hotdog

lion king

...and infinitely more fun: webmasters and their pets incognito! Happy Halloween, everyone! If you see any costumes that would pass the SafeSearch filter :), feel like sharing a gripe or telling a good story, please join the chat!

Take care, and don't forget to brush your teeth.
Yours scarily,
The Webmaster Central Team

Our glasses-wearing, no vampire-teeth vampire (Ryan), zoombie Mur, Holiday Fail (Tiffany Lane), Colbert Hipster (Dan Vanderkam), Rick Astley Cutts, Homeboy Ben D'Angelo, Me -- pinker & poofier, Investment Bank CEO Shyam Jayaraman (though you can't see the golden parachute in his backpack)

Chark as Juno, Wysz as Beah Burger (our co-worker), Adi and Matt Dougherty as yellow ninja, red ninja!

Heroes come in all shapes and sizes...

Powdered toast man, Mike Leotta

Adam Lasnik as, let me see if I get this right, a "secret service agent masquerading as a backstage tech" :)

Written by Maile Ohye, Developer Programs Tech Lead

Sitemap:	mRSS:	Contents:
<loc>	<link>	The playpage URL
<video:player_loc>	<media:player> (url attribute)	The SWF URL
<video:content_loc>	<media:content> (url attribute)	The FLV or other raw video URL

SEO News » Items by Maile Ohye

Feeds

Items by Maile Ohye

Posted: January 26th, 2012, 2:53pm CET by Maile Ohye

Tags: products and services

Posted: January 25th, 2012, 11:00am CET by Maile Ohye

Tags: products and services

Posted: January 19th, 2012, 4:00pm CET by Maile Ohye

Tags: Search results

Posted: December 16th, 2011, 10:59am CET by Maile Ohye

Tags: intermediate

Posted: November 7th, 2011, 11:40am CET by Maile Ohye

Tags: products and services

Posted: November 1st, 2011, 4:53pm CET by Maile Ohye

Tags: crawling and indexing

Posted: September 15th, 2011, 7:00am CEST by Maile Ohye

Tags: crawling and indexing

Posted: September 15th, 2011, 7:00am CEST by Maile Ohye

Tags: crawling and indexing

Posted: August 24th, 2011, 12:22pm CEST by Maile Ohye

Tags: products and services

Posted: August 16th, 2011, 2:15pm CEST by Maile Ohye

Tags: webmaster tools

Posted: July 29th, 2011, 5:55pm CEST by Maile Ohye

Tags: intermediate

Posted: June 14th, 2011, 12:30pm CEST by Maile Ohye

Tags: Search results

Posted: June 7th, 2011, 2:49pm CEST by Maile Ohye

Tags: crawling and indexing

Posted: June 2nd, 2011, 2:10am CEST by Maile Ohye

Tags: Search results

Posted: May 18th, 2011, 3:21pm CEST by Maile Ohye

Tags: webmaster tools

Posted: May 6th, 2011, 8:00am CEST by Maile Ohye

Tags: intermediate

Posted: April 1st, 2011, 7:00pm CEST by Maile Ohye

Tags: crawling and indexing

Posted: March 30th, 2011, 4:45pm CEST by Maile Ohye

Tags: intermediate

Posted: March 24th, 2011, 3:00pm CET by Maile Ohye

Tags: intermediate

Posted: March 22nd, 2011, 11:30am CET by Maile Ohye

Tags: products and services

Posted: February 18th, 2011, 12:00pm CET by Maile Ohye

Tags: intermediate

Posted: December 25th, 2010, 1:20am CET by Maile Ohye

Tags: sitemaps

Posted: December 23rd, 2010, 12:41am CET by Maile Ohye

Tags: sitemaps

Posted: December 17th, 2010, 11:00am CET by Maile Ohye

Tags: intermediate

Posted: November 17th, 2010, 6:00pm CET by Maile Ohye

Tags: Search results

Posted: November 11th, 2010, 6:20pm CET by Maile Ohye

Tags: crawling and indexing

Posted: November 8th, 2010, 4:08pm CET by Maile Ohye

Tags: feedback and communication

Posted: November 4th, 2010, 3:00pm CET by Maile Ohye

Tags: feedback and communication

Posted: November 3rd, 2010, 10:00am CET by Maile Ohye

Tags: intermediate

Posted: November 2nd, 2010, 2:50pm CET by Maile Ohye

Tags: intermediate

Posted: October 20th, 2010, 11:51pm CEST by Maile Ohye

Tags: general tips

Posted: September 22nd, 2010, 1:08pm CEST by Maile Ohye

Tags: intermediate

Posted: September 17th, 2010, 5:45pm CEST by Maile Ohye

Tags: sitemaps

Posted: September 9th, 2010, 2:56am CEST by Maile Ohye

Tags: crawling and indexing

Posted: September 8th, 2010, 12:15pm CEST by Maile Ohye

Tags: webmaster tools

Posted: September 2nd, 2010, 6:57pm CEST by Maile Ohye

Tags: Search results

Posted: September 1st, 2010, 1:30am CEST by Maile Ohye

Tags: crawling and indexing

Posted: August 17th, 2010, 12:06am CEST by Maile Ohye

Tags: webmaster tools

Posted: August 16th, 2010, 12:41am CEST by Maile Ohye