Multilingual SEO architecture for clinics: TR/EN/AR hreflang mistakes and the fix playbook
The most common hreflang mistakes on TR/EN/AR clinic sites, canonical conflicts, and the right fix order: multilingual architecture with a single source of truth.
By Roozbeh Nazari · CEO
A clinic site targeting international patients typically publishes in at least three languages: Turkish, English and Arabic, often joined by Russian or Farsi. With the right architecture this variety is strength; with the wrong one it is silent loss: Arabic pages never getting indexed, the English page ranking in Arabic results, or two languages cannibalizing each other's traffic — symptoms that usually trace back to the same root. This article covers three things in order: the architecture decisions, the hreflang mistakes we see most often in the field, and the order in which to fix them.
Start with the architecture decision. For most clinics the right default is language subdirectories under a single domain: /tr/, /en/, /ar/. One domain carries earned authority across all languages and keeps the infrastructure in one place. Country ccTLDs send a strong local signal but each domain must build its authority from zero; subdomains add management overhead while weakening the consolidation advantage. Keep the language code consistent in URLs; Arabic and Farsi slugs written in their own scripts are not a problem — browsers carry them with percent-encoding. What matters is that every page has a single canonical form. If you are migrating an existing site into this structure, treat the URL change as a migration project in its own right: moving without a one-to-one 301 map per locale can pay for the architectural gain with months of lost rankings.
hreflang's job is to link the language and region versions of the same content; it is a signal, not a command. The syntax looks simple but combines two standards: ISO 639-1 for the language, optional ISO 3166-1 Alpha-2 for the region. "ar" targets all Arabic-speaking users; "ar-AE" only Arabic users in the United Arab Emirates. The most common conceptual mistake is treating a country code as a language: there is no language called "ae", and such a tag is silently ignored.
The mistakes we run into most often in the field: first, missing return tags — the Turkish page points to the Arabic version but the Arabic page does not point back, and Google treats the pair as invalid; this behavior is documented. Second, hreflang pointing to a redirect, a 404 or a noindexed page; if the alternate is unreachable, the mapping does not work. Third, canonical contradicting hreflang — canonicalizing all languages to the Turkish version while declaring alternates in hreflang tells Google "these are separate pages" and "they are all really one page" at the same time. Fourth, relative URLs; hreflang values must be absolute. Fifth, a missing x-default. Sixth, templates stamping tags for translations that do not exist; if a page has no Arabic version, no Arabic alternate should be declared.
x-default and the splitting of Arabic deserve extra care. x-default marks the version to show when no language matches; if you have a language selector page, point it there — otherwise the English version is usually a sensible choice. A common reflex in Arabic is opening a separate version per Gulf country: ar-SA, ar-AE, ar-KW and so on. If the content does not genuinely differ — pricing, contact details or regulations changing by country — consolidating into a single "ar" version reduces both maintenance load and the risk of competing with yourself. The same logic applies to the Farsi you may add later: start with a single "fa". Open a regional version only when you have real content differences and the maintenance capacity to feed it; every version you open is a new row in the hreflang matrix whose upkeep you now own.
Where you put hreflang is also a decision: link tags in the HTML head, or the XML sitemap. Both are valid; trouble starts when you use both at once. The two sources drift apart over time, and conflicting signals produce the most laborious class of errors to untangle. Pick a single source of truth: on a typical clinic site of a few hundred pages, managing it in the head is simple; when page counts reach the thousands, the sitemap side automates more easily.
hreflang alone is not enough for discoverability; language versions must also be connected with normal links. The language switcher in the header or footer should be built with crawlable a tags, not a JavaScript menu that carries no href; every page should genuinely link to its own alternates. On the sitemap side, the URLs of all languages must be listed completely; whether you use one sitemap per language or a single file, make sure all of them are submitted to Search Console. The shortest route to leaving a language version's discovery to chance is for the only path to it to be an uncrawlable dropdown.
On the detection side you need the right tools, because Search Console is not the help it used to be: the International Targeting report was removed in 2022, and GSC today offers no screen that directly reports hreflang errors. The practical method is to use a crawler like Screaming Frog and its hreflang reports to dump missing return tags, unreachable alternates and canonical conflicts, then confirm suspicious pages with URL Inspection. Fix order matters: align canonicals first, then complete the return tags, and add x-default last. Go in the reverse order and each fix can mask the previous one. In Screaming Frog, look at three reports in particular: missing return links, hreflang URLs responding with anything other than 200, and unsupported language codes. That trio surfaces most of the errors we see in the field in a single crawl; what remains usually hides in canonical alignment and template logic.
Language quality signals are as much a part of the architecture as the technical mapping. Every version should carry the correct html lang value, and Arabic and Farsi pages should use dir="rtl"; half-translated Arabic pages with an English menu weaken both user trust and the signal of which language the page serves. Machine-translated pages that never saw an editor are an added risk in YMYL areas like health; Google's quality evaluation framework looks harder at trustworthiness there. If your translation budget is tight, translating few pages well always beats translating many pages badly. A simple routine is enough to measure translation quality: each quarter, have a native speaker read a few randomly chosen pages per language and feed the correction notes back into the content calendar.
One final field note: this playbook is not a run-once job. As new service pages, blog posts and campaign pages are added, the errors come back; we recommend a full audit each quarter and spot checks on newly published pages in between. In SEO Evaluate's Technical SEO service, the multilingual audit is part of the standard scope; we handle hreflang, canonicals and the indexing layer in a single pass, because these three tend to break each other when fixed separately. Tie the audit output to a written change list too: which tag changed on which page, who approved it, when it went live. That record shows you in minutes, at the next audit, exactly what regressed.