A website in two languages

What you are actually buying

A second language is not a translation job with some technical work attached. It is a second site that happens to share a design.

Everything doubles and stays doubled. Every page, every title, every description, every product, every article you publish from now on. The build is the small part. The part people underestimate is that in a year you will be maintaining two of everything, and if one of them falls behind, visitors can tell immediately.

Which leads to the only question worth asking before starting: is there somebody whose job it is to keep the second language current? If the answer is no, a partial second language is worse than none. A visitor who lands on an English page and clicks through to Spanish has learned something about how you operate.

Three ways to do it, and what each costs you

The choice is mostly about addresses, and it is easier to make than the internet suggests.

Subdirectories. `site.com/en/`. One domain, one accumulated authority, one thing to secure and renew. This is what we use and what we recommend for almost everyone.

Subdomains. `en.site.com`. Cleanly separated, useful if the two versions are run by genuinely different teams. The cost is that you are building authority in two places instead of one.

Separate country domains. `site.co.uk` and `site.es`. The strongest possible signal that a version belongs to a country, and the most expensive: separate domains to buy, renew, secure and build up from zero. Worth it when a market matters enough to have its own everything.

And the one nobody warns you about: a country domain carries its country with it permanently. A `.es` tells Google the site is for Spain, and there is no setting to change that. The country targeting option in Search Console exists only for generic domains and is disabled for country ones, precisely because the domain is already the signal. Nothing you write changes it. We know, because that is the situation this site is in.

The rule that invalidates everything if you break it

Search engines need to be told which pages are versions of which. That is the `hreflang` annotation, and it has one rule that catches almost everybody.

It has to be reciprocal, and every version has to declare all the others including itself. If the English page points at the Spanish one and the Spanish one does not point back, the pair is discarded. Not downgraded. Discarded, and the engine goes back to guessing which version to show.

That is why a half-finished setup performs worse than none: it looks like an instruction and functions as noise.

The other one worth knowing, because it is written wrong constantly: `UK` is not a valid region code. The code for the United Kingdom is `GB`. Google's own documentation is direct about what happens when you use the wrong one, which is that it ignores that part of the annotation. So `en-UK` does nothing at all, silently, and looks fine in the page source.

The case nobody writes about: when they are not translations

Every guide assumes each page has an exact twin. Often it does not, and this is where a real bilingual site gets interesting.

Our own case, decided recently. This site has a blog in Spanish and a blog in English, and the articles are not translations of each other. They are written for different questions, because the searches are not the same and neither is the market. There is no Spanish version of the article you might be reading.

So what do you declare? The two blog indexes are equivalents, because both are "the blog" regardless of what is inside. The individual articles declare nothing. Pairing two pieces that say different things is announcing a translation that does not exist, and that is the kind of contradictory signal an engine throws away entirely.

The rule that comes out of it, and it is more useful than any checklist: declare an equivalence only where a visitor switching languages would land on the page they expected. If they would land somewhere unrelated, there is no pair, and saying there is makes things worse rather than better.

What not to do

A translation widget on top of the existing site. It generates no addresses, so there is nothing for a search engine to index, list or rank. You have made the site readable for somebody already on it and invisible to everybody who is not. That is a usability feature sold as a market entry.

Machine translation left unreviewed. Not because it is bad any more, it often is not, but because it translates the words you already wrote for the other market. A page that converts in Spanish is built on assumptions about what the reader knows and worries about. Translated faithfully, those assumptions travel with it.

Automatic redirection by the visitor's location. It seems helpful and it does two harmful things: it stops a visitor reaching a version they deliberately asked for, and it can prevent crawlers from ever seeing anything but one version. Offer the choice, remember it, do not impose it.

Both languages on the same page. One address cannot rank for two languages. It ranks for neither.

Doing it without a plugin

Plugins exist because most sites run on a content manager that was not built for this, and they solve a real problem. Two things worth knowing before you install one.

The first is what it costs to run. Translation plugins are among the heaviest additions to a typical site, they sit in the request path for every page, and they are a permanent dependency: it has to keep working through every update of everything around it, or your second language breaks.

The second is that if the site is being built from scratch, this is not a feature you add. It is a decision about how content is stored, and made at the start it costs close to nothing. The text lives in one place with a language key, the routes are generated per language, and the annotations come out of the same data that generates the pages, so they cannot drift out of sync with each other.

That is how this site works. Two languages, one source of content, and the `hreflang` annotations generated rather than typed. Typed by hand, they are correct on the day they are written and wrong within a month.

When one language is the right answer

We build these, so it is worth saying when not to.

If nobody owns the second language, do not start. The half-maintained version does more damage than the missing one.

If you are not sure there is demand, the cheap test is your own analytics: look at where visitors already come from and which pages they leave fastest. If nobody is arriving from that market now, a translated site does not create them. A single well-aimed landing page might tell you within a quarter whether the full version is worth building.

And if you sell something that only ships to one country, a second language is a courtesy rather than a channel. Nothing wrong with that. It just should not carry a growth forecast.