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.

Text Ad - Medium Rectangle (300x250)	Video Ad - Medium Rectangle (300x250)

Image Ad - Leaderboad (728x90)

• Earn revenue from relevant and engaging advertising that enhances the user experience of your site.
• You’re in control, protecting your brand by customizing the size, location, and type of ads that appear.
• Gain insight with the powerful integration of Google Analytics and AdSense, helping you easily identify trends and factors that influence the earning potential of your website.
• Simple and easy to set up. Just add a few lines of code to your site and you’re ready to start showing ads.
• No risk. No obligation. There’s no minimum term of commitment. And it’s free.

• "Thank you for the time you have spent helping me. It is genuinely appreciated."
• "Thank you to everyone who helped with my problem! My creaky old 1996 era website is all cleaned up and doing just fine now! Good Guys Rule!"
• "WOW!!!!!!!! Thank you so much for your help! I was reluctant to post because I thought you guys might think my site is too small, too insignificant, etc. Thanks so much! To me, it's a BIG deal!"
• "My traffic has doubled and I am now either top or close to the top in search terms"
• "Thanks. Hopefully my late night paid off then, all the help and information has been great!!!!!!!"
• "Wow Webado Thank You Again.. You Really Know Your stuff! (…) You Are a True professional and Seriously The Only Person That Could Even Figure This out. I even Spoke to Other Top Specialists and YOU were the Only one who told me what to do and what was wrong."
• "You are AMAZING! Thank you so much!"
• "Finally, thanks so much for your concern and prompt reply, Squibble. Can't imagine a person would deligated his efforts to someones you don't even know and met. (…) Thanks for your help!! It means everything to me!"
• "Wow thanks so much! I have just been to the hot springs in Banos Ecuador, the volcano is rumbling and the town has evacuated but I am still here talking Apache, now that is dedication, I will test your helpfulness out 2moro! Thanks so much!!!"
• "THANKYOU THANKYOU THANKYOU! YOU ARE SOOOO AMAZING! MY BLOG IS GONE FROM GOOGLE AND ALL THE OLD POSTS ASSOCIATED WITH THAT TOO! THANK YOU! I LOVE YOU!"
• "It worked! Thank you very much for your help Cristina :)"
• "I could NEVER have seen what's possible without this forum. I am so grateful."
• "Thank you so much for your detailed response to my questions. In 10 years of me having a website, no one has explained these concepts better to me than you did."
• "IT WORKED!!! Thank you so much for saving me the grief and embarrassment of this problem. I truly appreciate both your knowledge and guidance."
• "Thank you so much for such a detailed answer and putting into terms I can easily understand. (…) Where shall I send the batch of brownies?"
• "Thank you so much Squibble you are a hero. I have done what it says and i will check to see if i appear in google! Thanks again!"
• "you guys are amazing! thank you so much redleg! (…) and if you happen to ever be in san carlos give me a shout - you deserve at least a beer and a lunch! "
• "Thank you Squibble, Vanessa, Cristina, and Ishigaki for weighing in on this and helping me. I hope I can pay it forward one day."
• "Great info Guys. I really appreciate it. It was awesome of y'all to help me out. I really appreciate it. Thank you."
• "Your amazing :-) i love you lol xx im sorted now thanks and never in a million years would i have found that out!"
• "THANK YOU! I love Google and appreciate that they have these safety precautions in place for those nasty hackets - especially when we can fix the problem! Thanks so much for your help. Whew."
• "Thank you very much, Robbo! With a little tweaking it worked perfectly!"
• "yay!!! I think it finally went through - THANK YOU SO MUCH!!!"

1. Can the source/content of the video (perhaps a third-party vendor) be hosted on another site? For example, can I host my videos on YouTube and still be eligible for Video Search traffic?
   
   Yes, you can use a third party to host videos. Only the play page--the URL within the <loc> tag--needs to be on your site. <video:content_loc> and <video:player_loc> can list URLs on a different site or subdomain.
   
   For example, here’s a snippet from a valid Video Sitemap that shows content hosted on a different subdomain from the play page:
   
   

   <url>
     <loc>http://www.example.com/videos/some_video_landing_page.html</loc>
       <video:video>
         <video:thumbnail_loc>http://www.example.com/thumbs/123.jpg</video:thumbnail_loc>
         <video:title>Grilling steaks for summer</video:title>
         <video:description>Alkis shows you how to get perfectly done steaks every time</video:description>
         <video:content_loc>http://video-hoster.example.com/video123.flv</video:content_loc>
         <video:player_loc allow_embed="yes" autoplay="ap=1">http://www.example.com/videoplayer.swf?video=123</video:player_loc>
       </video:video>
   </url>



