Run a business in Spain as an international and you serve two worlds at once: Spanish locals who found you on Google Maps, and fellow expats who found you in a Facebook group. A multilingual website sounds like the obvious answer — and done right, it is. Done the usual way (English site + machine translation plugin), it quietly repels the exact local customers it was supposed to win. Here's how to do it properly, what it honestly costs in money and upkeep, and the case where one language is the smarter call.
The test: where does the money search from?
Before any technical talk, the only question that matters: in which language do your paying customers type their Google searches? Not "which languages do I speak" — where does revenue come from.
- Beach-town holiday rentals: bookings search in English, German, French. Multilingual isn't optional; it's the product.
- A neighborhood physio in a Spanish city: 90% of searches are in Spanish. English is a courtesy, not a channel.
- A gestoría serving expats: English is the differentiator — leading with it is the strategy.
Every language you add is content you must write, maintain, and keep in sync forever. Add languages where money searches, not where pride points.
Why machine-translated sites feel off (and cost trust)
Google Translate has gotten genuinely good, which tempts everyone into the plugin approach: build in English, auto-translate to Spanish, done. The result reads almost right — and that's the problem. Spaniards click "Contáctenos ahora mismo" (nobody says that), scan two more calqued sentences, and reach the correct conclusion: this business didn't care enough to speak to them properly. For a service business, where the website's whole job is trust, almost right is a negative signal — arguably worse than English-only, which at least is honest about who it's for.
The fix isn't hiring Cervantes. It's writing each language natively — short, natural sentences a local would actually say — rather than translating sentence-by-sentence. Our own site runs three locales (Spanish, English, Ukrainian) written as three texts with one message, not one text through three filters. Visitors can't articulate the difference; they feel it in whether they message you.
hreflang, in human words
The technical layer has exactly one concept worth knowing as an owner: hreflang. It's an invisible label telling Google "this page in Spanish and that page in English are the same content for different audiences — show each searcher their own." Get it wrong (or skip it) and three things happen quietly: English speakers land on Spanish pages and bounce, Google may treat your translations as duplicate content, and your Spanish rankings can cannibalize your English ones.
What to ask any developer, verbatim: "Are hreflang tags set for all language versions, are they reciprocal, and is there an x-default?" A competent answer takes one minute. A blank stare is also an answer — and it costs nothing to check now rather than re-index everything later. The rest (URL structure like /en/, language switchers that keep you on the same page, not the homepage) is craftsmanship a decent builder handles by default.
What it honestly costs
Money first: for our fixed-price builds, each additional language on a landing adds structure and native copy work — but the bigger line item is yours: someone has to produce and approve content in every language, at launch and at every future change. A price update touches two pages now. A new service touches four.
That ongoing tax is why the honest recommendation is often to launch with fewer languages than you think — the ones that pass the money test — and add later. Adding a language to a properly built site is straightforward; maintaining a stale, half-translated one is a permanent embarrassment. (For the wider setup context — domains, legal texts, and the rest of the Spain launch stack — see the starting a business in Spain checklist.)
When one language is the right answer
If 95% of your customers search in Spanish, a sharp Spanish-only site beats a mediocre bilingual one — every hour spent polishing the English version was stolen from the version that pays rent. Same logic reversed for expat-only services. The multilingual site is a tool for businesses genuinely straddling audiences; it's not a maturity badge. We'll say this plainly even though we build multilingual sites: don't buy languages you can't feed.
Frequently asked questions
Can't I just add a Google Translate widget?
As a courtesy layer for occasional foreign visitors — fine, it's free and clearly machine-made, so nobody's misled. As your actual second language version — no: it isn't indexed as proper localized content, it reads calqued, and it converts accordingly. A language either earns native treatment or isn't worth offering as "your" content.
Do I need Catalan/Valencian too?
Politically sensitive, commercially simple: apply the money test regionally. In some markets and sectors (public-facing, institutional) a co-official language builds real goodwill and reach; in others it doubles content for minimal search volume. Look at what your customers actually search — data over sentiment, in both directions.
Does a multilingual site rank worse because content is "duplicated"?
Not when hreflang is correct — Google explicitly supports translated versions and shows each user theirs. The duplication risk appears with sloppy machine translation and missing tags, which is one more reason the plugin shortcut costs more than it saves.
The short version
Add a language where paying customers search in it — nowhere else. Write each language natively (three texts, one message), never sentence-through-a-filter; make sure hreflang is reciprocal with an x-default; and budget the ongoing content tax before signing up for it. Our own three-locale site is the working example, and multilingual builds are part of the fixed pricing. Unsure whether your case passes the money test? Describe your customers in one WhatsApp message — sometimes the honest answer is "Spanish only, and better."