Many Turkish and English websites publish two language versions and assume search engines will work out the rest. In practice, multilingual SEO breaks down on structure, tagging, localisation and reporting long before content quality becomes the main issue.
If you want both language versions to rank, you need a setup that is technically clear and operationally easy to maintain. Below is a practical approach we use when planning multilingual SEO for bilingual sites that need to serve users cleanly across markets.
Subdirectory, subdomain or ccTLD
The first decision in multilingual SEO is where each language lives. For Turkish and English sites, the usual options are subdirectories such as /tr/ and /en/, subdomains such as tr.example.com and en.example.com, or separate country-code domains.
For most teams, subdirectories are the simplest starting point. They keep content under one domain, make analytics and governance easier, and reduce the chances of splitting authority across multiple properties. A clean setup often looks like this:
- example.com/tr/ for Turkish
- example.com/en/ for English
- Consistent URL slugs by language, rather than mixing both languages in one path
Subdomains can work, but they usually add complexity in tracking, CMS configuration and technical ownership. ccTLDs make sense when legal, market or operational requirements genuinely differ by country, but they are often unnecessary for a site that simply needs Turkish and English versions.
A practical rule: choose the structure your team can maintain for the next two years, not the one that sounds most sophisticated in a pitch deck.
What to set up from day one
Whichever structure you choose, apply these basics before publishing at scale:
- Create a dedicated URL for each language version. Do not swap page language dynamically on the same URL.
- Keep the information architecture aligned where possible. If the Turkish version has a service page, the English version should have an equivalent page, even if the copy differs.
- Make language switching crawlable. Use plain HTML links rather than JS-only switches that search engines may not follow reliably.
- Set a self-referencing canonical on each page version.
- Include each language URL in XML sitemaps.
If you are using WordPress, teams often ask about polylang seo implications. The plugin choice matters less than the output. Check that your multilingual plugin creates stable URLs, separate metadata fields per language, correct canonicals and workable hreflang output. Do not assume the default settings are enough.
One more detail that gets missed: avoid automatic browser-based redirects that force all Turkish-browser users onto Turkish pages. A user in Germany may prefer English. Let people choose, and let search engines crawl both versions without obstruction.
hreflang without the usual mistakes
hreflang helps search engines understand which language version to show to which user. It does not improve rankings by itself. Its job is to reduce ambiguity between near-equivalent pages in different languages.
For a Turkish and English setup, the most common implementation pattern is straightforward:
- Turkish page references itself as tr and the English equivalent as en
- English page references itself as en and the Turkish equivalent as tr
- An optional x-default points to a language selector or your default international page
A simple example for the English page:
- rel=”alternate” hreflang=”en” pointing to the English URL
- rel=”alternate” hreflang=”tr” pointing to the Turkish URL
- rel=”alternate” hreflang=”x-default” pointing to the fallback URL if used
The usual mistakes are rarely about the tag itself. They come from page mapping and maintenance.
Five checks worth doing manually
- Return links are reciprocal. If the English page points to the Turkish page, the Turkish page must point back to the English page.
- Language codes are valid. Use tr for Turkish and en for English unless you have a real reason to specify region variants such as en-gb or en-us.
- Each hreflang target resolves with a 200 status. Do not point to redirected, canonicalised or noindexed URLs.
- The content pair is genuinely equivalent. Do not connect a Turkish category page to an English blog post because they feel topically related.
- Do not combine conflicting signals. A page should not canonicalise to one URL while hreflang references another version as the actual page.
When pages are missing in one language, do not force the pairing. It is better to omit hreflang on that unmatched page than to map it to an irrelevant destination.
For larger sites, place hreflang in the HTML head or XML sitemap, then sample-check key templates: homepage, service pages, blog posts, product pages and paginated archives. This catches template-level errors faster than checking random URLs one by one.
If your CMS relies on plugin automation, audit after every structural change. We have seen bilingual sites keep old hreflang references long after URLs were renamed, which quietly creates indexation noise across the whole site.
Translation is not localisation
A direct translation can make a page readable, but not necessarily useful or competitive in search. Localisation means adjusting the page to match how users in each language actually search, compare and decide.
That starts with page elements many teams leave identical across languages:
- Title tags and meta descriptions
- Navigation labels
- Internal anchor text
- CTA wording
- Trust signals, examples and references
For example, an English page may frame a service around flexibility, integration or growth. The Turkish equivalent might perform better when it leads with operational clarity, implementation scope or speed of response, depending on the buying context. The point is not to stereotype users. The point is that the same commercial intent is often expressed differently across languages.
Localise the page, not just the paragraphs
A practical workflow is to localise in layers:
- Search intent layer: confirm that the target keyword in each language matches the same intent.
- Page structure layer: adjust headings, FAQs and CTA sequence to fit how users evaluate the offer.
- Proof layer: update examples, use cases and terminology so they feel native to the market.
- Conversion layer: adapt form labels, microcopy and next-step expectations.
Suppose a SaaS onboarding page in English uses phrases like “book a demo” and “talk to sales.” The Turkish version may need a more explicit next step, such as requesting a consultation or implementation review, if that better matches how buyers qualify suppliers. Small wording changes can improve relevance because they align the page with user expectations, not because they add keywords.
This is also where many international seo projects go off course. Teams replicate the same page count and layout in each language but ignore differences in terminology, category depth or search behaviour. Localisation does not mean rebuilding the whole site. It means allowing each language version to do its job properly.
If you have content in both languages but one version consistently underperforms, review the first screen of the page. Check the headline, subheading, CTA and internal links. Often the issue is not authority or indexation. It is that the page was translated line by line without being adapted for the way users scan and decide.
Keyword research in two languages
Keyword research for bilingual sites is not a translation exercise. One English keyword does not map neatly to one Turkish keyword, and search volumes can lead you into false confidence if you do not check intent.
A practical method is to build keyword research around page targets, not around a giant term list. Start with the pages you need: homepage, service pages, category pages, core blog content and key support pages. Then research each language separately.
A workable bilingual keyword workflow
- List the core pages. Define the commercial or informational role of each page.
- Write seed terms independently in Turkish and English. Do not begin by translating one list into the other.
- Check SERPs for both languages. Look at what types of pages rank: guides, landing pages, directories, product pages, comparison content.
- Group by intent. Separate informational research terms from service or purchase-ready terms.
- Assign one primary keyword theme per page per language. Supporting variants can be added naturally in subheadings and body copy.
Here is the practical reason this matters: an English query may be broad and education-led, while the closest Turkish phrase may skew toward supplier evaluation. If you force both onto identical page structures, one version often misses the mark.
For this article’s topic, the phrase multilingual seo works as a broad concept in English. In Turkish, the equivalent search behaviour may split across language-specific phrases, implementation questions and platform-related terms. That means your Turkish page may need stronger explanatory framing or a slightly different content architecture.
What to look for in the SERP
During research, note these details manually:
- Whether local-language results use English loan terms or native terminology
- Whether top-ranking pages are agency pages, publisher guides or software documentation
- How often location qualifiers appear in titles and headings
- Whether users seem to want strategy advice, implementation help or tool-specific instructions
This is especially useful when planning content around tools or CMS setups. A query related to polylang seo may signal practical implementation needs rather than broad educational intent. That usually calls for a shorter, more task-focused page than a general multilingual strategy guide.
Once the keyword map is done, align internal links by language. English pages should mainly strengthen the English cluster, and Turkish pages should mainly strengthen the Turkish cluster. Cross-language links are useful for users switching language, but they should not replace topical internal linking within each language section.
If you need a starting point for structuring this cluster, a related guide on B02 would fit naturally after the keyword mapping section, especially for readers planning topic coverage across multiple markets.
Measuring per-language performance
Reporting is where multilingual SEO often becomes too vague to be useful. If you only look at sitewide traffic, you will miss the real pattern: one language may be gaining impressions while the other loses rankings on key commercial pages.
The simplest fix is to measure by language directory, page group and intent. For a Turkish and English setup using subdirectories, that means separating /tr/ and /en/ in both analytics and search reporting.
Build a language-level dashboard around these views
- Organic landing pages by language directory
- Search Console queries by page set
- Index coverage issues by language section
- Conversions or lead actions by language
- Top linked pages internally within each language
Do not stop at traffic. Compare whether each language section has:
- Equivalent coverage of key commercial pages
- Comparable metadata quality
- Healthy crawlability and indexation
- Internal links pointing to priority pages
A useful monthly review can be very simple:
| Check | Turkish | English |
|---|---|---|
| Core pages indexed | Review service and category URLs | Review service and category URLs |
| Top landing pages | Note gains and drops by template | Note gains and drops by template |
| Query intent mix | Informational vs commercial | Informational vs commercial |
| Conversions | Track form and contact actions | Track form and contact actions |
| Technical issues | hreflang, canonicals, redirects | hreflang, canonicals, redirects |
If one language is underperforming, diagnose in order: indexation, page mapping, search intent fit, then authority. Teams often jump to link building before checking whether the page title, body copy and internal linking actually match what users in that language want.
This is also the right place to connect SEO work with wider content and automation processes. If your publishing workflow duplicates updates in one language but delays the other, performance drift is inevitable. A reference to D01 would sit well here for readers interested in tightening the operational side of multilingual publishing and reporting.
For teams refreshing older bilingual sites, a practical next step is to audit three page pairs only: homepage, one core service page and one high-traffic article. If structure, hreflang, metadata and localisation are wrong there, the same issues usually exist across the rest of the site. A link to B03 would make sense at this point for readers moving from diagnosis into implementation planning.
Good multilingual SEO is less about adding more pages and more about making each language version structurally clear, locally relevant and measurable on its own terms. Turkish and English sites do not need a complicated stack. They need a setup the team can maintain consistently.
If you are planning a Turkish and English site structure, or fixing a bilingual setup that is already live, Let’s talk.
FAQ
Is it better to use subdirectories or subdomains for Turkish and English SEO?
For most sites, subdirectories are easier to manage and measure. They keep both language sections under one domain and usually simplify analytics, internal linking and technical maintenance.
Do I need hreflang if my Turkish and English pages have different URLs?
Yes, if the pages are language equivalents. Different URLs alone do not tell search engines which version should be shown to users in each language.
Can I translate my English keywords directly into Turkish?
Not reliably. Keyword research should be done separately in each language because terminology and search intent often differ.
How should I measure multilingual SEO performance?
Report by language section, page type and intent. Track indexation, landing pages, queries, conversions and technical issues separately for Turkish and English.
