Einträge von Google

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: All

In recent months we?ve been especially focused on helping people find high-quality sites in Google?s search results. The ?Panda? algorithm change has improved rankings for a large number of high-quality websites, so most of you reading have nothing to be concerned about. However, for the sites that may have been affected by Panda we wanted to provide additional guidance on how Google searches for high-quality sites.

Our advice for publishers continues to be to focus on delivering the best possible user experience on your websites and not to focus too much on what they think are Google?s current ranking algorithms or signals. Some publishers have fixated on our prior Panda algorithm change, but Panda was just one of roughly 500 search improvements we expect to roll out to search this year. In fact, since we launched Panda, we've rolled out over a dozen additional tweaks to our ranking algorithms, and some sites have incorrectly assumed that changes in their rankings were related to Panda. Search is a complicated and evolving art and science, so rather than focusing on specific algorithmic tweaks, we encourage you to focus on delivering the best possible experience for users.

What counts as a high-quality site?

Our site quality algorithms are aimed at helping people find "high-quality" sites by reducing the rankings of low-quality content. The recent "Panda" change tackles the difficult task of algorithmically assessing website quality. Taking a step back, we wanted to explain some of the ideas and research that drive the development of our algorithms.

Below are some questions that one could use to assess the "quality" of a page or an article. These are the kinds of questions we ask ourselves as we write algorithms that attempt to assess site quality. Think of it as our take at encoding what we think our users want.

Of course, we aren't disclosing the actual ranking signals used in our algorithms because we don't want folks to game our search results; but if you want to step into Google's mindset, the questions below provide some guidance on how we've been looking at the issue:

• Would you trust the information presented in this article?
• Is this article written by an expert or enthusiast who knows the topic well, or is it more shallow in nature?
• Does the site have duplicate, overlapping, or redundant articles on the same or similar topics with slightly different keyword variations?
• Would you be comfortable giving your credit card information to this site?
• Does this article have spelling, stylistic, or factual errors?
• Are the topics driven by genuine interests of readers of the site, or does the site generate content by attempting to guess what might rank well in search engines?
• Does the article provide original content or information, original reporting, original research, or original analysis?
• Does the page provide substantial value when compared to other pages in search results?
• How much quality control is done on content?
• Does the article describe both sides of a story?
• Is the site a recognized authority on its topic?
• Is the content mass-produced by or outsourced to a large number of creators, or spread across a large network of sites, so that individual pages or sites don?t get as much attention or care?
• Was the article edited well, or does it appear sloppy or hastily produced?
• For a health related query, would you trust information from this site?
• Would you recognize this site as an authoritative source when mentioned by name?
• Does this article provide a complete or comprehensive description of the topic?
• Does this article contain insightful analysis or interesting information that is beyond obvious?
• Is this the sort of page you?d want to bookmark, share with a friend, or recommend?
• Does this article have an excessive amount of ads that distract from or interfere with the main content?
• Would you expect to see this article in a printed magazine, encyclopedia or book?
• Are the articles short, unsubstantial, or otherwise lacking in helpful specifics?
• Are the pages produced with great care and attention to detail vs. less attention to detail?
• Would users complain when they see pages from this site?

Writing an algorithm to assess page or site quality is a much harder task, but we hope the questions above give some insight into how we try to write algorithms that distinguish higher-quality sites from lower-quality sites.

What you can do

We've been hearing from many of you that you want more guidance on what you can do to improve your rankings on Google, particularly if you think you've been impacted by the Panda update. We encourage you to keep questions like the ones above in mind as you focus on developing high-quality content rather than trying to optimize for any particular Google algorithm.

One other specific piece of guidance we've offered is that low-quality content on some parts of a website can impact the whole site?s rankings, and thus removing low quality pages, merging or improving the content of individual shallow pages into more useful pages, or moving low quality pages to a different domain could eventually help the rankings of your higher-quality content.

We're continuing to work on additional algorithmic iterations to help webmasters operating high-quality sites get more traffic from search. As you continue to improve your sites, rather than focusing on one particular algorithmic tweak, we encourage you to ask yourself the same sorts of questions we ask when looking at the big picture. This way your site will be more likely to rank well for the long-term. In the meantime, if you have feedback, please tell us through our Webmaster Forum. We continue to monitor threads on the forum and pass site info on to the search quality team as we work on future iterations of our ranking algorithms.

