How to get the new WordPress SEO 2.0 to Join Google's Knowledge Graph

The 'WordPress SEO 2.0' is the latest addition to the notorious YOAST SEO Plugin.
All what you have to do is to either download it, or if you already have it, just update it.


Once you do you will find this new feature which support Google’s new Knowledge Graph.

When Google has picked it up and shows a Knowledge Graph block for you or your company, it would look like this: (but it is not guaranteed of course)

The Grid | AI Websites That Design Themselves

Content is power. Power your content on The Grid. http://www.thegrid.io

This is not another do-it-yourself website builder. The Grid harnesses the power of artificial intelligence to take everything you throw at it - videos, images, text, urls and more - and automatically shape them into a custom website unique to you. As your needs grow, it evolves with you, effortlessly adapting to your needs.

The Grid's algorithms expertly analyze your media and apply color palettes that keep your messaging consistent and unique. The Grid also detects color contrasts, automatically adjusting typographic color to maximize legibility.

What's possible when an AI does all the hard work for you? You can get things done, even on the go. Drag-n-drop builders don't play nice with fingers on phones, but AI works perfectly, anywhere.

Never again change your content to fit your template or the latest hot mobile device. The layout changes as you add content, and adapts to look great and work flawlessly no matter where your users find you.

It’s as easy as that. Actually, it’s incredibly complicated, but The Grid figures it out so you don’t have to. 

Join the evolution today at http://www.thegrid.io.

Differences Between Responsive Design, Dynamic Serving, and a Separate Mobile Site

There are many ways to configure a website for all screens. Factors to think about include the cost, time to build, your available human resources and infrastructure, and the needs of your customers.

Whatever configuration you choose, as an underlying principle we strongly recommend that you serve all your sites from a single domain, like example.com. In particular, if your desktop site is hosted on example.com, don’t put your mobile site on a separate domain, like a.com/example.

Stay with a single domain and you’ll build brand and URL equity with your users. With that principle in mind, let’s look at the three basic ways you can build a mobile-friendly website: responsive design, dynamic serving, and a fully separate mobile site.

Responsive Design

Responsive web design (RWD for short) is a clever design technique that uses a single HTML code base for all platforms. That is, all viewing devices read from the same code on the same URL.  The content resizes itself to fit the screen being used, based on pre-defined breakpoints and fluid grids.

RWD requires solid up-front planning. Costs can be high at first, but once the device-specific strategy is set, maintenance can be less resource-intensive.

Pros:

·        One URL for all content. Using a single URL for a piece of content makes it easier for your users to interact with, share, and link to your content. It’s also easier for search engines to discover and index your content.

·        A streamlined user experience. Presentation of all content is customized, and device-specific features can still be used.

·        Flexible orientation. RWD naturally allows for landscape or portrait device orientation changes by users.

·        No redirects. Load time is reduced and performance increased.

Cons:

·        Careful planning required. Since all HTML is shared here, careful planning is a must to develop a truly custom and robust experience with optimal performance for each device and user.

Common mistakes to avoid:

·        Data bloat. Don’t let mobile users download full-size images meant for big screens and fast speeds. Try to reduce HTTP requests and minimize CSS and JavaScript. Load visible content first and defer everything else.

Who it’s for:

Businesses that are focused on offering a consistent experience and can plan holistically for all devices with a single web team. (Starbucks.com, BostonGlobe.com and Time.com all use this approach.) RWD can be expanded to fit new devices as they emerge, and the single URL is good for linking and sharing articles without confusion or redirects.

Dynamic Serving

In this method, the web server detects the type of device a visitor is using, then presents a custom page designed just for that device. Custom pages can be designed for any device type, from mobile phones and tablets to smart TVs.

Pros:

·        A custom user experience. Each user gets content and layout created just for their device.

·        Easier changes. Adjust content or layout for one screen size without having to touch other versions.

·        Faster loading. Your team can streamline content for optimal load times on each device.

·        Single URL. As with Responsive Design, Dynamic Serving keeps all your users on a single URL.

Cons:

·        Content forking. Multiple custom pages mean multiple sets of the same content. Unless you have a sophisticated CMS in place, keeping content up to date on all device-specific pages can be challenging.

Common mistakes:

