26. Bölüm: Birden Fazla Ülkeye SEO Nasıl Yapılır?

Son güncelleme: 1 Kasım 2026.

Bir siteyi İngilizceye, Almancaya veya Arapçaya çevirmek uluslararası SEO yapmak değildir.

Uluslararası SEO’da asıl mesele şu:

Doğru kullanıcıyı, doğru dil ve bölge varyasyonuyla, doğru URL’ye yönlendirmek.

Bu nedenle iş sadece çeviri değil. Teknik yapı, hreflang, URL mimarisi, ülke hedefleme, içerik yerelleştirmesi ve anahtar kelime araştırması birlikte düşünülmeli.

1. Çok dilli site ile çok bölgeli site aynı şey değil

Google iki yapıyı birbirinden ayırıyor.

Çok dilli site (Multilingual Site) birden fazla dilde içerik sunar. Örneğin:

• Türkçe
• İngilizce
• Almanca

Çok bölgeli site (Multi-Regional Site) ise farklı ülke veya bölgelerdeki kullanıcılara özel içerik sunar. Örneğin İngilizce içerik aynı dilde olabilir ama şunları sunabilirsiniz:

• ABD için farklı fiyat
• İngiltere için farklı para birimi
• Kanada için farklı teslimat
• Avustralya için farklı ürün gamı

Bir site aynı anda hem çok dilli hem çok bölgeli de olabilir. Google’ın kendi örneğinde Kanada için İngilizce ve Fransızca, ABD için ayrı İngilizce sürüm bulunabiliyor. Google for Developers

2. Dil ile ülke hedeflemesini birbirine karıştırmamak gerekiyor

Burada kodlama tarafında sık hata yapılabiliyor.

Örneğin Türkçe için tr kullanabiliriz. Türkiye’deki Türkçe içerik için ise tr-TR kullanabiliriz. Buradaki ilk bölüm dili, ikinci bölüm ise isteğe bağlı olarak bölgeyi ifade ediyor.

Google hreflang değerlerinde ilk kodun ISO 639-1 dil kodu, ikinci kodun ise isteğe bağlı ISO 3166-1 Alpha 2 bölge kodu olması gerektiğini açıkça belirtiyor. Google for Developers

Bu nedenle tr-TR doğru bir kullanım. Ama aynı mantıkla en-EN yazamayız. Çünkü EN diye bir ülke kodu yok.

İngilizce içerikte örneğin şunlar kullanılabilir:

• en: bölgeden bağımsız İngilizce
• en-US: ABD’deki İngilizce kullanıcılar
• en-GB: Birleşik Krallık’taki İngilizce kullanıcılar
• en-AU: Avustralya’daki İngilizce kullanıcılar

Google’ın kendi hreflang örneklerinde de en-US, en-GB, de gibi kullanımlar yer alıyor. Google for Developers

Bence bu küçük gibi görünen ama önemli bir detay. Kodlama sırasında geliştirici “tr-TR var, o zaman İngilizce de en-EN olsun” diye düşünebiliyor. Bu yanlış.

Dil kodu ile ülke kodunu ezbere değil, standartlara göre kullanmak gerekiyor.

3. Her dil için ülke belirtmek zorunda değiliz

Bu da önemli.

Eğer İngilizce içeriğiniz bütün İngilizce konuşan kullanıcılara aynı şekilde hizmet ediyorsa hreflang="en" yeterli olabilir. Ama ABD ve İngiltere için içerik farklıysa en-US ve en-GB şeklinde ayrım yapmak mantıklı hale gelir.

Örneğin iki sayfa da İngilizce olabilir ama ABD sayfasında şunlar kullanılıyor olabilir:

• Dollar
• US shipping
• US terminology

İngiltere sayfasında ise:

• Pound
• UK shipping
• British terminology

Google da aynı dilde fakat farklı bölgesel varyasyonları olan sayfalar için hreflang kullanılmasını öneriyor. Google for Developers

