Pages

Thursday, May 27, 2010

Chrome Extensions for web development

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.

Thursday, May 6, 2010

Top Search Queries is now Search Queries with Average Position and Stars

Webmaster Level: All

Since we released the latest version of Top Search Queries in Webmaster Tools we've gotten a bunch of feedback, most of which was overwhelmingly positive. Today, we're happy to bring even more improvements to Top Search Queries that we've implemented as a direct result of your feedback. First of all we've shortened "Top Search Queries" to be just "Search Queries" to better reflect all of the data provided by this feature. In addition to the name change you'll notice that Search Queries has several new updates. As requested by many of you, we're now showing an "Average position" column right on the main Search Queries page. This provides a quick at-a-glance way to see where your site is showing in the search results for specific queries. The other change you'll notice is that we're showing a "Displaying" number for Impressions and Clicks. This number represents a total count of the data displayed in the Search Queries table. The number in bold appearing just above it is a total count of all queries including the "long tail" of queries which are not displayed in the Search Queries table. When the "Displaying" number is not visible, such as when you select a specific country from the "All countries" drop-down menu, then the bold number is the total count of the data displayed in the Search Queries table.



We've also added an Average position column to the Search Queries download.



The other addition we've made to Search Queries is a "Starred" tab. Next to each Query on the Search Queries page there is now a clickable star icon. You can click the star icon for all of the queries that are of most interest to you. All of the queries that you "star" will be consolidated under the Starred tab providing a super easy way to view just the queries you care about.



We hope that this update makes Search Queries even more useful. If you've got feedback or suggestions for Search Queries please let us know in the Webmaster Help Forum.

Wednesday, May 5, 2010

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

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!

Tuesday, May 4, 2010

Do know evil

(Cross-posted on the Google Online Security Blog)

UPDATE July 13: We have changed the name of the codelab application to Gruyere. The codelab is now located at http://google-gruyere.appspot.com.

We want Googlers to have a firm understanding of the threats our services face, as well as how to help protect against those threats. We work toward these goals in a variety of ways, including security training for new engineers, technical presentations about security, and other types of documentation. We also use codelabs — interactive programming tutorials that walk participants through specific programming tasks.

One codelab in particular teaches developers about common types of web application vulnerabilities. In the spirit of the thinking that "it takes a hacker to catch a hacker," the codelab also demonstrates how an attacker could exploit such vulnerabilities.

We're releasing this codelab, entitled "Web Application Exploits and Defenses," today in coordination with Google Code University and Google Labs to help software developers better recognize, fix, and avoid similar flaws in their own applications. The codelab is built around Gruyere, a small yet full-featured microblogging application designed to contain lots of security bugs. The vulnerabilities covered by the lab include cross-site scripting (XSS), cross-site request forgery (XSRF) and cross-site script inclusion (XSSI), as well as client-state manipulation, path traversal and AJAX and configuration vulnerabilities. It also shows how simple bugs can lead to information disclosure, denial-of-service and remote code execution.

The maxim, "given enough eyeballs, all bugs are shallow" is only true if the eyeballs know what to look for. To that end, the security bugs in Gruyere are real bugs — just like those in many other applications. The Gruyere source code is published under a Creative Commons license and is available for use in whitebox hacking exercises or in computer science classes covering security, software engineering or general software development.

To get started, visit http://google-gruyere.appspot.com/. An instructor's guide for using the codelab is now available on Google Code University.

Monday, May 3, 2010

URL removal explained, Part IV: Tracking your requests & what not to remove

Webmaster Level: All

In this final installation in our URL removal series, let's talk about following up on your removal requests, as well as when not to use Google's URL removal tool. If you haven't already, I recommend reading the previous posts in this series:
Part I: Removing URLs & directories
Part II: Removing & updating cached content
Part III: Removing content you don't own
Companion post: Managing what information is available about you online

Understanding the status of your requests

Once you've submitted a removal request, it will appear in your list of requests. You can check the status of your requests at any time to see whether the content has been removed, or whether the request is still or pending or was denied.

