A business website in Polish, Ukrainian and English: hreflang without mistakes

A Warsaw company speaks three languages, its website speaks one

The front desk answers calls in Polish, Ukrainian and English, because that's who is on the other end of the line. The website usually lags behind: one Polish version, sometimes an English subpage with a translated menu, and a Ukrainian version — if it exists at all — sitting on its own with no technical connection to the rest.

The result is twofold. First, a customer searching in Ukrainian often never reaches your site at all, because Google has no signal that a Ukrainian version exists or what it corresponds to. Second, even when they do land on the site, they may see the wrong language version, because without correct configuration the search engine picks a page by its own signals rather than by your intent. An analysis of Warsaw business websites shows that gaps like this — not missing content — are what most often explain why customers don't leave inquiries: they land on the site, just not on the version that answers their question in their language.

What hreflang actually tells Google (and what it doesn't)

Hreflang is an annotation that tells Google about the existence of language or regional variants of the same page, so the search engine can show a visitor the version matched to their language or region. That's the whole job — hreflang doesn't translate content, doesn't improve its quality, and doesn't stand in for the translation itself.

Google does not detect a page's language from hreflang or the lang attribute

This is the most common wrong assumption: hreflang does not tell Google what language a page is written in. Google determines a page's language with its own algorithms, by analysing the actual content — not a declaration in the code. That has a practical consequence: if you mark a page hreflang="uk" while the text on it is still in Polish, hreflang will not fix that. Before touching any tags, make sure the content is genuinely in the declared language — not halfway, not just in the menu.

Three ways to implement it — one is enough

Google accepts three methods of signalling language versions. You don't need all three at once — one, applied consistently across the whole site, is enough.

Tags in the page head

The most common method for HTML pages: in the head section of every language version you place a series of link rel="alternate" hreflang="..." tags, one for every version including the page you're on. This works well for a handful to a few dozen pages — beyond that, the head section starts to get heavy.

HTTP headers and the sitemap

For files that have no head section — PDFs, for example — the language-version information can be sent as an HTTP header in the server's response. The third route is listing the hreflang relationships directly in the XML sitemap, which is convenient at scale, since you update one file instead of the code of every page. Which method fits depends on who maintains the site day to day: for a company website running on a single content engine, tags in the head are usually the simplest to keep consistent.

Rules that apply no matter which method you pick

Whichever method you choose, the same technical rules apply, as described by Google Search Central:

• every language version must list itself as well as all other versions — not just point to the others, but also declare itself;
• URLs must be fully qualified, including the https:// protocol — relative paths don't work;
• the language code follows ISO 639-1 (e.g. pl, uk, en), and the region — optionally — follows ISO 3166-1 Alpha 2 (e.g. pl-PL, when you need to distinguish region and not just language).

For three versions — Polish, Ukrainian and English — that means the Polish page's code must carry three tags: one pointing to itself, one to the Ukrainian version, one to the English version. The exact same set repeats in the code of the Ukrainian and English pages.

The x-default value: a page for languages you haven't listed

The x-default value in the hreflang attribute points to the page Google should show visitors whose language isn't covered by any of your listed versions — a German-speaking visitor, say, when you only have pl, uk and en. Most often x-default points to a language-selector page or to the company's default version, usually Polish.

x-default isn't mandatory, but without it, visitors outside your three supported languages reach the search engine with no clear signal about which version to show them — which raises the odds they land on some random subpage instead of the homepage. It's the same kind of failure as accessibility issues on a restaurant's ordering page: the visitor reaches the site, but can't easily find what they came for.

The mistakes that most often break hreflang

A hreflang setup is fragile — one missing piece in a single version can invalidate the rest.

Missing return links

This is mistake number one according to Google's documentation: if page X points to page Y as its language variant, page Y must point back to X. If even one pair of versions is missing that return link, Google may ignore the annotations — not just for the incomplete pair, but potentially for the whole set. A typical scenario: you add a new Ukrainian version and give it links to the Polish and English pages, but forget to update the existing Polish and English pages so they point to the new Ukrainian one too. Result: the new version never actually starts working the way it's supposed to.

The second common issue is a hreflang tag pointing to an address that no longer exists, or never did — for example after a URL restructuring that wasn't reflected in the tags. Google hits a 404 instead of the promised language version and treats the whole set with suspicion.

Translating only the menu is duplicate content

A common shortcut: translate the navigation, the footer and the "order" button, leave the rest of the text in Polish, and call it done as an "English version." From a search engine's point of view that isn't a separate language version at all — it's nearly identical content at a different address, which is duplicate content, something Google's SEO guide warns against, recommending you reduce this kind of repetition and use descriptive URLs.

rel="canonical" and when to use it

For duplicate or very similar pages, Google lets you indicate a preferred canonical URL, among other methods, with rel="canonical". That's a tool for a different problem than hreflang: canonical says "this is the same content, count only this address," while hreflang says "these are different languages of the same content, show each visitor their version." Mixing the two up — for instance pointing a canonical from the Ukrainian version back to the Polish one when the text genuinely differs — can hide the Ukrainian version from results instead of promoting it.

What you must translate, and what you don't have to

Not every page needs a complete translation from day one, but a few elements are mandatory the moment you declare a language version at all: service descriptions the customer needs to understand before contacting you, pricing or how pricing works, contact details, and terms of service. If those stay in Polish on the "English" page, that isn't an English version — it's a page with an English heading.

Writing that content directly in three languages from the start, rather than bolting on a translation later, is a copywriting job spanning the whole page (Copywriting): headlines, the offer and calls to action consistent in every version — not separate paragraphs sent to a translator without the context of the rest of the page. The same inconsistency problem shows up with the facts assistants read about a restaurant — a mismatch between versions hurts in every language, whatever the industry. A consistent company description in every version also supports GEO / AI visibility, since systems reading the web then see one story about the company, not three different ones. It's also worth making sure that spinning up more language pages without real content doesn't turn into the issue Google warns about in its guidance on generating content at scale — a page with no value for the user in that language won't help, even with technically correct hreflang.

Do it yourself: a page-by-language table and a return-link check

Before you call a hreflang setup finished, run the simplest possible audit: a table with key pages in the rows and language versions in the columns.

An empty cell means one of two things: either that language version doesn't exist and shouldn't have hreflang at all, or it does exist but someone forgot to add it to the set of mutual links — and that second case is the one that breaks everything.

You can work out how many links you need to check with a simple formula: mutual links = N × (N-1), where N is the number of language versions of one page. For three versions (pl, uk, en), each version points to the other two, so N-1 = 2, giving 3 × 2 = 6 directional pairs to verify: pl-uk, pl-en, uk-pl, uk-en, en-pl, en-uk. With four versions that would already be 4 × 3 = 12 directions — which is why adding a new language version is a good moment to re-check the whole table, not just add a row.

The last step is one sentence in your internal process: who updates every language version when pricing or the scope of a service changes. Without that, it's routine for the Polish version to carry the new price while English and Ukrainian still show the old one. The same kind of ownership question is worth writing down for process automation in a company in general — hreflang is just one of many places where a missing owner quietly breaks the result.

What it looks like when a system builds this for you

Publishing a new page looks different once hreflang isn't a manual checklist:

It works most reliably when hreflang for every pair is generated automatically from one source and return links are checked before publishing, so the mistake described above never reaches a live page. Correct hreflang is not a promise of better rankings — it's removing a technical obstacle that doesn't depend on how good your text is anyway. If you're building Websites and stores in several languages, the UI/UX design of the language switcher matters too — a visitor needs to reach their own language easily, not just the search engine, and a standalone Landing page for a per-language campaign needs the same discipline as the homepage. Making those translated pages visible in results is then a job for SEO and maps. See how it works in the websites offer (Websites and stores) or ask about your specific site.

Frequently asked questions

Does every language version need its own domain?

No. Hreflang works regardless of whether the language versions live on separate domains, subdomains (en.company.com) or subfolders (company.com/en/) — the only requirement is that each version has a full, stable URL and correctly lists the others.

What is x-default and when should I add it?

x-default is the hreflang value pointing to the page for visitors whose language isn't covered by any version you list. It's worth adding when you have, say, three versions (pl, uk, en) but still get traffic from other countries — x-default will send them to a language-selector page or a default version instead of a random subpage.

Will Google figure out on its own that my page is in Ukrainian?

Google determines a page's language by analysing the content itself, not from the hreflang tag or the lang attribute in the code. That means if a page is supposed to be Ukrainian, the text on it actually has to be in Ukrainian — the tag alone won't substitute for that.

What happens if I remove one language version from the site?

You then need to remove the links to it from every other version that used to point at it. Leaving a dead hreflang link to a page that no longer exists is one of the classic mistakes that can make Google start ignoring the whole set of annotations.

Is it enough to translate just the menu and the order button?

No — from a search engine's perspective that's still mostly the same content at a different address, a duplicate rather than a separate language version. At minimum, translate the service descriptions, pricing, contact details and terms — otherwise the declared language version has no real content to show.

How do I check whether hreflang on my site actually works?

The simplest way without external tools is to open the source code of every language version and manually check that it lists itself and all other versions with full URLs — exactly as in the "Do it yourself" table above. Missing even one return link is enough to break that whole pair.