2. If I’m using YouTube to host my videos, can Google verify that I’m the legitimate owner?
   
   Currently, there doesn’t exist functionality that allows you, as the uploader, to verify that you’re the owner of a video. The issue of authorship is a hard problem on the web, not just for videos, but nearly all types of content.


3. Because Google owns YouTube, should users who embed YouTube videos still submit Video Sitemaps or is it unnecessary?
   
   Google treats YouTube as just another source for video content -- though you don’t need to submit a Video Sitemap if you only want your YouTube-hosted videos indexed. If, however, you’re using YouTube as a online video platform (i.e., with play pages on your own site), then we do recommend Sitemap submission.


4. How long does it take for Google to accept and verify a Video Sitemap?
   
   Video Sitemap submission is a two-part process:
   
   
   
   1. We fetch the Sitemap and parse it for syntax errors. This happens within minutes.
   
   
   2. We fetch the assets referenced in the Sitemap, perform checks, validate metadata, do more cool stuff, and last, index the video. This step can require varied amounts of time depending on your site and our system load.
   
   
5. What tags and categories are most important in Video Sitemaps or mRSS? Should I create my own categories or is there a list that I should conform to?
   
   Currently, the most important metadata to include is title and description -- both are required. The category tag is optional, and there isn’t a list from which to select.


6. Do I have to use HTML5 to use Video Sitemaps?
   Does HTML5 help with discovery?
   Or, if my site is HTML5 compliant, do I still need to submit a Video Sitemap?
   
   None of the Video Search principles change with HTML5. We still recommend using a Video Sitemap regardless of the markup on your site. HTML5 can be helpful, though, because tags like <video> make it easier for our systems to verify that video exists on the page.


7. If I use an iframe rather than embedding my videos, can Google still find it?
   
   We do not recommend using iframes to embed video content on your pages.


8. Can I have multiple videos on one URL?
   
   You can. We’ve found, however, that users may not consider it the best experience. When users click on a video search result, they most often don’t like being forced to locate the correct video among multiple videos on the resulting page.


9. Do I need to specifically create a robots.txt file that allows Googlebot, or do I just need to make sure Googlebot isn’t blocked?
   
   Just make sure that Googlebot isn’t blocked.


10. I provided a thumbnail, but it’s not being used. Does Google create their own thumbnails from my videos?
    
    We try to use the thumbnail you provide if it’s valid. If not, we’ll try to generate a thumbnail ourselves. We recommend that you provide thumbnails that are at least 120x90 pixels. We also accept many thumbnail formats, such as PNG and JPEG.


11. Any video filesize limitations?
    
    At this time, there aren’t video filesize limitations on content submitted through VIdeo Sitemaps.


12. Is there any way to indicate a transcript or closed captioning for a video?
    
    Currently there isn’t, but perhaps down the road.


13. What if I’m using Lightbox or a popup to display a video; can it still be indexed?
    
    Depends on the use case and how it’s rendered, but if indexing by search engines is important to you, it’s not the safest method. In the Webmaster Help Center, we explain that “When designing your site, it's important to configure your video pages without any overly complex JavaScript or Flash setup.” Most often, for bots, simpler is safer.

• While both feeds and on-page markup give search engines metadata, Video Sitemaps/mRSS also help with crawl discovery. We may find a new URL through your feed that we wouldn’t have easily discovered otherwise.


• Using Video Sitemaps/mRSS requires that the search engine support these formats and not all engines do. Because on-page markup is just that -- on the page -- crawlers can gather the metadata through organic means as they index the URL. No feed support is required.

• Up to four web results from each domain (i.e., several domains may have multiple results)
• Single-line snippets for the additional results, to keep them compact

Today Google introduced Instant Previews, a new search feature that helps people find information faster by showing a visual preview of each result. Traditionally, elements of the search results like the title, URL, and snippet—the text description in each result—help people determine which results are best for them. Instant Previews achieves the same goal with a visual representation of each page and where the relevant content is, instead of a text description. For our webmaster community, this presents an opportunity to reveal the design of your site and why your page is relevant for a particular query. We'd like to offer some thoughts on how to take advantage of the feature.

