Çok Dilli SEO Mimarisi: Hreflang, Kanonik Etiketler ve Gerçek URL Stratejisi

Bir web sitesi birden çok dilde içerik sunduğunda veya birden çok ülkeyi hedeflediğinde, temel mimari arama görünürlüğü için belirleyici bir faktör haline gelir. Müşterilerimizin, *çok dilli* ve *çok uluslu* SEO'yu birbirine karıştırdıkları veya hreflang'ı sonradan akıllarına geldiği gibi uyguladıkları için aylarca süren sıralama kazanımlarını kaybettiklerini gördük. DigiForge'de uluslararası mimariyi, hosting ve HTTPS ile aynı seviyede, temel bir katman olarak ele alıyoruz. Bu makale, bu temelin üç direğini ele alıyor: URL stratejisi, hreflang uygulaması ve canonical yönetimi. Ayrıca ekip iş akışlarına da değineceğiz çünkü iyi bir koordinasyon olmadan en iyi teknik kurulum bile çöker.

Çok Dilli ve Çok Uluslu: Farkı Bilin

Teknik seçimlere dalmadan önce, çok dilli ve çok uluslu SEO arasındaki ayrımı yapmak kritik öneme sahiptir. Search Engine Land'in açıkladığı gibi, çok dilli SEO, genellikle aynı dili konuşan birden çok ülkedeki kullanıcılara farklı dillerde içerik sunmaya odaklanır. Çok uluslu SEO ise, aynı dilde olabilen ancak yerel tercihlere, düzenlemelere veya para birimlerine uyarlanmış içerikle farklı ülkeleri hedefler. Çok dilli bir site, tüm Fransızca konuşanlar için tek bir URL yapısı kullanabilirken, çok uluslu bir sitenin dil aynı olsa bile Fransa, Kanada ve İsviçre için ayrı sürümlere ihtiyacı olabilir. Bu ayrımı anlamak, URL modelinizi ve hreflang stratejinizi en baştan şekillendirir.

URL Stratejisi: Alt Alan Adları, Alt Dizinler ve Ülke Kodlu Üst Düzey Alan Adları

Doğru URL yapısını seçmek, en önemli ve en sonuç doğuran karardır. Kabaca üç desen vardır ve her birinin tarama bütçesi, bağlantı eşitliği ve kullanıcı deneyimi üzerinde etkileri olan ödünleşimleri vardır. Seçim genellikle farklı dilleri mi yoksa farklı ülkeleri mi hedeflediğinizle iç içe geçer.