·        Faulty device detection. Your servers will need to run scripts to recognize all available devices. This step prevents problems like the server sending a mobile-optimized site to tablet users. Your webmaster will need to keep the directory up-to-date and running smoothly to avoid bad detection or gaps in service. Another common mistake is that the server assumes a device orientation, most commonly portrait, but the user may be holding the device in a different orientation (ie landscape).

·        Changing experiences: Users will be confused if you have multiple sites and they appear radically different. While it’s important to customize for each screen size, your brand look and feel should be recognizable in all formats.

Who it’s for:

Dynamic serving is a resource-intensive solution for companies that make frequent changes to their website, and who often need to adjust display for one device, such as tweaking only their mobile site. A capable IT staff (or vendor) is a must to manage the different and possibly complex sets of website code required.

A Separate Mobile Site

A third option is to simply create a mobile site that’s separate from your original desktop site. Your system detects mobile visitors and redirects them to your mobile-optimized site (often using a sub-domain like m.yourname.com).

Only mobile users will see the separate mobile site. Users of tablets, Web-enabled TVs or other devices will still see your original desktop site.

Pros:

·        A custom user experience. This gives you the most freedom to create a separate mobile site that is designed only for mobile users.

·        Easier changes. Content or design changes can be limited to the mobile version of the site, with no effect on other devices.

Cons:

·        Multiple URLs. Sharing a web page requires careful redirects and integration between your mobile and non-mobile sites. Redirects also lead to longer page load times.

·        Content forking. Keeping two different sets of content can make data management more complex.

Common mistakes:

·        Faulty redirects. When a mobile user lands on a deep desktop page, make sure they aren’t redirected to your generic mobile homepage. Also important: avoid smartphone-only errors, where a desktop URL redirects to a non-existent mobile URL.

·        Missing annotations. The two-way (“bidirectional”) annotation helps Googlebot discover your content and helps our algorithms understand the relationship between your desktop and mobile pages and treat them correctly.

·        Inconsistent user experience: People who look at your smartphone site should recognize it as the same business they see on your desktop site. This prevents confusion and a bad overall user experience.

Who it’s for:

Businesses that for any reason need to manage their mobile site independently. For instance, some businesses may want to use a different vendor for mobile, or may want a mobile structure that simply wouldn’t be possible with RWD. Since setup is relatively easy and can be quite cost-effective, a separate mobile site can be good for small businesses with more basic site needs.

References:

1. http://www.google.com/think/multiscreen/start.html
2. http://www.feedthebot.com/mobile/ 
3. https://developers.google.com/webmasters/mobile-sites/
4. http://www.foraker.com/choosing-between-responsive-web-design-and-a-separate-mobile-site-to-improve-mobile-visitors%E2%80%99-experience/ 
5. http://mob.is.it/blog/why-separate-mobile-site-is-usually-better-than-responsive-design 

301 Redirect Old Domain Without Passing Link Juice or Referral Signals

If you're hit by Google algorithm's Penguin and tried your best to disavow all the "Bad" links coming to your site, but your site has not been recovered yet, then you might be thinking of starting a new website with clean backlinks portfolio and White Hat SEO.

Of course you do not want your visitors to go to the old abandoned site, and of course you cannot 301 redirect the old domain to the new one, or else you will be transferring all the harmful link signals with you.