4. Hreflang nedir?

Hreflang, Google’a bir sayfanın diğer dil veya bölge sürümlerini anlatmamızı sağlayan anotasyon.

Örneğin aynı sayfanın şu sürümleri olabilir:

• Türkçe
• İngilizce ABD
• İngilizce İngiltere
• Almanca

HTML içerisinde kabaca şöyle görünebilir:

<link rel="alternate" hreflang="tr-TR" href="https://site.com/tr/urun" />
<link rel="alternate" hreflang="en-US" href="https://site.com/us/product" />
<link rel="alternate" hreflang="en-GB" href="https://site.com/uk/product" />
<link rel="alternate" hreflang="de-DE" href="https://site.com/de/produkt" />

Böylece Google’a bu URL’lerin birbirinin dil veya bölge varyasyonları olduğunu söylüyoruz.

5. Hreflang sıralama faktörü mü?

Bence hreflang’a şöyle bakmak daha doğru:

Sıralamayı yükseltmek için değil, doğru sürümü doğru kullanıcıya göstermek için kullanıyoruz.

Örneğin ABD’deki kullanıcıya İngiltere sayfasını göstermek istemeyebiliriz. İngilizce aynı olsa bile şunlar farklı olabilir:

• Para birimi
• Kargo
• Vergi
• Telefon
• Adres
• Ürün stoğu
• Kampanya

Hreflang Google’a bu varyasyonları anlamasında yardımcı oluyor. Google, doğru dil veya bölge sürümünü kullanıcıya göstermeye yardımcı olmak için hreflang kullanımını öneriyor. Google for Developers

6. Hreflang karşılıklı olmak zorunda

Bu en sık yapılan hatalardan biri.

A sayfası B sayfasını alternatif olarak gösteriyorsa B sayfasının da A sayfasını göstermesi gerekiyor.

Örneğin Türkçe sayfada hreflang="en-GB" var. Ama İngilizce sayfada Türkçe sayfaya dönüş yok. Bu durumda hreflang kümesi eksik olur.

Google eksik dönüş bağlantılarını açıkça yaygın hreflang hatalarından biri olarak belirtiyor ve bu anotasyonların yok sayılabileceğini söylüyor. Google for Developers

Kısaca:

TR → EN varsa, EN → TR de olmalı.

7. Sayfa kendisini de hreflang içerisinde göstermeli

Bir hreflang kümesinde yalnızca diğer dilleri değil, mevcut sayfanın kendisini de belirtmek gerekiyor. Google bunu zorunlu tutuyor.

Örneğin Türkçe sayfada şunlar bulunabilir:

• tr-TR: kendisi
• en-US: ABD sürümü
• en-GB: İngiltere sürümü
• de-DE: Almanca sürüm

Böylece bütün varyasyonlar tek bir küme oluşturur.

8. x-default nedir?

Bazen kullanıcının diline veya bölgesine uygun özel bir sayfamız olmayabilir. Bu durumda hreflang="x-default" kullanılabilir.

Google bunu hiçbir dil veya bölgeyle eşleşmeyen kullanıcılar için varsayılan sürümü belirtmek amacıyla kullanıyor. Özellikle ülke/dil seçici sayfalarında faydalı olabiliyor. Google for Developers

Örneğin:

<link rel="alternate" hreflang="en-US" href="https://site.com/us/" />
<link rel="alternate" hreflang="en-GB" href="https://site.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/" />

Burada ana sayfa kullanıcıyı ülke veya dil seçimine yönlendiren genel sayfa olabilir.

9. Hreflang ile Canonical birbirine karıştırılmamalı

Bu önemli.

Canonical şunu anlatıyor:

“Bu benzer URL’ler arasındaki tercih ettiğim esas URL bu.”

Hreflang ise:

“Bu sayfanın farklı dil veya bölge sürümleri bunlar.”

