WorryFree Computers   »   [go: up one dir, main page]

Webmaster Level: Beginner

Update on October 3, 2010: We have fixed the issue causing the highlighted text to be obscured on Linux PDF readers.

About two years ago we published our first SEO Starter Guide, which we have since translated into 40 languages. Today, we’re very happy to share with you the new version of the guide with more content and examples.

Here’s what’s new:
  • Glossary to define terms throughout the guide
  • More example images to help you understand the content
  • Ways to optimize your site for mobile devices
  • Clearer wording for better readability
You may remember getting to see what Googlebot looks like in our “First date with Googlebot” post. In this version of the SEO Starter Guide, Googlebot is back to provide you with some more SEO tips.

You can download the new version here [PDF]. Entertain and impress your friends by leaving a printed copy on your coffee table.

Googlebot

Webmaster Level: All
Cross-posted from the Lat Long Blog.

We’re sharing some news today that we hope webmasters will find exciting. As you know, we’re constantly working to organize the world’s information - be it textual, visual, geographic or any other type of useful data. From a local search perspective, part of this effort means looking for all the great web pages that reference a particular place. The Internet is teeming with useful information about local places and points of interest, and we do our best to deliver relevant search results that help shed light on locations all across the globe.

Today, we’re announcing that your use of Rich Snippets can help people find the web pages you’ve created that may reference a specific place or location. By using structured HTML formats like hCard to markup the business or organization described on your page, you make it easier for search engines like Google to properly classify your site, recognize and understand that its content is about a particular place, and make it discoverable to users on Place pages.

You can get started by reviewing these tips for using Rich Snippets for Local Search. Whether you’re creating a website for your own business, an article on a newly opened restaurant, or a guide to the best places in town, your precise markup helps associate your site with the search results for that particular place. Though this markup does not guarantee that your site will be shown in search results, we’re excited to expand support for making the web better organized around real world places.

Webmaster Level: All

Often a website which hosts videos will have a common top-level page that groups conceptually related videos together. Such a page may be of interest to a user searching on that subject. Sites with many videos about a single subject can group these videos together on a top-level page, often known as a gallery. This can make it easier for users to find exactly what they're looking for. In this case, you can use a Sitemap to tell Google the URL of the gallery page on which each video appears.


You can specify the URL of the gallery level page using the optional tag <video:gallery_loc> on a per-video basis. Note that only one gallery_loc is allowed per video.

For more information on Google Videos, including Sitemap specifications, please visit our Help Center. To post questions and search for answers, check out our Help Forum.

Webmaster Level: All

As a search company, we at Google try to develop scalable solutions to problems. In fact, Webmaster Tools was born out of this instinct: rather than fighting the losing battle of trying to respond to questions via email (and in multiple languages!), we developed an automated, scalable product that gives webmasters like you information about your sites and lets you handle many requests yourself. Now you can streamline the crawling of your site, improve your sitelinks, or clean up after a malware attack all on your own.

Of course, our Help Forum still gets hundreds of questions from site owners every week — everything from "Why isn't my site in Google?" to very specific questions about a particular API call or a typo in our documentation. When we see patterns—such as a string of questions about one particular topic—we continue to use that information in scalable ways, such as to help us decide which parts of the product need work, or what new features we should develop. But we also still answer a lot of individual questions in our forum, on our blog, and at industry events. However, we can't answer them all.

So how do we decide which questions to tackle? We have a few guiding principles that help us make the most of the time we spend in places like our forum. We believe that there are many areas in which Google’s interests and site owners’ interests overlap, and we’re most motivated by questions that fall into these areas. We want to improve our search results, and improve the Internet; if we can help you make your site faster, safer, more compelling, or more accessible, that’s good for both of us, and for Internet users at large. We want to help as many people at a time as we can, so we like questions that are relevant to more than just one person, and we like to answer them publicly. We want to add value with the time we spend, so we prefer questions where we can provide more insight than the average person, rather than just regurgitating what’s already written in our Help Center.

The reason I tell you all this is because you can greatly increase your chances of getting an answer if you make it clear how your question helps us meet these goals. Here are some tips for increasing the likelihood that someone will answer your question:
  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.
Bonus tip: Are you more comfortable communicating in a language other than English? We have Webmaster Help Forums available in 18 other languages; you can find the list here.

Webmaster Level: Advanced

Warning: This specific configuration of rel-alternate-hreflang markup has been replaced by the general guidelines for multilingual and multi-regional content. Please see using hreflang for language and regional URLs for our current recommendations.


If you have a global site containing pages where the:
  • template (i.e. side navigation, footer) is machine-translated into various languages,
  • main content remains unchanged, creating largely duplicate pages,
and sometimes search results direct users to the wrong language, we’d like to help you better target your international/multilingual audience through:

<link rel=”alternate” hreflang="a-different-language" href="http://url-of-the-different-language-page" />

As you know, when rel=”canonical” or a 301 response code is properly implemented, we become more precise in clustering information from duplicate URLs, such as consolidating their linking properties. Now, when rel=”alternate” hreflang=”x” is included in conjunction with rel=”canonical” or 301s, not only will our indexing and linking properties be more accurate, but we can better serve users the URL of their preferred language.

Sample configuration that’s prime for rel=”alternate” hreflang=”x”

How does this all work? Imagine that you’re the proud owner of example.com, a site called “The Network” where you allow users to create their very own profile. Let’s say Javier Lopez, a Spanish speaker, makes his page at http://es.example.com/javier-lopez:


Because you’re trying to target a multilingual audience, once Javier hits “Publish,” his profile becomes immediately available in other languages with the translated templates. Also, each of the new language versions is served on a separate URL.


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

Background on the old issue: duplicate content caused by language variations

