hreflang: how to publish your website in several languages without confusing Google
A practical hreflang guide for businesses with customers in Colombia and the USA: what it is, how to implement it, which URL structure to choose and the errors Google ignores.
Your store sells in Bogotá and also to Hispanic customers in Atlanta. Someone in the United States searches for your service in English and Google shows them your page in Spanish, or the other way around. The content exists in both languages, but the search engine does not know they are the same page.
hreflang is the way to tell it. Here is how to do it right and which errors make Google ignore it.
What is hreflang and what is it for?
It is an annotation that tells Google which pages are variants of the same content in another language or region. According to the Google Search Central documentation, it lets Search show the most suitable version to each person. Google clarifies that, even if you do not use it, it might find the versions on its own, but stating it explicitly is usually best.

One fact worth knowing: Google does not use hreflang or the lang attribute to detect a page's language, it does so with its own algorithms. hreflang only connects the versions to each other.
In which three ways is it implemented?
You can use HTML tags, HTTP headers or the XML sitemap, and Google treats them as equivalent. Choose just one: using all three adds nothing extra in Search.
| Method | Where it goes | When it fits |
|---|---|---|
link tags | In the head of each page | Small sites without control over headers |
HTTP Link headers | In the server response | Files that are not HTML, such as PDFs |
| XML sitemap | xhtml:link entries per URL | Sites with many pages |
If you already take care of your sitemap, as we explain in Search Console and sitemap, that is usually the tidiest route.
What rules does it have to meet?
Each version must list itself and all the others, and the pages must point to each other. These are Google's core rules:
- Self-reference: the list of annotations is identical on all versions, and includes the page itself.
- Reciprocal links: if two pages do not point to each other, Google ignores the tags.
- Full URLs: with the protocol, like
https://ejemplo.com/pagina, not relative paths. - x-default (optional): a fallback page for languages that match none of the versions, for example a language selector.
Common mistake: using the country code alone, like
COorUS. Google is clear: you cannot specify the country on its own. The language comes first and the region is optional (es,es-CO,en-US). Reserved regions such asEUorUKdo not work either: Google ignores them.
Which URL structure should you choose?
For most small businesses, subdirectories (tuweb.com/en/) are the simplest. Google compares four options in its guide to multi-regional sites:
| Structure | Main advantage | Main disadvantage |
|---|---|---|
Country domain (.de) | Clear geotargeting | Costly and targets a single country |
Subdomain (en.tuweb.com) | Easy to separate | You cannot tell whether it is a language or a country |
Subdirectory (tuweb.com/en/) | Easy and low maintenance | A single server location |
Parameters (?loc=en) | None highlighted | Not recommended |
If you are choosing a domain, first look at .co or .com: which to choose.

How do I keep my site from looking bad in each language?
Translate all the main content and do not automatically redirect based on browser language. Google recommends a single language per page in content and navigation, and avoiding side-by-side translations. If you only translate menus and leave the content in one language, the experience in results is poor.
On redirects, Google warns that sending the user to another version based on an assumed language can keep users and search engines from seeing all the versions. Googlebot usually crawls from the United States and does not send Accept-Language headers, so a dynamic switch can leave it with undiscovered versions. The way out: visible links to each language. And if you need to move URLs when reorganizing, review 301 redirects.
Heads up: localized pages only count as duplicates if their main content remains untranslated. Translating well is the best defense.
How do I check that it came out right?
Open each version and check that it lists all of them, itself included, with full URLs and valid codes. Google mentions that third-party validators exist, such as the Merkle hreflang tool, although it does not maintain or review them. Complement it with the titles and meta descriptions of each language.
In short
Your customer in Atlanta and your customer in Bogotá should reach the version they understand, without Google doubting which one to show. hreflang achieves it if each version lists itself and the others, with valid language codes and no redirecting by browser. If you want us to set it up for you, we do it in our SEO and GEO with AI service.
Frequently asked questions
What is hreflang?
It is an annotation that tells Google which pages are variants of the same content in different languages or regions, so it shows the most suitable one to each user.
Where do you put hreflang?
According to Google, there are three equivalent ways: link tags in the page head, HTTP Link headers or entries in the XML sitemap. Using one is enough.
What happens if the pages do not point to each other?
Google states that if two pages do not link to each other, the tags are ignored. That is why each version must list all the others and itself.
Can I use just the country code, like CO?
No. Google makes clear that you cannot specify the country on its own: the language code comes first and the region is optional, for example es-CO.
Should I redirect each visitor based on their browser language?
Google advises against it: it can keep users and search engines from seeing all the versions. It is better to add visible links to each language.
Do not stop at the theory: apply it to your business
We implement SEO and GEO with AI end to end, with your real operation. The first conversation is free.