First of all, it's important to understand what the new feature does. When someone clicks on the magnifying glass on any result, a zoomed-out snapshot of the underlying page appears to the right of the results. Orange highlights indicate where highly relevant content on the page is, and text call outs show search terms in context.

These elements let people know what to expect if they click on that result, and why it's relevant for their query. Our testing shows that the feature really does help with picking the right result—using Instant Previews makes searchers 5% more likely to be satisfied with the results they click.

Many of you have put a lot of thought and effort into the structure of your sites, the layout of your pages, and the information you provide to visitors. Instant Previews gives people a glimpse into that design and indicates why your pages are relevant to their query. Here are some details about how to make good use of the feature.

• Keep your pages clearly laid out and structured, with a minimum of distractions or extraneous content. This is always good advice, since it improves the experience for visitors, and the simplicity and clarity of your site will be apparent via Instant Previews.
• Try to avoid interstitial pages, ad pop-ups, or other elements that interfere with your content. In some cases, these distracting elements may be picked up in the preview of your page, making the screenshots less attractive.
• Many pages have their previews generated as part of our regular crawl process. Occasionally, we will generate screenshots on the fly when a user needs it, and in these situations we will retrieve information from web pages using a new "Google Web Preview" user-agent.
• Instant Previews does not change our search algorithm or ranking in any way. It's the same results, in the same order. There is also no change to how clicks are tracked. If a user clicks on the title of a result and visits your site, it will count as a normal click, regardless of whether the result was previewed. Previewing a result, however, doesn't count as a click by itself.
• Currently, adding the nosnippet meta tag to your pages will cause them to not show a text snippet in our results. Since Instant Previews serves a similar purpose to snippets, pages with the nosnippet tag will also not show previews. However, we encourage you to think carefully about opting out of Instant Previews. Just like regular snippets, previews tend to be helpful to users—in our studies, results which were previewed were more than four times as likely to be clicked on. URLs that have been disallowed in the robots.txt file will also not show Instant Previews.
• Currently, some videos or Flash content in previews appear as a "puzzle piece" icon or a black square. We're working on rendering these rich content types accurately.

Posted by Jeremy Silber, Software Engineer

• a browser button to report the currently viewed page
• an option to retrieve recent Google searches from your Chrome history
• an option to retrieve recently visited URLs from your Chrome history

If you happen to come across a gibberish site similar to this one, it’s most likely spam.

• the cached version contains significantly different (often keyword-rich) content from the live version
• you’re redirected to a completely different domain with off-topic, commercial content
• the site is filled with auto-generated or keyword-stuffed content that seems to make no sense

• Submit the URLs of the pages where you see spam (not just the domain name). This makes it easy for us to verify the problem on those specific pages.
• Try to specify the issue as clearly as possible using the checkboxes. Don’t just check every single box--such reports are less likely to be reviewed.
• If only a part of the page uses spammy techniques, for example if it uses cloaking or has hidden text on an otherwise good page, provide a short explanation on how to look for the spam you’re seeing. If you’re reporting a site for spammy backlinks rather than on-page content, mention that.

• Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
• Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
• Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

"Go Daddy is continually looking for ways to provide our customers the best user experience possible. That's the reason we partnered with Google on the 'Make the Web Faster' initiative. Go Daddy engineers are seeing a dramatic decrease in load times of customers' websites using mod_pagespeed and other technologies provided. We hope to provide the technology to our customers soon - not only for their benefit, but for their website visitors as well.”

YouTube desktop version on the left, YouTube Leanback on the right

• Text is large enough to be viewable from the sofa-to-TV distance.
• Site navigation can be performed through button arrows on the remote (a D-pad), rather than mouse/touchpad usage
• Selectable elements provide a visual queue when selected (when you’re 10 feet away, it needs to be really, really obvious what selections are highlighted)
• and more...

1. On a large monitor, make your window size 1920 x 1080.
2. In a browser, visit your site at full screen.
3. Zoom the browser to 1.5x the normal size. This is performed in different ways with different keyboards. For example, in Chrome if you press ctrl+ (press ctrl and + at the same time) twice, that’ll zoom the browser to nearly 1.5x the initial size.
4. Move back 3 x (the distance between you and the monitor).
5. Check out your site!

