Friday, December 4, 2009

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to for Mac.

  • [r33490] Disabled extensions. (Issue: 29086)
  • [r33556] [r33768] Added more localized string translations.
  • [r33803] Fixed download dialog truncation in German locale. (Issue: 23178)

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome Program Manager

[Gd] Your site's performance in Webmaster Tools

| More

Official Google Webmaster Central Blog: Your site's performance in Webmaster Tools

Webmaster level: Intermediate

Let's take a quick look at the individual sections in the Google Webmaster Tools' Site Performance feature:

Performance overview

The performance overview shows a graph of the aggregated speed numbers for the website, based on the pages that were most frequently accessed by visitors who use the Google Toolbar with the PageRank feature activated. By using data from Google Toolbar users, you don't have to worry about us testing your site from a location that your users do not use. For example, if your site is in Germany and all your users are in Germany, the chart will reflect the load time as seen in Germany. Similarly, if your users mostly use dial-up connections (or high-speed broadband), that would be reflected in these numbers as well. If only a few visitors of your site use the Google Toolbar, we may not be able to show this data in Webmaster Tools.

The line between the red and the green sections on the chart is the 20th percentile — only 20% of the sites we check are faster than this. This website is pretty close to the 20% mark, which pages would we have to work on first?

Example pages with load times

In this section you can find some example pages along with the average, aggregated load times that users observed while they were on your website. These numbers may differ from what you see as they can come from a variety of different browsers, internet connections and locations. This list can help you to recognize pages which take longer than average to load — pages that slow your users down.

As the page load times are based on actual accesses made by your users, it's possible that it includes pages which are disallowed from crawling. While Googlebot will not be able to crawl disallowed pages, they may be a significant part of your site's user experience.

Keep in mind that you may see occasional spikes here, so it's recommended that you watch the load times over a short period to see what's stable. If you consistently see very large load times, that probably means that most of your users are seeing very slow page loads (whether due to slow connections or otherwise), so it's something you should take seriously.

Page Speed suggestions