Örneğin ABD ve İngiltere sayfaları birbirine çok benzer olabilir. Ama her ikisi de ayrı kullanıcı kitlesine hizmet ediyorsa her sayfanın canonical’ı genellikle kendisini göstermeli. Sonra hreflang ile birbirlerine bağlanmalı.

Google çok bölgeli sitelerde benzer içerikler olduğunda canonical ve hreflang sinyallerinin birlikte doğru kullanılmasını öneriyor. Google for Developers

Şöyle bir yapı genellikle doğru olmaz: ABD sayfası canonical → UK ama aynı zamanda hreflang en-US → ABD diyor.

Bir taraftan “Esas sayfa UK.” diğer taraftan “ABD kullanıcılarına ABD sayfasını göster.” diyoruz.

Teknik sinyallerin birbirleriyle çelişmemesi gerekiyor.

10. Sadece çeviri yapmak yeterli mi?

Bence uluslararası SEO’da en büyük hatalardan biri bu.

Türkçe sayfayı alıp İngilizceye çeviriyoruz. Sonra “İngilizce SEO tamam.” diyoruz.

Ama daha önce anahtar kelime araştırmasında söylediğimiz gibi:

Çeviri yapmak başka, anahtar kelime araştırması yapmak başka.

Bir ürün Türkiye’de bir kelimeyle aranırken ABD’de başka, İngiltere’de başka bir kelimeyle aranabilir. Hatta aynı dil içerisinde bile terminoloji değişebilir.

Örneğin İngilizcede şu gibi bölgesel kullanım farkları var:

• vacation / holiday
• apartment / flat
• truck / lorry

Ürün tarafında da aynı şey geçerli. Türkçe anahtar kelimeyi İngilizceye çevirmek bize gerçek arama davranışını söylemez.

Bu nedenle her ülke için mümkünse yeniden şunları yapmak gerekiyor:

• Keyword Research
• SERP analizi
• Rakip analizi
• Arama niyeti analizi

11. Yerelleştirme (Localization) ile çeviri aynı şey değil

Çeviri “Bu metnin başka dilde karşılığı nedir?” sorusuna cevap verir. Yerelleştirme ise “Bu içerik o pazardaki kullanıcı için gerçekten uygun mu?” sorusuna.

Örneğin içerikte şunların da değişmesi gerekebilir:

• Para birimi
• Tarih formatı
• Ölçü birimleri
• Telefon numarası
• Adres
• Teslimat bilgileri
• Vergi
• İade koşulları
• Hukuki metinler
• Görseller
• Ürün çeşitleri
• Kampanyalar
• Kullanılan örnekler

ABD için hazırladığınız sayfada fiyat Euro, ölçüler santimetre, telefon numarası Türkiye numarası ve teslimat bilgisi yalnızca Türkiye içinse metni İngilizceye çevirmiş olmanız çok fazla şey ifade etmez.

12. Türkiye’deki Türk kullanıcı ile Almanya’daki Türk kullanıcı aynı mı?

Her zaman değil.

Örneğin tr-TR Türkiye’deki Türkçe kullanıcıları hedefleyebilir. Almanya’da yaşayan Türk kullanıcılar için ise iş modeline göre ayrı bir deneyim gerekebilir.

Sayfa yine Türkçe olabilir ama şunlar bulunabilir:

• Fiyat Euro
• Teslimat Almanya’ya
• Alman mevzuatı
• Yerel telefon
• Yerel mağazalar
• Almanya’ya özgü kampanyalar

Bu durumda teknik olarak tr-DE gibi Türkçe + Almanya kombinasyonu kullanılabilir. Google dil + bölge biçiminde bu tür kombinasyonlara izin veriyor. Aynı mantıkla İspanya’daki Almanca konuşan kullanıcılar için de-ES de kullanılabiliyor. Google for Developers

Ama burada “her ülke için mutlaka ayrı sayfa açalım” demiyorum. Gerçek bir içerik veya ticari fark varsa anlamlı.

