Multilingual GEO: hreflang and International Visibility

A clinic's website has a TR/EN toggle sitting in the top right corner. You click it: the page does not reload, not a single character changes in the address bar, and the text turns into English where it stands. The site looks bilingual. In Search Console there is only one language. Ask ChatGPT the same question in English and that clinic appears in no answer at all.

There is no translation problem here. The English text has been written, it is sound, and it sits exactly where it should. The problem is a different one: that text has no address. A search engine and an AI assistant both recognise a page by its URL, index it by its URL and cite it by its URL. Content without an address is in the folder but not in the index.

If the distinction has to fit into one sentence: producing content in two languages and being visible in two languages are not the same job. The second one is a technical setup, and when it is skipped, every piece of second-language content you produced is treated in practice as if it had never been written. To be honest about it, the site publishing this article was in exactly that position when it was written: TR and EN lived at the same address and the language preference was stored in the browser. It has since moved to the setup described here — the two languages were split onto separate addresses and reciprocal hreflang declarations were added.

What keeping two languages on one URL actually costs

If the language choice is held on the client side — in localStorage, a cookie or in JavaScript — then every automated client that visits the site sees the default version of the page. A browser presses the button and the language changes; nothing that is not a browser ever presses it.

The consequences of this are not abstract. They can be counted one by one:

• There is no address to put in the sitemap. Because the second language has no URL, the sitemap stays in one language. The gap between the number of URLs you submit and the amount of content that actually exists disappears right here.
• hreflang cannot be set up. hreflang is a link built between two URLs. If the second URL does not exist, the other end of the link does not exist either.
• The second language never accumulates any authority. Every link that gets shared, every external link that arrives, goes to a single address. A separate link profile for your English page never forms at all.
• There is no target for a model to cite. The source list in an AI answer is a list of URLs. If you want to be cited, you have to hand over an address that can be cited.
• Measurement is switched off. In Search Console you cannot see which language showed up for which query, because in the engine's eyes there is a single page.

A language switch that runs on the server — that is, a setup which genuinely changes the address — solves every one of these items in a single move. The question is not the translation budget; it is an addressing decision.

Separate URL structures: three options and the cost of moving

There are three common structures, and the choice is usually less technical and more organisational than people assume.

For a small business the practical answer is usually the subdirectory. It is the cheapest to set up, it does not split the trust a single domain has accumulated, and it is the easiest one to reverse. We went through what has to be in place on the infrastructure side in detail in our GEO-ready website infrastructure guide for small businesses.

Settle one distinction at the outset: are you targeting a language or a country? /en/ points at a language; /en-gb/ points at a language and a country together. If you do not genuinely need the country breakdown, do not open it; every new breakdown means a new set of pages that has to be maintained and kept up to date.

Do not let the migration cost slip past you either. If you are changing an existing structure, you have to set up permanent redirects from the old addresses to the new ones, update your internal links and regenerate the sitemap. Skip the redirects and the addresses that were already indexed break; the change you made in order to gain something costs you what you already had. We covered separately how the address structure is part of the page plan, and how the second language is marked out at the planning stage, in our article on the page plan for a business website.

How hreflang is set up, and where it breaks

hreflang is a signal that says "the version of this page in that language is over there". It can be served from three places: the page's <head> section, the XML sitemap, or an HTTP header. For HTML pages, <head> is the most common route and the easiest one to audit.

<link rel="alternate" hreflang="tr" href="https://site.com/hizmetler/" />
<link rel="alternate" hreflang="en" href="https://site.com/en/services/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/" />

The setup has three conditions:

Reciprocity. If the Turkish page points at the English one, the English page is obliged to point back at the Turkish one. A one-way link is usually ignored in its entirety — the tag sits there in the file but does no work whatsoever. This is the silent failure you run into most often.

Listing itself. Every page also writes itself, in its own language, into the hreflang list. In a three-language set of pages there are three lines on every page, not two.

x-default. Where should a user go when they match none of the defined languages? You write the answer here: either a language selection page or the page for your main market. It is not mandatory, but if you leave it empty you have handed the decision entirely to the engine.

Its relationship with canonical deserves a heading of its own, because the mistake here is fatal. hreflang does not override canonical. Every language version has to point its canonical at itself. If the canonical of /en/services/ points at the Turkish page, what you have told the engine is "do not index this page, the original is over there". The English version then never gets indexed at all, and nobody works out why.