http://example.com/product.php?item=swedish-fish
http://example.com/product.php?item=swedish-fish
http://example.com/product.php?item=swedish-fish

http://example.com/shop.php?category=candy&sort-by=asc-price&page=1
http://example.com/shop.php?category=candy&sort-by=desc-price&page=1
http://example.com/shop.php?category=candy&sort-by=asc-price&page=2
http://example.com/shop.php?category=candy&sort-by=desc-price&page=2

1. Ask in public.
   If you post your question in our forum, the whole world gets to see the answer. Then when Betty has the same question a week later, she benefits because she can find the answer instantly in our forum, and I benefit because it saves me from having to answer the same question twice (or ten times, or fifty times, or...). We have a very strong preference for answering questions publicly (in a forum, on a blog, at a conference, in a video...) so that many people can benefit from the answer.
2. Do your homework.
   We put a lot of effort into writing articles, blog posts and FAQs to help people learn about search and site-building, and we strongly encourage you to search our Help Center, blog and/or forum for answers before asking a question. You may find an answer on the spot. If you don’t, when you post your question be sure to indicate what resources you’ve already read and why they didn’t meet your needs: for example, “I read the Help Center article on affiliate websites but I’m still not sure whether this particular affiliate page on my site has enough added value; can I get some feedback?” This shows that you’ve taken the time to try to help yourself, it saves everyone from reiterating the obvious solutions if you’ve already ruled those out, and it will help get you a more specific and relevant answer. It can also help us improve our documentation if something’s missing.
3. Be specific.
   If you ask a vague question, you’re likely to get a vague answer. The more details and context you can give, the more able someone will be to give you a relevant, personalized answer. For example, “Why was my URL removal request denied?” is likely to get you a link to this article, as removals can be denied for a variety of reasons. However, if you say what type of removal you requested, what denial reason you got, and/or the URL in question, you’re more likely to get personalized advice on what went wrong in your case and what you can do differently.
4. Make it relevant to others.
   As I said earlier, we like to help as many people at a time as we can. If you make it clear how your question is relevant to more people than just you, we’ll have more incentive to look into it. For example: “How can site owners get their videos into Google Video search? In particular, I’m asking about the videos on www.example.com.”
5. Let us know if you’ve found a bug.
   As above, the more specific you can be, the better. What happened? What page or URL were you on? If it’s in Webmaster Tools, what site were you managing? Do you have a screenshot? All of these things help us track down the issue sooner. We appreciate your feedback, but if it’s too vague we won’t understand what you’re trying to tell us!
6. Stay on-topic.
   Have a question about Google Analytics? iGoogle? Google Apps? That’s great; go ask it in the Analytics / iGoogle / Apps forum. Not every Googler is familiar with every product Google offers, so you probably won’t get an answer if you’re asking a Webmaster Central team member about something other than Web Search or Webmaster Tools.
7. Stay calm.
   Trust me, we’ve heard it all. Making threats, being aggressive or accusatory, YELLING IN ALL CAPS, asking for “heeeeeeeeeeeeeeelp!!!!!1!!,” or claiming Google is involved in a mass conspiracy against you & your associates because your sites aren’t ranked on page one... Rather than making others want to help you, these things are likely to turn people off. The best way to get someone to help is by calmly explaining the situation, giving details, and being clear about what you’re asking for.
8. Listen, even when it’s not what you wanted to hear.
   The answer to your question may not always be the one you wanted; but that doesn’t mean that answer isn’t correct. There are many areas of SEO and website design that are as much an art as a science, so a conclusive answer isn’t always possible. When in doubt, feel free to ask people to cite their sources, or to explain how/where they learned something. But keep an open mind and remember that most people are just trying to help, even if they don’t agree with you or tell you what you wanted to hear.

• template (i.e. side navigation, footer) is machine-translated into various languages,
• main content remains unchanged, creating largely duplicate pages,

Two localized versions, http://en.example.com/javier-lopez in English and http://fr.example.com/javier-lopez in French

• Have one URL associated with one piece of content. We recommend against using the same URL for multiple languages, such as serving both French and English versions on example.com/page.html based on user information (IP address, Accept-Language HTTP header).


• When multiple languages are at play, it’s best to include the language or country indication in the URL, e.g., example.com/en/welcome.html and example.com/fr/accueil.html (which specify “en” and “fr”) rather than example.com/welcome.html and example.com/accueil.html (which don’t contain an explicit country/language specification). More suggestions can be found in our blog posts about designing localized URLs and multilingual sites.