13. Site yapısını nasıl kuracağız?

Uluslararası sitelerde en çok konuşulan üç yapı var.

Ülke alan adı (ccTLD)

Örneğin site.de, site.fr, site.co.uk.

En büyük avantajı ülke hedefinin kullanıcıya ve arama motoruna çok açık olması. Google ccTLD’leri güçlü ülke sinyallerinden biri olarak değerlendiriyor. Google for Developers

Ama şunlar işi zorlaştırabilir:

• Domain maliyetleri
• Ayrı teknik yönetim
• Ayrı SEO otoritesi geliştirme ihtiyacı
• Bazı ülkelerde domain kayıt şartları

Alt alan adı (Subdomain)

Örneğin de.site.com, fr.site.com, uk.site.com.

Yönetim açısından ayrıştırmak kolay olabilir. Farklı uygulamalar, ekipler veya altyapılar kullanabilirsiniz.

Alt dizin (Subdirectory)

Örneğin site.com/de/, site.com/fr/, site.com/uk/.

Tek domain altında ilerlediğiniz için yönetimi daha kolay olabilir.

Google hem subdomain hem alt dizin yapılarının kullanılabileceğini açıkça belirtiyor; çok bölgeli siteler için her ikisini de geçerli URL mimarileri arasında gösteriyor. Google for Developers

14. Alt dizin mi, subdomain mi?

Burada benim pratik yaklaşımım biraz farklı.

Google teknik olarak hem alt dizin hem subdomain kullanımını destekliyor ve uluslararası hedefleme açısından ikisini de geçerli seçenek olarak gösteriyor. Google for Developers

Ama ben proje yönetimi açısından genelde şöyle düşünüyorum:

Alt dizin daha çok mevcut sitenin devamı gibi.

site.com/de/ aynı sitenin Almanca bölümü hissini veriyor.

Subdomain ise operasyonel olarak daha bağımsız bir site gibi yönetilebilir.

de.site.com ayrı uygulama, ayrı sunucu, ayrı ekip veya ayrı teknik yapı ile çalıştırılabilir.

Burada “Google subdomain’i kesin ayrı site sayar” demek fazla kesin olur. Ama pratikte subdomain’in teknik ve içerik yönetimini daha bağımsız kurgulamak mümkün olduğu için onu ayrı bir site gibi düşünmek bazen işleri daha anlaşılır hale getiriyor.

Ben çoğu projede teknik veya organizasyonel bir zorunluluk yoksa alt dizin yapısını daha sade buluyorum. Örneğin site.com/tr/, site.com/en/, site.com/de/ hem ekip hem kullanıcı açısından daha kolay yönetilebiliyor.

Ama her proje için tek doğru mimari yok.

15. URL’nin içinde /en/ yazması Google’a İngilizce olduğunu anlatır mı?

Tek başına hayır. Bu da önemli bir detay.

Google, URL’deki veya subdomain’deki en, de, en-gb gibi ifadeleri sayfanın hedef kitlesini otomatik belirlemek için kullanmadığını açıkça söylüyor. Hedef dil ve bölgeyi içerik, hreflang ve diğer sinyallerle açıkça belirtmek gerekiyor. Google for Developers

Yani en.site.com veya site.com/en/ kullanmanız mimari açıdan anlaşılır olabilir. Ama “URL’de en yazıyor, Google zaten anlar.” dememek gerekiyor.

16. Kullanıcıyı IP’ye göre otomatik yönlendirmek doğru mu?

Burada dikkatli olmak gerekiyor.

Örneğin Türkiye IP’si görüp kullanıcıyı zorla Türkçe siteye yönlendirmek sorun yaratabilir. Kullanıcı Türkiye’de olabilir ama İngilizce sürümü görmek istiyor olabilir. VPN kullanıyor olabilir. Googlebot da farklı lokasyonlardan gelebilir.

