Preview the latest +1 button changes

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

Page Speed Service - Web Performance, Delivered.

Webmaster level: Advanced

Two years ago we released the Page Speed browser extension and earlier this year the Page Speed Online API to provide developers with specific suggestions to make their web pages faster. Last year we released mod_pagespeed, an Apache module, to automatically rewrite web pages. To further simplify the life of webmasters and to avoid the hassles of installation, today we are releasing the latest addition to the Page Speed family: Page Speed Service.

Page Speed Service is an online service that automatically speeds up loading of your web pages. To use the service, you need to sign up and point your site’s DNS entry to Google. Page Speed Service fetches content from your servers, rewrites your pages by applying web performance best practices, and serves them to end users via Google's servers across the globe. Your users will continue to access your site just as they did before, only with faster load times. Now you don’t have to worry about concatenating CSS, compressing images, caching, gzipping resources or other web performance best practices.

In our testing we have seen speed improvements of 25% to 60% on several sites. But we know you care most about the numbers for your site, so check out how much Page Speed Service can speed up your site. If you’re encouraged by the results, please sign up. If not, be sure to check back later. We are diligently working on adding more improvements to the service.

At this time, Page Speed Service is being offered to a limited set of webmasters free of charge. Pricing will be competitive and details will be made available later. You can request access to the service by filling out this web form.

Posted by Ram Ramani, Engineering Manager

The +1 Button: Now Faster

Webmaster level: All

One of the 10 things we hold to be true here at Google is that fast is better than slow. We keep speed in mind in all things that we do, and the +1 button is no exception. Since the button’s launch, we have been hard at work improving its load time. Today, we’re proud to announce two updates that will make both the +1 button and the page loading it, faster.

First, we’ve begun to roll out out a set of changes that will make the button render up to 3x faster on your site. No action is required on your part, so just sit back, relax, and watch as the button loads more quickly than before.

In addition to the improvements made to the button, we’re also introducing a new asynchronous snippet, allowing you to make the +1 experience even faster. The async snippet allows your web page to continue loading while your browser downloads the +1 JavaScript. By loading these elements in parallel, we’re ensuring the HTTP request to get the +1 button JavaScript doesn’t lead to an increase in your page load time. For those of you who have already implemented the button, you’ll need to update the code to the new async snippet, and then you should see an overall improvement in your page load time.

To generate the new async snippet, use our +1 Configuration Tool. Below, you’ll find an example of the code, which should be included below the last <g:plusone> tag on your page for best performance.

If you haven’t already implemented the +1 button on your site, we’re excited for your first experience to be a fast one. This is a great opportunity to allow your users to recommend your site to their friends, potentially bringing in more qualified traffic from Google search. To those that already have the button, we hope that you enjoy the improvements in speed. Our team will continue to work hard to enhance the +1 button experience as we know that “fast is better than slow” is as true today as it’s ever been.

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. For advanced tips and tricks, check our Google Code site.

Posted by David Byttow, Software Engineer

Improved handling of URLs with parameters

Webmaster level: Advanced

You may have noticed that the Parameter Handling feature disappeared from the Site configuration > Settings section of Webmaster Tools. Fear not; you can now find it under its new name, URL Parameters! Along with renaming it, we refreshed and improved the feature. We hope you’ll find it even more useful. Configuration of URL parameters made in the old version of the feature will be automatically visible in the new version. Before we reveal all the cool things you can do with URL parameters now, let us remind you (or introduce, if you are new to this feature) of the purpose of this feature and when it may come in handy.

When to use
URL Parameters helps you control which URLs on your site should be crawled by Googlebot, depending on the parameters that appear in these URLs. This functionality provides a simple way to prevent crawling duplicate content on your site. Now, your site can be crawled more effectively, reducing your bandwidth usage and likely allowing more unique content from your site to be indexed. If you suspect that Googlebot's crawl coverage of the content on your site could be improved, using this feature can be a good idea. But with great power comes great responsibility! You should only use this feature if you're sure about the behavior of URL parameters on your site. Otherwise you might mistakenly prevent some URLs from being crawled, making their content no longer accessible to Googlebot.