Written by Amit Singhal, Google Fellow

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: All

With Instant Previews, users can see a snapshot of a search result before clicking on it. We?ve made a number of improvements to the feature since its introduction last November, and if you own a site, one of the most relevant changes for you is that Instant Previews now supports Flash.



In most cases, when the preview for a page is generated through our regular crawl, we will now render a snapshot of any Flash components on the page. This will replace the "puzzle piece" icon that previously appeared to indicate Flash components, and should improve the accuracy of the previews.

However, for pages that are fetched on demand by the "Google Web Preview" user-agent, we will generate a preview without Flash in order to minimize latency. In these cases the preview will appear as if the page were visited by someone using a browser without Flash enabled, and "Install Flash" messages may appear in the preview, depending on how your website handles users without Flash.

To improve your previews for these on-demand renders, here are some guidelines for using Flash on your site:

• Make sure that your site has a reasonable, seamless experience for visitors without Flash. This may involve creating HTML-only equivalents for your Flash-based content that will automatically be shown to visitors who can't view Flash. Providing a good experience for this case will improve your preview and make your visitors happier.


• If Flash components are rendering but appear as loading screens instead of actual content, try reducing the loading time for the component. This makes it more likely we'll render it properly.


• If you have Flash videos on your site, consider submitting a Video Sitemap which helps us to generate thumbnails for your videos in Instant Previews.


• If most of the page is rendering properly but you still see puzzle pieces appearing for some smaller components, these may be fixed in future crawls of your page.

If you have additional questions, please feel free to post them in our Webmaster Help Forum.

As always, we'll keep you updated as we continue to make improvements to Instant Previews.

Posted by Raj Krishnan, Product Manager

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: Intermediate to Advanced

Users are taught to protect themselves from malicious programs by installing sophisticated antivirus software, but often they may also entrust their private information to websites like yours, in which case it?s important to protect their data. It?s also very important to protect your own data; if you have an online store, you don?t want to be robbed.

Over the years companies and webmasters have learned?often the hard way?that web application security is not a joke; we?ve seen user passwords leaked due to SQL injection attacks, cookies stolen with XSS, and websites taken over by hackers due to negligent input validation.

Today we?ll show you some examples of how a web application can be exploited so you can learn from them; for this we?ll use Gruyere, an intentionally vulnerable application we use for security training internally, too. Do not probe others? websites for vulnerabilities without permission as it may be perceived as hacking; but you?re welcome?nay, encouraged?to run tests on Gruyere.


Client state manipulation - What will happen if I alter the URL?

Let?s say you have an image hosting site and you?re using a PHP script to display the images users have uploaded:

http://www.example.com/showimage.php?imgloc=/garyillyes/kitten.jpg

So what will the application do if I alter the URL to something like this and userpasswords.txt is an actual file?

http://www.example.com/showimage.php?imgloc=/../../userpasswords.txt

Will I get the content of userpasswords.txt?

Another example of client state manipulation is when form fields are not validated. For instance, let?s say you have this form:



It seems that the username of the submitter is stored in a hidden input field. Well, that?s great! Does that mean that if I change the value of that field to another username, I can submit the form as that user? It may very well happen; the user input is apparently not authenticated with, for example, a token which can be verified on the server.
Imagine the situation if that form were part of your shopping cart and I modified the price of a $1000 item to $1, and then placed the order.

Protecting your application against this kind of attack is not easy; take a look at the third part of Gruyere to learn a few tips about how to defend your app.

Cross-site scripting (XSS) - User input can?t be trusted



A simple, harmless URL:
http://google-gruyere.appspot.com/611788451095/%3Cscript%3Ealert('0wn3d')%3C/script%3E
But is it truly harmless? If I decode the percent-encoded characters, I get:

<script>alert('0wn3d')</script>

Gruyere, just like many sites with custom error pages, is designed to include the path component in the HTML page. This can introduce security bugs, like XSS, as it introduces user input directly into the rendered HTML page of the web application. You might say, ?It?s just an alert box, so what?? The thing is, if I can inject an alert box, I can most likely inject something else, too, and maybe steal your cookies which I could use to sign in to your site as you.

