Webmaster level: All

Today, we’re happy to introduce Recipe View, a new way of finding recipes when searching on Google. Recipe View enables you to filter your regular web search results to show only recipes and to restrict results based on ingredients, cook time, or calorie preferences:

Read more about Recipe View on the Official Google Blog and be sure to check out our video of Google Chef Scott Giambastiani demonstrating how he uses Recipe View to find great recipes for Googlers:



Recipe View is based on data from recipe rich snippets markup. As a webmaster, to make sure your recipe content can show in Recipe View (currently rolling out in the US and Japan) as well as in regular search results with rich snippets (available globally), be sure to add structured data markup to your recipe pages. Rich snippets are also available for reviews, people, products, and events, and we’ll continue to expand this list of categories over time. You can always see the full list of supported types by referring to our rich snippets documentation and by watching for further updates here on the Webmaster Central Blog.

This marks an exciting milestone for us -- it’s the first time we’ve introduced search filters based on rich snippets markup from webmasters. Over time, we’ll continue exploring new ways to enhance the search experience using this data.

Posted by Toshiaki Fujiki, Google Search team

Webmaster level: Intermediate
We’ve noticed a rise in the number of questions from webmasters about how best to structure a website for mobile phones and how websites can best interact with Googlebot-Mobile. In this post we’ll explain the current situation and give you specific recommendations you can implement now.

Some Background

Let’s start with a simple question: what do we mean by “mobile phone” when talking about mobile-friendly websites?
A good way to answer this question is to think about the capabilities of the mobile phone’s web browser, especially in relation to the capabilities of modern desktop browsers. To simplify matters, we can break mobile phones into a few classifications:

1. Traditional mobile phones: Phones with browsers that cannot render normal desktop webpages. This includes browsers for cHTML (iMode), WML, WAP, and the like.
2. Smartphones: Phones with browsers that render normal desktop pages, at least to some extent. This category includes a diversity of devices, such Windows Phone 7, Blackberry devices, iPhones, and Android phones, and also tablets and eBook readers.We can further break down this category by support for HTML5:
   
   • Devices with browsers that do not support HTML5
   • Devices with browsers that support HTML5

Once upon a time, mobile phones connected to the Internet using browsers with limited rendering capabilities; but this is clearly a changing situation with the fast rise of smartphones which have browsers that rival the full desktop experience. As such, it’s important to note that the distinction we are making here is based on the current situation as we see it and might change in the future.

Googlebot and Mobile Content

