Webmaster Level: All
You can now use Google search to find SVG documents. SVG is an open, XML-based format for vector graphics with support for interactive elements. We’re big fans of open standards, and our mission is to organize the world’s information, so indexing SVG is a natural step.
We index SVG content whether it is in a standalone file or embedded directly in HTML. The web is big, so it may take some time before we crawl and index most SVG files, but as of today you may start seeing them in your search results. If you want to see it yourself, try searching for [sitemap site:fastsvg.com] or [HideShow site:svg-whiz.com]
If you host SVG files and you wish to exclude them from Google’s search results, you can use the “X-Robots-Tag: noindex” directive in the HTTP header.
Check out Webmaster Central for a full list of file types we support.
Posted by Bogdan Stanescu and John Sarapata, Software Engineers
[Link]
Webmaster Level: All
Today we’ve launched a change to our ranking algorithm that will make it much easier for users to find a large number of results from a single site. For queries that indicate a strong user interest in a particular domain, like [exhibitions at amnh], we’ll now show more results from the relevant site:
Prior to today’s change, only two results from www.amnh.org would have appeared for this query. Now, we determine that the user is likely interested in the Museum of Natural History’s website, so seven results from the amnh.org domain appear. Since the user is looking for exhibitions at the museum, it’s far more likely that they’ll find what they’re looking for, faster. The last few results for this query are from other sites, preserving some diversity in the results.
We’re always reassessing our ranking and user interface, making hundreds of changes each year. We expect today’s improvement will help users find deeper results from a single site, while still providing diversity on the results page.
Written by Samarth Keshava, Software Engineer
[Link]
Webmaster Level: All
Nobody likes to duplicate effort. Unfortunately, sometimes it's a fact of life. If you want to use Google Analytics, you need to add a JavaScript tracking code to your pages. When you're ready to verify ownership of your site in other Google products (such as Webmaster Tools), you have to add a meta tag, HTML file or DNS record to your site. They're very similar tasks, but also completely independent. Until today.
You can now use a Google Analytics JavaScript snippet to verify ownership of your website. If you already have Google Analytics set up, verifying ownership is as simple as clicking a button.
This only works with the newer asynchronous Analytics JavaScript, so if you haven't migrated yet, now is a great time. If you haven't set up Google Analytics or verified yet, go ahead and set up Google Analytics first, then come verify ownership of your site. It'll save you a little time — who doesn't like that? Just as with all of our other verification methods, the Google Analytics JavaScript needs to stay in place on your site, or your verification will expire. You also need to remain an administrator on the Google Analytics account associated with the JavaScript snippet.
Don’t forget that once you've verified ownership, you can add other verified owners quickly and easily through the Verification Details page. There's no need for each owner to manually verify ownership. More effort and time saved!
We’ve also introduced an improved interface for verification. The new verification page gives you more information about each verification method. In some cases, we can now provide detailed instructions about how to complete verification with your specific domain registrar or provider. If your provider is included, there's no need to dig through their documentation to figure out how to add a verification DNS record — we'll walk you through it.
The time you save using these new verification features might not be enough to let you take up a new hobby, but we hope it makes the verification process a little bit more pleasant. As always, please visit the Webmaster Help Forum if you have any questions.
Written by Sean Harding, Software Engineer
[Link]
Webmaster Level: All
You can now check your Video Sitemap for even more errors right in Webmaster Tools! It’s a new Labs feature to signal issues in your Video Sitemap such as:
- URLs disallowed by robots.txt
- Thumbnail size errors (160×120px is ideal. Anything smaller than 90×50 will be rejected.)
Video Sitemaps help us to better crawl and extract information about your videos, so we can appropriately feature them in search results.
Totally new to Video Sitemaps? Check out the Video Sitemaps center for more information. Otherwise, take a look at this new Labs feature in Webmaster Tools.
Written by Jackie Lai, Video Search Team
[Link]
Webmaster Level: All
If you want to add video information to a Sitemap or mRSS feed you must specify the location of the video. This means you must include one of two tags, either the video:player_loc or video:content_loc. In the case of an mRSS feed, these equivalent tags are media:player or media:content, respectively. We need this information to verify that there is actually a live video on your landing page and to extract metadata and signals from the video bytes for ranking. If one of these tags is not included we will not be able to verify the video and your Sitemap/mRSS feed will not be crawled. To reduce confusion, here is some more detail about these elements.
Video Locations Defined
Player Location/URL: the player (e.g., .swf) URL with corresponding arguments that load and play the actual video.
Content Location/URL: the actual raw video bytes (e.g., .flv, .avi) containing the video content.
The Requirements
One of either the player video:player_loc or content video:content_loc location is required. However, we strongly suggest you provide both, as they each serve distinct purposes: player location is primarily used to help verify that a video exists on the page, and content location helps us extract more signals and metadata to accurately rank your videos.
URL extensions at a glance:
.nobrtable br { display: none }
Sitemap: mRSS: Contents:
The playpage URL
(url attribute)
The SWF URL
(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)
If you would like to better ensure that only Googlebot accesses your content, you can perform a reverse DNS lookup.
For more information on Google Videos please visit our Help Center, and to post questions and search for answers check out our Help Forum.
Posted by Nelson Lee, Product Manager, Video Search