Another example is when the stored user input isn?t sanitized. Let?s say I write a comment on your blog; the comment is simple:

<a href=?javascript:alert(?0wn3d?)?>Click here to see a kitten</a>

If other users click on my innocent link, I have their cookies:



You can learn how to find XSS vulnerabilities in your own web app and how to fix them in the second part of Gruyere; or, if you?re an advanced developer, take a look at the automatic escaping features in template systems we blogged about on our Online Security blog.

Cross-site request forgery (XSRF) - Should I trust requests from evil.com?

Oops, a broken picture. It can?t be dangerous--it?s broken, after all--which means that the URL of the image returns a 404 or it?s just malformed. Is that true in all of the cases?

No, it?s not! You can specify any URL as an image source, regardless of its content type. It can be an HTML page, a JavaScript file, or some other potentially malicious resource. In this case the image source was a simple page?s URL:



That page will only work if I?m logged in and I have some cookies set. Since I was actually logged in to the application, when the browser tried to fetch the image by accessing the image source URL, it also deleted my first snippet. This doesn?t sound particularly dangerous, but if I?m a bit familiar with the app, I could also invoke a URL which deletes a user?s profile or lets admins grant permissions for other users.

To protect your app against XSRF you should not allow state changing actions to be called via GET; the POST method was invented for this kind of state-changing request. This change alone may have mitigated the above attack, but usually it's not enough and you need to include an unpredictable value in all state changing requests to prevent XSRF. Please head to Gruyere if you want to learn more about XSRF.

Cross-site script inclusion (XSSI) - All your script are belong to us

Many sites today can dynamically update a page's content via asynchronous JavaScript requests that return JSON data. Sometimes, JSON can contain sensitive data, and if the correct precautions are not in place, it may be possible for an attacker to steal this sensitive information.

Let?s imagine the following scenario: I have created a standard HTML page and send you the link; since you trust me, you visit the link I sent you. The page contains only a few lines:

<script>function _feed(s) {alert("Your private snippet is: " + s['private_snippet']);}</script><script src="http://google-gruyere.appspot.com/611788451095/feed.gtl"></script>

Since you?re signed in to Gruyere and you have a private snippet, you?ll see an alert box on my page informing you about the contents of your snippet. As always, if I managed to fire up an alert box, I can do whatever else I want; in this case it was a simple snippet, but it could have been your biggest secret, too.

It?s not too hard to defend your app against XSSI, but it still requires careful thinking. You can use tokens as explained in the XSRF section, set your script to answer only POST requests, or simply start the JSON response with ?\n? to make sure the script is not executable.

SQL Injection - Still think user input is safe?

What will happen if I try to sign in to your app with a username like

JohnDoe?; DROP TABLE members;--

While this specific example won?t expose user data, it can cause great headaches because it has the potential to completely remove the SQL table where your app stores information about members.

Generally, you can protect your app from SQL injection with proactive thinking and input validation. First, are you sure the SQL user needs to have permission to execute ?DROP TABLE members?? Wouldn?t it be enough to grant only SELECT rights? By setting the SQL user?s permissions carefully, you can avoid painful experiences and lots of troubles. You might also want to configure error reporting in such way that the database and its tables? names aren?t exposed in the case of a failed query.
Second, as we learned in the XSS case, never trust user input: what looks like a login form to you, looks like a potential doorway to an attacker. Always sanitize and quotesafe the input that will be stored in a database, and whenever possible make use of statements generally referred to as prepared or parametrized statements available in most database programming interfaces.

Knowing how web applications can be exploited is the first step in understanding how to defend them. In light of this, we encourage you to take the Gruyere course, take other web security courses from the Google Code University and check out skipfish if you're looking for an automated web application security testing tool. If you have more questions please post them in our Webmaster Help Forum.

Written by Gary Illyes, Webmaster Trends Analyst

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: Beginner/Intermediate



So there you are, minding your own business, using Webmaster Tools to check out how awesome your site is... but, wait! The Crawl errors page is full of 404 (Not found) errors! Is disaster imminent??





Fear not, my young padawan. Let?s take a look at 404s and how they do (or do not) affect your site:



Q: Do the 404 errors reported in Webmaster Tools affect my site?s ranking?

