A clinic with patients who speak more than one language needs more than a translated menu. If a patient searches in Polish, they should land on the Polish page. If they search in English, they should land on the English one. Getting that right is mostly a matter of structure, and Google’s documentation on multilingual website SEO is specific about what that structure should be.
Short answer
Google needs a separate address for each language, a link between the versions, and no automatic redirects.
- Give every language its own address, such as / for English and /pl/ for Polish, and translate the real pages, not only the menu.
- Tell Google how the versions relate with hreflang annotations: each version points to all the others and to itself.
- Do not redirect visitors automatically by browser language or location. Let them choose, and let Google reach every version.
In plain wordshreflang is a note on each door: “this room also exists in Polish, down the corridor”. The door down the corridor has to say the same back, or the note is ignored.
One address per language
Google’s guidance is that each language version should have its own address. Putting languages on the same address behind a switch, a cookie or a script means Google can only see one of them. Simple structures work best. A language directory such as /pl/ is the easiest one to set up and to keep running: it is one site, one hosting plan, one set of settings.
Google works out the language of a page from its visible text. It does not use the lang attribute or the hreflang annotation for this, so the content on the page has to be in the language you want it to show up for.
Tell Google how the versions relate
With hreflang, you tell Google which version belongs to which language, so a patient searching in Polish sees the Polish page. A few rules that people often get wrong:
- Both directions. If the English page lists the Polish one, the Polish page must list the English one, and each also lists itself. Google can ignore annotations that are not reciprocal.
- Correct codes. Use ISO 639-1 language codes: English is
en, Polish ispl. A country code is not a language code, sogbis wrong for English; if the content really is for Britain, add the region:en-GB. - An x-default. Add an
x-defaultentry for visitors whose language you do not cover, usually your main or language-picker page. - Full addresses. Each annotation points to the full address of the other version, including the protocol.
- Where to put them. In the page head, in the HTTP header, or in the sitemap. Pick one place and keep it up to date.
Do not redirect by language or location
It is tempting to send visitors to the language of their browser or the country of their IP address. Google advises against automatic redirects or changing the content on the fly, because Google’s crawler may only ever see one version. Instead, show a visible language switcher on every page, one that links to the same page in the other language, and let the visitor choose.
Translate the pages that bring patients in
A clinic’s pages are not decoration. They are what a patient needs to decide: who the doctors are, what the services involve, what they cost or how pricing works, how to book and where to find you. If only the home page is translated, a patient who clicks through arrives at a page in a language they cannot read.
- Doctors and services. Translate them in full, with real names, titles and specialties, not machine-translated summaries.
- Contact and booking. The form, its confirmation message and the emails it sends should speak the same language the patient chose.
- Do not leave auto-translation unchecked. Google treats automatically translated text published without human review as a violation of its spam policies.
- No half-translated pages. A page that is part English and part Polish helps no one. Either translate it or leave it out of that language.
- Keep the pages in sync. When a price, a doctor or an address changes, it changes in every language.
What we do in practice
We built a website for a dental surgery clinic in three languages and moved a reproductive-medicine clinic to WordPress with several language versions. In both cases each language lives on its own address inside one site, and the language switcher links to the matching page in the other language.
Check before launch
Questions clinic owners ask
Do I need a separate domain for each language?
No. Google describes language directories (like /pl/) as a simple, workable setup: easier to set up and maintain, though everything sits on one server. Separate domains cost more to run.
Does the lang attribute tell Google the page language?
No. Google determines the language from the visible text of the page. Keep the attribute correct for accessibility and browsers, but do not rely on it for search.
Can I translate with a translation tool and publish?
Not without checking it. Google treats unreviewed automatic translations as a spam policy violation, and for a clinic a wrong word in a service description is worse than no translation.
Should visitors be redirected to their language?
No. Google advises against automatic redirects by browser language or location. Show a switcher and let people choose.
What if I have a page in only one language?
That is fine. Just make sure the pages that exist in several languages point to each other, and do not link to a language version that does not exist.
For your developer
- Structure. One site, language directories (for example
/pl/), a stable address for each translated page. - hreflang. Reciprocal annotations including self-reference and
x-default, with full addresses, in one place only (head, HTTP header or sitemap). Do not mix methods. - Codes. ISO 639-1 language codes:
en,pl. Add a region only where content really differs by region. - Switcher. A real link to the equivalent page in the other language, not a script that rewrites the current one. No automatic redirects based on
Accept-Languageor IP. - Canonicals. Each language version points to itself, not to the main language.
- Plugin choice. With a multilingual plugin, check that it outputs separate addresses, hreflang and a multilingual sitemap, and that string translations (forms, emails, buttons) are covered.
- Tracking. Keep booking and form events consistent across languages so you can compare them.
- After launch. Check the Pages report in Search Console and test single addresses with the URL Inspection tool.
If you would rather not do it yourself
We build clinic websites on WordPress with doctor and service pages, online booking and several languages. Tell us about your clinic: within two working days we send a structure review, an indicative timeline and a price, with no obligation. The price is fixed before work starts. See our clinic website page.