Official Google Webmaster Central Blog: május 2010

Chrome Extensions for web development

csütörtök, május 27, 2010

Chrome Developer ToolsChrome Web Storefeatures extensions for web development

Speed Tracer

Resolution Test

Web Developer

Chrome Editorextensions for web development pagegalleryWritten by Koh Kim, Google Chrome Team

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

csütörtök, május 06, 2010

Webmaster Toolsis

Webmaster Help ForumWritten by Jonathan Simon, Webmaster Trends Analyst

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

szerda, május 05, 2010

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.webmaster guidelinesspam reportspam reportsWritten by Viktor Nebehaj and Matt Cutts, Search Quality Team

Do know evil

kedd, május 04, 2010

(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. Posted by Bruce Leban, Software Engineer

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

hétfő, május 03, 2010

notPart I: Removing URLs & directoriesPart II: Removing & updating cached contentPart III: Removing content you don't ownManaging what information is available about you onlineUnderstanding the status of your requests

screenshot of removal requests and their status

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.

Help ForumPosted by Susan Moskwa, Webmaster Trends Analyst

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

vasárnap, május 02, 2010

speed is a signal in rankingsThe Need For Speed: Google Says It Mattersverify ownership of your websiteplugin

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.code.google.com/speed/Written by Maile Ohye, Developer Programs Tech Lead

Webmaster Central Blog

Chrome Extensions for web development

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

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

Do know evil

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

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

Címkék

Archive

Feed

Subscribe via email