[Link]
Webmaster Level: All
When Googlebot crawls your site, it’s expected that most URLs will return a 200 response code, some a 404 response, some will be disallowed by robots.txt, etc. Whenever we’re unable to reach your content, we show this information in the Crawl errors section of Webmaster Tools (even though it might be intentional and not actually an error). Continuing with our effort to provide useful and actionable information to webmasters, we're now sending SiteNotice messages when we detect a significant increase in the number of crawl errors impacting a specific site. These notifications are meant to alert you of potential crawl-related issues and provide a sample set of URLs for diagnosing and fixing them.
A SiteNotice for a spike in the number of unreachable URLs, for example, will look like this:
We hope you find SiteNotices helpful for discovering and dealing with issues that, if left unattended, could negatively affect your crawl coverage. You’ll only receive these notifications if you’ve verified your site in Webmaster Tools and we detect significant changes to the number of crawl errors we encounter on your site. And if you don't want to miss out on any these important messages, you can use the email forwarding feature to receive these alerts in your inbox.
If you have any questions, please post them in our Webmaster Help Forum or leave your comments below.
Posted by Pooja Shah and Jonathan Simon
[Link]
Webmaster Level: All
We know that some of you, or your clients or colleagues, may be new to online video publishing. To make it easier for everyone to understand video indexing and Video Sitemaps, we’ve created a video — narrated by Nelson Lee, Video Search Product Manager — that explains everything in basic terms:
Also, last month we wrote about some best practices for getting video content indexed on Google. Today, to help beginners better understand the whys and hows of implementing a Video Sitemap, we added a starting page to the information on Video Sitemaps in the Webmaster Help Center. Please take a look and share your thoughts.
Posted by Amy MacIsaac, Content Partnerships
[Link]
Webmaster Level: All
Have you ever wanted to submit your various content types (video, images, etc.) in one Sitemap? Now you can! If your site contains videos, images, mobile URLs, code or geo information, you can now create—and submit—a Sitemap with all the information.
Site owners have been leveraging Sitemaps to let Google know about their sites’ content since Sitemaps were first introduced in 2005. Since that time additional specialized Sitemap formats have been introduced to better accommodate video, images, mobile, code or geographic content. With the increasing number of specialized formats, we’d like to make it easier for you by supporting Sitemaps that can include multiple content types in the same file.
The structure of a Sitemap with multiple content types is similar to a standard Sitemap, with the additional ability to contain URLs referencing different content types. Here's an example of a Sitemap that contains a reference to a standard web page for Web search, image content for Image search and a video reference to be included in Video search:
http://www.example.com/foo.html
http://example.com/image.jpg
http://www.example.com/videoABC.flv
Grilling tofu for summer
Here’s an example of what you'll see in Webmaster Tools when a Sitemap containing multiple content types is submitted:
We hope the capability to include multiple content types in one Sitemap simplifies your Sitemap submission. The rest of the Sitemap rules, like 50,000 max URLs in one file and the 10MB uncompressed file size limit, still apply. If you have questions or other feedback, please visit the Webmaster Help Forum.
Written by Jonathan Simon, Webmaster Trends Analyst
[Link]
A popular question on our Webmaster Help Forum is in regard to best practices for organic link building. There seems to be some confusion, especially among less experienced webmasters, on how to approach the topic. Different perspectives have been shared, and we would also like to explain our viewpoint on earning quality links.
If your site is rather new and still unknown, a good way marketing technique is to get involved in the community around your topic. Interact and contribute on forums and blogs. Just keep in mind to contribute in a positive way, rather than spamming or soliciting for your site. Just building a reputation can drive people to your site. And they will keep on visiting it and linking to it. If you offer long-lasting, unique and compelling content — something that lets your expertise shine — people will want to recommend it to others. Great content can serve this purpose as much as providing useful tools.
A promising way to create value for your target group and earn great links is to think of issues or problems your users might encounter. Visitors are likely to appreciate your site and link to it if you publish a short tutorial or a video providing a solution, or a practical tool. Survey or original research results can serve the same purpose, if they turn out to be useful for the target audience. Both methods grow your credibility in the community and increase visibility. This can help you gain lasting, merit-based links and loyal followers who generate direct traffic and "spread the word." Offering a number of solutions for different problems could evolve into a blog which can continuously affect the site's reputation in a positive way.
Humor can be another way to gain both great links and get people to talk about your site. With Google Buzz and other social media services constantly growing, entertaining content is being shared now more than ever. We've seen all kinds of amusing content, from ASCII art embedded in a site's source code to funny downtime messages used as a viral marketing technique to increase the visibility of a site. However, we do not recommend counting only on short-lived link-bait tactics. Their appeal wears off quickly and as powerful as marketing stunts can be, you shouldn't rely on them as a long-term strategy or as your only marketing effort.
It’s important to clarify that any legitimate link building strategy is a long-term effort. There are those who advocate for short-lived, often spammy methods, but these are not advisable if you care for your site's reputation. Buying PageRank-passing links or randomly exchanging links are the worst ways of attempting to gather links and they're likely to have no positive impact on your site's performance over time. If your site's visibility in the Google index is important to you it's best to avoid them.
Directory entries are often mentioned as another way to promote young sites in the Google index. There are great, topical directories that add value to the Internet. But there are not many of them in proportion to those of lower quality. If you decide to submit your site to a directory, make sure it's on topic, moderated, and well structured. Mass submissions, which are sometimes offered as a quick work-around SEO method, are mostly useless and not likely to serve your purposes.
It can be a good idea to take a look at similar sites in other markets and identify the elements of those sites that might work well for yours, too. However, it's important not to just copy success stories but to adapt them, so that they provide unique value for your visitors.
Social bookmarks on YouTube enable users to share content easily
Finally, consider making linking to your site easier for less tech savvy users. Similar to the way we do it on YouTube, offering bookmarking services for social sites like Twitter or Facebook can help spread the word about the great content on your site and draw users' attention.
As usual, we'd like to hear your opinion. You're welcome to comment here in the blog, or join our Webmaster Help Forum community.
Written by Kaspar Szymanski, Search Quality Strategist, Dublin
[Link]
Webmaster Level: All
We’d like to highlight three best practices that address some of the most common problems found when crawling and indexing video content. These best practices include ensuring your video URLs are crawlable, stating what countries your videos may be played in, and that if your videos are removed, you clearly indicate this state to search engines.
- Best Practice 1: Verify your video URLs are crawlable: check your 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
For more information on Google Videos please visit our Help Center, and to post questions and search answers check out our Help Forum.
Posted by Nelson Lee, Product Manager, Video Search
[Link]
(Cross-posted on the Official Google Blog)
Today, we're announcing the completion of a new web indexing system called Caffeine. Caffeine provides 50 percent fresher results for web searches than our last index, and it's the largest collection of web content we've offered. Whether it's a news story, a blog or a forum post, you can now find links to relevant content much sooner after it is published than was possible ever before.
Some background for those of you who don't build search engines for a living like us: when you search Google, you're not searching the live web. Instead you're searching Google's index of the web which, like the list in the back of a book, helps you pinpoint exactly the information you need. (Here's a good explanation of how it all works.)
So why did we build a new search indexing system? Content on the web is blossoming. It's growing not just in size and numbers but with the advent of video, images, news and real-time updates, the average webpage is richer and more complex. In addition, people's expectations for search are higher than they used to be. Searchers want to find the latest relevant content and publishers expect to be found the instant they publish.
To keep up with the evolution of the web and to meet rising user expectations, we've built Caffeine. The image below illustrates how our old indexing system worked compared to Caffeine:
Our old index had several layers, some of which were refreshed at a faster rate than others; the main layer would update every couple of weeks. To refresh a layer of the old index, we would analyze the entire web, which meant there was a significant delay between when we found a page and made it available to you.
With Caffeine, we analyze the web in small portions and update our search index on a continuous basis, globally. As we find new pages, or new information on existing pages, we can add these straight to the index. That means you can find fresher information than ever before — no matter when or where it was published.
Caffeine lets us index web pages on an enormous scale. In fact, every second Caffeine processes hundreds of thousands of pages in parallel. If this were a pile of paper it would grow three miles taller every second. Caffeine takes up nearly 100 million gigabytes of storage in one database and adds new information at a rate of hundreds of thousands of gigabytes per day. You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles.
We’ve built Caffeine with the future in mind. Not only is it fresher, it's a robust foundation that makes it possible for us to build an even faster and comprehensive search engine that scales with the growth of information online, and delivers even more relevant search results to you. So stay tuned, and look for more improvements in the months to come.
Posted by Carrie Grimes, Software Engineer
[Link]
Webmaster Level: All
Today we’re releasing a feature to help you discover if your site serves undesirable "soft” or “crypto” 404s. A "soft 404" occurs when a webserver responds with a 200 OK HTTP response code for a page that doesn't exist rather than the appropriate 404 Not Found. Soft 404s can limit a site's crawl coverage by search engines because these duplicate URLs may be crawled instead of pages with unique content.
The web is infinite, but the time search engines spend crawling your site is limited. Properly reporting non-existent pages with a 404 or 410 response code can improve the crawl coverage of your site’s best content. Additionally, soft 404s can potentially be confusing for your site's visitors as described in our past blog post, Farewell to Soft 404s.
You can find the new soft 404s reporting feature under the Crawl errors section in Webmaster Tools.
Here’s a list of steps to correct soft 404s to help both Google and your users:
- Check whether you have soft 404s listed in Webmaster Tools
- For the soft 404s, determine whether the URL:
- Contains the correct content and properly returns a 200 response (not actually a soft 404)
- Should 301 redirect to a more accurate URL
- Doesn’t exist and should return a 404 or 410 response
- Confirm that you’ve configured the proper HTTP Response by using Fetch as Googlebot in Webmaster Tools
- If you now return 404s, you may want to customize your 404 page to aid your users. Our custom 404 widget can help.
We hope that you’re now better enabled to find and correct soft 404s on your site. If you have feedback or questions about the new "soft 404s" reporting feature or any other Webmaster Tools feature, please share your thoughts with us in the Webmaster Help Forum.
Written by Jonathan Simon, Webmaster Trends Analyst
[Link]
We’re kicking off June with the start of a new round of webmaster Q&A on the Webmaster Central YouTube channel. You submitted and voted on questions for Matt Cutts to answer, and Matt sat in the studio for a full day sharing advice for webmasters.
For those of you who watch each video (and who doesn’t?), we’ve worked hard to keep things interesting. Not only did Matt wear different colored shirts, we changed the backgrounds as well! Just don’t submit any screen grabs to We Have Lasers, okay?
To get you started, here’s the first video, which addresses a question about geographic targeting in Webmaster Tools:
We’ll be posting links to new videos as they’re posted on our Twitter account, so follow us there or subscribe to our YouTube channel to be notified of new answers.
Posted by Michael Wyszomierski, Search Quality Team
[Link]
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.
Written by Koh Kim, Google Chrome Team
[Link]
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.
Written by Jonathan Simon, Webmaster Trends Analyst
[Link]
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!
Written by Viktor Nebehaj and Matt Cutts, Search Quality Team
[Link]
(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
[Link]
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.
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.
Posted by Susan Moskwa, Webmaster Trends Analyst
[Link]
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/.
Written by Maile Ohye, Developer Programs Tech Lead
[Link]
Webmaster Level: All
As part of our efforts to make search results more useful to our users around the world, we’re announcing the international availability of rich snippets. If you’ve been following our blog posts, you already know that rich snippets let users see additional facts and data from your site in search results.
For example, we recently launched rich snippets for recipes which, for certain sites, lets users see quick recipe facts as part of the snippet and makes it easier to determine if the page has what they are looking for:
We’ve had a lot of questions on our blogs and forums about international support for rich snippets – and we know that many of you have already started marking up your content – so today’s announcement is very exciting for us.
In addition to adding support for rich snippets in any language, we have published documentation on how to mark up your sites for rich snippets in the following languages: simplified Chinese, traditional Chinese, Czech, Dutch, English, French, German, Hungarian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, and Turkish. (You can change the Help language by scrolling to the bottom of the help page and selecting the language you want from the drop-down menu.)
We encourage you to read the documentation to take advantage of the different types of rich snippets currently supported: people profiles, reviews, videos, events and recipes. You can also use our testing tool (in English only, but useful to test markup in any language) and start validating your markup to make sure results show as you would expect.
Finally and as you’ve probably heard by now (several times), we’re taking a gradual approach to surface rich snippets. This means that marking up your site doesn’t guarantee that we’ll show rich snippets for your pages. We’re doing this to ensure a good experience for our users; but rest assured we’re working hard to expand coverage and include more web pages.
Written by Kavi Goel, Pravir Gupta, and Yu Watanabe
[Link]
01 Sep 2010 20 Aug 2010 19 Aug 2010 17 Aug 2010 16 Aug 2010