A lot more to do
Okay, let’s talk about what’s new and improved. To begin with, in addition to assigning a crawl action to an individual parameter, you can now also describe the behavior of the parameter. You start by telling us whether or not the parameter changes the content of the page. If the parameter doesn’t affect the page’s content then your work is done; Googlebot will choose URLs with a representative value of this parameter and will crawl the URLs with this value. Since the parameter doesn’t change the content, any value chosen is equally good. However, if the parameter does change the content of a page, you can now assign one of four possible ways for Google to crawl URLs with this parameter:

• Let Googlebot decide
• Every URL
• Only crawl URLs with value=x
• No URLs

We also added the ability to provide your own specific value to be used, with the “Only URLs with value=x” option; you’re no longer restricted to the list of values that we provide. Optionally, you can also tell us exactly what the parameter does--whether it sorts, paginates, determines content, etc. One last improvement is that for every parameter, we’ll try to show you a sample of example URLs from your site that Googlebot crawled which contain that particular parameter.

Of the four crawl options listed above, “No URLs” is new and deserves special attention. This option is the most restrictive and, for any given URL, takes precedence over settings of other parameters in that URL. This means that if the URL contains a parameter that is set to the “No URLs” option, this URL will never be crawled, even if other parameters in the URL are set to “Every URL.” You should be careful when using this option. The second most restrictive setting is “Only URLs with value=x.”

Feature in use
Now let’s do something fun and exercise our brains on an example.

- - -

Once upon a time there was an online store, fairyclothes.example.com. The store’s website used parameters in its URLs, and the same content could be reached through multiple URLs. One day the store owner noticed, that too many redundant URLs could be preventing Googlebot from crawling the site thoroughly. So he sent his assistant CuriousQuestionAsker to The GreatWebWizard to get advice on using the URL parameters feature to reduce the duplicate content crawled by Googlebot. The Great WebWizard was famous for his wisdom. He looked at the URL parameters and proposed the following configuration:

Parameter name	Effect on content?	What should Googlebot crawl?
trackingId	None	One representative URL
sortOrder	Sorts	Only URLs with value = ‘lowToHigh’
sortBy	Sorts	Only URLs with value = ‘price’
filterByColor	Narrows	No URLs
itemId	Specifies	Every URL
page	Paginates	Every URL

The CuriousQuestionAsker couldn’t avoid his nature and started asking questions:

CuriousQuestionAsker: You’ve instructed Googlebot to choose a representative URL for trackingId (value to be chosen by Googlebot). Why not select the Only URLs with value=x option and choose the value myself?
Great WebWizard: While crawling the web Googlebot encountered the following URLs that link to your site:

1. fairyclothes.example.com/skirts/?trackingId=aaa123
2. fairyclothes.example.com/skirts/?trackingId=aaa124
3. fairyclothes.example.com/trousers/?trackingId=aaa125

Imagine that you were to tell Googebot to only crawl URLs where “trackingId=aaa125”. In that case Googlebot would not crawl URLs 1 and 2 as neither of them has the value aaa125 for trackingId. Their content would neither be crawled nor indexed and none of your inventory of fine skirts would show up in Google’s search results. No, for this case choosing a representative URL is the way to go. Why? Because that tells Googlebot that when it encounters two URLs on the web that differ only in this parameter (as URLs 1 and 2 above do) then it only needs to crawl one of them (either will do) and it will still get all the content. In the example above two URLs will be crawled; either 1 & 3, or 2 & 3. Not a single skirt or trouser will be lost.

CuriousQuestionAsker: What about the sortOrder parameter? I don’t care if the items are listed in ascending or descending order. Why not let Google select a representative value?
Great WebWizard: As Googlebot continues to crawl it may find the following URLs:

1. fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
2. fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’highToLow’
3. fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’lowToHigh’
4. fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

Notice how the first pair of URLs (1 & 2) differs only in the value of the sortOrder parameter as do URLs in the second pair (3 & 4). However, URLs 1 and 2 will produce different content: the first showing the least expensive of your skirts while the second showing the priciest. That should be your first hint that using a single representative value is not a good choice for this situation. Moreover, if you let Googlebot choose a single representative from among a set of URLs that differ only in their sortOrder parameter it might choose a different value each time. In the example above, from the first pair of URLs, URL 1 might be chosen (sortOrder=’lowToHigh’). Whereas from the second pair URL 4 might be picked (sortOrder=’ highToLow’). If that were to happen Googlebot would crawl only the least expensive skirts (twice):

• fairyclothes.example.com/skirts/?page=1&sortBy=price&sortOrder=’lowToHigh’
• fairyclothes.example.com/skirts/?page=2&sortBy=price&sortOrder=’ highToLow’

