That is a question I have to wrestle with weekly with global websites trying to explain why companies need to do something only to have them point to either a larger company or a random article that is doing or advocates doing it the way they want despite significant evidence or even a written standard not to do it that way.
In a post on X last week, Mike Blazer asked the recurring question about using es-419 in hreflang and if the further adaptations implemented in Google Drive’s hreflang XML sitemap were legit.
This prompted Gianluca Fiorelli to respond on X, indicating Google has confirmed this is not a valid language and region string multiple times at conferences and on social media. This was followed by the obligatory response referencing a 5-year-old article from Dan Taylor suggesting the es–419 is valid.
Ironically, using the further extended es-419 code was the least of their concerns with this hreflang implementation. Scroll to the end for the other and bigger problem with the implementation.
Gianluca also posted the question on LinkedIn, asking Google for confirmation.
John Mueller from Google responded that the documentation had stayed the same and that if they had made a change, they would let people know.
John further stated that you should not follow what big companies do. Interestingly, my survey earlier this year of why companies use incorrect hreflang codes indicated that 36% of companies with errors copy the implementation of a larger competitor. I am very tempted to also classify this response as a “Do as we say, not as we do,” but more on that in a moment.
<Rant> Please Just Say Yes or No </Rant>
In my extensive fixing hreflang errors course, I mentioned that Google fosters ambiguity when they respond with “it’s in the standards” or “the standard is clear” rather than a definitive yes or no. This allows many to interpret this lack of a definite no as a maybe or the classic SEO answer of “It Depends.” In my training, there are multiple examples of where a clarification opportunity was missed, further resulting in the perpetuation of the deviation from standards. In the case of es-419, whenever I parrot the party line that es-419 is not part of the standards, I always get shown the hreflang tags using the code on the very page where the hreflang standards should tell you if they are allowed or not. Note the red line in the screen capture: the Google Hreflang standards page uses es-419.
It is one thing to find a code like this used on other parts of Google, as in the case of the Google Drive and Andriod site, where you can say they are like every other dysfunctional and non-collaborating dev team, where they do what they want, enable-based on CMS rules, copy a competitor or use whatever blog post fits their needs. However, when it is on the page with the standard maintained by the team that wrote the standards and insists the standard is clear, it is hard to argue that it is not a valid element.
Is es-419 Part of the Hreflang Standard?
In my opinion, no, it is not part of the standards. The hreflang element was initially introduced by W3C to help browsers move between and process different languages more efficiently. A few years later, it was expanded to the link element to enable search engines to better understand the language of the content they were indexing. Google later adopted and promoted this function to allow multilingual websites to designate both the language and the region to prevent those pages from being considered duplicates, enabling the correct market version to be shown to searchers.
The W3C (the higher-level standard but does not control what Google does) requires a primary two-letter code from ISO-639 and ISO-3166 to designate the country for the language. Before the ISO3166 reference, note that any two-letter subcode is “understood to be an ISO-3166 country code. This two-letter code statement clarifies that they mean ISO 3166-1 Alpha 2, a list of two-letter country codes.
Google’s documentation similarly requires a language code from ISO-639-1 (two-letter) and an optional second code for a region (country), ISO 3166-1 Alpha 2. The country code is often this subcode where developers and SEOs differ in their interpretations.
Based on both W3C and Google documentation, the es-419 is not a valid code for hreflang implementations as the 419 value is not either an ISO 639 or 3166-1 value.
Where does the es-419 code come from?
The es is from ISO 639-1, the language code for Spanish, and the 419 code is from UN M.49, a set of three-digit codes developed by the United Nations for statistical analysis and later adopted by the IETF.
In 2006, the International Engineering Task Force (IETF) extended its international software development documentation using ISO-639 and ISO-3166 to allow subtags of three to eight letters. This set the foundation for expanding their guidelines to allow ISO 15924 four-letter script codes, UN M.49 three-digit geographical region codes, and ISO 639-3 and 639-5, which cover nearly all languages.
Because this is the internationalization standard learned by formally trained software developers, it has entered content management systems and, most recently, in-house-developed hreflang implementations. While using IETF standards is a perfectly valid programming and internationalization standard, Google does not currently support it for hreflang. Many have asked for an extension of both the language and country standards for languages not in the two approved standards and accommodating regional websites where some of the most frequent errors occur.
Trying to understand the large-scale adoption and fierce advocacy for this code forced me to investigate why developers insist this is the correct code. The familiarity with the IETF coding standards by developers helps explain why 27% of hreflang implementers say they did not read the W3C or Google standard and why 36% seem to be confident in copying code from a large competitor, where they may assume they have highly experienced developers.
Why Does Google Use it?
The knowledge of a parallel standard may explain why the Android team uses it on their website, as they reference it in the Android Developers SDK as well as Google Play Development Guides. The original Google Drive hreflang XML sitemap shown in the screen capture (hint) appears to have been created using the URL path to make the tags because that is how the internal CMS was structured.
That is the only way I can rationalize why they used it as a language code and appended the country. Anyone aware of the standard or looking at most other websites would have used the more common es-MX for Spanish Mexico, es-AR for Spanish Argentina, and es-US for US Spanish. The Google Search Central team may have the same problems with editing the CMS code or prioritizing tickets to change it, as it is based on hardwired CMS rules.
Google Drive’s Bigger Issue
It was surprising that none of the commentators on X or LinkedIn mentioned the more significant mistake being made. In the screen capture of their hreflang XML sitemap, it shows the hreflang alternate websites as https://www.google.com/drive/, but if you visit any of the URLs, you are 302 redirected to the referenced URL on https://workspace.google.com/. This effectively breaks the hreflang for the old website. Interestingly, they are using a 302 temporary redirect on what appears to be a permanent product rebranding. Why is this hreflang XML still live? Did someone forget to remove it, or since they are using 302 and Google keeps the original URL, they are using it for hreflang purposes? Even if they are the redirect and canonical on those pages, break the cluster. I am wrapping up an article on why Hreflang is critical during migrations and re-platforming due to the number of websites making this mistake.
After reviewing the new Workplace subdomain hreflang XML sitemaps, I found that they still use the same URL path with an es-419 code and an appended country code to designate the unique websites. They have corrected the hreflang elements for those specific market websites to the correct language and country codes and use es-419 exclusively for the Latin America region.
To be a stickler for details, the US would not be part of the es-419 block as the US is part of North America, a different region code.
Does the es-419 code Work?
I do not suggest using the es-419 as it is not part of the official standards. That being said, I have seen situations where this designation appears to work and has not. When it has not, it was typically due to one or more other errors. In the case of Google Workspace, while I did not check all fifty-two 419 markets, I did check multiple across the region using a VPN and Incognito. In every case, the es-419 regional website appeared in the local market search results.
Wrapping Up
I wish Google would be more restrictive and direct in their documented standards and best practices guidelines, adding a list of don’t do elements and clarifications. While the es-419 may be understood, Google acknowledging it as a valid hreflang element opens up a big problem regarding the applicability of all other code variations that need to be managed and validated by their systems. I agree that the current standard is too restrictive and challenges NGOs and religious organizations with hundreds of languages on their site, many of which are not represented by the two-letter codes. I have suggested multiple times that an International Search forum needs to be created to hash through the many complications of internationalization and at least document them and potential solutions. The challenges of international indexing, preventing duplicates, and cross-market cannibalization are significant, and the sooner we can address them, the quicker we can try to identify solutions.