Step 1: Select the proper canonical.
The canonical designates the version of your content you’d like indexed and returned to users.

The first step towards making the right content indexable is to pick one canonical URL that best reflects the genuine locale of the page’s main content. In the example above, since Javier is a Spanish-speaking user and he created his profile on es.example.com, http://es.example.com/javier-lopez is the logical canonical. The title and snippet in all locales will be selected from the canonical URL.

Once you have the canonical URL picked out, you can either:

A. 301 (permanent redirect) from the language variants to the canonical

As an example, if a French speaker visits fr.example.com/javier-lopez (not the canonical), have this page include a cookie to remember the user's language preference of French. Then permanently redirect from fr.example.com/javier-lopez to the canonical at es.example.com/javier-lopez. Because of the cookie, es.example.com/javier-lopez will still render its boilerplate in French (even on the es.example.com subdomain!). Similarly, en.example.com/javier-lopez would set the value of this cookie to English and then 301 redirect to es.example.com/javier-lopez.

Including a language selection link is also helpful should a multilingual user prefer a different experience of your site.

B. Use rel=”canonical”

On the other language variants, include a link rel=”canonical” tag pointing to your chosen canonical. In our example, since the canonical for Javier’s profile is the Spanish version, the English and French pages (and optionally even the Spanish page itself) would include <link rel=”canonical” href="http://es.example.com/javier-lopez" />.

Cookies are not involved in this setup. Therefore, a French speaker will be served es.example.com/javier-lopez with a Spanish template. Implement step 2 if you want the French speakers to be served the French version at fr.example.com/javier-lopez in Google search results.

Step 2: In the canonical URL, specify the various language versions via the rel=”alternate” link tag, using its hreflang attribute.

rel=”alternate” URLs can be displayed in search results in accordance with a user’s language preference. The title and snippet, however, remain generated from the canonical URL (as is customary with rel=”canonical”), not from the content of any rel=”alternate”.

You can help Google display the correctly localized variant of your URL to our international users by adding the following tags to http://es.example.com/javier-lopez, the selected canonical:

<link rel=”alternate” hreflang="en" href="http://en.example.com/javier-lopez" />

<link rel=”alternate” hreflang="fr" href="http://fr.example.com/javier-lopez" />

rel=”alternate” indicates that the URL contains an alternate version located at the URI of the href value. hreflang identifies the language code of the alternate URL and can be specified with ISO-639.

Please note: If your site supports many languages and you’re worried about the increased file size when declaring numerous rel=”alternate” URLs, please see our Help Center article about configuring rel=”alternate” with file size constraints.

• http://en.example.com/javier-lopez

  either 301s with a language cookie or contains <link rel=”canonical” href=”http://es.example.com/javier-lopez” />

• http://fr.example.com/javier-lopez

  either 301s with a language cookie or contains <link rel=”canonical” href=”http://es.example.com/javier-lopez” />

• http://es.example.com/javier-lopez

  is the canonical and contains
  <link rel=”alternate” hreflang="en" href="http://en.example.com/javier-lopez" />
  and
  <link rel=”alternate” hreflang="fr" href="http://fr.example.com/javier-lopez" />

• When your content is returned in search results, users will likely see the URL that corresponds to their language preference, whether or not it’s the canonical. (Good news!) This is because with with rel=”canonical” or a 301 redirect, we can cluster the language variations with the canonical. With rel=”alternate” hreflang=”x” at serve-time we can deliver the URL of the most appropriate language to the user: English speakers will be served en.example.com/javier-lopez as the result for the URL in Javier’s profile, French speakers will see fr.example.com/javier-lopez, Spanish speakers will see es.example.com/javier-lopez.


• By implementing step 1, only content from the canonical version will be available for users in search results (i.e. content from the duplicate versions won’t be searchable). Because the Spanish version es.example.com/javier-lopez is the canonical, queries that include template content from this page, e.g. [Javier Lopez familia] -- when using any language preference -- may return his profile (content from the canonical version). On the other hand, queries that include template content of the “duplicate” version, e.g. [Javier Lopez family], are less likely to return his profile page. If you would like the other language versions indexed separately and searchable, avoid using rel=”canonical” and rel=”alternate”.


