5 Reasons Your Hreflang Is Probably Broken

I had the opportunity to listen to Dan Taylor of the Salt Agency present his hreflang error research he had initially published on Search Engine Land at the International Search Summit in Barcelona.

He indicated that 31% of the international websites he reviewed had hreflang errors.  Based on Hreflang Builder’s day-to-day work and analysis of the top 100 most localized websites, the number is closer to 75%.  This is similar to similar research by Patrick Stox of Ahref, finding that 67% of websites using hreflang tags had errors.

So why do we still have these problems after more than ten years? I have been researching with various agencies, SEOs, and brands to understand how we can make so many of the same careless mistakes. While my analysis is not completed, here are some initial findings.

1. Lack of understanding of the purpose of hreflang

A while back, I wrote a post trying to explain the true and straightforward purpose of hreflang.

 Hreflang elements are a method for site owners to

1. Explicitly state the language and language region (country/market) of a specific webpage.
2. Indicate that a web page has one or more equivalent (alternate) URLs

Hreflang is just that simple; its purpose is to indicate a web page’s language and language region (market) and list alternate versions. This removes the ambiguity of where this page should be presented to searchers, allowing the New Zealand page (exact duplicate of Australia) to be shown in New Zealand rather than the Australian page.

If you are not using hreflang, then you leave it to the search engines to decide what to show in each market. Without a designated purpose (language/market), Google may view the page as duplicate and suppress it using another market page. This is common when you have multiple same-language versions of your websites with few attributes to indicate which market.

Misunderstanding #1 – Only Required on Home Pages

Some believe you only need hreflang on your home pages. Other “experts” have argued that adding hreflang clusters to all pages is “redundant” and only necessary on one version of the site, and the all-knowing Google will “learn” and “figure it out” and apply your wishes across all website pages.

This does not work as Hreflang is page-specific and not website-specific. When challenged, I asked if this was true and why Google showed an error in the International Search Report. Each page must list its alternates, and those alternates must reciprocate. This is one of the simple rules of hreflang implementation.

I also see many deployments that only tag the same language websites. They will use hreflang to list all their English websites but exclude other languages. Then, their Spanish sites list all Spanish versions but never overlap the languages. While most cannibalization happens in the same language, this will not solve the problem for product names and brands. Someone searching for New Balance 940 has not used a language or market attribute in the query. In many cases, the US or another more prominent market website may show up in the results, potentially discouraging searchers from clicking, especially if local retailers offer it in their language.

The other problem is when website owners try to stretch this definition and try to tag multiple pages to make it look global. I have seen a single website with 185 hreflang tags with the reason is they want to be global. With a single website, you are global. Hreflang is to remove the ambiguity between your alternate versions, not propel a single English version to the top of the SERPS globally.

Misunderstanding #2 – Overestimating Google’s Ability

Some English-only websites use the local language code in hreflang to denote it is a French language webpage and hope to rank for French searches in France. Search engines can understand language, which is worthless, but people still need to try. One of the biggest mistakes we see is launching a website targeting the 27 national markets of the European Union with a website in Euro currency and then tagging each page for multiple languages and countries. This is very common with regional sites for Latin America, APAC, and the Middle East using country ccTLDs for the regional site or trying to use a country ISO code for a region like the LA code for Laos for Latin America or ME country code for Macedonia for the Middle East.

2. Rushed Deployments

Often, a brand will identify a cannibalization problem between markets, and a senior executive mandates an immediate fix. In their rush to get it out, the team or agency may cut corners, deploy partially, use free solutions, and hack together a script that uses folders or language tags. A common problem is when a company has 50 products but not all markets sell, the team will insert or paste in a hreflang cluster representing every page. This script will add an alternate reference for every market despite the page not existing. This increases 404 or redirect errors and breaks the cluster. We have seen an uptick in scripts that use a folder structure as the language and country code identifier, incorrectly flagging China’s Simplified Chinese as CNSZH or creating an invalid region code like es-LatAM. I just wrote bout some of these errors with recent Shopify Deployments. https://www.hreflangbuilder.com/shopify-hreflang-challenges/

3. Because we can Versions and Aspirational Hreflang

Dan also found that 23% of the websites had “odd” combinations of language and countries. This typically happens when an e-commerce website translates content into multiple languages and releases those versions on every market. You end up with Arabic, Chinese, and Spanish pages in markets with few people who speak this language,

In one case, the websites added 5 million extra pages for Google to sift through, and without hreflang, which one would they choose to show? Many of these sites have told me they invested in the localization and want to use it. This is fine if you want to allow a user to view an English page in Arabic if they are on holiday in Fiji, but there is no need to have it indexed by Google. If a website wants to use hreflang tags, this can create hundreds of lines of code for the page.

Another challenge happens when sites are deployed with partial localization. During the build, the team will set hreflang tags to the local language and market, but the content is still in English or another language that does not match the hreflang settings. We call this aspirational hreflang, where tags are deployed, hoping the website grows into them.

4. Site Migrations & Dual CMS

Another significant issue is created when websites set up hreflang on one content management system and then deploy another in a phased approach. Since the systems cannot talk to each other, this breaks the clusters into smaller clusters on their respective platforms. We have solved this problem for websites using hreflang XML sitemaps, which can represent both versions. I have only recently seen hreflang on migration checklists. Unless someone owns this process, they may not even look for a solution, given all the other migration challenges. Some sites may want 18 to 24 months until all markets are deployed, even considering a solution resulting in significant cannibalization or errors.

5. No Ownership & Lack of Collaboration

The lack of primary ownership of Hreflang pretty much guarantees you do or will have problems with your deployment. Hreflang spans multiple stakeholder territories, making it a hot potato no one wants to own. In this case, many stakeholders want to own or decide how to deploy the solution. It impacts search engines, so the Search or Marketing team is involved, there is a technology component, so IT is involved and requires interacting with webpages, so DevOps is involved, and the impact s on cart abandonment and online sales so that is yet another stakeholder. This problem can be minimized with senior executive involvement at the global level. We have over a dozen potential projects in limbo for many months as agencies, dev teams, and markets agree on the best solution. The growth manager is often stuck in the middle while teams fight it out. Another problem comes from fixing the cannibalization problem. There is a market that is benefiting from the incorrect traffic. While it may not convert, they don’t want their numbers to go down, so they block solutions to fix this problem for the company. We had a project on standby for 14 months as they needed signoff from all 87 markets on the solution. Over this time, it has cost them millions in lost revenue, but without a global champion with authority to make a decision, it drags on, and the loss continues. 

Recommendations:

Look at your hreflang deployment to see if there are any errors.  You can use Screaming Frog to test your implementation. Ahrefs has a new Hreflang link graph visualization tool to test Hreflang. Ask your markets if they are aware of cannibalization. You can see this in Google Search Console reports, rank reports, and shopping cart bounce rates, especially if you filter by markets. The more complex your web infrastructure the more challenges you will have when deploying hreflang. If you have rushed a deployment or have not done an audit recently on its implementation and effectiveness, reach it would be time. As we face economic headwinds, we need to ensure we can convert everyone possible, and losing traffic and sales due to what is presented in search engines is preventable.