Google, IP veya tahmin edilen dile dayalı otomatik yönlendirmelerden kaçınılmasını ve kullanıcıya dil/bölge sürümleri arasında geçiş yapabileceği bağlantılar sunulmasını öneriyor. Google for Developers

Bence en sağlıklı yaklaşım “Türkiye sitesine gitmek ister misiniz?” gibi öneri göstermek ama kullanıcıyı zorlamamak.

17. Her sayfa tamamen tek dilde olmalı

Bu da Google’ın özellikle dikkat çektiği konulardan biri.

Örneğin sayfanın şöyle olması iyi bir kullanıcı deneyimi değil:

• Menüleri Almanca
• İçeriği İngilizce
• Footer’ı Türkçe

Google da her sayfanın içerik ve navigasyonunda ağırlıklı olarak tek dil kullanılmasını öneriyor. Sadece menü ve footer gibi şablon alanlarını çevirip ana içeriği aynı bırakmak sorun yaratabilir. Google for Developers

18. Her ülkede aynı ürün satılmıyorsa ne olacak?

Bu noktada uluslararası SEO e-ticarete dönüşüyor.

Örneğin Türkiye’de 500 ürününüz var. Almanya’da yalnızca 300’ü satılıyor. ABD’de ise 200 farklı ürün daha var.

Her ülkede aynı sitemap’i ve aynı kategori yapısını kullanmaya çalışmak doğru olmayabilir. Her pazar için şunlar gerçek yapıya uygun olmalı:

• Ürün stoğu
• Kategori
• Fiyat
• Para birimi
• Teslimat
• Vergi
• Kampanya

Google’a hreflang ile alternatif sayfa gösteriyoruz diye var olmayan ürünü başka ülkeye kopyalamak zorunda değiliz.

19. Uluslararası backlink ve otorite konusu

Bir site Türkiye’de çok güçlü olabilir ama Almanya’da hiç bilinmeyebilir.

Yerel pazarda şunlar farklı olabilir:

• Yerel yayınlar
• Sektör siteleri
• Yerel iş ortakları
• Haber siteleri
• Dernekler
• Kullanıcı yorumları

Google da ülke hedefini belirlerken yerel adres, telefon, para birimi ve diğer yerel sitelerden gelen bağlantılar gibi ek sinyallerden yararlanabileceğini belirtiyor. Google for Developers

Bu nedenle uluslararası SEO yalnızca hreflang dosyası hazırlamak değil. Her pazarda gerçekten varlık göstermek.

20. Uluslararası SEO’da Search Console ve Analytics nasıl kullanılmalı?

Bütün trafiği tek toplam rakam olarak izlemek çok anlamlı değil.

Örneğin ayrı ayrı bakabiliriz:

• Türkiye organik trafik
• Almanya organik trafik
• ABD organik trafik
• İngiltere organik trafik

Sonra şu gibi sorular sorabiliriz:

• Hangi sorgular geliyor?
• Hangi landing page trafik alıyor?
• Yanlış ülke URL’si sıralanıyor mu?
• Almanya sorgularında Türkiye sayfası mı görünüyor?
• Hangi ülkede dönüşüm yüksek?
• Hangi ülkede impression var ama click yok?

Özellikle yanlış lokal URL’nin sıralanması hreflang veya site yapısı problemlerini fark etmemize yardımcı olabilir.

21. Hreflang hatalarını nasıl kontrol ederiz?

Ben özellikle şunlara bakardım:

• Dil kodları doğru mu?
• Bölge kodları doğru mu?
• en-EN gibi geçersiz kombinasyon var mı?
• Return link eksik mi?
• Sayfalar kendilerini gösteriyor mu?
• Canonical ile hreflang çelişiyor mu?
• 404 veya yönlendirme veren URL hreflang içinde mi?
• noindex sayfalar kullanılıyor mu?
• HTTP ve HTTPS karışmış mı?
• x-default doğru yerde mi?
• Her varyasyon aynı kümedeki alternatifleri gösteriyor mu?