Ülke Kodlu Üst Düzey Alan Adları (ccTLD'ler)

example.fr veya example.de gibi bir ccTLD, en güçlü coğrafi hedefleme sinyalini gönderir. Arama motorları alan adını o ülkeyle ilişkilendirir ve kullanıcılar içgüdüsel olarak ona güvenir. Dezavantajı operasyonel karmaşıklıktır: her ccTLD ayrı bir alan adıdır, bu nedenle ayrı SSL sertifikaları, ayrı hosting yapılandırmaları gerekir ve bağlantı eşitliği aralarında akmaz. Sadece iki veya üç pazarda faaliyete geçen bir işletme için bu kabul edilebilir olabilir. Otuz pazar için ise bir bakım kabusuna dönüşür. Dahası, içeriğiniz ccTLD'ler arasında aynıysa (örneğin küresel bir marka sitesi), otoriteyi seyreltir ve tarayıcıları her alan adını bağımsız olarak keşfetmeye zorlarsınız.

Alt Alan Adları

fr.example.com gibi bir alt alan adı modeli, ccTLD'lerden daha kolay yönetilir ancak siteyi tarayıcı açısından yine de böler. Google, alt alan adlarını ayrı varlıklar olarak ele alır, bu nedenle ana alan adından gelen bağlantı değeri otomatik olarak alt alan adına geçmez. Ayrıca ayrı analiz özellikleri kurmanız gerekir ve çerez kapsamı sorunlarıyla karşılaşabilirsiniz. Bununla birlikte, alt alan adları, içerik veya ekip sahipliği açısından büyük ölçüde farklılık gösteren dil varyantları için yararlı olabilir; örneğin, Almanya ekibiniz bağımsız olarak çalışıyorsa ve kendi teknoloji yığınını kullanıyorsa. Ancak çoğu proje için alt alan adlarının gereksiz sürtüşme yarattığını düşünüyoruz.

Alt Dizinler (veya Alt Klasörler)

DigiForge'da varsayılan önerimiz alt dizin yaklaşımıdır: example.com/fr/ veya example.com/de/. Tüm içerik aynı kök alan adı altında yaşar, böylece bağlantı değeri doğal olarak birikir, analizler tek bir noktada toplanır ve SSL tek bir sertifikadır. Google ayrıca, hreflang ve meta etiketleriyle eşleştirildiğinde alt dizin yolunu bir coğrafi hedefleme sinyali olarak kullanır. Ana risk, kötü yapılandırılmış bir alt dizin ağacının kök alan adının konu otoritesini sulandırabilmesidir, ancak pratikte dil klasörlerini temiz tutar ve uygun dahili bağlantı kullanırsanız bu nadirdir. İyi organize edilmiş bir alt dizin yapısı ayrıca uluslararası genişlemeyi basitleştirir; yeni bir dil eklemek, kendi hreflang ek açıklamalarına sahip yeni bir klasör oluşturmak anlamına gelir.

Her duruma uyan tek bir cevap yoktur. Yalnızca Japonya'yı bir .jp alan adından hedefliyorsanız, ccTLD ekstra çabaya değer olabilir. Ancak Kanada, İsviçre ve Fransa'daki Fransızca konuşanlara hizmet veriyorsanız, her bölge için hreflang ek açıklamalarına sahip tek bir /fr/ klasörü, üç ayrı alan adından daha verimlidir. Anahtar, iş hedeflerinizi teknik modele erken haritalamak ve kararı belgelemektir.

Hreflang Uygulaması: En Zor Kısım

Hreflang, arama motorlarına bir sayfanın hangi dil veya bölgesel sürümünün belirli bir yerde gösterileceğini söyler. Yanlış yapılmasıyla ünlüdür. En yaygın hata, hreflang'ı canonical etiketlerin yerine kullanmaktır; oysa bunlar farklı amaçlara hizmet eder. Bir diğer sık yapılan hata, kendine referans veren hreflang girişlerini atlamaktır. Bir diğer yaygın hata, dil-bölge kodlarının uyuşmamasıdır: örneğin, en-GB yerine en-uk kullanmak. Bu hatalar genellikle trafik düşene kadar fark edilmez.

Sözdizimi ve Yerleştirme

Hreflang ek açıklamalarını belirtmek için üç seçeneğiniz vardır: HTML <head> içinde <link> öğeleri olarak, HTTP başlığında (PDF gibi HTML olmayan dosyalar için) veya bir XML site haritasında. Bir avuçtan fazla dil varyantı olan siteler için site haritası yöntemini şiddetle tercih ediyoruz, çünkü işaretlemeyi HTML dışında tutar ve denetimi kolaylaştırır. Hangi yöntemi seçerseniz seçin, her dil sürümü kendisine ve diğer tüm sürümlere geri dönen bir bağlantı içermelidir. Bu, varsayılan veya yedek sayfayı da içerir ve x-default kullanmalıdır. Kendine referans veren bağlantıyı asla atlamayın; arama motorları, ilişkiyi doğrulamak için hreflang'ın karşılıklı doğasına güvenir. Bu olmadan, ek açıklamayı tamamen yok sayabilirler.

<url>
  <loc>https://example.com/en/</loc>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/" />
  <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
  <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/" />
  <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/" />
</url>

Dil ve Bölge Kodları

ISO 639-1 dil kodlarını (ör. en, fr) ve gerektiğinde ISO 3166-1 alpha-2 bölge kodlarını (ör. en-GB, fr-CA) kullanın. Bölge kodu isteğe bağlıdır ancak aynı dil ülkeye göre farklılık gösterdiğinde kritik önem taşır — örneğin en-US ve en-GB gibi. Kodları asla tahmin etmeyin; doğruluğunu kontrol edin. Küçük bir yazım hatası bile (ör. küçük harfli en-gb) ek açıklamayı bozabilir. Ayrıca, dil belirtmeyen sayfalar (ör. bir açılış sayfası) için x-default kullanımı zorunludur. Aksi takdirde kullanıcılar istenmeyen bir dil sürümünü görebilir.

Neredeyse Aynı İçeriği Yönetme

İçerik diller arasında temelde aynı olduğunda (ör. yalnızca dil değişiklikleri olan küresel bir marka sayfası), yalnızca hreflang yeterlidir — her varyant için ayrı canonical belirtmeniz gerekmez. Ancak aynı konuyu ele alan ancak bağımsız yazılmış bir İngilizce ve bir Fransızca sayfanız varsa, her sayfa kendi URL'sini işaret eden bir self-referencing canonical'e sahip olmalı ve hreflang bunları alternatif olarak bağlamalıdır. Canonical ve hreflang nitelikleri bir arada bulunur; biri diğerini geçersiz kılmaz. Yaygın bir yanılgı, hreflang'ın bir canonical ilişkisi ima ettiğidir — oysa etmez. Bunlar birbirinden bağımsız sinyallerdir.

Diller Arasında Canonical Etiketleri: Hassas Bir Denge

Canonical etiketi, arama motorlarına yinelenen sayfalar arasında hangi sürümün yetkili olduğunu söyler. Çok dilli bir bağlamda sıklıkla kafa karışıklığı yaşanır: bazı ekipler tüm dil varyantlarının canonical'ini varsayılan dil URL'sine ayarlar. Bu neredeyse her zaman yanlıştır. Google'a Fransızca sayfanın İngilizce sayfanın bir kopyası olduğunu ve dizine eklenmemesi gerektiğini söyler. Sonuç: Fransızca trafiğiniz kaybolur. Bu tek hata nedeniyle tüm dil bölümlerinin dizinden kaldırıldığı siteler denetledik.

Doğru yaklaşım, her dil sürümünün canonical etiketini kendisine işaret edecek şekilde ayarlamaktır. Gerçekten aynı içeriğe sahipseniz (örneğin, makine çevirisiyle değişiklik yapmadan çevirdiğiniz ürün açıklamaları), bunların alternatif olduğunu belirtmek için hreflang kullanabilirsiniz — ancak canonical yine de kendine referans vermelidir. Arama motorları, hreflang ile bağlanan sayfaların kopya olmadığını, farklı kitlelere yönelik dil varyantları olduğunu anlar. Tek bir meşru istisna vardır: sendikasyon içerik. Ana sitenizde İngilizce olarak yayınladığınız bir makalenin aynısını bir partner sitesinde İspanyolca olarak yayınlıyorsanız, İspanyolca sayfa için canonical olarak İngilizce URL'yi kullanabilirsiniz — ancak yalnızca hreflang da kullanmıyorsanız. Diller arası bir canonical ile hreflang'ı karıştırmak çelişkili sinyaller gönderir. Pratikte, müşterilerimize bu durumdan tamamen kaçınmalarını ve bunun yerine her dil için benzersiz içerik oluşturmalarını öneririz.

DigiForge'da bir kez, Almanca bölümün tamamında rel="canonical" İngilizce eşdeğerine işaret eden bir site denetlemiştik. Almanca sayfalar ya dizine eklenmemişti ya da düşük sıralamadaydı. Canonical'ları kendine referans olacak şekilde düzeltmek — uygun hreflang ile birlikte — Almanca sayfaları haftalar içinde dizine geri getirdi.

Ekip İş Akışları: Mimarîyi Canlı Tutmak

Teknik mimari savaşın sadece yarısıdır. Farklı pazarlardaki ekipler arasındaki koordinasyon, uygulamanın bir yeniden tasarımdan sağ çıkıp çıkmayacağını belirler. Search Engine Journal, işbirliğini teşvik etmek için pratik adımlar özetliyor: ekip üyelerinin ipuçlarını ve içgörüleri paylaştığı küçük bir Slack kanalı veya intranet klasörüyle başlayın. Zamanla, üç aylık bilgi paylaşım oturumlarına veya bölgesel atölyelere dönüşün.

SEO en iyi uygulamalarını — özellikle hreflang ve canonical kurallarını — projeyle birlikte taşınan canlı bir kılavuzda belgelemenin gerekli olduğunu gördük. Çok fazla uluslararası site, bir pazardaki geliştiricinin XML site haritası hreflang ek açıklamalarını güncellemeden yeni bir dil klasörü eklemesi nedeniyle bozulur. Tek bir doğruluk kaynağına (paylaşılan bir belge veya sürüm kontrolünde bir yapılandırma dosyası) sahip olmak bu hataları önemli ölçüde azaltır. Ayrıca, tüm pazarların erişebileceği, doğru işaretleme örnekleri içeren merkezi bir SEO kılavuzu oluşturmanızı öneririz. CI/CD ile güncellenen, tüm dil sürümlerini içeren paylaşılan bir site haritası dizini kullanın. hreflang karşılıklılığını ve canonical kendine referanslarını doğrulayan otomatik testler kurun. Son olarak, erken sapmaları yakalamak için teknik SEO ve yerelleştirme ekipleri arasında aylık bir senkronizasyon toplantısı yapın.

Otomasyon en iyi dostunuzdur. Site haritasını tarayan ve her hreflang ek açıklamasının karşılıklı olduğunu kontrol eden komut dosyaları yazıyoruz. lxml kullanan basit bir Python betiği, eksik kendine referansları veya bozuk bölge kodlarını yakalayabilir. Bu kontrolleri dağıtım hattınıza entegre edin, böylece yanlış yapılandırılmış bir site haritası asla üretime ulaşmaz.

import requests
from lxml import etree

# Example check: verify hreflang reciprocity
sitemap_url = 'https://example.com/sitemap.xml'
response = requests.get(sitemap_url)
root = etree.fromstring(response.content)
ns = {'xhtml': 'http://www.w3.org/1999/xhtml'}

urls = {}
for url in root.findall('{http://www.sitemaps.org/schemas/sitemap/0.9}url'):
    loc = url.find('{http://www.sitemaps.org/schemas/sitemap/0.9}loc').text
    alternates = url.findall('xhtml:link', ns)
    for alt in alternates:
        hreflang = alt.get('hreflang')
        href = alt.get('href')
        if href == loc and hreflang:
            # self-reference found
            pass
        else:
            # check if href reciprocates
            pass
# More robust logic needed in practice

Gerçek bir üretim kontrolü, her dil sayfası için tüm alternatiflerin karşılıklı olduğunu doğrulamalıdır. Bu, sıralamaları etkilemeden önce en yaygın hataları yakalar. Bu kontrolleri genellikle her dağıtımda çalıştırır ve herhangi bir tutarsızlık bulunursa ekibi uyarırız.

Hepsini Bir Araya Getirmek: Stratejik Bir Çerçeve

Her çok dilli site benzersizdir, ancak yapılandırılmış bir karar sürecinin en yaygın hatalardan kaçınmaya yardımcı olduğunu gördük. Hedef kitlenizin dillere mi, ülkelere mi yoksa her ikisine mi yönelik olduğunu netleştirerek başlayın. Ardından operasyonel kapasitenize uygun bir URL modeli seçin. Hreflang'ı satır içi HTML yerine site haritasında uygulayın ve her sayfanın canonical etiketinin kendisini işaret ettiğinden emin olun. Son olarak, ekip iletişimine ve otomatik kontrollere yatırım yapın.

İşte DigiForge'da çok dilli bir mimari planlarken kullandığımız hızlı bir kontrol listesi:

• Hedef kitleleri tanımlayın: dile göre mi, ülkeye göre mi, yoksa her ikisine göre mi?
• URL modelini seçin (ccTLD, alt alan adı veya alt dizin) ve nedenini belgeleyin.
• Site haritalarında x-default ve kendine referansları içerecek şekilde hreflang'ı ayarlayın.
• Her dil sayfasının kendine referans veren bir canonical'e sahip olduğundan emin olun.
• Paylaşılan bir SEO stil kılavuzu ve dağıtım süreci oluşturun.
• CI/CD hattında otomatik doğrulama uygulayın.
• Google Search Console'da dil bazında indeks kapsamını izleyin.

Ödül, arama motorlarının belirsizlik olmadan anladığı bir sitedir — Quebec'teki bir kullanıcı fr-CA sürümünü, Berlin'deki bir kullanıcı de sürümünü alır ve diğer herkes x-default sürümüne düşer. Bu düzeyde bir hassasiyet bir lüks değildir; küresel çapta rekabet etmek ile uluslararası alanda görünmez olmak arasındaki farktır.

Uluslararası bir genişleme planlıyorsanız veya eski bir çok dilli yapıyı çözmeniz gerekiyorsa, DigiForge ile iletişime geçin. Bu mimarilerden yeterince inşa ettik ve denetledik; işe yarayan kısayolları ve yanlış gidenleri biliyoruz.