Your most expensive skirts would not be crawled at all! When dealing with sorting parameters consistency is key. Always sort the same way.

CuriousQuestionAsker: How about the sortBy value?
Great WebWizard: This is very similar to the sortOrder attribute. You want the crawled URLs of your listing to be sorted consistently throughout all the pages, otherwise some of the items may not be visible to Googlebot. However, you should be careful which value you choose. If you sell books as well as shoes in your store, it would be better not to select the value ‘title’ since URLs pointing to shoes never contain ‘sortBy=title’, so they will not be crawled. Likewise setting ‘sortBy=size’ works well for crawling shoes, but not for crawling books. Keep in mind that parameters configuration has influence throughout the whole site.

CuriousQuestionAsker: Why not crawl URLs with parameter filterByColor?
Great WebWizard: Imagine that you have a three-page list of skirts. Some of the skirts are blue, some of them are red and others are green.

• fairyclothes.example.com/skirts/?page=1
• fairyclothes.example.com/skirts/?page=2
• fairyclothes.example.com/skirts/?page=3

This list is filterable. When a user selects a color, she gets two pages of blue skirts:

• fairyclothes.example.com/skirts/?page=1&flterByColor=blue
• fairyclothes.example.com/skirts/?page=2&flterByColor=blue

They seem like new pages (the set of items are different from all other pages), but there is actually no new content on them, since all the blue skirts were already included in the original three pages. There’s no need to crawl URLs that narrow the content by color, since the content served on those URLs was already crawled. There is one important thing to notice here: before you disallow some URLs from being crawled by selecting the “No URLs” option, make sure that Googlebot can access the content in another way. Considering our example, Googlebot needs to be able to find the first three links on your site, and there should be no settings that prevent crawling them.

- - -

If your site has URL parameters that are potentially creating duplicate content issues then you should check out the new URL Parameters feature in Webmaster Tools. Let us know what you think or if you have any questions post them to the Webmaster Help Forum.

Written by Kamila Primke, Software Engineer, Webmaster Tools Team

Validation: measuring and tracking code quality

Webmaster level: All

Google’s Webmaster Team is responsible for most of Google’s informational websites like Google’s Jobs site or Privacy Centers. Maintaining tens of thousands of pages and constantly releasing new Google sites requires more than just passion for the job: it requires quality management.

In this post we won’t talk about all the different tests that can be run to analyze a website; instead we’ll just talk about HTML and CSS validation, and tracking quality over time.

Why does validation matter? There are different perspectives on validation—at Google there are different approaches and priorities too—but the Webmaster Team considers validation a baseline quality attribute. It doesn’t guarantee accessibility, performance, or maintainability, but it reduces the number of possible issues that could arise and in many cases indicates appropriate use of technology.

While paying a lot of attention to validation, we’ve developed a system to use it as a quality metric to measure how we’re doing on our own pages. Here’s what we do: we give each of our pages a score from 0-10 points, where 0 is worst (pages with 10 or more HTML and CSS validation errors) and 10 is best (0 validation errors). We started doing this more than two years ago, first by taking samples, now monitoring all our pages.

Since the beginning we’ve been documenting the validation scores we were calculating so that we could actually see how we’re doing on average and where we’re headed: is our output improving, or is it getting worse?

Here’s what our data say:

Validation score development 2009-2011.

On average there are about three validation issues per page produced by the Webmaster Team (as we combine HTML and CSS validation in the scoring process, information about the origin gets lost), down from about four issues per page two years ago.

This information is valuable for us as it tells us how close we are to our goal of always shipping perfectly valid code, and it also tells us whether we’re on track or not. As you can see, with the exception of the 2nd quarter of 2009 and the 1st quarter of 2010, we are generally observing a positive trend.

What has to be kept in mind are issues with the integrity of the data, i.e. the sample size as well as “false positives” in the validators. We’re working with the W3C in several ways, including reporting and helping to fix issues in the validators; however, as software can never be perfect, sometimes pages get dinged for non-issues: see for example the border-radius issue that has recently been fixed. We know that this is negatively affecting the validation scores we’re determining, but we have no data yet to indicate how much.

Although we track more than just validation for quality control purposes, validation plays an important role in measuring the health of Google’s informational websites.

How do you use validation in your development process?

Posted by Jens O. Meiert, Google Webmaster Team