Web Design
How to build a hreflang strategy for a multilingual corporate website
Short answer
A hreflang strategy for a multilingual corporate website is the combination of technical markup and content decisions that tell search engines which language version of a page belongs where. On a site with a Turkish and an English version, a missing or broken hreflang tag can make Google show visitors.
The wrong-language page, and the two versions end up competing for the same traffic instead of adding to it.
This isn’t a single line of code set once and forgotten. It also covers which pages get fully translated, what URL structure to use, and how the two language versions are expected to affect each other’s search results.
Who actually needs a multilingual website?
Running a bilingual site doesn’t automatically create an SEO need. A manufacturer selling abroad, a holding company courting foreign investors, or an agency serving English-speaking clients gets real marketing value from an English version, and that value disappears fast if the setup is wrong. A business that only serves a local market in one language gains little from adding a second one beyond extra maintenance, since a stale English page reads as neglected to both visitors and search engines.
The simplest way to check whether a business actually needs a second language version is to look at where existing traffic already comes from. Searches from other countries, visitors who spend a long time on a page without filling out a form, or inquiries that arrive in English by email are usually a sign that a second language pays for itself quickly.
What does a hreflang tag actually do?
Hreflang is HTML markup that tells search engines which language and region a page is meant for. Google’s own documentation explains that when a page points to another language version through hreflang, that version needs to point back the same way. Without that return link, Google treats the signal as unreliable and can ignore it entirely.
The tag’s real job is to tell search engines that two pages covering the same topic in different languages are matching counterparts, not duplicates. Done correctly, a search from Turkey surfaces the Turkish page and a search from the UK surfaces the English one, rather than the two pages competing for the same query.
How do you set up hreflang for multilingual websites?
Setup happens across three layers: URL structure, page markup, and content matching. Each language version needs its own permanent address first; a Turkish page might live at the root while the English version sits under an /en/ path. This site follows exactly that pattern, and every post’s English counterpart is published under the /en/ prefix.
Page markup means adding a link rel="alternate" hreflang="..." line in the <head> of every page, pointing to both its own language and the counterpart. In a static site generator, these lines are usually generated from a single field in the content schema (translationSlug on this site) rather than typed by hand on every page. Manual entry tends to fall out of sync as a site grows.
Subfolder or a separate domain?
For most corporate sites, a subfolder is the more practical choice, since every language version shares the same domain’s authority and the whole thing stays in one codebase. A separate domain only makes sense when a different legal entity or a genuinely distinct brand requires it; otherwise authority splits across two domains and both rank more slowly. Getting this decision right at the start of a corporate web design project is far cheaper than restructuring URLs after the fact.
Translation or localization?
The gap between literal translation and real localization is the part of a multilingual strategy that gets skipped most often. Translating a service page sentence by sentence removes the language barrier but rarely matches actual search intent, since English-speaking visitors tend to search with different phrasing and go through a different decision process. Localization means rebuilding the same page around how the target language’s audience actually searches and what they expect to see.
In practice that means running separate keyword research for each language and writing each page’s title and description for its own search result, not as a direct translation of the other. That’s why this site links its Turkish and English post pairs through a shared translationSlug field while writing each title on its own terms. Readers in either language get a page that reads naturally, not one that reads like a translation.
What hreflang mistakes come up most often?
The most common mistake is a one-way link: the Turkish page points to the English version, but the English page never points back. Once Google notices that asymmetry, it drops the tag entirely and evaluates both pages as if hreflang were never there.
The second common mistake is using only a language code, like hreflang="en", and skipping the region. That’s harmless for most sites, but a site serving separate US and UK English pages needs the region code too, or the wrong version ends up in front of the wrong country. A third mistake is a canonical tag that contradicts the hreflang setup: if a page’s canonical points to a page in a different language, search engines can’t tell which version is the real one, and one of the two usually drops out of rankings.
How do you measure whether it’s working?
Search Console’s country and language filters are the most reliable way to check whether a hreflang setup is actually doing its job. If a page gets strong impressions from Turkey while its English counterpart gets none from any country, that usually points to a tagging error or a page that hasn’t been indexed yet. Making sure both versions sit inside sitemap.xml, and that the sitemap has been submitted to Search Console, is the fastest way to catch an indexing gap early.
The metric worth tracking over time is combined visibility across both languages. The goal isn’t for the English version to eat into the Turkish version’s traffic; it’s for the two together to grow total visitors. Looking at the country breakdown monthly shows clearly which language is actually landing in which market.
Next step
Hreflang for a multilingual corporate website isn’t a setting configured once and forgotten; every new page needs both language versions published together and pointing back at each other. Get the URL structure, the reciprocal tags, and real per-language keyword research right, and a second language stops being overhead and turns into a measurable growth channel.
If you’re planning a move to a multilingual corporate website or want a second look at your current hreflang setup, our group company Web Tasarım Ofisi supports multilingual corporate site projects with technical setup and content localization. You can also check our guide on why a website doesn’t show up on Google for common indexing issues, or get in touch to talk through your project.
Frequently asked questions
Does every corporate site need a hreflang tag?
No. Hreflang is only necessary when the same content exists in more than one language or regional version. A site serving a single language and a single country gains nothing from adding it beyond extra complexity.
What happens if a hreflang tag is missing?
Google decides on its own which language version to show a given visitor, which often means the wrong-language page gets surfaced, or the two versions end up competing against each other for the same search query.
Should I use a subfolder (/en/) or a separate domain?
A subfolder works better for most corporate sites because every language version shares the same domain's authority. A separate domain only makes sense when a different legal entity or a genuinely distinct brand requires it.
Should the English page just be a translation of the Turkish one?
No, a literal translation rarely matches actual search intent. English-speaking visitors tend to search with different phrasing, so rewriting the title and description around that language's own search habits gets better results.
How do I know if a hreflang setup is actually working?
Check Search Console's country and language breakdown. If the English version gets no impressions from any country while the Turkish page performs well, that usually points to a tagging error or a page that hasn't been indexed yet.