A: 404s are a perfectly normal part of the web; the Internet is always changing, new content is born, old content dies, and when it dies it (ideally) returns a 404 HTTP response code. Search engines are aware of this; we have 404 errors on our own sites, as you can see above, and we find them all over the web. In fact, we actually prefer that, when you get rid of a page on your site, you make sure that it returns a proper 404 or 410 response code (rather than a ?soft 404?). Keep in mind that in order for our crawler to see the HTTP response code of a URL, it has to be able to crawl that URL?if the URL is blocked by your robots.txt file we won?t be able to crawl it and see its response code. The fact that some URLs on your site no longer exist / return 404s does not affect how your site?s other URLs (the ones that return 200 (Successful)) perform in our search results.



Q: So 404s don?t hurt my website at all?

A: If some URLs on your site 404, this fact alone does not hurt you or count against you in Google?s search results. However, there may be other reasons that you?d want to address certain types of 404s. For example, if some of the pages that 404 are pages you actually care about, you should look into why we?re seeing 404s when we crawl them! If you see a misspelling of a legitimate URL (www.example.com/awsome instead of www.example.com/awesome), it?s likely that someone intended to link to you and simply made a typo. Instead of returning a 404, you could 301 redirect the misspelled URL to the correct URL and capture the intended traffic from that link. You can also make sure that, when users do land on a 404 page on your site, you help them find what they were looking for rather than just saying ?404 Not found."



Q: Tell me more about ?soft 404s.?

A: A soft 404 is when a web server returns a response code other than 404 (or 410) for a URL that doesn?t exist. A common example is when a site owner wants to return a pretty 404 page with helpful information for his users, and thinks that in order to serve content to users he has to return a 200 response code. Not so! You can return a 404 response code while serving whatever content you want. Another example is when a site redirects any unknown URLs to their homepage instead of returning 404s. Both of these cases can have negative effects on our understanding and indexing of your site, so we recommend making sure your server returns the proper response codes for nonexistent content. Keep in mind that just because a page says ?404 Not Found,? doesn?t mean it?s actually returning a 404 HTTP response code?use the Fetch as Googlebot feature in Webmaster Tools to double-check. If you don?t know how to configure your server to return the right response codes, check out your web host?s help documentation.



Q: How do I know whether a URL should 404, or 301, or 410?

A: When you remove a page from your site, think about whether that content is moving somewhere else, or whether you no longer plan to have that type of content on your site. If you?re moving that content to a new URL, you should 301 redirect the old URL to the new URL?that way when users come to the old URL looking for that content, they?ll be automatically redirected to something relevant to what they were looking for. If you?re getting rid of that content entirely and don?t have anything on your site that would fill the same user need, then the old URL should return a 404 or 410. Currently Google treats 410s (Gone) the same as 404s (Not found), so it?s immaterial to us whether you return one or the other.



Q: Most of my 404s are for bizarro URLs that never existed on my site. What?s up with that? Where did they come from?

A: If Google finds a link somewhere on the web that points to a URL on your domain, it may try to crawl that link, whether any content actually exists there or not; and when it does, your server should return a 404 if there?s nothing there to find. These links could be caused by someone making a typo when linking to you, some type of misconfiguration (if the links are automatically generated, e.g. by a CMS), or by Google?s increased efforts to recognize and crawl links embedded in JavaScript or other embedded content; or they may be part of a quick check from our side to see how your server handles unknown URLs, to name just a few. If you see 404s reported in Webmaster Tools for URLs that don?t exist on your site, you can safely ignore them. We don?t know which URLs are important to you vs. which are supposed to 404, so we show you all the 404s we found on your site and let you decide which, if any, require your attention.



Q: Someone has scraped my site and caused a bunch of 404s in the process. They?re all ?real? URLs with other code tacked on, like http://www.example.com/images/kittens.jpg" width="100" height="300" alt="kittens"/></a... Will this hurt my site?

A: Generally you don?t need to worry about ?broken links? like this hurting your site. We understand that site owners have little to no control over people who scrape their site, or who link to them in strange ways. If you?re a whiz with the regex, you could consider redirecting these URLs as described here, but generally it?s not worth worrying about. Remember that you can also file a takedown request when you believe someone is stealing original content from your website.



Q: Last week I fixed all the 404s that Webmaster Tools reported, but they?re still listed in my account. Does this mean I didn?t fix them correctly? How long will it take for them to disappear?