• Indexing properties, such as linking information, from the duplicate language variants will be consolidated with the canonical.

While the presentation of the search results may change, our most important advice to webmasters remains the same: Users want to visit pages with compelling content and a great user experience.

1. Your site is displayed in search results as a response to a user’s completed query (e.g. by pressing “enter” or selecting a term from autocomplete). This is the traditional model.
   
   With Google Instant, we also measure impressions in these new cases:


2. The user begins to type a term on Google and clicks on a link on the page, such as a search result, ad, or a related search.


3. The user stops typing, and the results are displayed for a minimum of 3 seconds.

• URLs disallowed by robots.txt
• Thumbnail size errors (160x120px is ideal. Anything smaller than 90x50 will be rejected.)

URL extensions at a glance:

Sitemap:	mRSS:	Contents:
<loc>	<link>	The playpage URL
<video:player_loc>	<media:player> (url attribute)	The SWF URL
<video:content_loc>	<media:content> (url attribute)	The FLV or other raw video URL

NOTE: All URLs should be unique (every URL in your entire Video Sitemap and mRSS feed should be unique)

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.sitemaps.org/schemas/sitemap-image/1.1"
        xmlns:video="http://www.sitemaps.org/schemas/sitemap-video/1.1">
  <url> 
    <loc>http://www.example.com/foo.html</loc> 
    <image:image>
       <image:loc>http://example.com/image.jpg</image:loc> 
    </image:image>
    <video:video> 
    <video:content_loc>http://www.example.com/videoABC.flv</video:content_loc>    
      <video:title>Grilling tofu for summer</video:title> 
    </video:video>
  </url>
</urlset>

• Best Practice 1: Verify your video URLs are crawlable: check your robots.txt
  
  • Sometimes publishers unknowingly include video URLs in their Sitemap that are robots.txt disallowed. Please make sure your robots.txt file isn't blocking any of the URLs specified in your Sitemap. This includes URLs for the:
    
    • Playpage
      
    • Content and player
      
    • Thumbnail
    More information about robots.txt.
    
  
  
• Best Practice 2: Tell us what countries the video may be played in
  
  • Is your video only available in some locales? The optional attribute “restriction” has recently been added (documentation at http://www.google.com/support/webmasters/bin/answer.py?answer=80472), which you can use to tell us whether the video can only be played in certain territories. Using this tag, you have the option of either including a list of all countries where it can be played, or just telling us the countries where it can't be played. If your videos can be played everywhere, then you don't need to include this.
    
  
  
• Best Practice 3: Indicate clearly when videos are removed -- protect the user experience
  
  • Sometimes publishers take videos down but don't signal to search engines that they've done so. This can result in the search engine's index not accurately reflecting content of the web. Then when users click on a search result, they're taken to a page either indicating that the video doesn't exist, or to a different video. Users find this experience dissatisfying. Although we have mechanisms to detect when search results are no longer available, we strongly encourage following community standards.
    
    To signal that a video has been removed,
    
    1. Return a 404 (Not found) HTTP response code, you can still return a helpful page to be displayed to your users. Check out these guidelines for creating useful 404 pages.
       
    2. Indicate expiration dates for each video listed in a Video Sitemap (use the <video:expiration_date> element) or mRSS feed (<dcterms:valid> tag) submitted to Google.

1. Check whether you have soft 404s listed in Webmaster Tools
   
2. For the soft 404s, determine whether the URL:
   1. Contains the correct content and properly returns a 200 response (not actually a soft 404)
      
   2. Should 301 redirect to a more accurate URL
      
   3. Doesn’t exist and should return a 404 or 410 response
      
3. Confirm that you’ve configured the proper HTTP Response by using Fetch as Googlebot in Webmaster Tools
   
4. If you now return 404s, you may want to customize your 404 page to aid your users. Our custom 404 widget can help.

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

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

Yes. WebPagetest.org can test performance from the United States (both East and West Coast—go West Coast! :), United Kingdom, China, and New Zealand.

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.

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.

1. http://<your-domain-here>/<some-directory-here>/
   (with trailing slash)
2. http://<your-domain-here>/<some-directory-here>
   (no trailing slash)

• If only one version can be returned (i.e., the other redirects to it), that’s great! This behavior is beneficial because it reduces duplicate content. In the particular case of redirects to trailing slash URLs, our search results will likely show the version of the URL with the 200 response code (most often the trailing slash URL) -- regardless of whether the redirect was a 301 or 302.


• If both slash and non-trailing-slash versions contain the same content and each returns 200, you can:
  • Consider changing this behavior (more info below) to reduce duplicate content and improve crawl efficiency.
  • Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay. :)
  • Rest assured that for your root URL specifically, http://example.com is equivalent to http://example.com/ and can’t be redirected even if you’re Chuck Norris.

