How to run English, Spanish and Catalan versions of a site in Spain without them competing: structure, hreflang, canonicals and the four errors we see most.
Running a site in more than one language in Spain is mostly a structural decision, not a tagging one. Get the structure wrong and no amount of hreflang will save it.
If you are selling into Spain in English, Spanish and possibly Catalan, the question that matters is not which hreflang syntax to use. It is which pages exist, who each one is for, and what happens when two of them are close enough that Google has to choose. Hreflang is how you tell search engines about a decision you have already made. It is not the decision itself.
This guide covers the structural choice, where Catalan fits, the four hreflang errors we see most often on live sites, and how to tell whether your language versions are helping each other or quietly competing.
The decision that comes first: language or country?
Every multilingual setup answers one question, explicitly or by accident. Are you targeting a language, a country, or both?
Language targeting serves Spanish speakers wherever they are. One Spanish version, no regional split. Simple, cheap to maintain, and correct for most businesses whose offer does not change by country.
Country targeting serves people in Spain specifically, regardless of the language they read in. This is what you want when pricing, stock, delivery, legal terms or currency differ by market.
Both means a matrix: Spanish for Spain, Spanish for Mexico, English for Spain, English for the UK. Powerful, and the most common source of the problems we get called in to unpick, because the matrix grows faster than the content team can fill it.
For a UK or Irish business entering Spain, the honest answer is usually narrower than the ambition. One English version aimed at international and expatriate buyers, one Spanish version aimed at Spain, and nothing else until both are earning. Building the matrix first means maintaining thin pages in four variants and giving Google four weak candidates instead of two strong ones.
Three structures, and when each is right
Subdirectories
A structure like example.com/es/ inherits the authority of the main domain, is cheapest to run and easiest to migrate later. This is the right default for almost every business we work with, and it is what we would recommend unless there is a specific reason not to.
Subdomains
Something like es.example.com gives cleaner separation for genuinely independent operations with their own teams and infrastructure. The trade-off is that authority does not flow as freely, so each subdomain has more work to do.
Country domains
A .es domain is the strongest local signal and by far the most expensive path. You are building a new site's authority from nothing, in a market where you have no history. Worth it when the Spanish operation is a real business rather than an export channel, and rarely worth it before that.
The structural choice is much harder to reverse than any tag, which is why it belongs at the start of the conversation rather than the end. Our international SEO guide goes further into the trade-offs across markets.
Where Catalan fits
Catalan is where a lot of otherwise sensible setups go wrong, usually because it gets treated as a nice-to-have translation of the Spanish pages.
Two things are worth knowing. First, Catalan has a real and growing search presence in Catalonia, and Google handles it as a distinct language, not a dialect. Second, a large share of Catalan speakers search in Spanish anyway, particularly for commercial and technical terms, which means Catalan pages often compete for a narrower set of queries than the population figures suggest.
The practical read: Catalan is worth building when you have a physical presence, a local partner, or a brand position in Catalonia that a Spanish-only site would undersell. It is not worth building as a machine translation of the Spanish version, because a thin third variant adds maintenance and cannibalisation risk without adding demand. If you do build it, build it for Catalonia specifically, and give it content that a Spanish page would not carry, such as local delivery, local partners and local references.
Getting hreflang right
Hreflang tells Google that two pages are the same content aimed at different audiences, so it can show the right one rather than treating one as duplicate. It is a hint, not a directive, and it is unforgiving of small mistakes. Four errors account for most of what we find.
Missing return links
If your English page points at the Spanish page, the Spanish page must point back. Hreflang is bidirectional, and Google ignores one-way declarations entirely. This is the single most common failure, and it usually appears when a new language version is added and only the new pages get updated.
Hreflang and canonical fighting each other
Every page in an hreflang set must self-canonicalise. If your Spanish page carries hreflang annotations but canonicalises to the English page, you have told Google two contradictory things: treat these as separate regional versions, and also treat this one as a copy of that one. Google resolves the contradiction by ignoring the hreflang. We find this on a surprising number of otherwise well-built sites, usually because a plugin sets the canonical and a developer set the hreflang.
Wrong or invented codes
The language code is ISO 639-1 and the optional region code is ISO 3166-1 Alpha 2. So es for Spanish, es-ES for Spanish in Spain, ca-ES for Catalan in Catalonia, en-GB for English in the United Kingdom. There is no es-CAT, no en-EU, and no uk, which is the code for Ukrainian. Invalid codes are silently dropped.
No x-default
The x-default value tells Google what to serve when no version matches the user. Without it, a German visitor searching in English gets whatever Google guesses. With it, they get the page you chose. It costs one line.
Where you put the annotations matters less than being consistent. HTML head, XML sitemap or HTTP headers all work, but pick one and use it everywhere. Sitemap-level hreflang is usually easiest to maintain at scale because it lives in one file rather than across thousands of templates.
What actually cannibalises
Cannibalisation between language versions is less common than people fear. Cannibalisation between regional variants of the same language is very common indeed.
Spanish for Spain and Spanish for Mexico with near identical content will compete, because the content genuinely is the same and Google has no strong reason to prefer one for a given user. The fix is either to differentiate the pages meaningfully, through pricing, stock, delivery, examples, currency and local references, or to collapse them into a single Spanish page. A regional variant that says nothing regional is not a regional variant.
The same applies to British and American English, and it is the reason we usually advise against splitting English until there is something genuinely different to say.
Within a single language, the cannibalisation risk is the ordinary one: two pages targeting the same intent. A Spanish service page and a Spanish blog post both trying to rank for the same commercial term will split the signal, exactly as they would in English. Map one intent to one page and the problem does not arise.
Translation is not localisation
The part that decides whether any of this pays back is the content itself, and it is the part most likely to be under-resourced.
Translated keyword lists are the first thing to go wrong. The Spanish term with the volume is frequently not the direct translation of the English term you rank for. Keyword research has to be done natively in the target language, against the Spanish database, by someone who can tell the difference between a term people search and a term that is technically correct. We have seen whole content plans built on translated seed lists that turned out to target phrases nobody uses.
Then there is the register. Spanish business writing is not English business writing with different words. Formality, sentence length, how directly you can make a claim, whether you address the reader as tu or usted: all of it signals whether you are a local operator or a foreign site that ran the copy through a tool. Buyers notice, and so, increasingly, do the AI systems summarising you.
For English-speaking brands entering Spain, our market entry SEO playbook for Spain covers the sequencing of the wider launch, and the Barcelona market page sets out how we work with brands on the ground there.
How to tell whether it is working
Four checks, run monthly for the first two quarters.
First, Search Console filtered by country. Impressions and average position for Spain specifically, not the global figure. A rising global average can hide a Spanish version that is going nowhere.
Second, which URL Google actually serves. Search a target Spanish term from a Spanish IP or with the country parameter set, and see which of your pages appears. If the English page shows for a Spanish query, the hreflang is not being honoured or the Spanish page is too thin to be preferred.
Third, the international targeting report and hreflang errors. Return link errors and unknown language codes surface here, and they are the ones that quietly disable the whole set.
Fourth, cannibalisation by query. Pull the queries where two of your URLs both earn impressions. That list is your work queue.
Questions we get asked
Do I need hreflang if the versions are different?
No. Hreflang exists to connect equivalent pages. If the Spanish site is a different offer with different pages, there is nothing to map, and you are running two sites rather than one multilingual one.
Does hreflang improve rankings?
Not directly. It improves which version is shown to whom, which usually improves click-through and engagement, which helps. But it will not lift a page that would not otherwise rank.
Can I use machine translation?
As a starting draft, increasingly yes. As the published version, no. Machine output is fluent enough to pass a skim and wrong enough on register and terminology to cost you the commercial terms. The economical approach is machine draft plus native edit, with keyword research done natively before either.
Should the Spanish version live on a .es domain?
Only if the Spanish operation is a real business with its own presence rather than an export channel. Otherwise a subdirectory on your existing domain will rank sooner and cost less to run.
What about Basque and Galician?
The same logic as Catalan, with smaller populations and thinner commercial search volume. Worth it when you have a genuine regional presence, not as a translation exercise.
The short version
Decide the structure before you write a line of Spanish. Keep the number of variants smaller than your ambition suggests. Make every variant self-canonicalise and point back. Research keywords natively rather than translating them. And treat Catalan as a market decision rather than a translation task.
Get those five right and hreflang becomes a maintenance job rather than a recurring problem. If you would like a read on an existing multilingual setup, or you are planning a Spanish launch and want the structure settled before the build, get in touch.