Finding Your Project Champion
March 13, 2024Why is Hreflang So Annoying to SEOs?
May 10, 2024Why so many hreflang errors?
I am always amazed at the number of websites with major hreflang errors. Both Patrick Stox from Ahreaf’s and Dan Taylor’s recent research confirmed that most hreflang implementations are a complete disaster, with the majority of websites, 67%, having one or more errors.
I have been curious about this and have tried to reach out on Linkedin and other places to understand why. As a result of my recent LinkedIn poll, I have determined that “hreflang implementors just don’t care if hreflang is correct.
“81% hreflang implementors just don’t care if hreflang is correct or not.
Bill Hunt, Hreflang Builder
For those unaware, the most fundamental element of the hreflang syntax is to set the language of the page. The language must be noted as the ISO-639-1 language code. This is non-negotiable. Similar to setting a country that the language may be targeting. The country must also use a specific region code from ISO-3166-1. Google clearly states this in their documentation and, again, specifically, as one of the most common errors. The Ahrefs research indicated that the incorrect country or language occurred 5% of the time. You may say it is just 5%, but that represents nearly 19,000 websites with the error. Dan Taylor’s research found that 9% of websites had a language error, 2% had a region error, and even crazier, he found 23% had combinations that were not realistic representations of language regions, like the Chinese language for Zambia.
27% of respondents indicated they were unaware of the standard – how did this happen? Did they blindly trust someone to implement hreflang? Did they use some free tool that had an error? How would you even know the syntax without looking at some guide?
We might be a bit forgiving when the brand cannot control the error creation. This is the 18% that attributed using incorrect syntax to system failure. What is interesting, though, is that as I was working on the error section of the Implementing Hreflang Course with International Webmastery, I found that most CMS natively create one or more problems for hreflang due to how the folders or initial language and target market settings are implemented.
The answer that shocked and frustrated me was that 36% of the respondents said they simply copied a competitor. What if you copied one of the 19,000 that had it incorrect? It has always amazed me working with enterprises the number of SEOs that incorrectly that their major competitor must have their act together. Again, I was speechless that someone would blindly copy the code strings and swap URLs from another site, and implement it without any sort of verification.
The other interesting response was “We ignored the standard to match the site,” with some commenting that they knew it was incorrect, but that is either what their CMS was adding or how their site is structured, and “We needed to enter a code.” This latter statement adds a lot of clarity to what many have this mistake.
For example, Seagate has done this with their regional websites in the highlighted rows. They have three regional websites for EMEA (en-em) because the system took the first two letters of EMEA and created es-em. The second was their ASEAN (en-as) website, which had the same issues, taking the AS from ASEAN and making en-as. The problem is that AS is the country code for American Samoa. The third is the most common “don’t tell me what to do code,” the magical es-la representing their LatAM website. The problem is that LA is the country code for Laos, which predominantly speaks Laotian and not Spanish.
In this situation, Seagate has let their system set this automatically since their CMS uses the language and market settings embedded into the system. Since there is no region setting within the ISO standard and hreflang, either a decision was made or the system parsed the first letters as noted. Even once deployed, when an SEO diagnostic tool was run on the sites, this should have been flagged incorrectly. At that point, this mistake could have been cataloged as either a CMS mistake or we needed to set something.