Özellikle büyük sitelerde küçük bir şablon hatası on binlerce sayfayı etkileyebilir. Bu nedenle birkaç URL’yi manuel kontrol etmek yetmeyebilir. Crawler kullanmak gerekebilir.

22. Sık yapılan hreflang hatalarından biri: kodu tahmin etmek

Tekrar dönmek istiyorum çünkü pratikte çok kolay hata yapılabilecek bir alan.

Türkiye tr-TR olduğu için geliştirici doğal olarak İngiltere için en-EN yazabiliyor. Ama burada ilk kod dil, ikinci kod bölge olduğu için doğru İngiltere örneği en-GB olmalı. Diğer örnekler:

• ABD: en-US
• Avustralya: en-AU
• Kanada Fransızcası: fr-CA
• Brezilya Portekizcesi: pt-BR
• Portekiz Portekizcesi: pt-PT

Bu nedenle uluslararası sitelerde ülke ve dil eşleşmelerini kodlamadan önce tablo halinde çıkarmak bence iyi bir kontrol yöntemi.

23. Uluslararası SEO’ya nasıl başlarım?

Ben kabaca şu sırayla giderdim:

• Hangi ülkeleri hedefliyoruz?
• Hangi diller kullanılacak?
• Her ülkede ürün/hizmet aynı mı?
• Aynı dilin farklı bölgesel sürümleri gerekiyor mu?
• Her ülke için ayrı keyword research yapıldı mı?
• Rakipler kim?
• URL mimarisi nasıl olacak?
• ccTLD, subdomain veya alt dizin?
• Hreflang planı nedir?
• Canonical yapısı doğru mu?
• Para birimi ve yerel bilgiler doğru mu?
• İçerikler sadece çevrilmiş mi, yerelleştirilmiş mi?
• Yerel backlink ve marka sinyalleri var mı?
• Analytics ve Search Console’da ülkeler ayrı takip edilebiliyor mu?

Hreflang’ı bundan sonra uygulamak çok daha kolay. Çünkü asıl zor olan kod değil.

Hangi kullanıcı için hangi sayfanın doğru olduğuna karar vermek.

Sonuç olarak

Uluslararası SEO’yu “Siteyi İngilizceye çevirelim.” seviyesinde görmemek gerekiyor. Aynı dilde bile kullanıcı deneyimi ülkeye göre değişebilir.

İngilizce en olabilir. Ama gerektiğinde en-US ve en-GB olarak ayrılabilir. Türkçe tr olabilir. Türkiye hedefinde tr-TR kullanılabilir. Dolayısıyla hreflang kodlarını ezbere türetmek hata çıkarabilir.

Site mimarisinde de tek doğru yöntem yok. Google hem alt dizinleri hem subdomain’leri destekliyor. Ancak ben çoğu projede alt dizini mevcut sitenin doğal devamı, subdomain’i ise yönetim açısından daha bağımsız bir yapı gibi düşünmenin faydalı olduğunu düşünüyorum.

Ve belki bu bölümün en önemli cümlesi şu:

Uluslararası SEO çeviri işi değil, pazar işidir.

Doğru dil, doğru ülke, doğru arama davranışı, doğru fiyat, doğru ürün, doğru URL ve doğru teknik sinyal bir araya geldiğinde anlamlı hale geliyor.

Bir sayfayı başka dile çevirmek birkaç dakika sürebilir. Ama başka bir pazarda gerçekten bulunabilir olmak çok daha kapsamlı bir çalışma gerektirir.

Önceki: 25. Bölüm, Google Sayfanızı Daha İyi Nasıl Anlıyor? · İçindekiler · Sonraki: 27. Bölüm, Google Bazı Sitelere Neden Daha Çok Güveniyor?

Bu bölümün ilk hali X’te yayınlandı (30 Eylül 2026).