A: Take a look at the ?Detected? column on the Crawl errors page?this is the most recent date on which we detected each error. If the date(s) in that column are from before the time you fixed the errors, that means we haven?t encountered these errors since that date. If the dates are more recent, it means we?re continuing to see these 404s when we crawl.



After implementing a fix, you can check whether our crawler is seeing the new response code by using Fetch as Googlebot. Test a few URLs and, if they look good, these errors should soon start to disappear from your list of Crawl errors.



Q: Can I use Google?s URL removal tool to make 404 errors disappear from my account faster?

A: No; the URL removal tool removes URLs from Google?s search results, not from your Webmaster Tools account. It?s designed for urgent removal requests only, and using it isn?t necessary when a URL already returns a 404, as such a URL will drop out of our search results naturally over time. See the bottom half of this blog post for more details on what the URL removal tool can and can?t do for you.



Still want to know more about 404s? Check out 404 week from our blog, or drop by our Webmaster Help Forum.



Posted by Susan Moskwa, Webmaster Trends Analyst

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

[Cross-posted on the YouTube Blog]



Last week we sent an email to Google Video users letting them know we would be ending playbacks of Google Videos on April 29 and providing instructions on how to download videos currently hosted on the platform. Since then we?ve received feedback from you about making the migration off of Google Video easier. We work every day to make sure you have a great user experience and should have done better. Based on your feedback, here?s what we?re doing to fix things.



Google Video users can rest assured that they won't be losing any of their content and we are eliminating the April 29 deadline. We will be working to automatically migrate your Google Videos to YouTube. In the meantime, your videos hosted on Google Video will remain accessible on the web and existing links to Google Videos will remain accessible. If you want to migrate to YouTube now, here?s how you do it:

• We?ve created an ?Upload Videos to YouTube? option on the Google Video status page. To do this, you?ll need to have a YouTube account associated with your Google Video account (you can create one here). Before doing this you should read YouTube?s Terms of Use and Copyright Policies. If you choose this option, we?ll do our best to ensure your existing Google Video links continue to function.

If you?d prefer to download your videos from Google Video, that option is still available.



As we said nearly two years ago, the team is now focused on tackling the tough challenge of video search. We want to thank the millions of people around the world who have taken the time to create and share videos on Google Video. We hope today's improvements will help ease your transition to another video hosting service.



Posted by Mark Dochtermann, Engineering Manager

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster Level: All

For webmasters with self-hosted WordPress blogs, there?s now a Webmaster Tools site verifcation plugin for Wordpress that completely automates our verification process! You can install it directly from the ?Install Plugins? control panel built into your WordPress blog, or you can download the ZIP file from the WordPress plugin site. This plugin can only be used by self-hosted WordPress blogs; it can?t be installed on blogs hosted on wordpress.com.

With verified ownership of your site in Webmaster Tools, you can receive specific statistics and information (e.g. relevant search queries, malware notices) about your site directly from Google. For recent news about verification for other types of sites, please see our recent blog post, ?Your fast pass through security.?


Written by Kevin Marshall, Software Engineer

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: All

Security checks are nobody's cup of tea. We've never seen people go through airport baggage checks for fun. But while security measures are often necessary, that doesn't mean they have to be painful. In that spirit, we?ve implemented several major improvements to make the Google Site Verification process faster, more straightforward, and perhaps even a pleasure to use?so you can get on with the tasks that matter to you.

New verification method recommendations


You?ll quickly notice the changes we?ve made to the verification page, namely the new tabbed interface. These tabs allow us to give greater visibility to the verification method that we think will be most useful to you, which is listed in the Recommended Method tab.


Our recommendation is just an educated guess, but sometimes guesses can be wrong. It?s possible that the method we recommend might not work for you. If this is the case, simply click the "Alternate methods" tab to see the other verification methods that are available. Verifying with an alternate method is just as powerful as verifying with a recommended method.

Our recommendations are computed from statistical data taken from users with a similar configuration to yours. For example, we can guess which verification methods might be successful by looking at the public hosting information for your website. In the future we plan to add more signals so that we can provide additional customized instructions along with more relevant recommendations.

