Website development for businesses in Spain

Why the language question in Spain has more than one right answer

In most countries a website's language is not a decision. There's a national language, possibly English alongside it for international audiences, and that's the whole conversation.

Spain works differently, and the difference is structural rather than cosmetic. Alongside Spanish, several regions have co-official languages with their own audiences, institutions and everyday use. A business in Barcelona, Valencia, Bilbao or Santiago faces a question that a business in Madrid simply doesn't — and the answer isn't the same for a restaurant serving its own neighbourhood as it is for a firm selling to clients across the country.

Add a third factor: on the coasts and islands, a large foreign-resident and visiting population searches in English, German, French or Russian, and for many businesses there they represent more revenue than local customers do.

So the honest position is that there isn't one correct configuration. There's a decision, and it belongs to the business rather than to whoever builds the site.

Why defaulting is the expensive version

What happens in practice is that the decision gets made accidentally. The site is built in whichever language was convenient — often whichever the developer worked in — and the others are postponed until later.

Later is where the cost sits. A site built for one language and then extended to two isn't a translation project; it's an architectural change, because language versions affect routing, URL structure, canonical relationships, content modelling and the entire administrative side of adding a page. Doing it at the start is close to free. Doing it eighteen months in usually means rebuilding.

The practical advice is the same regardless of which languages you land on: decide the full list now, even if you launch with one of them. Building the structure to accept a second and third language costs almost nothing when nothing exists yet.

Who your buyers actually are, which isn't always who you'd assume

Worth establishing before the language question, because it answers it.

A business in a Spanish city serving that city has one profile. A business on the Costa del Sol or in the Balearics may find that most of its enquiries come from people who don't live there yet — buyers researching property, relocation, services and schools from another country, months in advance. A business selling professional services nationally has a third profile again.

Each of those reads a website differently. Local customers check for local specifics and immediacy. Foreign buyers researching remotely read far more carefully, compare across borders, and increasingly ask an AI assistant before they open a single site — which means the facts on your pages get summarised before a person ever sees your design.

I've built for that last pattern directly: a property catalogue running in four languages, drawing buyers from more than twenty countries, nearly all of whom decided before ever arriving. Different country, same behaviour.

What I cover and what I don't

The work I do here is the structure, the build, the technical layer, the markup and the multilingual architecture, in English and Russian.

Spanish, Catalan, Galician and Basque content is not part of what I deliver. If your site needs any of them — and for most businesses selling within Spain it will — that's arranged on your side, and the structure I build accepts those versions without being rebuilt for them.

For a business whose customers are primarily local Spanish- or Catalan-speaking, I'm the wrong supplier for the content side and I'd rather say so at the first conversation. For a business selling to foreign residents, remote buyers or an international audience, the languages I work in are the ones your buyers are searching in.

What gets checked before anything ships

The part that's hard to advertise and easy to verify. Every language version is opened and read rather than assumed to work because the first one did. Layouts are checked in each script the site actually carries, on mobile conditions rather than on a fast connection at a desk. Structured data is validated against what the page actually says instead of being copied from a template. Every claim on the page is one that can be checked, because a claim that can't be is a liability the first time someone tries.

None of that is remarkable individually. What makes the difference is that it's done every time rather than when there's room in the schedule.