screenshot of removal requests and their status

If a request was denied, you should see a "Learn more" link next to it explaining why that particular request was denied. Since different types of removals have different requirements, the reason why a particular request was denied can vary. The "Learn more" link should help you figure out what you need to change in order to make your request successful. For example, you may need to change the URL in question so that it meets the requirements for the type of removal you requested; or, if you can't do that, you may need to request a different type of removal (one whose requirements your URL currently meets).

If a request has been marked "Removed" but you still see that content in search results, check the following:
  • Is the URL that's appearing in search results the exact same URL that you submitted for removal? It's fairly common for the same, or similar, content to appear on multiple URLs on a site. You may have successfully removed one URL, but still see others containing that same content.
       Solution: Request removal of the other URL(s) in question. See this article for help.

  • Keep in mind that URLs are case sensitive, so requesting removal of http://www.example.com/embarrassingstuff.html is not the same as requesting removal of http://www.example.com/EmbarrassingStuff.html
       Solution: Request removal of the exact URL(s) that appear in search results, including the same capitalization. See this article for help.

  • When a request is marked "Removed," that can mean different things depending on what type of request you submitted. If you requested removal of an entire URL, then "Removed" should mean that that entire URL no longer appears in our search results. If you requested removal of the cached copy of a URL, "Removed" means that the cached copy has been removed and will no longer appear in search results; but the URL itself may still appear.
       Solution: Double-check what type of removal you requested by looking at the "Removal Type" column. If you requested a cache removal but you want the entire URL gone, make sure the URL meets the requirements for complete removal and then file a new request for complete removal of the URL.
When not to use the URL removal tool
  • To clean up cruft, like old pages that 404.
    The tool is intended for URLs that urgently need to be removed, such as confidential data that was accidentally exposed. If you recently made changes to your site and just have some outdated URLs in the index, Google's crawlers will see this as we recrawl your URLs, and those pages will naturally drop out of our search results over time. There's no need to request an urgent removal through this tool.

  • To remove crawl errors from your Webmaster Tools account.
    The removal tool removes URLs from Google's search results, not from your Webmaster Tools account. There's currently no way for you to manually remove URLs from this report; they will drop out naturally over time as we stop crawling URLs that repeatedly 404.

  • To "start from scratch" with your site.
    If you're worried that your site may have a penalty, or you want to "start from scratch" after purchasing a domain from someone else, we don't recommend trying to use the URL removal tool to remove your entire site and then "start over." Search engines gather a lot of information from other sites (such as who links to you, or what words they use to describe your site) and use this to help understand your site. Even if we could remove everything we currently know about your site, a lot of it would come back exactly the same once we'd recrawled all the other sites that help us understand your site and put it in context. If you're worried that your domain has some bad history, we recommend filing a reconsideration request letting us know what you're worried about and what has changed (such as that you've acquired the domain from someone else, or that you've changed certain aspects of your site).

  • To take your site "offline" after hacking.
    If your site was hacked and you want to get rid of bad URLs that got indexed, you can use the URL removal tool to remove any new URLs that the hacker created, e.g., http://www.example.com/buy-cheap-cialis-skq3w598.html. But we don't recommend removing your entire site, or removing URLs that you'll eventually want indexed; instead, simply clean up the hacking and let us recrawl your site so that we can reindex the new, cleaned-up content as soon as possible. This article contains more details on how to deal with hacking.

  • To get the right "version" of your site indexed.
    When a request to remove https://www.example.com/tattoo.html is accepted, http://www.example.com/tattoo.html is also removed. The same is true of the www and non-www versions of your URL or site. This is because the same content is often available at each of these URLs and we realize that most webmasters and searchers don't want these duplicates appearing in search results. In short, the URL removal tool should not be used as a canonicalization tool. It won't keep your favorite version, it'll remove all versions (http/https and www/non-www) of a URL.
We hope this series has answered your questions about removing content from Google's search results, and helped you troubleshoot any issues that may arise. Join us in our Help Forum if you still have questions.

Sunday, May 2, 2010

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

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