These suggestions are based on the Page Speed Firefox / Firebug plugin. In order to find the details for these sample URLs, we fetch the page and all its embedded resources with Googlebot. If we are not able to fetch all of embedded content with Googlebot, we may not be able to provide a complete analysis. Similarly, if the servers return slightly modified content for Googlebot than they would for normal users, this may affect what is shown here. For example, some servers return uncompressed content for Googlebot, similar to what would be served to older browsers that do not support gzip-compressed embedded content (this is currently the case for Google Analytics' "ga.js").

When looking at flagged issues regarding common third-party code such as website analytics scripts, one factor that can also play a role is how wide-spread these scripts are on the web. If they are common across the web, chances are that the average user's browser will have already cached the DNS lookup and the content of the script. While these scripts will still be flagged as separate DNS lookups, in practice they might not play a strong role in the actual load time.

We offer these suggestions as a useful guideline regarding possible first performance improvement steps and recommend using the Page Speed plugin (or a similar tool) directly when working on your website. This allows you to better recognize the blocking issues and makes it easy to see how modifications on the server affect the total load time.

For questions about Webmaster Tools and this new feature, feel free to read the Help Center article, search and post in the Webmaster Help Forums or in the Page Speed discussion group. We hope this information helps you make your website even faster!

Posted by John Mueller, Webmaster Trends Analyst, Google Zürich

[Gd] Links That Open in New Processes

| More

Chromium Blog: Links That Open in New Processes

We've introduced a new way for web developers to take advantage of Google Chrome's multi-process architecture, as of version Google Chrome already uses separate OS processes to isolate independent tabs from each other in the browser, so that crashes or slowdowns in one tab won't affect the others. Google Chrome even switches a given tab's process if you type a different site's URL into the Omnibox.

In many cases, though, Google Chrome needs to keep pages from related tabs in the same process, since they may access each other's contents using JavaScript code. For example, clicking links that open in a new window will generally cause the new and old pages to share a process.

In practice, web developers may find situations where they would like links to other pages to open in a separate process. As one example, links from messages in your webmail client would be nice to isolate from the webmail client itself. This is easy to achieve now, thanks to new support in WebKit for HTML5's "noreferrer" link relation.

To cause a link to open in a separate process from your web page, just add rel="noreferrer" and target="_blank" as attributes to the <a> tag, and then point it at a URL on a different domain name. For example:

<a href="" rel="noreferrer" target="_blank">Google</a>

In this case, Google Chrome knows that the page will be opened in a new window, that no referrer information will be passed to the new page, and that the window.opener value will be null in the new page. As a result, the two pages cannot script each other, so Chrome can load them in separate processes. Google Chrome will still keep same-site pages in the same process, to allow them to share caches and minimize overhead.

We hope you find this useful on your own sites!

Posted by Charlie Reis, Software Engineer

[Gd] "If you were a brand new QA manager ..." (cont)

| More

Google Testing Blog: "If you were a brand new QA manager ..." (cont)

By James A. Whittaker

More thoughts:

Understand your orgs release process and priorities
Late cycle pre-release testing is the most nerve racking part of the entire development cycle. Test managers have to strike a balance between doing the right testing and ensuring a harmonious release. I suggest attending all the dev meetings, but certainly as release approaches you shouldn't miss a single one. Pay close attention to their worries and concerns. Nightmare scenarios have a tendency to surface late in the process. Add test cases to your verification suite to ensure these scenarios won't happen.

The key here is to get late cycle pre-release testing right without any surprises. Developers can get skittish so make sure they understand your test plan going into the final push. The trick isn't to defer to development as to how to perform release testing but to make sure they are on-board with your plan. I find that at Google increasing the team's focus on manual testing is wholeheartedly welcomed by the dev team. Find your dev team's comfort zone and strike a balance between doing the right testing and making the final hours/days as wrinkle-free as possible.

Question your testing process
Start by reading every test case and reviewing all automation. Can you map these test cases back to the test plan? How many tests do you have per component? Per feature? If a bug is found outside the testing process did you create a test case for it? Do you have a process to fix or deprecate broken or outdated test cases?

As a test manager the completeness and thoroughness of the set of tests is your job. You may not be writing or running a lot of tests, but you should have them all in your head and be the first to spot gaps. It should be something a new manager tackles early and stays on top of at all times.

Look for ways to innovate
The easiest way to look good in the eyes of developers is to maintain the status quo. Many development managers appreciate a docile and subservient test team. Many of them like a predictable and easily understood testing practice. It's one less thing to worry about (even in the face of obvious inefficiencies the familiar path is often the most well worn).

As a new manager it is your job not to let them off so easy! You should make a list of the parts of the process that concern you and the parts that seem overly hard or inefficient. These are the places to apply innovation. Prepare for nervousness from the developer ranks, but do yourself and the industry a favor and place some bets for the long term.

There is no advice I have found universally applicable concerning how to best foster innovation. What works for me is to find the stars on your team and make sure they are working on something they can be passionate about. As a manager this is the single most important thing you can do to increase productivity and foster innovation.

Thursday, December 3, 2009

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to for Windows.

  • [r33602] Delete old version directories of installed extensions during garbage collection. (Issue: 28884)
  • Fixes for two top crashes. (Issues: 28994 and 27068)

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome Program Manager

[Gd] Google Wave API Articles: Extensions Debugging & Robot-to-Gadget Communication

| More

Google Wave Developer Blog: Google Wave API Articles: Extensions Debugging & Robot-to-Gadget Communication

We've recently added an articles section to the Google Wave APIs documentation, with three articles to make Google Wave API development easier.

Debugging Robots
Learn how to use the App Engine logs for easier debugging, verify your robot is set up correctly, and even test your robot locally (without deploying). This article can speed up your development process by making it faster and easier to catch bugs.

Debugging Gadgets
Get tips for testing new code, simulating multiple users, logging debug messages, and logging state deltas. Developing multi-user real-time gadgets is hard when you're just one developer, and this article should make it easier for you.

Robot-to-Gadget Communication
Delve into the innards of "Embeddy", the robot that generates embed code for a wave. This article describes how robots can insert gadgets on a wave, and then set the state of them. Some of the most useful extensions out there involve careful interaction of robots and gadgets, and this can get you started.

Enjoy the articles - and please tell us in the forum if you have improvements or your own articles to share.

Posted by Pamela Fox, Developer Relations

[Gd] App Engine SDK 1.2.8 Released Including New Admin Console features

| More

Google App Engine Blog: App Engine SDK 1.2.8 Released Including New Admin Console features

The App Engine team has been hard at work tackling our the issues on our tracker, tweaking APIs and closing bugs. In addition to a ton of bug fixes, 1.2.8 also includes:

Enhanced Admin Console - Users will notice new tools for managing tasks and queues created with the Task Queue API, and more visibility into index processing.

Improved Java Compatibility - This release adds support for new filter operators and inheritance to JPA and JDO as well as support for JAXB, the single most requested feature for the Java SDK.

This was also the first release we "previewed" with developers before formally rolling out changes. Thanks very much to all the developers that gave us feedback on the preview release. And if you're interested in helping with future prereleases, please subscribe to the discussion groups to see preview release announcements.

1.2.8 is now available for both Python and Java developers. Take a look at our release notes for details on all the changes included in this release.

Posted by Google App Engine Team

[Gd] Android SDK Updates

| More

Android Developers Blog: Android SDK Updates

Today we are releasing updates to multiple components of the Android SDK:

  • Android 2.0.1, revision 1
  • Android 1.6, revision 2
  • SDK Tools, revision 4

Android 2.0.1 is a minor update to Android 2.0. This update includes several bug fixes and behavior changes, such as application resource selection based on API level and changes to the value of some Bluetooth-related constants. For more detailed information, please see the Android 2.0.1 release notes.

To differentiate its behavior from Android 2.0, the API level of Android 2.0.1 is 6. All Android 2.0 devices will be updated to 2.0.1 before the end of the year, so developers will no longer need to support Android 2.0 at that time. Of course, developers of applications affected by the behavior changes should start compiling and testing their apps immediately.

We are also providing an update to the Android 1.6 SDK component. Revision 2 includes fixes to the compatibility mode for applications that don't support multiple screen sizes, as well as SDK fixes. Please see the Android 1.6, revision 2 release notes for the full list of changes.

Finally, we are also releasing an update to the SDK Tools, now in revision 4. This is a minor update with mostly bug fixes in the SDK Manager. A new version of the Eclipse plug-in that embeds those fixes is also available. For complete details, please see the SDK Tools, revision 4 and ADT 0.9.5 release notes.

One more thing: you can now follow us on twitter @AndroidDev.


[Gd] Technically speaking, what makes Google Chrome fast?

| More

Chromium Blog: Technically speaking, what makes Google Chrome fast?

Earlier this year, we heard from many of you on how important speed is to your daily activities on the web. We kicked off a series of discussions with the Internet community on ways to make the web faster: from Internet protocols and best practices in website development, to improvements in the browser itself.

A lot of engineering effort is involved in making sure that a browser continually provides a fast, responsive, and satisfying experience on the web. We're excited to see modern browsers continue to push the envelope in designing and optimizing browser architecture for speed and performance.

We've often been asked what makes Google Chrome so fast -- from its snappy start-up time and fast page-loading, to the ability to run complex web applications quickly. To walk through some of the thought processes and technical decisions involved in making Google Chrome a fast browser, we've put together three technical interviews on DNS pre-resolution, the V8 JavaScript engine, and DOM bindings. In a future post, we'll also cover other important areas like WebKit and UI responsiveness.

DNS pre-resolution
with Jim Roskind

  1. What is DNS pre-resolution, and how does it make Google Chrome even faster?
  2. Why is DNS pre-resolution difficult to do?
  3. Explain in more detail how adaptive pre-resolution works.
  4. How else is DNS pre-resolution beneficial? Can it help with browser start-up time?
  5. How do we measure and benchmark the benefits of DNS pre-resolution?
  6. What's next for DNS pre-resolution?

V8 JavaScript engine
with Mads Ager

  1. What is V8?
  2. What are we currently doing to speed up JavaScript performance on V8?
  3. How do we achieve big boosts in JavaScript speed, such as the recent 150% improvement since our initial launch?
  4. How do we measure V8's performance?

DOM bindings and more
with Mike Belshe

  1. What are DOM bindings?
  2. What are the most recent improvements in DOM bindings, for Google Chrome as well as other browsers?
  3. The Google Chrome beta release in August 2009 included improvements in DOM bindings. Tell us more.
  4. How do we measure and benchmark improvements in DOM bindings?
  5. In general, what are the biggest performance impediments for a browser?
  6. What are some of the performance benefits of Google Chrome's multiprocess architecture?

Posted by Min Li Chan, Product Marketing Manager

[Gd] Introducing Google Public DNS: A new DNS resolver from Google

| More

Google Code Blog: Introducing Google Public DNS: A new DNS resolver from Google

Today, as part of our efforts to make the web faster, we are announcing Google Public DNS, a new experimental public DNS resolver.

The DNS protocol is an important part of the web's infrastructure, serving as the Internet's "phone book". Every time you visit a website, your computer performs a DNS lookup. Complex pages often require multiple DNS lookups before they complete loading. As a result, the average Internet user performs hundreds of DNS lookups each day, that collectively can slow down his or her browsing experience.

We believe that a faster DNS infrastructure could significantly improve the browsing experience for all web users. To enhance DNS speed but to also improve security and validity of results, Google Public DNS is trying a few different approaches that we are sharing with the broader web community through our documentation:
  • Speed: Resolver-side cache misses are one of the primary contributors to sluggish DNS responses. Clever caching techniques can help increase the speed of these responses. Google Public DNS implements prefetching: before the TTL on a record expires, we refresh the record continuously, asychronously and independently of user requests for a large number of popular domains. This allows Google Public DNS to serve many DNS requests in the round trip time it takes a packet to travel to our servers and back.

  • Security: DNS is vulnerable to spoofing attacks that can poison the cache of a nameserver and can route all its users to a malicious website. Until new protocols like DNSSEC get widely adopted, resolvers need to take additional measures to keep their caches secure. Google Public DNS makes it more difficult for attackers to spoof valid responses by randomizing the case of query names and including additional data in its DNS messages.

  • Validity: Google Public DNS complies with the DNS standards and gives the user the exact response his or her computer expects without performing any blocking, filtering, or redirection that may hamper a user's browsing experience.
We hope that you will help us test these improvements by using the Google Public DNS service today, from wherever you are in the world. We plan to share what we learn from this experimental rollout of Google Public DNS with the broader web community and other DNS providers, to improve the browsing experience for Internet users globally.

To get more information on Google Public DNS you can visit our site, read our documentation, and our logging policies. We also look forward to receiving your feedback in our discussion group.

By Prem Ramaswami, Public DNS Team

Wednesday, December 2, 2009

[Gd] You got questions? We've got answers!

| More

Google Wave Developer Blog: You got questions? We've got answers!

Last Saturday, at the Mass GTUG Wave Hackathon, I spent six hours hopping from table to table, answering questions about the best way to do X, the quickest way to do Y, and the future way to do Z. I soon realized that these questions were likely reflective of the questions that go through the heads of developers getting started with the Google Wave APIs, and I started taking notes (in Google Wave, of course). With the help of my colleagues, we've turned those notes into the beginnings of an FAQ for Wave developers. There are 4 sections in the FAQ, covering questions on sandbox/preview accounts, client libraries, and general development tips, helping you answer questions like "How do you retrieve a submitted blip?" and "How can you view the XML representation of a Wave?".

The coolest part of the FAQ is that it's actually generated from a series of waves on, and a robot takes care of exporting the waves into the HTML page. This means that our team can use Wave for super-easy collaboration on the FAQs, but we can represent the information in a format that is viewable by everyone and fits in with the rest of the documentation. The FAQ-generator robot is based on the Exporty sample, so take a look at that if you want to implement a similar system to meet your own needs.

Please read through the FAQ when you have the chance; you might learn something new, or hey, you might have an answer that's better than ours. Stop by the Google Wave API forum to let us know what we can improve or add.

Posted by Pamela Fox, Developer Relations

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to for Linux, Mac, and Windows.

  • [r33013] Disable --enable-user-scripts. (Issue: 27520)
    • NOTE: You can now install user scripts by navigating to them. You will have to reinstall your current scripts (they aren't migrated).
  • [r33086] Remove toolstrips API. (Issue: 24475)
  • [r32875] Turn on HTML5 DBs by default.

  • [r32793] Omnibox no longer becomes too long for window after installing a few themes (Issue: 28476)
  • [r32843] Display a warning dialog if there was a problem reading the profile (Issue: 26377)
  • [r32943] Switch "Save" and "Discard" buttons on dangerous download warning to match platform standard. (Issue: 28638)
  • [r33105] Show feedback while dragging bookmarks (Issue: 17608)
  • [r33243] Implement non-admin autoupdate (Issue: 16360)

Known Issue
  • [MAC] (Issue: 29121) If a user clicks "Set Up Automatic Updates for All Users" and later clicks "Update Now" from the About Box, an error 12 will be displayed. The product is updated successfully; restarting the browser will apply the update.

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome Program Manager

[Gd] Deeper integration for Friend Connect and Twitter

| More

Google Code Blog: Deeper integration for Friend Connect and Twitter

Did you hear that Friend Connect and Twitter are more closely integrated than ever? To learn more, check out our post on the Social Web Blog.

By James Reilly, Google Friend Connect Team

[Gd] How fast is your site?

| More

Official Google Webmaster Central Blog: How fast is your site?

We've just launched Site Performance, an experimental feature in Webmaster Tools that shows you information about the speed of your site and suggestions for making it faster.

This is a small step in our larger effort to make the web faster. Studies have repeatedly shown that speeding up your site leads to increased user retention and activity, higher revenue and lower costs. Towards the goal of making every webpage load as fast as flipping the pages of a magazine, we have provided articles on best practices, active discussion forums and many tools to diagnose and fix speed issues.

Now we bring data and statistics specifically applicable to your site. On Site Performance, you'll find how fast your pages load, how they've fared over time, how your site's load time compares to that of other sites, examples of specific pages and their actual page load times, and Page Speed suggestions that can help reduce user-perceived latency. Our goal is to bring you specific and actionable speed information backed by data, so stay tuned for more of this in the future.

screenshot of Site Performance

The load time data is derived from aggregated information sent by users of your site who have installed the Google Toolbar and opted-in to its enhanced features. We only show the performance charts and tables when there's enough data, so not all of them may be shown if your site has little traffic. The data currently represents a global average; a specific user may experience your site faster or slower than the average depending on their location and network conditions.

This is a Labs product that is still in development. We hope you find it useful. Please let us know your feedback through the Webmaster Tools Forum.

Posted by Sreeram Ramachandran, Software Engineer & Arvind Jain, Director, Faster Web program

[Gd] "If you were a brand new QA manager ..."

| More

Google Testing Blog: "If you were a brand new QA manager ..."

By James A. Whittaker

I got this question in email this morning from a reader:

"I am a test supervisor at --- and was promoted to a QA management position yesterday. I'm excited and terrified, so I have been thinking about how to organize the thought in my mind. After attending StarWest and following your blog for a while now, I am very interested in your opinion.

If you were a brand new QA Manager, and you knew what you know now, what are the top 5-10 things you would focus on?"

I am flattered by the confidence but in the event it is misplaced I wanted to answer this question publicly and invite readers to chime in with their own experiences. Besides, I am curious as to other opinions because I live with this same excitement and terror every day and could use a little advice myself. Here's my first couple and I'll add some more in future posts (unless of course you guys beat me to it).

Start living with your product, get passionate about it
Drink your product's kool-aid, memorize the sales pitch, understand it's competitive advantages but retain your skepticism. Test/QA managers should be as passionate about the product as dev managers but we need to temper our passion with proof. Make sure the test team never stops testing the functionality represented by the sales pitch.

Furthermore, part of living with your product is being a user yourself. I now live without a laptop and exclusively use my Chrome OS Netbook for my day to day work. As people see me with it in the hallways, I get to recite its sales pitch many times every day. Great practice. I also get to live with its inadequacies and take note of the things it has yet to master. This is great discussion fodder with devs and other stakeholders and also forces me to consider competitive products. When I can't do something important on my Chrome OS Netbook, I have to use a competing product and this spawns healthy discussions about how users will perceive our product's downside and how we can truthfully communicate the pros and cons of our product to customers. Every day becomes a deep dive into my product as an actual user.

This is a great way to start off on a new product.

Really focus on the test plan, make it an early priority
If you are taking over an existing role as test manager for an existing product chances are that a test plan already exists and chances are that test plan is inadequate. I'm not being unkind to your predecessor here, I am just being truthful. Most test plans are transitory docs.

Now let me explain what I mean by that. Testers are quick to complain about inadequate design docs: that devs throw together a quick design doc or diagram but once they start coding, that design stagnates as the code takes on a life of its own. Soon the code does not match the design and the documentation is unreliable. If this is not your experience, congratulations but I find it far more the norm than design docs that are continually updated.

Testers love to complain about this. "How can I test a product without a full description of what the product does?" But don't we often do the same thing with respect to our test plans? We throw together a quick test plan but as we start writing test cases (automated or manual) they take on a life of their own. Soon the test cases diverge from the test plan as we chase new development and our experience develops new testing insight. The test plan has just become like the design docs: a has-been document.

You're a new test manager now, make fixing these documents one of your first priorities. You'll get to know your product's functionality and you'll see holes in the current test infrastructure that will need plugging. Plus, you'll have a basis to communicate with dev managers and show them you are taking quality seriously. Dev managers at Google love a good test plan, it gives them confidence you know what you are doing.

Coming up next:

Understand your orgs release process and priorities
Question your testing process
Look for ways to innovate


[Gd] Discover v2009: New Ad Types

| More

AdWords API Blog: Discover v2009: New Ad Types

The release of the new v200909 included a number of improvements and new features. Among these additions are new ad types: DeprecatedAd, LocalBusinessAd, MobileImageAd, and TemplateAd, which are all part of the AdGroupAdService.

The idea behind deprecated ads is to have a consistency in returning ads that are no longer supported. For example, if your ad group has a Click To Call ad (this ad format was deprecated on Dec. 3, 2007) and you try to fetch this particular ad via API, we will return it as a DeprecatedAd type and allow you to delete it. This is a quick and easy way for cleaning up your outdated inventory using API.

Note that deprecated ads can be deleted, but can not be created.

This is a new format of ads that can appear on mobile websites. When users click on your ad, they will be sent to your mobile webpage. Below is a Python snippet of code that shows how to add a mobile image ad for T-Mobile and Verizon carriers in US.

  operations = [{
    'operator': 'ADD',
    'operand': {
      'type': 'AdGroupAd',
      'adGroupId': '123456789',
      'ad': {
        'type': 'MobileImageAd',
        'markupLanguages': ['HTML'],
        'mobileCarriers': ['T-Mobile@US', 'Verizon@US'],
        'image': {
          'dimensions': [{
            'key': 'SHRUNKEN',
            'value': {'width': '192', 'height': '53'}
          'name': 'image_192x53.jpg',
          'data': MOBILE_IMAGE_DATA
        'url': '',
        'displayUrl': ''

This ad type represents a legacy local business ad format. When edited via the AdWords interface, the legacy ad will be converted to create a new text ad with ad-level location extension and the original local business ad will be deleted. The location extension itself is created at campaign level with the association for that ad at the ad-level. The usage of the LocalBusinessAd format will allow you to perform the conversion via API of your existing legacy local business ads into the new location extensions. We plan to spend more time talking about the new location extension format in one of our upcoming posts.

Note that local business ads can be deleted or paused/unpaused, but can not be modified.

The template ad is an easy way to add new formats to the AdWords interface. In a nutshell, we come up with an idea for an ad format, a set of required input data elements is created, and that's all. There is now a new ad format that is available in AdWords.

Note that template ads run only on content network.

To help you get started, we've included support for these and other ad types in our
client libraries. As always, we are here to answer your questions, collect feedback, and assist with migration to v200909 of the AdWords API.

Keep an eye on the blog for the next part of the "Discover v2009" series.

--Stan Grinberg, AdWords API Team


[Gd] New User Agent for News

| More

Official Google Webmaster Central Blog: New User Agent for News

Webmaster Level: Intermediate

Today we are announcing a new user agent for robots.txt called Googlebot-News that gives publishers even more control over their content. In case you haven't heard of robots.txt, it's a web-wide standard that has been in use since 1994 and which has support from all major search engines and well-behaved "robots" that process the web. When a search engine checks whether it has permission to crawl and index a web page, the "check if we're allowed to crawl this page" mechanism is robots.txt.

Publishers could easily contact us via a form if they didn't want to be included in Google News but did want to be in Google's web search index. Now, publishers can manage their content in Google News in an even more automated way. Site owners can just add Googlebot-News specific directives to their robots.txt file. Similar to the Googlebot and Googlebot-Image user agents, the new Googlebot-News user agent can be used to specify which pages of a website should be crawled and ultimately appear in Google News.

Here are a few examples for publishers:

Include pages in both Google web search and News:
User-agent: Googlebot

This is the easiest case. In fact, a robots.txt file is not even required for this case.

Include pages in Google web search, but not in News:
User-agent: Googlebot

User-agent: Googlebot-News
Disallow: /

This robots.txt file says that no files are disallowed from Google's general web crawler, called Googlebot, but the user agent "Googlebot-News" is blocked from all files on the website.

Include pages in Google News, but not Google web search:
User-agent: Googlebot
Disallow: /

User-agent: Googlebot-News

When parsing a robots.txt file, Google obeys the most specific directive. The first two lines tell us that Googlebot (the user agent for Google's web index) is blocked from crawling any pages from the site. The next directive, which applies to the more specific user agent for Google News, overrides the blocking of Googlebot and gives permission for Google News to crawl pages from the website.

Block different sets of pages from Google web search and Google News:
User-agent: Googlebot
Disallow: /latest_news

User-agent: Googlebot-News
Disallow: /archives

The pages blocked from Google web search and Google News can be controlled independently. This robots.txt file blocks recent news articles (URLs in the /latest_news folder) from Google web search, but allows them to appear on Google News. Conversely, it blocks premium content (URLs in the /archives folder) from Google News, but allows them to appear in Google web search.

Stop Google web search and Google News from crawling pages:
User-agent: Googlebot
Disallow: /

This robots.txt file tells Google that Googlebot, the user agent for our web search crawler, should not crawl any pages from the site. Because no specific directive for Googlebot-News is given, our News search will abide by the general guidance for Googlebot and will not crawl pages for Google News.

For some queries, we display results from Google News in a discrete box or section on the web search results page, along with our regular web search results. We sometimes do this for Images, Videos, Maps, and Products, too. This is known as Universal search results. Since Google News powers Universal "News" search results, if you block the Googlebot-News user agent then your site's news stories won't be included in Universal search results.

We are currently testing our support for the new user agent. If you see any problems please let us know. Note that it is possible for Google to return a link to a page in some situations even when we didn't crawl that page. If you'd like to read more about robots.txt, we provide additional documentation on our website. We hope webmasters will enjoy the flexibility and easier management that the Googlebot-News user agent provides.

Written by Jonathan Simon, Webmaster Trends Analyst

Tuesday, December 1, 2009

[Gd] Region Tags in Google Search Results

| More

Official Google Webmaster Central Blog: Region Tags in Google Search Results

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 "" 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 (, 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

[Gd] Google Analytics Launches Asynchronous Tracking

| More

Google Code Blog: Google Analytics Launches Asynchronous Tracking

Today we're excited to announce our new Google Analytics Asynchronous Tracking Code snippet as an alternative way to track your websites! It provides the following benefits:
  • Faster tracking code load times for your web pages due to improved browser execution
  • Enhanced data collection & accuracy
  • Elimination of tracking errors from dependencies when the JavaScript hasn't fully loaded
Here is the JavaScript source of the new tracking snippet:
<script type="text/javascript">

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-X']);

(function() {
var ga = document.createElement('script');
ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
'http://www') + '';
ga.setAttribute('async', 'true');

The first part of the asynchronous tracking code snippet assigns the _gaq variable to a JavaScript array. After that, two tracking API calls (encoded as arrays) are pushed onto _gaq. When the tracking code initializes, it transforms the _gaq object from a standard array into a new object and executes all the tracking API calls initially collected in the array. With this feature, you can immediately store all necessary tracking calls even before the Google Analytics tracking code is downloaded! No more worrying about race conditions or dependency issues on the ga.js tracking code.

The second half of the snippet provides the logic that loads the tracking code in parallel with other scripts on the page. It executes an anonymous function that dynamically creates a <script> element and sets the source with the proper protocol. As a result, most browsers will load the tracking code in parallel with other scripts on the page, thus reducing the web page load time. Note here the forward-looking use of the new HTML5 "async" attribute in this part of the snippet. While it creates the same effect as adding a <script> element to the DOM, it officially tells browsers that this script can be loaded asynchronously. Firefox 3.6 is the first browser to officially offer support for this new feature. If you're curious, here are more details on the official HTML5 async specification.

Once loaded, the tracking code, transforms the _gaq array into an Analytics _gaq object. This object acts as a wrapper for the underlying _gat object and executes all the commands, sending data to your Google Analytics account. Your page code can ignore this fact though, because the _gaq.push syntax can be used at any time. See the Asynchronous Tracking Usage Guide for more details.

The new tracking code is now in Beta and available to all Google Analytics users. Keep in mind that use of the code is also optional: all your existing Google Analytics code will continue to work as-is should you decide not to adopt the new tracking method. But if you want to improve the speed of your website and the increase accuracy of your Analytics data, then we think you'll love this new option.

Learn more about this new tracking code in our Google Code developer docs and get started with our migration guide.

By Brian Kuhn, Google Analytics Team

[Gd] Changes in First Click Free

| More

Official Google Webmaster Central Blog: Changes in First Click Free

Webmaster level: intermediate

We love helping publishers make their content available to large groups of readers, and working on ways to make the world's information useful and accessible through our search results. At the same time, we're also aware of the fact that creating high-quality content is not easy and, in many cases, expensive. This is one of the reasons why we initially launched First Click Free for Google News and Google Web Search -- to allow publishers to sell access to their content in general while still allowing users to find it through our search results.

While we're happy to see that a number of publishers are already using First Click Free, we've found that some who might try it are worried about people abusing the spirit of First Click Free to access almost all of their content. As most users are generally happy to be able to access just a few pages from these premium content providers, we've decided to allow publishers to limit the number of accesses under the First Click Free policy to five free accesses per user each day. This change applies to both Google News publishers as well as websites indexed in Google's Web Search. We hope that this encourages even more publishers to open up more content to users around the world!

Questions and answers about First Click Free

Q: Do the rest of the old guidelines still apply?
A: Yes, please check the guidelines for Google News as well as the guidelines for Web Search and the associated blog post for more information.

Q: Can I apply First Click Free to only a section of my site / only for Google News (or only for Web Search)?
A: Sure! Just make sure that both Googlebot and users from the appropriate search results can view the content as required. Keep in mind that showing Googlebot the full content of a page while showing users a registration page would be considered cloaking.

Q: Do I have to sign up to use First Click Free?
A: Please let us know about your decision to use First Click Free if you are using it for Google News. There's no need to inform us of the First Click Free status for Google Web Search.

Q: What is the preferred way to count a user's accesses?
A: Since there are many different site architectures, we believe it's best to leave this up to the publisher to decide.

Posted by John Mueller, Webmaster Trends Analyst, Google Zürich

Monday, November 30, 2009

[Gd] Dev Channel Update

| More

Google Chrome Releases: Dev Channel Update

The Dev channel has been updated to for Linux.


  • [r32941] Change the default CSS fonts for Simplified Chinese, Japanese, Korean and Thai on Linux to poplular Linux fonts. (Issue: 20171)
  • [r33145] Properly detect KDE4 on newer systems (e.g. [K]Ubuntu 9.04). (Issue: 25938)

More details about additional changes are available in the svn log of all revisions.

You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

Anthony Laforge
Google Chrome Program Manager