New Google Sites Are Automatically Verified
For some of you, we?ve made the process even more effortless?Google Sites administrators are now automatically verified for all new sites that they create. When you create a new Google Site, it?ll appear verified in the details page. The same goes for adding or removing owners: when you edit the owners list in your Google Site's settings, the changes will automatically appear in Webmaster Tools.

One thing to note is that we?re unable to automatically verify preexisting Google Sites at this time. If you?d like to verify your older Google Sites, please continue to use the meta tag method already available.

We hope these enhancements help get you through security even faster. Should you get pulled over and have any questions, feel free to check out our Webmaster Help Forums.


Written by Kevin Marshall, Konstantin Roslyakov, Ian Porteous (Software Engineers)

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: Beginner - Intermediate

We recently hosted our second site clinic, this time at TechHub in London, UK. Like last year, here?s our summary of the topics that came up.

• Title tags and meta description tags are easy ways to improve your site's visibility in Google search results, yet we still see webmasters not fully utilizing their potential. We have a bit of help available about writing good page titles and descriptions which you can read to brush up on the subject. That said, you can ignore the meta keywords, at least as far as Google is concerned.
• One way Google's algorithms determine the context of content on a page is by looking at the page?s headings. The way semantic markup is used throughout a site, including h1, h2, and h3 tags, helps us to understand the priorities of a site?s content. One should not fret, though, about every single H tag. Using common sense is the way to go.
• Just as we recommend you structuring pages logically, it is similarly important to structure the whole website, particularly by linking to related documents within your site as necessary. This helps both users and search engine bots explore all the content you provide. To augment this, be sure to provide a regularly updated Sitemap, which can be conveniently linked to from your site?s robots.txt file for automatic discovery by Google and other search engines.
• Duplicate content and canonicalization issues were discussed for many websites reviewed at the site clinic. Duplicate content within a website is generally not a problem, but can make it more difficult for search engines to properly index your content and serve the right version to users. There are two common ways to signal what your preferred versions of your content are: By using 301 redirects to point to your preferred versions, or by using the rel="canonical" link element. If you?re concerned about setting your preferred domain in terms of whether to use www or non-www, we recommend you check out the related feature for setting the preferred domain feature in Webmaster Tools.
• Another commonly seen issue is that some sites have error pages which do not return an error HTTP result code, but instead return the HTTP success code 200. Only documents that are actually available should reply with the HTTP success result code 200. When a page no longer exists, it should return a 404 (Not found) response. Header responses of any URL can be checked using Fetch as Googlebot in Webmaster Tools or using third party tools such as the Live HTTP Headers Firefox addon or web-sniffer.net.
• Ranking for misspelled queries, e.g. local business names including typos, seems to be an area of concern. In some cases, Google?s automatic spelling correction gets the job done for users by suggesting the correct spelling. It isn?t a wise idea to stuff a site's content with every typo imaginable. It?s also not advisable to hide this or any other type of content using JavaScript, CSS or similar techniques. These methods are in violation of Google?s Webmaster Guidelines and we may take appropriate action against a site that employs them. If you?re not sure how Googlebot ?sees? your pages, e.g. when using lots of JavaScript, you can get a better idea by looking at the text-only version of the cached copy in Google web search results.
• Users love fast websites. That?s why webpage loading speed is an important consideration for your users. We offer a wide range of tools and recommendations to help webmasters understand the performance of their websites and how to improve them. The easiest way to get started is to use Page Speed Online, which is the web-based version of our popular Page Speed Chrome extension. Our Let's make the web faster page has great list of resources from Google and elsewhere for improving website speed, which we recommend you to read.

We?d like to thank the TechHub team, who helped us facilitate the event, and give a big thank you to all participants. We hope you found the presentation and Q&A session interesting. We've embedded the presentation below.

And as we mentioned in the site clinic, sign up at the Google Webmaster Help Forum to discuss any further questions you might have and keep an eye on our Webmaster Central Blog.

Written by Kaspar Szymanski, Pierre Far, Sven Naumann

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Over a month ago we introduced an algorithmic improvement designed to help people

find more high-quality sites in search. Since then we?ve gotten a lot of positive responses about the change: searchers are finding better results, and many great publishers are getting more traffic.