1. Choose one URL as the preferred version. If your site has a directory structure, it’s more conventional to use a trailing slash with your directory URLs (e.g., example.com/directory/ rather than example.com/directory), but you’re free to choose whichever you like.


2. Be consistent with the preferred version. Use it in your internal links. If you have a Sitemap, include the preferred version (and don’t include the duplicate URL).


3. Use a 301 redirect from the duplicate to the preferred version. If that’s not possible, rel=”canonical” is a strong option. rel=”canonical” works similarly to a 301 for Google’s indexing purposes, and other major search engines as well.


4. Test your 301 configuration through Fetch as Googlebot in Webmaster Tools. Make sure your URLs:
   http://example.com/foo/
   http://example.com/foo
   are behaving as expected. The preferred version should return 200. The duplicate URL should 301 to the preferred URL.


5. Check for Crawl errors in Webmaster Tools, and, if possible, your webserver logs as a sanity check that the 301s are implemented.


6. Profit! (just kidding) But you can bask in the sunshine of your efficient server configuration, warmed by the knowledge that your site is better optimized.

• Removed or blocked content
  
  If the website owner removes a page, requests for the removed page should return a "404 Not Found" response or a "410 Gone" response. If they choose to block the page from search engines, then the page should either be disallowed in the site's robots.txt file or contain a noindex meta tag. Once one of these requirements is met, you can submit a removal request using the "Webmaster has already blocked the page" option.
  
  
  
  Sometimes a website owner will claim that they’ve blocked or removed a page but they haven’t technically done so. If they claim a page has been blocked you can double check by looking at the site’s robots.txt file to see if the page is listed there as disallowed.

  User-agent: *
  Disallow: /blocked-page/

  Another place to check if a page has been blocked is within the page’s HTML source code itself. You can visit the page and choose “View Page Source” from your browser. Is there a meta noindex tag in the HTML “head” section?

  <html>
  <head>
  <title>blocked page</title>
  <meta name="robots" content="noindex">
  </head>
  ...

  If they inform you that the page has been removed, you can confirm this by using an HTTP response testing tool like the Live HTTP Headers add-on for the Firefox browser. With this add-on enabled, you can request any URL in Firefox to test that the HTTP response is actually 404 Not Found or 410 Gone.


• Content removed from the page
  
  Once you've confirmed that the content you're seeking to remove is no longer present on the page, you can request a cache removal using the 'Content has been removed from the page' option. This type of removal--usually called a "cache" removal--ensures that Google's search results will not include the cached copy or version of the old page, or any snippets of text from the old version of the page. Only the current updated page (without the content that's been removed) will be accessible from Google's search results. However, the current updated page can potentially still rank for terms related to the old content as a result of inbound links that still exist from external sites. For cache removal requests you’ll be asked to enter a "term that has been removed from the page." Be sure to enter a word that is not found on the current live page, so that our automated process can confirm the page has changed -- otherwise the request will be denied. Cache removals are covered in more detail in part two of the "URL removal explained" series.
  
  
  
  
• Removing inappropriate webpages or images that appear in our SafeSearch filtered results
  
  Google introduced the SafeSearch filter with the goal of providing search results that exclude potentially offensive content. For situations where you find content that you feel should have been filtered out by SafeSearch, you can request that this content be excluded from SafeSearch filtered results in the future. Submit a removal request using the 'Inappropriate content appears in our SafeSearch filtered results' option.
  
  
  

• Page Speed, an open source Firefox/Firebug add-on that evaluates the performance of web pages and gives suggestions for improvement.
• YSlow, a free tool from Yahoo! that suggests ways to improve website speed.
• WebPagetest shows a waterfall view of your pages' load performance plus an optimization checklist.
• In Webmaster Tools, Labs > Site Performance shows the speed of your website as experienced by users around the world as in the chart below. We've also blogged about site performance.

• Many other tools on code.google.com/speed.