A multilingual site is not a translation, it is a structure

Most businesses with an international audience do exactly the same thing, and they do it with the best intentions in the world: they put two flags in the menu, run the whole site through a translation tool, hit save, and go for coffee feeling rather pleased, because the site is bilingual now. Am I lying? The result is not a bilingual site, it is a Greek site with English text on it, and, sorry to spoil the coffee, Google sees it exactly that way.

The difference is not a matter of taste. We are not arguing about whether the translation reads nicely or whether the translator was in a good mood that morning. A properly structured multilingual site answers four decisions that get taken before the first translation is written. Let us take them one at a time.

First decision: where your languages are going to live

Google documents four structures and, to its credit, does not hide the downsides. It writes them out itself.

For a small business the answer is almost always the subdirectory. It is easy to set up, low maintenance, and above all it keeps all the work under one domain rather than splitting it across three that each start from zero. Think of it as one house with three rooms, not three houses in three neighbourhoods. That is how this site is built: Greek at the root, English under /en/.

One detail that saves wasted effort: Google ignores old location meta tags such as geo.position or distribution. If someone offers them to you with the air of a well kept secret, they do nothing.

Second decision: hreflang, and the rules it will not negotiate

hreflang tells the search engine something very simple: that two URLs are the same page in another language. There are three ways to declare it: in the HTML, in an HTTP header, or in the sitemap. Pick one. One, not all three to be on the safe side.

Three rules that do not forgive mistakes.

Every version lists itself too. Not just the others. The English page declares “I am the English one” and “the Greek one is over there”. It sounds redundant, like introducing yourself in your own living room, but that is how it wants it.

Reciprocity is absolute. If page X points to Y, Y must point back to X. Otherwise, Google writes, the annotations may be ignored or misinterpreted. The reason is security, and a sensible one: without reciprocity, anyone could arbitrarily name their site an alternative version of yours. The search engine wants a handshake, not a wave from across the street.

URLs are written in full, including the transport method. Not relative paths.

There is also the reserved value x-default, the safety net for whoever matches nothing else. On this site x-default points at the Greek version, because that is the primary market.

The codes, where the most common mistake happens

The first code is the language, in ISO 639-1 format. It is optionally followed by a region code, in ISO 3166-1 Alpha 2 format. The structure comes from BCP 47. Language first, place second, never the other way round.

Three traps I have seen on real sites:

A bare country code. Google says it explicitly: you cannot declare a country alone, because it does not derive the language from it.

UK instead of GB. Codes reserved for other purposes, such as EU, UN and UK, are ignored entirely. For the United Kingdom the correct one is GB.

Codes outside the standards. Only what exists in the two standards is supported. Forms such as es-419 are not.

And a clarification worth making, because it gets sold wrongly: Google describes hreflang as a mechanism that helps it point users to the most appropriate version. It does not appear among the canonicalisation signals it documents, nor is it presented as a ranking factor. hreflang does not lift you up, it sends the right people to the right page. It is the usher showing you to your seat, not the star of the show.

Third decision: stop throwing people where you assume they belong

This is the most tempting mistake. I see a visitor from Germany, I throw them into German. Sounds clever, does it not?

Google explicitly recommends avoiding automatic redirection from one language version to another, and separately recommends not using IP analysis, because location analysis that way is difficult and generally unreliable. It suggests visible links so the user chooses. A radical idea, I know: asking the human what they want.

There is also a very practical reason. Googlebot usually crawls from the USA and sends requests without an Accept-Language header. If your site decides the language from country or browser preference, the search engine will only ever see one version, however many you built. You paid for five, you get counted for one.

And the human reason: the German tourist looking for a place on Naxos from a hotel in Athens does not want Greek because they happen to be here.

Fourth decision: what actually gets translated

Google determines a page’s language from the visible content. It says so plainly: it does not use code level information such as the lang attribute, or the URL. It reads the page. It does not take your word for it.

From that follows the worst case, which is sadly also the most common: the menus, buttons and footer get translated while the body stays in the original language. Google names this as a problem, and the canonicalisation documentation adds the decisive part: if only header, footer and other non critical text is translated while the main content stays the same, the pages are considered duplicates. Your English version is then not merely weak, it may not count as a separate page at all. A suit with new buttons sewn on is still the same suit.

On machine translation now, because I know you are thinking about it: it is not forbidden as a technique. The spam policies target generating many pages through automated transformations, with translation given as an example, where little value is provided to users. The test is the value the reader gets, not the tool you used. A machine translation that a human read and corrected is a different thing from a thousand pages nobody ever opened.

In practice, if you rent rooms or a boat

Two languages done well always beat five done roughly. If your audience is German and French, English alone is not enough, but half finished German does more harm than no German at all. Better to promise nothing than to make a promise anyone can see you did not keep.

And not everything needs translating. The pages that decide the booking, meaning rooms, prices, terms, location and contact, get translated properly and by a human. The blog can stay in one language, as long as it is not declared as another.

Why all of this gets decided at the start

So let us say it plainly, the way we began. A multilingual site is not the original plus a translation. It is a structure decided at the start: where the languages live, how they declare each other, who chooses, and what genuinely gets translated. Those decisions cost a few hours up front and a lot of money if taken later.

If you already have a second language and are not sure it is working, the check takes half an hour. Get in touch and I will tell you what the search engine sees, not what the menu shows.