Today we?ve rolled out this improvement globally to all English-language Google users, and we?ve also incorporated new user feedback signals to help people find better search results. In some high-confidence situations, we are beginning to incorporate data about the sites that users block into our algorithms. In addition, this change also goes deeper into the ?long tail? of low-quality websites to return higher-quality results where the algorithm might not have been able to make an assessment before. The impact of these new signals is smaller in scope than the original change: about 2% of U.S. queries are affected by a reasonable amount, compared with almost 12% of U.S. queries for the original change.



Based on our testing, we?ve found the algorithm is very accurate at detecting site quality. If you believe your site is high-quality and has been impacted by this change, we encourage you to evaluate the different aspects of your site extensively. Google's quality guidelines provide helpful information about how to improve your site. As sites change, our algorithmic rankings will update to reflect that. In addition, you?re welcome to post in our Webmaster Help Forums. While we aren?t making any manual exceptions, we will consider this feedback as we continue to refine our algorithms.



We will continue testing and refining the change before expanding to additional languages, and we?ll be sure to post an update when we have more to share.



Posted by Amit Singhal, Google Fellow

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster Level: Beginner

We?re very glad to announce that our recently updated SEO guide is now available in ten more languages: Spanish, French, German, Russian, Turkish, Finnish, Swedish, Hungarian, Traditional Chinese and Simplified Chinese.

For this new version, we?ve thoroughly reviewed and updated the content; we?ve also added a brand new section on best practices for mobile websites.



You can download each PDF file in its full 32-page glory from goo.gl/seoguide and print it to have it as a useful resource.

Posted by Esperanza Navas and Mariya Moeva, Search Quality Team

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster Level: Intermediate to Advanced



The Chrome team is exploring a few changes to Chrome?s UA string. These changes are designed to provide additional details in the user-agent, remove redundancy, and increase compatibility with Internet Explorer. They?re also happening in conjunction with similar changes in Firefox 4.



We intend to ship Chrome 11 with these changes, assuming they don't cause major web compatibility problems. To test them out and ensure your website remains compatible with Chrome, we recommend trying the Chrome Dev and Beta channel builds. If you have any questions, please check out the blog post on the Chromium blog or drop us a line at our help forum.



Written by Peter Kasting, Software Engineer

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: intermediate



At Google, we?re striving to make the whole web fast. As part of that effort, we?re launching a new web-based tool in Google Labs, Page Speed Online, which analyzes the performance of web pages and gives specific suggestions for making them faster. Page Speed Online is available from any browser, at any time. This allows website owners to get immediate access to Page Speed performance suggestions so they can make their pages faster.



In addition, we?ve added a new feature: the ability to get Page Speed suggestions customized for the mobile version of a page, specifically smartphones. Due to the relatively limited CPU capabilities of mobile devices, the high round-trip times of mobile networks, and rapid growth of mobile usage, understanding and optimizing for mobile performance is even more critical than for the desktop, so Page Speed Online now allows you to easily analyze and optimize your site for mobile performance. The mobile recommendations are tuned for the unique characteristics of mobile devices, and contain several best practices that go beyond the recommendations for desktop browsers, in order to create a faster mobile experience. New mobile-targeted best practices include eliminating uncacheable landing page redirects and reducing the amount of JavaScript parsed during the page load, two common issues that slow down mobile pages today.





Page Speed Online is powered by the same Page Speed SDK that powers the Chrome and Firefox extensions and webpagetest.org.



Please give Page Speed Online a try. We?re eager to hear your feedback on our mailing list and how you?re using it to optimize your site.



Posted by Andrew Oates and Richard Rabbat, Page Speed team

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster Level: Intermediate to Advanced

Here?s a trending User-Agent detection misstep we hope to help you prevent: While it seems completely reasonable to key off the string ?android? in the User-Agent and then redirect users to your mobile version, there?s a small catch... Android tablets were just released! Similar to mobile, the User-Agent on Android tablets also contains ?android,? yet tablet users usually prefer the full desktop version over the mobile equivalent. If your site matches ?android? and then automatically redirects users, you may be forcing Android tablet users into a sub-optimal experience.

As a solution for mobile sites, our Android engineers recommend to specifically detect ?mobile? in the User-Agent string as well as ?android.? Let?s run through a few examples.