The remaining frequent mistakes as a short list: writing the language code in the wrong format (tr-TR, not tr_TR), mistaking a country code for a language code, giving a relative address (an absolute URL is required), pointing at an address that redirects or returns 404, and offering a page that carries noindex as an alternate.

Translation and localisation are not the same job

Rendering the text in another language is not the same thing as answering the question a user asks in that language. You can see the difference across five items:

• Currency and how prices are shown. Translating the number is not enough; whether prices in that market are written with or without tax, which currency is expected, and what the decimal separator is all change.
• Regulatory and compliance language. A reference to KVKK (Turkey's personal data protection law) finds no equivalent on an English page; the reader there expects GDPR. A reference to the wrong regulation burns trust faster than the rest of the text can rebuild it.
• Examples and cases. An example told through a local city, a local industry or a local institution loses its context once it is translated.
• Contact information. Phone format, time zone, working hours, preferred channel. WhatsApp is the norm in one market while email is expected in another.
• Social proof. Turkish reviews do not persuade anyone on an English page. What you need is a reference written in that language, coming from that market.

This is precisely where machine translation falls short — and the gap is not grammar, it is intent. People ask different questions in different languages. For the same service, a Turkish search turns around price and location, while a search arriving from abroad turns around process, accommodation and guarantees. Translating the text does not translate the question. We covered what this difference looks like in service exports, with concrete page structures, in our GEO for medical tourism article.

Machine translation can be used as a starting draft. The version that goes live has to be reviewed by someone who speaks the language, particularly for terminology and for the sentences that make a claim.

Why models drift to English sources on Turkish questions

This is an observation; we are not giving a measured rate, because we do not have one. But on technical and niche subjects, English pages show up often in the source lists of answers to questions that were asked in Turkish. The answer comes back in Turkish; its basis is in English.

The reason is not surprising: on these subjects the volume of English source material is far larger, far older and far more tightly interlinked. On the Turkish side, the number of pages that give a clean definition of a concept and stand on their own is comparatively small. The model picks the best basis it has in front of it; matching the language comes second.

The operational reading of this is an opportunity. Where the competition is thin is in quality Turkish content. A page that defines the concept in Turkish, gives the English term in parentheses as well, and opens with a paragraph that can be quoted on its own stands out more easily than the tenth English page on the same subject. Giving the term in both languages on the same page also helps entity matching: the model can tie "generative engine optimization" and "üretken arama motoru optimizasyonu" to the same thing.

We explained how to build this approach out subject by subject in our semantic content strategy and topic cluster article.

Let us write down its limit too: this tendency shifts with the subject, with the engine, and with how local the question is. On local service queries the picture can flip the other way. Asking a handful of questions by hand in your own field is more reliable than any guess.

Which pages are worth translating

Not all of them are. The decision criterion reduces to a single question: can you actually serve a request that arrives in that language? If the answer is no, translation produces searches you cannot answer.

The order of priority works like this:

1. The homepage and one single core service page. This is the second language's first test.
2. The contact and quote page. This is where demand lands if it comes at all; an untranslated form cuts the whole chain.
3. The three services that get the most questions. Do not guess which ones they are; look at the emails and messages coming in.
4. The page that explains your process and pricing logic. Uncertainty is where requests from abroad get stuck most often.
5. The blog — last, and selectively. Not the whole of it: the three or five subjects that market genuinely asks about.

There are also pages that should not be translated: articles specific to local regulation, local event and news announcements, campaigns valid only in Turkey, and city-based local service pages. Translating those builds an irrelevant pile in the second language.

One warning: a half translation is the worst option of all. A page whose menu is English and whose content opens in Turkish misleads the user and the engine at the same time. Translating five pages completely is better than translating fifty pages halfway. We spelled out how this works on product pages in our GEO for e-commerce article. Producing complete product data in every language of a multilingual store is solved on the e-commerce website setup side.

One business in two languages: entity consistency

On multilingual sites the most insidious mistake is the same business appearing to be two separate entities. This throws no error message at all; you simply end up with two weak profiles instead of one strong one.

The points to watch:

• The legal name is not translated. If "Yıldız Diş Kliniği" is written on the English page as "Yildiz Dental Clinic", there are now two names in play. The right way is to keep the legal name fixed and give the descriptive part in parentheses.
• The schema identity has to be shared. In Organization schema both language versions must use the same @id value. That states plainly that the two pages are describing the same entity.
• The sameAs list has to be identical. Social profiles, the map listing, industry directories — the same links in both languages.
• Address and phone in the same format. Write them in international format and keep them character-for-character identical across the two languages.
• Founding year, logo and tax information and other fixed data must not contradict each other between the two versions.

Setting up this layer, and the schema side of it, is a standard part of the GEO solutions we offer.

An implementation order for a small site

A reasonable roadmap for a ten-page site:

1. Make the decision: are you genuinely doing business in the second language? If not, this is as far as it goes.
2. Choose a subdirectory (/en/) and build a setup that runs on the server side.
3. Start with five pages: homepage, one service, contact, about, process.
4. Give every page a permanent URL and a canonical that points at itself.
5. Build the hreflang links reciprocally, and add x-default.
6. Regenerate the sitemap; every address in both languages should be inside it.
7. Turn the language button into a real link — its target should be the equivalent of the same page, not the homepage.
8. Do not set up automatic language redirection. A forced redirect based on IP or browser language traps crawlers in a single version and makes the other one invisible. Suggest; do not force.
9. Share the schema @id.
10. Measure for 60-90 days: the language breakdown in Search Console, plus questions asked by hand in a few assistants. Then expand.

These steps do not guarantee visibility. What they do is more basic than that: they remove the structural obstacle standing in front of your second-language content's chance of being seen. If the content itself is not good, neither a separate URL nor hreflang will do anything for you — but when the content is good and this setup is missing, nobody ever gets to find out that it was.

One of the fields where this setup pays off most is clinics targeting patients from abroad; the detail is on our medical tourism solution page.

Frequently Asked Questions

Is keeping two languages on the same URL really a problem for search visibility?

Yes, and the problem is technically clear-cut. Search engines and AI assistants recognise, index and cite a piece of content through its URL. If the language choice is stored in the browser and the address never changes, automated clients see only the default language on every visit. In that situation the second language has no address to enter into the sitemap, no target to be connected by hreflang, and no source link that can be shown in an answer. The content has been written, but it sits outside the index.

Should I choose a subdirectory, a subdomain or a separate domain?

For small and mid-sized sites the practical answer is usually the subdirectory, in the form site.com/en/ for example. It is managed with one stack, it does not split the trust the main domain has accumulated, and it is the easiest option to undo. A subdomain makes sense when the second language lives in a separate system or with a separate team. A separate domain is preferred when there are reasons such as a country-specific legal entity, a separate brand or a legal requirement, and because every new domain has to build its authority from zero it is the most expensive option.

I added the hreflang tags but nothing changed, why?

One of three causes is usually behind it. The first is a missing reciprocity: if the Turkish page points at the English one but the English page does not point back at the Turkish one, the link is generally ignored in its entirety. The second is a canonical conflict: if the English page's canonical tag points at the Turkish page, you have told the engine not to index that page. The third is an invalid target address; an address that redirects, returns 404 or carries noindex is not accepted as an alternate. On top of that, the addresses have to be written in absolute form and the language codes have to be separated with a hyphen.

Is it harmful to translate pages with machine translation?

It is not directly harmful, but the places where it is not enough on its own are well known. Machine translation carries the grammar across; it does not carry the intent. People ask different questions about the same service in different languages, care about different information and expect different proof. Currency, regulatory references, contact conventions, examples and social proof are solved by localisation rather than translation. The practical approach is to use machine translation as a draft and have the version that goes live reviewed by someone who speaks the language, reworking terminology and any sentence that makes a claim in particular.

Do I have to translate the entire site into the second language?

It is not compulsory, and in most cases it is not the right thing to do either. The decision criterion is this: can you genuinely serve a request that arrives in that language? Translating areas you cannot serve produces searches that go unanswered. A reasonable order is the homepage, one single core service page, the contact and quote page, the few services that get the most questions, and the process information; the blog comes last and selectively. Articles about local regulation, local campaigns and city-based pages generally should not be translated. The worst option is a half translation: translating five pages completely gives a better result than translating fifty pages halfway.