The configuration above allowed visitors speaking different languages to more easily interpret the content, but for search engines it was slightly problematic: there are three URLs (English, French, and Spanish versions) for the same main content in Javier’s profile. Webmasters wanted to avoid duplicate content issues (such as PageRank dilution) from these multiple versions and still ensure that we would serve the appropriate version to the user.

A new solution for localized templates

First of all, just to be clear, the strategy we’re proposing isn’t appropriate for multilingual sites that completely translate each page’s content. We’re trying to specifically improve the situation where the template is localized but the main content of a page remains duplicate/identical across language/country variants.

Before we get into the specific steps, our prior advice remains applicable:
  • 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.
For the new feature:
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.
Once the steps are completed, the configuration on “The Network” would look like this:
  • 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" />

Results of the above implementation
  • 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.

To recap (one more time, with feeling!)

For sites that have their template localized but the keep their pages’ main content untranslated:

Step 1: Once you have the canonical picked out you can use either rel=”canonical” or a 301 (permanent redirect) from the various localized pages to the canonical URL.

Step 2: On the canonical URL, specify the language-specific duplicated content with different boilerplate via the rel=”alternate” link tag, using its hreflang attribute. This way, Google can show the correctly-localized variant of your URLs to our international users.

We realize this can be a little complicated, so if you have questions, please ask in our webmaster forum!

Webmaster Level: All

Webmasters, you may notice some changes in you Search queries data due to the launch of Google Instant. With Google Instant, the page updates dynamically to show results for the top completion of what the user has typed, so this means people could be seeing and visiting your website much faster than before, and often without clicking the search button or hitting “enter.”


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.

With Google Instant, you may notice an increase in impressions because your site will appear in search results as users type.


Impressions are measured in three ways with Google Instant:
  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.
To give an example, let’s say your site has lots of impressions for [hotels] and [hotels in santa cruz]. Now, because Instant is quickly fetching results as the user types, the user could see your site in the search results for [hotels] after typing only the partial query [hote]. If a user types the partial query [hote] and then clicks on any result on the page for [hotels], that counts as an impression for your site. That impression will appear in Webmaster Tools for the query [hotels]. The term 'hotels' would also be included in the HTTP referrer when the user clicks through to visit your website.

It’s likely that your site will still see impressions for queries like [hotels in santa cruz], but because Instant is helping the user find results faster, your site may see an increase in impressions for shorter terms as well.

Let us know if we can help you better understand how these changes impact Webmaster Tools, measured Search queries and impressions, CTR, or anything else. We’d love to hear from you in our blog comments or Webmaster Help Forum.

Webmaster Level: All

Now there’s a new way to see just the messages for a specific site. A new Messages feature will appear on all site pages. The feature is just like the Message Center on the home page, except it‘ll show only messages for the currently selected site. This gives you more freedom to choose how you want to view your messages: either for all your sites, or for just one site at a time.


Alerts (formally known as SiteNotice messages) will now be more prominent in the Message Center. These messages tell you about significant changes we’ve noticed related to your site which may indicate serious problems. For instance, alerts may warn you about an increase in crawl errors, an increase in 404 errors, or about possible outages. With their newfound prominence comes a new name: what used to be “SiteNotice messages” will now simply be known as “alerts.”

Messages containing alerts will be marked with an icon to make them quickly distinguishable from other messages. Each site’s Dashboard will display a notification whenever the site has unread alerts. The Dashboard notification will lead to the new site Message Center with a filter enabled to show only alerts for the current site.


You can also enable the alerts filter yourself. On the home page, enabling the alerts filter across all your sites is a great way to see alerts you may have missed and may help you find problems common across multiple sites. Even with these changes we recommend you use the email forwarding feature to receive these important alerts without having to visit Webmaster Tools.

We hope these new features make it easier to manage your messages. If you have any questions, please post them in our Webmaster Help Forum or leave your comments below.

Webmaster Level: All

Since the initial roll-out of rich snippets in 2009, webmasters have shown a great deal of interest in adding markup to their web pages to improve their listings in search results. When webmasters add markup using microdata, microformats, or RDFa, Google is able to understand the content on web pages and show search result snippets that better convey the information on the page. Thanks to steady adoption by webmasters, we now see more than twice as many searches with rich snippets in the results in the US, and a four-fold increase globally, compared to one year ago. Here are three recent product updates.

Testing tool improvements

Despite the healthy adoption rate by webmasters so far, implementing the rich snippets markup correctly can still be a major challenge. To help address this, we’ve added new error messages to the rich snippets testing tool to help you better identify and fix any problems with the markup.


If you’ve added markup in the past but haven’t seen rich snippets appear for your site, we encourage you to take a few minutes to try testing the markup again on the updated testing tool.

Rich snippets markup for breadcrumbs

Last year, Google announced a modification to search results to begin showing site hierarchies (typically referred to as "breadcrumbs") rather than standard URLs in cases where it helped users to better understand a website:


We are now adding support for a Breadcrumbs markup format that allows webmasters to explicitly identify the breadcrumb hierarchy on their pages.

If the breadcrumbs UI is already showing for your site, we'll continue to show it even if you don't do the markup, so don't worry about any existing UI disappearing. Note that this new format is experimental. Based on feedback and on other available standards, this format may be modified or replaced in the future. As with other rich snippet types, while markup helps us to better understand the content on your site, it does not guarantee that the breadcrumbs UI will be shown for your web pages in search results.

Events

In January, we added support for rich snippets for events. If a web page containing events listings showed up in search results, up to three links to specific events could be shown in the search result snippet.

This works well for general queries like [concerts in seattle], but we also wanted to improve the search experience when searching for a specific event. We will now show rich snippets when pages containing a single event show up in search results. Single event rich snippets now contain the date and location of the event:


For instructions on adding events markup, refer to the events page in the rich snippets documentation.