With a User-Agent like this:
Mozilla/5.0 (Linux; U; Android 3.0; en-us; Xoom Build/HRI39) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13
since there is no ?mobile? string, serve this user the desktop version (or a version customized for Android large-screen touch devices). The User-Agent tells us they?re coming from a large-screen device, the XOOM tablet.

On the other hand, this User-Agent:
Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
contains ?mobile? and ?android,? so serve the web surfer on this Nexus One the mobile experience!

You?ll notice that Android User-Agents have commonalities:


While you may still want to detect ?android? in the User-Agent to implement Android-specific features, such as touch-screen optimizations, our main message is: Should your mobile site depends on UA sniffing, please detect the strings ?mobile? and ?android,? rather than just ?android,? in the User-Agent. This helps properly serve both your mobile and tablet visitors.

For questions, please join our Android community in their developer forum.

Written by Maile Ohye, Developer Programs Tech Lead

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster level: All

We all know what it?s like to get a bit of help when you?re looking for it. Online, that advice can come from a number of places: a tweet, a shared video, or a blog post, to name a few. With Google Social Search we?ve been working to show that content when it?s useful, making search more personally relevant.

We think sharing on the web can be even better--that people might share more recommendations, more often, if they knew their advice would be used to help their friends and contacts right when they?re searching for relevant topics on Google. That?s why we?re introducing the +1 button, an easy way for Google users to recommend your content right from the search results pages (and, soon, from your site).



+1 is a simple idea. Let?s use Brian as an example. When Brian signs in to his Google Account and sees one of your pages in the organic search results on Google (or your search ads if you?re using AdWords), he can +1 it and recommend your page to the world.


The next time Brian?s friend Mary is signed in and searching on Google and your page appears, she might see a personalized annotation letting her know that Brian +1?d it. So Brian?s +1 helps Mary decide that your site is worth checking out.


We expect that these personalized annotations will help sites stand out by showing users which search results are personally relevant to them. As a result, +1?s could increase both the quality and quantity of traffic to the sites people care about.

But the +1 button isn?t just for search results. We?re working on a +1 button that you can put on your pages too, making it easy for people to recommend your content on Google search without leaving your site. If you want to be notified when the +1 button is available for your website, you can sign up for email updates at our +1 webmaster site.

Over the coming weeks, we?ll add +1 buttons to search results and ads on Google.com. We?ll also start to look at +1?s as one of the many signals we use to determine a page?s relevance and ranking, including social signals from other services. For +1's, as with any new ranking signal, we'll be starting carefully and learning how those signals affect search quality over time. At first the +1 button will appear for English searches only on Google.com, but we?re working to add more languages in the future.

We?re excited about using +1?s to make search more personal, relevant and compelling. We hope you?re excited too! If you have questions about the +1 button and how it affects search on Google.com, you can check the Google Webmaster Central Help Center.

Posted by David Byttow, Software Engineer, +1 Button

Dieser Artikel wurde von von der Seite Google verfasst und hier aggregiert.

Webmaster Level: All

If your website is the authoritative source for the video of a particular TV show, make sure we know about it! Hopefully, you already submit Video Sitemaps or mRSS feeds to inform us about video content on your website. We now support additional fields in both video Sitemaps and mRSS feeds where you can specify metadata specific to television or episodic content. This includes the series? title, the season and episode numbers for the video in question, the premiere date, as well as other additional information. The metadata from your video feed helps us provide more detailed, relevant results to users wanting to view your show.

Here?s an example Video Sitemap entry that includes all the required and some optional TV metadata in the <video:tvshow> element:

<video:video>
  <video:title>The Sample Show, Season 1, Episode 2</video:title>
  <!-- other required root level video tags omitted -->
  <video:tvshow>
    <video:show_title>The Sample Show</video:show_title>
    <video:video_type>full</video:video_type>
    <video:episode_title>A Sample Episode Title</video:episode_title>
    <video:season_number>1</video:season_number>
    <video:episode_number>2</video:episode_number>
  </video:tvshow>
</video:video>

The full documentation for the tags for both mRSS and Video Sitemaps can be found in our Webmaster Tools Help Center. As always, if you have any questions about Video Sitemaps or mRSS feeds, feel free to reach out to us in the Sitemaps section of the Webmaster Help Forum.

Written by Jeff Posnick, Video Search Team