es and ca-ES-valencia), not style variants.Valencia has a linguistic situation that complicates SEO more than most agencies admit. A city business may need Spanish by default, Valencian for local connection and, in certain sectors, legal obligation, and English because tourism, the international community and port-related trade generate constant demand. Three versions of the same content, three small sites coexisting, and one mechanism — hreflang — that almost nobody implements entirely correctly.
This article covers exactly that: when a multilingual site is worth building, how to do it without cannibalising yourself, and above all how to measure whether each version is working — the part that is nearly always skipped and the one that determines whether the investment made sense.
The decision to translate a site gets made on intuition or on competitor envy with alarming frequency. It is a substantial investment — translation, perpetual maintenance, technical complexity — and it can be validated with data before spending anything.
Two checks are enough.
The country and language breakdown of your current data. If you already receive meaningful impressions from the UK, Germany, France or the Netherlands on commercial queries, demand is demonstrated. In local sectors such as accommodation, hospitality, dental clinics, renovations for foreign owners or holiday lets, this shows up on its own. It takes a minute in Search Console analytics, and it is first-party: not a tool estimate.
Who occupies the SERP in that language. Check in rank tracking who ranks for your translated queries. If the top 10 are international portals and aggregators, entry is expensive. If there are local businesses with mediocre websites, the window is open.
Translating the whole site at once. The sensible move is translating the five or six commercial pages your data points at, measuring for three months, then deciding. A complete multilingual site left to rot is worse than a well-maintained monolingual one.
There are three valid ways to separate languages. The choice matters less than consistency, but each has real consequences.
| Structure | Example | For | Against |
|---|---|---|---|
| Subdirectory | mydomain.com/en/ | All authority on one domain; cheap and simple | Weaker explicit geographic signal |
| Subdomain | en.mydomain.com | Clean technical separation | Authority splits; more maintenance |
| Own domain | mydomain.co.uk | Strongest country signal | Authority starts from zero; expensive |
For 95% of local businesses the answer is subdirectory. A city business does not need to separate national markets: it needs to serve people who are here or coming here, in their language. Splitting a small domain's authority across three properties is an efficient way to rank in none of them.
The central misunderstanding is worth dismantling. Hreflang does not improve rankings. It is not a quality or relevance signal. All it does is tell Google: "these URLs are the same page in different languages; show each user the right one." Its benefit is preventing an English-speaking user landing on your Spanish page and leaving, and preventing two versions competing with each other.
That said, it is implemented badly with remarkable consistency. Three rules account for nearly all failures:
Each version's canonical must point at itself, not at the Spanish version. Pointing every translation's canonical back at the original is the fastest way to erase your translations from the index, and we see it constantly on sites built with badly configured plugins.
If you want the tag block generated rather than hand-written, our hreflang generator produces ready-to-paste markup.
Here is a detail almost nobody handles correctly. To Google, Valencian is not a stylistic variant of Spanish: it is handled within Catalan, and the correct code for the Valencian variant is ca-ES-valencia. Labelling it es or inventing a code causes the entire hreflang set to be discarded as invalid.
| Version | hreflang code | Typical use |
|---|---|---|
| Spanish | es or es-ES | Main version and x-default in most cases |
| Valencian | ca-ES-valencia | Local connection; required in certain sectors |
| English | en | Tourism, international residents, export-facing business |
| No match | x-default | The version served when none of the others fit |
The practical question we always get: is the Valencian version worth it in traffic terms? The honest answer is that search volume in Valencian is low compared with Spanish, even within the region. That does not make it pointless, for two reasons: some sectors face an institutional or contractual requirement, and in categories with strong local identity it works as a signal of belonging that influences the decision even when it does not influence the ranking. If you build it, build it properly — unreviewed machine translation does more reputational damage than not having it.
Detecting browser language and redirecting automatically. It breaks crawling — the bot only ever sees one version — frustrates users who wanted something else, and replaces a user decision with an assumption. Offer a visible switcher and respect the choice.
An English version that is a literal translation of the Spanish one rarely works, and the reason is not linguistic quality but search intent.
A real example from our work with dental clinics in Valencia: the local patient searches for the neighbourhood plus the treatment, or the treatment plus a price. The international patient searches "dental clinic Valencia English speaking", "dental implants Spain cost" or "dentist Valencia tourist emergency". These are not the same questions translated: they are different questions, with different concerns — staff languages, price compared with home, insurance, immediate availability — that the Spanish page never addresses, because a local does not worry about them.
Same text, another language. Ranks poorly because it answers another audience's question.
Same page, same sections, content adapted to what that audience actually asks.
Pages that exist in one language only because demand exists only there. Perfectly valid.
A technical note on that last one: if a page exists only in English, do not force it into an hreflang group with a fake equivalent. Let it declare itself. Hreflang groups containing pages that are not genuinely equivalent create more problems than they solve.
This is where most multilingual projects fail quietly. Three versions launch, total traffic is watched, it rises slightly, and for a year nobody discovers that the English version gets eleven visits a month because of an indexing fault.
The minimum that must be separated:
| Metric | Why it must be split by language |
|---|---|
| Clicks and impressions by directory | The total hides a version that never started. Filter by /en/ and /va/. |
| Countries of origin | If the English version only draws visits from Spain, hreflang is serving nobody new. |
| Positions on the translated set | English queries are another market with other competitors. Separate tracking group. |
| Indexed URLs per language | The most common silent failure: the translation exists and never entered the index. |
| Conversion per language | An international visitor converts differently. Without this you cannot tell if the traffic is worth anything. |
The first four come out of the free Semalt layer in an afternoon: filter the analytics by directory, create a per-language query group in rank tracking, and check each section's crawling in the indexing log. After that, silent failures stop happening.
One architectural detail separates multilingual sites that work from those that stall, and it has nothing to do with hreflang: how pages link to each other within each language.
The wrong pattern, and it is the usual one, is translating five pages, hanging them off the language switcher and linking them from nowhere else. The result is a set of orphan pages: they technically exist, hreflang declares them, and they receive no internal authority whatsoever. Google reads them as exactly what they look like — secondary content that even you do not consider important — and ranks them accordingly.
The practical rule is simple: each language needs its own complete internal linking network. The English service page should link to the other English service pages, the English contact page and the English supporting content. Not to the Spanish equivalent. Mixing languages in internal linking muddles the signal and drops the user out of their version halfway through.
As for cross-language linking, the only connection needed is the switcher, and it must point at the equivalent page. Any other cross-reference — a Spanish article linking to an English service — should be exceptional and justified by context.
A quick check we always run: take a translated page and ask how many internal links point at it from within its own language. If the answer is "only the switcher", you know why it does not rank, and the fix costs an afternoon.
A language switcher that always lands on the homepage. The user is reading a service page, clicks EN, and arrives at the English home. Every language change loses the context. It should go to the equivalent page.
The translated version is in no sitemap. Content created, uploaded, and nobody updated the sitemaps or linked the new pages from anywhere. They exist and are invisible.
Plugin-generated hreflang tags nobody reviewed. Especially on installations with several language plugins where one overwrites the other and the page ends up with contradictory tags.
Mixed content. "English" pages with the form, cookie notice, buttons and footer still in Spanish. Google detects the dominant language and may classify it wrongly; the user simply distrusts it.
Unreviewed machine translation published as-is. Technically valid, commercially damaging. In health, legal or financial sectors it is an outright risk.
The country and language breakdown of your current traffic is in the free analytics. It is the data point that turns an expensive decision into an informed one.
Sign in to Semalt Hreflang generatorNot directly. It stops your own versions competing and stops users landing in the wrong language. The benefit shows in bounce rate and conversion, not in a position jump.
Subdirectory for almost every local business. Splitting a small domain's authority across properties is counterproductive.
ca-ES-valencia. Labelling it es or inventing a code invalidates the entire tag set.
As a starting point, yes; published without human review, no. In health, legal or finance the risk outweighs any saving.
Almost never. Translate the commercial pages and create original content in the other language when data shows concrete demand. A translated, outdated blog adds nothing.
A well-built multilingual site is no harder technically than a monolingual one: three hreflang rules, a correct canonical per version, and a switcher that keeps context. The hard part is everything else — deciding with data whether demand exists, localising rather than translating, and measuring each version separately so a fault does not go unnoticed for a year.
If you run a Valencia business with international customers and have never looked at your country and language breakdown, start there: connect your domain and give it twenty minutes. It is the cheapest way to find out whether you are leaving money on the table — or to save yourself an investment your data does not justify.
And if you want an existing implementation reviewed — the reciprocity failure is so common we almost assume it — get in touch: that review is part of the free initial audit.
Free analytics for Google Search, SERP rankings and AI answers - plus fast indexing for your new pages.
Sign in to Semalt semalt.comGet in touch for a free audit