Google has two crawlers relevant to this topic: Googlebot and Googlebot-Mobile. Googlebot crawls desktop-browser type of webpages and content embedded in them and Googlebot-Mobile crawls mobile content. The questions we’re seeing more of can be summed up as follows:
Given the diversity of capabilities of mobile web browsers, what kind of content should I serve to Googlebot-Mobile?
The answer lies in the User-agent that Googlebot-Mobile supplies when crawling. There are several User-agent strings in use by Googlebot-Mobile, all of which use this format:
[Phone name(s)] (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
To decide which content to serve, assess which content your website has that best serves the phone(s) in the User-agent string. A full list of Googlebot-Mobile User-agents can be found here.
Notice that we currently do not crawl with Googlebot-Mobile using a smartphone User-agent string. Thus at the current time, a correctly-configured content serving system will serve Googlebot-Mobile content only for the traditional phones described above, because that’s what the User-agent strings in use today dictate. This may change in the future, and if so, it may mean there would be a new Googlebot-Mobile User-agent string.
For now, we expect smartphones to handle desktop experience content so there is no real need for mobile-specific effort from webmasters. However, for many websites it may still make sense for the content to be formatted differently for smartphones, and the decision to do so should be based on how you can best serve your users.

URL Structure for Mobile Content

The next set of questions ask about the URLs mobile content should be served from. Let’s look in detail at some common use cases.

Websites with only Desktop Experience Content

Most websites currently have only one version of their content, namely in HTML that is designed for desktop web browsers. This means all browsers access the content from the same URL.
These websites may not be serving traditional mobile phone users. The quality experienced by their smartphone users depends on the mobile browser they are using and it could be as good as browsing from the desktop.
If you serve only desktop experience content for all User Agents, you should do so for Googlebot-Mobile too; that is, treat Googlebot-Mobile as you treat all other or unknown User Agents. In these cases, Google may modify your webpages for an improved mobile experience.

Websites with Dedicated Mobile Content

Many websites have content specifically optimized for mobile users. The content could be simply reformatted for the typically smaller mobile displays, or it could be in a different format (e.g., served using WAP, etc.).
A very common question we see is: Does it matter if the different types of content are served from the same URL or from different URLs? For example, some websites have www.example.com as the URL desktop browsers are meant to access and have m.example.com or wap.example.com for the different mobile devices. Other websites serve all types of content from just one URL structure like www.example.com.
For Googlebot and Googlebot-Mobile, it does not matter what the URL structure is as long as it returns exactly what a user sees too. For example, if you redirect mobile users from www.example.com to m.example.com, that will be recognized by Googlebot-Mobile and both websites will be crawled and added to the correct index. In this case, use a 301 redirect for both users and Googlebot-Mobile.
If you serve all types of content from www.example.com, i.e. serving desktop-optimized content or mobile-optimized content from the same URL depending on the User-agent, this will also lead to correct crawling by Googlebot and Googlebot-Mobile. This is not considered cloaking by Google.
It is worth repeating that regardless of URL structure, you must correctly detect the User-agent as given by your users and Googlebot-Mobile, and serve both the same content. Don’t forget to keep the default content, the desktop-optimized content, for when an unknown User-agent requests it.

Mobile Sitemaps in Webmaster Tools

Finally, we receive many questions about what URLs to put in Mobile Sitemaps. As explained in our Mobile Sitemaps Help Center articles, you should include only mobile content URLs in Mobile Sitemaps, even if these URLs also return non-mobile content when accessed by a non-mobile User-agent.

More Questions?

A good place to start is our Mobile Sites Help Center articles and the relevant sections in our Search Engine Optimization Starter Guide. We also created a thread in our forums for you to ask questions about this post.
Posted by Pierre Far, Webmaster Trends Analyst

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.

Webmaster level: All

If you use Google Analytics to track site data, you can now link your Webmaster Tools verified site to an Analytics profile when they use the same Google Account.

Not only will your Analytics profiles be accessible within Webmaster Tools, but you'll also be able to more easily access a few Google Analytics features:

• View your Google Analytics Referring Pages report directly from the Links to your site page in Webmaster Tools. This report helps you understand the overall trends in traffic volume from referrals, as well as the sites driving those trends.


• Access the Google Analytics Dashboard directly from the Analytics link in the top left bar when you’re on a site-related page.

To link a verified site in Webmaster Tools to a Google Analytics profile:

1. On the Webmaster Tools home page, click Manage next to the site you want, then click Google Analytics profile.



2. Select the profile you want to associate with the site, then click Save.

Note: If your site has multiple owners, each owner will need to link their own account to a Google Analytics profile.

Written by Zhanlu Wang, Webmaster Tools Team

Webmaster level: All

Last year we relaunched an exciting feature in Webmaster Tools: Search Queries, an analysis tool that visualizes your site’s presence in our search results. It has two main parts: an interactive graph, and a table containing detailed data related to queries for which your site appears in our search results.

Two of the most important pieces of information in the table are ‘impressions’ and ‘clicks.’ ‘Impressions’ shows the number of times your pages were shown in the search results for a certain query, and ‘clicks’ is how many times users actually clicked on a result from your site.

Based on webmaster feedback, today we’re announcing a slight change in how these numbers are represented in Webmaster Tools, to simplify their interpretation. Instead of showing numbers rounded to two or three digits, the numbers will now be shown with one or two significant digits. For example, instead of Webmaster Tools showing you 246,000 impressions, it will now show 250,000 impressions, which is a nicer representation for a better, less confusing experience. We have not altered the way we calculate the numbers internally, but only changed how we round them in Webmaster Tools. Generally, a difference of less than 10% between the numbers you see now and those you saw prior to this change should not be considered significant.

Impressions before and after today’s Search Queries update

We hope that this update makes Search Queries easier to understand. If you want to learn more about this feature you can visit our Help Center. If you have feedback or suggestions for Search Queries, please let us know in the Webmaster Help Forum.

Posted by Pierre Far and Gary Illyes, Webmaster Trends Analyst team