In a previous post on how redirects cause Hreflang problems, we looked at how automatic redirection based on IP address geolocation or cookies can lead to bots being unable to crawl and access all your pages. In this post, we will look at other kinds of redirects and canonicals, and the Hreflang return tag problems they cause. Continue reading Redirects and canonicals cause many Hreflang problems
The Hreflang testing tool now has a new feature that many SEOs needed, especially those who work on large websites with thousands of URLs — exporting test results to an Excel file.
When you analyze a large number of errors, it’s not always easy to present all the information in a digestible format. I’m under no illusion that the web UI is great. It’s functional, and is best suited to see a long list of “All OK” results. But if there are errors — and especially if there are a large number of hreflang links per page, thereby increasing the likelihood of at least some errors — the web UI fails to deliver the results in a way that the user can actually do something about.
So the Export to Excel feature will be very useful. Here’s what you can expect in the Excel file, along with screenshots from a real Excel file generated when testing 110 Expedia pages for Hreflang errors. There are 4 worksheets in the Excel file: Continue reading Hreflang Tester — Export to Excel feature
Many websites try to make the user’s life easier by automatically redirecting her to the language/region version of their content that they infer based on IP address. But this approach is full of SEO pitfalls you should know about. In other words, the road to hell is paved with good intentions.
If you do automatic redirects, make sure there is a separate page (URL) that redirects to the appropriate page. No individual country/language URL should auto-redirect. In other words, do this:
Over the few months that the Hreflang testing tool has been live, I have noticed an erroneous pattern repeat itself in the URLs that SEOs submit for testing: many people use URLs with and without trailing slashes interchangeably. This is wrong.
http://www.example.com/de and http://www.example.com/de/ are technically 2 separate URLs. Google treats them as 2 separate pages. So does the test tool. The only situation where a URL with or without a trailing slash is the same is when specifying the root. For example, http://www.example.com and http://www.example.com/ are the same. Similarly, http://example.com and http://example.com/ are the same. And http://fr.example.com and http://fr.example.com/ are the same. In other words, it does not matter what the hostname is or whether it’s the root domain or a subdomain.
Multinational company has one website for each country it operates it. These websites use country-specific TLDs (e.g. example.au, example.ca, example.co.uk, example.de and so on). Websites contain information about the company’s various products. The product pages for .de are in German but the pages for .ca, .au, .co.uk and .us are all in English. So all of these pages have pretty much the exact same content. The company really wants its .au site to appear in SERPs in Australia and .ca in Canada and so on. So they create all these separate websites, use the same content on product pages on each site, and use Hreflang with “en-US”, “en-CA”, “en-GB” and “en-AU”.
What Google Does
Googlebot finds all these pages that are Hreflang’ed but are essentially duplicate content. So Google ignores the weak duplicates and ends up showing your .uk site in SERPs in Australia. What’s more, when Google does this sort of folding of duplicate pages into a different page, any Hreflang tags from those duplicate pages are ignored. So the Hreflang’ed pages get the missing return tag error in the search console. Continue reading Hreflang and Duplicate Content
One of the most common mistakes that occur in Hreflang implementations is the lack of return links. Google Webmaster Tools may report this as No Return Tags or Missing Return Tags.
As evident from questions in online forums, a lot of webmasters do not understand what this error means. Here’s a simple explanation.
Let’s say we have 3 pages that all have the same content but in different languages. Page A is in English, Page B is in Spanish and Page C is in French. This is how hreflang markup will appear on all 3 pages:
There are seemingly countless ways to screw up Hreflang implementation. While rel=canonical is a little more straightforward, webmasters and SEOs have been known to make mistakes there too. So using Hreflang and canonical tags together seems like a potential minefield of problems.
In this post, we will look at how to handle situations that involve both hreflang and rel=canonical together. This is the tweet that inspired this post:
— SEMrush (@semrush) October 21, 2015
Sometimes users of our Hreflang testing tool see an error like this and get baffled:
Invalid hreflang (en_US) found in HTML.
Why is en_US incorrect? Because the correct way to write a language code is with dashes, not underscores. The correct value is en-US. Continue reading What is a valid Hreflang?
There are many mistakes you could make when implementing Hreflang tags on your website. Via the online Hreflang testing tool, we try to catch as many of them as we can. Here’s a list, complete with how to fix each type of problem.
Continue reading What mistakes does the Hreflang Testing Tool look for?
What is Hreflang?
Explain to me like I’m five.
You will use Hreflang if—and only if—you have multiple pages (URLs) that all have the same content translated into different languages.
These pages do not all have to be on the same domain. For example, your English content could be at https://www.example.co.uk and your Spanish content could be at https://www.example.es. Or these pages can be on different subdomains, like en.example.com and fr.example.com. You could even create separate folders for each language, e.g. www.example.com/en/foo.html and www.example.com/de/foo.html.