So, the best technique to do (after you've decided to start a fresh site) is do this simple yet very effective technique:

1- get a new domain name to use as intermediary  (Example: www.oldsite2.com)
2- Add a Robots.txt file and make the root domain (of the intermediary site) Disallowed

User-agent:*
Disallow: / 

3- Redirect (301) the old domain to the intermediary.
4- Permananetly redirect (301) the intermediary to the brand new domain

More to do:

You can also:
1- Add a robots.txt file to the old site to deindex it from search engines (follow step 2)
2- Use Google's URL removal tool and remove all the URLS of the old site.

A Fresh Beginning:

Now it is a new opportunity to start fresh with a new domain, new content, and better strategy.

Short Story Long:

http://searchenginewatch.com/sew/how-to/2355513/youve-been-hit-by-penguin-should-you-start-over-or-try-to-recover
http://searchenginewatch.com/sew/how-to/2384644/can-you-safely-redirect-users-from-a-penguin-hit-site-to-a-new-domain

20 Reasons why Localization is Important to Website Conversion

Thanks to the global reach of the internet, website localization is one of the best things you can do to increase website conversions. By creating a culture- and language-specific version of your website for each demographic market you target, you become a truly international business. All businesses, even small online retailers, can benefit from localization. In fact, you can’t afford not to have localized websites, and here are 20 reasons why.

1. It offers global expansion and increased reach.

Although English is still the predominant language online, other languages, most notably Chinese, Spanish, French, and Arabic, are quickly closing the distance. Offering web content in additional languages and cultures helps you increase your reach and become a respected international business.

2. Localization helps you appeal to multicultural audiences.

Translation helps international visitors find and buy from you, but it doesn’t consider cultural differences and sometimes doesn’t convey your message or brand very well. Localization includes both cultural and linguistic concerns, helping you reach audiences in different cultures much better.

3. It increases web traffic.

Search engines rank websites with localized versions or pages higher than non-localized websites and return your website as a result more often. On top of that, local sites are more likely to link to you when you provide information in the local language. Increasing traffic is one of the three most important things you can do to boost revenue, and more traffic means more sales.

4. You get more traffic from regional and language-specific search engines.

These smaller search engines have much less competition because they’re small and most businesses don’t have localized websites to appear in results. This means it’s much easier for your localized websites to rank higher than your English website. The higher you rank and the more often your website appears in search results, the more traffic and sales you get.

5. Localization increases brand recognition.

When you translate your website into the language and culture of your target market, you show that you respect and value your audience. They in turn are more aware of your business than your English-only competitors because they see your website more often and more easily understand your message.

6. Localization increases website stickiness and sales.

Having a strong localization plan boosts your presence and sales in a targeted area, such as localizing in French and German to increase sales in Europe. Multiple studies have found that when users are presented with a website in their native language, they stay on the site twice as long and are four times more likely to make a purchase from it.

7. It increases overall ROI.

Increased traffic, conversions, and brand awareness also leads to increased trust, credibility, customer loyalty, and satisfaction, in turn leading to more conversions. Localization is also scalable for both your audience and your budget, delivering huge benefits for only a marginal additional cost.

8. Localization maintains low printing and content distribution costs.

Localizing your website increases reach without raising these costs a few ways. First, you can reuse much of the same content across multiple languages; second, translating your website into a new language and culture is scalable; finally, having a web presence costs the same no matter what language or culture. Having a localized website may also eliminate the need for direct mail such as catalogs and brochures in various languages.

9. It is a cost-effective virtual branch office or satellite location.

Instead of building a brick-and-mortar store or renting an office in an international location, your localized websites become those virtual stores by offering information, products, contacts, and everything else you can deliver digitally.

10. Localization lowers customer support costs.

By answering questions and providing information in a target market’s native language and culture, you give customers what they need online in the best format for them, which reduces the need for multilingual phone and chat support.

11. It allows you to target minorities in your own area.

Many countries have large subgroups with their own languages, cultures, and skyrocketing purchasing power, such as the Latino market in the USA. Creating localized websites for these groups helps you solidify your presence and boost sales in your own area.

12. Localization maintains brand image and voice across cultures.

The problem with straight translation is that it doesn’t consider cultural differences and doesn’t always maintain your branding message. Localization is better than translation because it considers communication, sales incentive, design, layout, and programming specific to each culture and area, so you don’t lose the integrity of your brand across languages.

13. You become a local business.

Localizing your website turns you into a local business, which boosts conversions because many people want to buy locally, you get more traffic from local keywords, and you have an easier time building brand awareness.

14. Localization makes your local marketing stronger.

When you have a website specific to a certain area’s language and culture, your local internet marketing efforts (including search engine optimization, directory listings, and social media) benefit from having a local resource to point visitors to.

15. It makes you more trustworthy and credible.

By using the area’s local slang, idioms, metaphors, and figures of speech, you can communicate with your target customers more easily and directly, reducing confusion and boosting your own reputation.

16. Localization appeals to more customers.

Most web users don’t buy products online in a language other than their own. By offering them that option, you attract more prospects and close more sales.

17. It means fewer abandoned carts.

Programming can be as much a barrier as language or culture. Localization includes proper programming to prevent backend problems such as forms that make it difficult to input personal and payment info. Fewer problems means more closed sales and higher average order value.

18. Localization makes payment easier.

When you enable local credit cards, shipping and tax codes, and buying practices, your localized websites attract customers that would shop elsewhere otherwise, boosting your ROI, conversions, and revenue.

19. It increases local sales.

Offering products, support, FAQs, and other information in your customers’ native languages makes them more likely to buy from you because they have all the information they need in a format they understand to make an informed purchase.

20. Localization increases revenue.

Most consumers care more about language than price. So even if they know they can find a product cheaper somewhere else, they are more likely to buy from you at full price if you have a localized website for them.

How to know where your visitors go when they leave your website?

How can I see which specific pages/URLs people visit after leaving my site? In other words, I can see the percentage of people that EXIT on a certain page, but I want to be able to see which links on an exit page they follow (i.e. what percent of the visitors to a certain page of our site click on each outbound link on our page)? Or are they just leaving our site without necessarily visiting an outside site we've linked to?

Short Answer: You add this code to your link so it looks like:

<a href="http://www.example.com/" onClick="javascript: pageTracker._trackPageview('/example');">Co name or link info</a>

Will show up in Google Analytics as a page view.

Detailed Answer: (From Google Support) 

You can customize your Google Analytics tracking code to find out when users click outbound links, or links that take users to a website other than your own.

This article gives you an example of how to set up outbound link tracking. This is a two-step process, and you need to follow both steps complete the process.

You must have Google Analytics account and the web tracking code set up before you can track outbound links. You should have a basic knowledge of HTML and JavaScript or work with a developer to complete the set up.

Step 1: Set up an Event to track outbound links

Event tracking is a way you can track user interactions that aren’t automatically collected by the Google Analytics tracking code snippet, including clicks to outbound links. Learn more about Event tracking.

You can copy and paste the example below into your own pages to set up Event tracking for outbound links. We recommend you put this script in your page headers, but not within the basic Google Analytics tracking code snippet.

When you set up an Event, you must define values for the Event components. The Event components define how the data appears in your reports. In this example, the Category, Action, and Label are defined (in bold). You can use these values, or change them and define your own values. Learn more about Event components or refer to our Developer Guides for more technical information on the Event tracking.

The changes you need to make to your web pages depend on which tracking code you’re using. See if you have Classic Analytics (ga.js) or Universal Analytics (analytics.js).

This example uses Event tracking for Universal Analytics. If you’re using Classic Analytics, refer to our Developer Guides for more information on how to track outbound links with Events using the ga.js JavaScript library.

<script>
/**
* Function that tracks a click on an outbound link in Google Analytics.
* This function takes a valid URL string as an argument, and uses that URL string
* as the event label.
*/
var trackOutboundLink = function(url) {
   ga('send', 'event', 'outbound', 'click', url, {'hitCallback':
     function () {
     document.location = url;
     }
   });
}
</script>

Step 2: Add the onclick attribute to your outbound links

After you have Event tracking set up (Step 1), you must also add (or modify) the onclick attribute to your links. This is how data from a specific link gets sent to Google Analytics.

Use this example as a model for your own links:

<a href="http://www.example.com" onclick=”trackOutboundLink(‘http://www.example.com’); return false;">Check out example.com</a>

Additional resources (for developers)

This example includes the hitCallback field, which tells Google Analytics when the user interaction is complete., and uses the trackOutboundLink() as the JavaScript function. This makes sure that you collect the interaction data before the user leaves your site.

For more information on how this works, refer to the hitCallback reference in our Developer Guides.

This tutorial describes how to track outgoing links using the NEW Google Universal Analytics.js code, commonly called Analytics.js or UA. If you are using the OLD ga.js code click here.

This guide describes how to track outgoing links using Google Universal Analytics or commonly known as Analytics.js - the NEW (since late 2013) tracking that Google provides it's webmasters.

If the tracking code you use on your website starts with

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function()

... then you are using the NEW Analytics.js code and you can continue reading below.

If however your tracking code starts with

var _gaq=_gaq||[];

... then you are using the OLD Google Analytics code, and you should refer to the other guide: Track outbound links with Google Analytics (ga.js)

The issue tracking outbound links

Since Google introduced the Asynchronous Tracking method, one of the most common questions is: "how do I track outgoing links"? The solution is quite simple, one has to track outgoing links as events (found in Google Analytics under Behavior - Events). The problem however is that it does not always work for everyone, the reason being that events are only recorded once a link is clicked. If that link takes you away from a page (such as an outgoing link in the same window), that tracking event often does not have time to register with the analytics server before the new page starts to load and the tracking request cancelled.

In order to ensure that tracking is done properly, we either have to ensure that the target window is a new window (eg: _blank), or delay the opening of the link by about half a second, giving your browser enough time to register the event and load the tracking url.

Automatically track outbound links

The best method of "auto-tracking" outgoing links is to automatically detect outbound links with JavaScript when they are clicked, and automatically track that event. That tracking event should first check to see whether that link is destined to open in a new window (target="_blank"), and:

• If yes, register the track, and open the link in the new window
• If no, register the track and delay opening the link by half a second, then proceed to open that link.

This method is by far the most robust, and simply means you need to include an external JavaScript file on your pages.

function _gaLt(event){
    var el = event.srcElement || event.target;

    /* Loop up the tree through parent elements if clicked element is not a link (eg: an image inside a link) */
    while(el && (typeof el.tagName == 'undefined' || el.tagName.toLowerCase() != 'a' || !el.href))
        el = el.parentNode;

    if(el && el.href){
        if(el.href.indexOf(location.host) == -1){ /* external link */
            ga("send", "event", "Outgoing Links", el.href, document.location.pathname + document.location.search);
            /* if target not set then delay opening of window by 0.5s to allow tracking */
            if(!el.target || el.target.match(/^_(self|parent|top)$/i)){
                setTimeout(function(){
                    document.location.href = el.href;
                }.bind(el),500);
                /* Prevent standard click */
                event.preventDefault ? event.preventDefault() : event.returnValue = !1;
            }
        }

    }
}

/* Attach the event to all clicks in the document after page has loaded */
var w = window;
w.addEventListener ? w.addEventListener("load",function(){document.body.addEventListener("click",_gaLt,!1)},!1)
  : w.attachEvent && w.attachEvent("onload",function(){document.body.attachEvent("onclick",_gaLt)});

Manually Track outbound links

If you are wanting to track links manually (ie: in the code), an outbound link on your website should look something like this:

<a href="http://outgoinglink.com"
   onclick="ga('send','event','Outgoing Links','outgoinglink.com')" target="_blank">Link Text</a>

What this will do (when clicked) is track an event called "outgoing_links" as "outgoinglink.com". This means that in your Google Analytics account, which has an "Event Tracking" section, you now get a category called "Outgoing Links" containing an action (and total recorded) of outgoing links. Please note the target="_blank" as this ensures your web browser is kept open and the event is able to register.

Tracking any other links

Using this new method, you can theoretically track anything on your website, including downloads, videos, etc. You just need to assign an "onclick" event with your own category and "description" (action), such as:

<a href="/myfiles/mypdf.pdf"
 onclick="ga('send','event','downloads','/myfiles/mypdf.pdf')" target="_blank">Link Text</a>

The Future of SEO is Taking your Visitors to Your Company's Kitchen

Many of you must have heard of Google's new R&D projects to emulate human interactions on website to base their ranking algorithm on the user experience and whether the visited site offered a perceived value or not.

That is why the future of SEO will not be keywords or backlinks but "Users"
Therefore, site owners need to offer a true user experience to their visitors by being more transparent with them. i.e. involving them in the kitchen :


So, Forget about the famous quote, attributed to Otto von Bismarck: 

Laws are like sausages, it is better not to see them being made.

How To Be More Transparent?

1. Add a company page.
2. Add images to your company page (let your visitors see you.)
3. Add team video. Let your visitors see and hear you and your team
4. Photos or video of your office. Let your visitors see where you work and what you offices look like.
5. Don’t hide your phone number. This is a huge red flag.
6. Integrate your social media accounts
7. Show customer reviews and testimonials
8. Embed a Google map of your office
9. Show a photo and name of your sales person on the sales or contact page
10. Don’t use stock photos of people in offices. Instead take real photos of your people in your offices.
11. If you sell services, then describe your process
12. If you sell products, then show how they get made

(I know a Toronto based SEO company called Powered By Search that has an animated photo of their office on the Main header on the Home Page showing visitors their employees while working.) 

Here are some extra guidelines from the Stanford Web Credibility Project: 

Resources:

1. http://credibility.stanford.edu/ 
2. http://en.wikipedia.org/wiki/Stanford_Web_Credibility_Project
3. http://blog.seogroup.com/the-most-important-website-trend-in-2014-is/

How to find a Broken Backlink? The 404 Analysis Method

You may ask a client, supplier, blogger or whatever to add a link to one of your pages to get some link juice or referrals, but they may do a typo and add a wrong link URL to your site that when clicked it ends visitors up on a 404 not found page. So, how can you know those bad links?!

Here are some ideas to track those links and report them:

1- In the header template of your 404 page, find this line in your Google Analytics Tracking Code: _gaq.push(['_trackPageview']); Then change it as follows: _gaq.push(['_trackPageview','/404error/?url=' + document.location.pathname + document.location.search + '&ref=' + document.referrer]); What's happening here is we're creating a virtual pageview that starts with /404error/ (you can name it anything you want) and then appending 2 made-up parameters to help us spot the source of the problem:

• · "url=" will catch the URL which a visitor attempted to access. 
• · "ref=" will catch the referring page. 

Here's what it will look like in your reports (when you do a search for "404error")

2- Another way is use Raven's GA Config tool. Simply add your GA account number then copy the Google Analytics tracking script just before the </head> tag on your 404 page (not your entire website). 

The code will be like this:

Asynchronous

<script type="text/javascript">

  var _gaq = _gaq || [];

 _gaq.push(['_setAccount', 'UA-XXXXX-X']);

  _gaq.push(['_trackPageview', '/404.html?page=' + document.location.pathname + document.location.search + '&from=' + document.referrer]);

  (function() {

    var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;

    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);

  })();

</script>

Traditional ga.js

<script type="text/javascript">

var gaJsHost = (("https:" == document.location.protocol) ? " https://ssl." : "http://www.");

document.write(unescape("%3Cscript src='" + gaJsHost + " google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));

</script>

<script type="text/javascript">

try{

var pageTracker = _gat._getTracker("UA-XXXXX-X");

pageTracker._trackPageview("/404.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer);

} catch(err) {}

</script>

3- More ways:

http://ralphvanderpauw.com/digital-analytics/google-analytics-best-to-track-404-error-pages/ 

Use rel="alternate" hreflang="x" annotations to Serve the Correct Language or Regional URL to Searchers!

The rel='alternate' attribute enables you to tell search engines that a web page is available in different language versions. For example, you could add the following to the head section of a web page if that page is available in English, German and French:

<link rel=”alternate” href=”http://en.example.com” hreflang=”en” />
<link rel=”alternate” href=”http://de.example.com” hreflang=”de” />
<link rel=”alternate” href=”http://.fr.example.com” hreflang=”fr” />

All other languages can be directed to the default version of your website:

<link rel=”alternate” href=”http://example.com” hreflang=”x-default” />

From Google Webmasters:

Some example scenarios where rel="alternate" hreflang="x" is recommended:

• You keep the main content in a single language and translate only the template, such as the navigation and footer. Pages that feature user-generated content like a forums typically do this.
• Your content has small regional variations with similar content in a single language. For example, you might have English-language content targeted to the US, GB, and Ireland.
• Your site content is fully translated. For example, you have both German and English versions of each page.

Using language annotations

Imagine you have an English language page hosted at http://www.example.com/, with a Spanish alternative at http://es.example.com/. You can indicate to Google that the Spanish URL is the Spanish-language equivalent of the English page in one of three ways:

• HTML link element in header. In the HTML <head> section of http://www.example.com/, add a link element pointing to the Spanish version of that webpage at http://es.example.com/, like this:

  <link rel="alternate" hreflang="es" href="http://es.example.com/" />

• HTTP header. If you publish non-HTML files (like PDFs), you can use anHTTP header to indicate a different language version of a URL:

  Link: <http://es.example.com/>; rel="alternate"; hreflang="es"

• Sitemap. Instead of using markup, you can submit language version information in a Sitemap.

If you have multiple language versions of a URL, each language page must identify all language versions, including itself.  For example, if your site provides content in French, English, and Spanish, the Spanish version must include a rel="alternate" hreflang="x" link for itself in addition to links to the French and English versions. Similarly, the English and French versions must each include the same references to the French, English, and Spanish versions.

You can specify multi-language URLs in the same domain as a given URL, or use URLs from a different domain.

It's a good idea to provide a generic URL for geographically unspecified users if you have several alternate URLs targeted at users with the same language, but in different locales. For example, you may have specific URLs for English speakers in Ireland (en-ie), Canada (en-ca), and Australia (en-au), but want all other English speakers to see your generic English (en) page, and everyone else to see the homepage. In this case you should specify the generic English-language (en) page for searchers in, say, the UK. You can annotate this cluster of pages using a Sitemap file or using HTML link tags like this:

<link rel="alternate" href="http://example.com/en-ie" hreflang="en-ie" />
<link rel="alternate" href="http://example.com/en-ca" hreflang="en-ca" />
<link rel="alternate" href="http://example.com/en-au" hreflang="en-au" />
<link rel="alternate" href="http://example.com/en" hreflang="en" />

For language/country selectors or auto-redirecting homepages, you should add an annotation for the hreflang value "x-default" as well:
<link rel="alternate" href="http://example.com/" hreflang="x-default" />

Supported language values

The value of the hreflang attribute identifies the language (in ISO 639-1 format) and optionally the region (in ISO 3166-1 Alpha 2 format) of an alternate URL. For example:

• de: German content, independent of region
• en-GB: English content, for GB users
• de-ES: German content, for users in Spain

Do not specify a country code by itself! Google does not automatically derive the language from the country code. You can specify a language code by itself if you want to simplify your tagging.  Adding the country code after the language to restrict the page to a specific region.  Examples:

• be: Belarusian language, independent of region (not Belgium French)
• nl-be: Dutch for Belgium
• fr-be: French for Belgium 

For language script variations, the proper script is derived from the country. For example, when using zh-TW for users zh-TW, the language script is automatically derived (in this example: Chinese-Traditional). You can also specify the script itself explicitly using ISO 15924, like this:

• zh-Hant: Chinese (Traditional)
• zh-Hans: Chinese (Simplified)

Alternatively, you can also specify a combination of script and region—for example, usezh-Hans-TW to specify Chinese (Simplified) for Taiwanese users.

Finally, the reserved value "x-default" is used for indicating language selectors/redirectors which are not specific to one language or region, e.g. your homepage showing a clickable map of the world.

Common Mistakes

Important: Make sure that your provided hreflang value is actually valid. Take special care in regard to the two most common mistakes:

In general you are advised to sign up with your site to Webmaster Tools. This enables you to receive messages in regard to wrong annotations.

Example configuration: Annotations in action

Example Widgets, Inc has a website that serves users in the USA, Great Britain, and Germany. The following URLs contain substantially the same content, but with regional variations:

• http://www.example.com/ Default page that doesn't target any language or locale; may have selectors to let users pick their language and region.
• http://en.example.com/page.html English-language homepage. Contains information about fees for shipping internationally from the USA.
• http://en-gb.example.com/page.html English-language; displays prices in pounds sterling.
• http://en-us.example.com/page.html English-language; displays prices in US dollars.
• http://de.example.com/seite.html German-language version of the content

rel="alternate" hreflang="x" is used as a page level, not a site level, and you need to mark up each set of pages, including the home page, as appropriate. You can specify as many content variations and language/regional clusters as you need.

To indicate to Google that you want the German version of the page to be served to searchers using Google in German, the en-us version to searchers using google.com in English, and the en-gb version to searchers using google.co.uk in English, userel="alternate" hreflang="x" to identify alternate language versions.

Update the HTML of each URL in the set by adding a set of rel="alternate" hreflang="x" link elements. For the default page that doesn’t target any specific language or locale, add rel="alternate" hreflang="x-default":

<link rel="alternate" hreflang="x-default" href="http://www.example.com/" />
<link rel="alternate" hreflang="en-gb" href="http://en-gb.example.com/page.html" />
<link rel="alternate" hreflang="en-us" href="http://en-us.example.com/page.html" />
<link rel="alternate" hreflang="en" href="http://en.example.com/page.html" />
<link rel="alternate" hreflang="de" href="http://de.example.com/seite.html" />

This markup tells Google's algorithm to consider all of these pages as alternate versions of each other.