Breadcrumb, çoğu zaman UX kararı olarak değerlendirilir ve teknik SEO tartışmalarında ikinci plana düşer. Tek dilli bir sitede bu yaklaşım kabul edilebilir; breadcrumb büyük ölçüde gezinme kolaylığı sağlar, arama motoru tarafında ise görece basit bir yapısal sinyal üretir. Çok dilli bir sitede tablo değişir. Her dil sürümünün kendi URL hiyerarşisi vardır, her sürüm için ayrı bir breadcrumb yolu kurulması gerekir ve bu yolun hem görsel gösterimde hem de yapısal veri katmanında tutarlı olması beklenir.
Pratikte en sık karşılaşılan sorun, CMS'in breadcrumb'ı otomatik üretmesi ve bu üretimin dil bazında doğrulanmamasıdır. İngilizce sürüm için doğru çalışan bir breadcrumb yapılandırması, Almanca ya da Japonca sürümde yanlış URL'ler, çevrilmemiş kategori adları veya canonical ile çelişen bağlantılar üretebilir. Bu tutarsızlıklar tek tek küçük görünse de bir arama motoru toplu olarak taradığında site hiyerarşisi hakkında çelişkili sinyaller alır.
Breadcrumb yapısını çok dilli bağlamda doğru kurmak için birkaç farklı kararın bağımsız değil birlikte ele alınması gerekir: görsel breadcrumb'da dil kodunun gösterilip gösterilmeyeceği, BreadcrumbList schema'sındaki URL'lerin hangi sürüme ait olması gerektiği, canonical ile breadcrumb yolunun nasıl hizalanacağı ve farklı URL yapılarında (alt dizin, subdomain) kök öğenin nereye işaret edeceği.
Breadcrumb'ın çok dilli sitede üstlendiği ek görev
Tek dilli sitede breadcrumb "Neredesiniz?" sorusunu yanıtlar: Ana Sayfa > Kategori > Alt Kategori > Sayfa. Bu yol hem kullanıcıya hem de arama motoruna site hiyerarşisini gösterir. Çok dilli sitede bu yol dil sürümüne özgü bir hiyerarşi haline gelir — ve her sürümün kendi yolunun tutarlı biçimde tanımlanmış olması gerekir.
Google, BreadcrumbList schema'sını kullanarak arama sonuçlarında breadcrumb'ı görsel olarak gösterir. Bu görünüm tıklama oranını etkiler ve kullanıcıya sayfanın site içindeki konumunu önceden iletir. Çok dilli sitelerde her dil sürümünün schema'sı o sürüme ait URL'leri içermelidir. Almanca sürüm için BreadcrumbList schema'sında İngilizce URL'lerin yer alması, teknik olarak geçerli ama anlam açısından hatalı bir yapı üretir.
Bunun ötesinde breadcrumb, URL yapısı kararlarını somutlaştıran bir katmandır. Alt dizin yapısında /de/ prefixi breadcrumb'ın kök öğesini etkiler; subdomain yapısında de.example.com aynı rolü farklı biçimde üstlenir. Bu fark küçük görünebilir; ancak arama motorunun site otoritesini nasıl dağıttığını ve dil sürümleri arasındaki hiyerarşik ilişkiyi nasıl yorumladığını etkiler.
Dil kodu breadcrumb'da görünmeli mi?
URL'de bulunan dil kodu (/en/, /de/, /tr/) breadcrumb yolunun görsel gösteriminde yer almalı mı? Pratikte buna gerek yoktur ve çoğu durumda kullanıcı deneyimini olumsuz etkiler. "Ana Sayfa > /de > Ürünler > Ürün Adı" şeklinde bir breadcrumb yolu gereksiz bir teknik bilgiyi öne çıkarır.
Doğru yaklaşım şudur: görsel breadcrumb'da dil kodunu gizle, ancak BreadcrumbList schema'sındaki item URL'lerinde dil kodunu tam olarak kullan. Yani kullanıcı "Ana Sayfa > Ürünler > Ürün Adı" görürken schema katmanında item: "https://example.com/de/produkte/" doğru biçimde tanımlanmış olur.
Burada sık yapılan hata ise tam tersidir: görsel breadcrumb doğru dil kodu içeren URL'lerle çalışırken schema'daki URL'ler dil kodu olmadan yazılır ya da ana dil URL'leri kopyalanır. Bu durumda Google, schema'dan aldığı URL bilgisini sayfanın canonical'ıyla karşılaştırır ve tutarsızlık tespit eder. Çok dilli sitelerde yapısal veri yönetiminde bu tür uyumsuzluklar denetim listesinin kalıcı bir maddesi olmalıdır.
BreadcrumbList schema'sı dil sürümlerine göre nasıl kurulur?
Her dil sürümü kendi BreadcrumbList schema'sını içermelidir. Bu schema'nın item alanlarındaki URL'ler, o dil sürümünün canonical URL'leriyle birebir eşleşmelidir. Üç dilli bir sitede Türkçe, İngilizce ve Almanca sayfaların her biri ayrı bir schema bloğu taşır ve bu blokların URL'leri birbirinden farklıdır.
name alanı çevrilebilir: Almanca sürümde "Startseite", Türkçe sürümde "Ana Sayfa", İngilizce sürümde "Home" kullanmak doğrudur. Ancak item alanı asla başka bir dil sürümünün URL'siyle doldurulmamalıdır. Bu kurala uymayan siteler genellikle şu şekilde hata üretir: şablon dosyasından otomatik çekilen breadcrumb schema'sı, dil sürümüne göre dinamik olarak değil sabit URL'lerle yazılır. Sonuç: on dil sürümünün tamamı aynı İngilizce URL'leri içeren schema taşır.
Dinamik schema üretiminin mümkün olmadığı ortamlarda — bazı statik site üreteci kurulumlarında olduğu gibi — her dil için ayrı şablon ya da derleme adımı tanımlamak, bu sorunu sistematik olarak çözmenin tek yoludur. Söz konusu zahmeti göze almayan ekipler çoğunlukla schema'yı tamamen atlamayı tercih eder; bu da arama sonuçlarında breadcrumb görünümünden yoksun kalmak anlamına gelir.
Breadcrumb derinliği de dil sürümleri arasında tutarsız olabilir. İngilizce sürümde dört katmanlı bir hiyerarşi varken Japonca sürüm iki katmana indirgenebilir. Bu asimetri kendi başına bir sorun değildir; ancak schema'nın her sürümün gerçek URL hiyerarşisini yansıtması gerekir. Kopyalanan schema bloğu derinlik farkını gizlediğinde arama motoru yanlış bir hiyerarşi modeli oluşturur.
Canonical URL ile breadcrumb yolu arasındaki uyumsuzluk
Canonical etiket, "bu sayfanın yetkili sürümü budur" mesajını taşır. BreadcrumbList schema'sındaki son item URL'si ise "bu sayfa bu yolun sonundadır" mesajını verir. İkisinin farklı URL'ye işaret etmesi, arama motorunun "hangi URL'yi dizine eklemeliyim?" sorusuna tutarlı bir yanıt alamaması anlamına gelir.
Bu uyumsuzluk en çok faceted navigation veya birden fazla kategori altında görünebilen ürün sayfalarında ortaya çıkar. Bir ürün sayfası hem /tr/elektronik/telefon/model-x hem de /tr/kampanyalar/model-x yoluyla ulaşılabilirse, canonical etiketi bu iki yoldan birini seçer. CMS ise breadcrumb'ı kullanıcının o anki gezinme yoluna göre otomatik oluşturabilir — bu durumda canonical'ın işaret ettiği yol ile breadcrumb'ın gösterdiği yol birbirinden ayrılır.
Çok dilli sitede bu senaryo daha da karmaşık hale gelir çünkü her dil sürümünün canonical URL'si ayrıdır ve CMS'in breadcrumb üretimi her sürüm için bağımsız çalışmayabilir. Uluslararası SEO teknik hatalarını tararken canonical ile breadcrumb schema URL'lerini karşılaştırmak, ihmal edilen ama etkili bir kontrol adımıdır.
Pratik önlem: BreadcrumbList schema üretimini canonical URL'den türetmek. Son item değeri her zaman canonical etiketten alınırsa bu uyumsuzluk sistematik olarak önlenir. Çoğu modern CMS bunu otomatik yapar; ancak özelleştirilmiş şablonlar ve plugin zincirleri bu mantığı bozabilir.
Alt dizin ve subdomain yapılarında breadcrumb kökü
Alt dizin mi subdomain mi kararı, breadcrumb yapısını doğrudan etkiler. İki yapıda kök öğe farklı davranır ve bu farkın bilinçli olarak yönetilmesi gerekir.
Alt dizin yapısında (example.com/de/) breadcrumb'ın kök öğesi tipik olarak iki farklı biçimde kurulur. Birincisi ana alan adının ana sayfasına işaret eder: item: "https://example.com/". Bu tercih, Almanca sayfadan ana domain'e bir bağ kurar ve teorik olarak otorite akışını destekler. İkincisi dil sürümünün ana sayfasına işaret eder: item: "https://example.com/de/". Bu tercih, Almanca sitenin kendi içinde kapalı bir hiyerarşi kurmasını sağlar.
Her iki seçenek teknik olarak geçerlidir; ancak tutarlılık şarttır. Bazı sayfalar ana domain'e, bazıları dil ana sayfasına işaret eden karışık bir breadcrumb yapısı, hiyerarşi sinyalini belirsizleştirir. Subdomain yapısında (de.example.com) kök öğe her zaman o subdomainin ana sayfasını işaret etmelidir. Ana domain'in URL'sini subdomain breadcrumb'ına koymak, farklı origin'ler arasında çapraz işaret üretir ve arama motoru tarafında beklenen hiyerarşik sinyal yerine çelişkili bir sinyal üretebilir.
Subdomain yapısında ayrıca şu senaryo sık görülür: Almanca subdomain'in breadcrumb kök öğesi https://www.example.com/ olarak yazılır çünkü şablon ana domain URL'sini sabit olarak içerir. Bu hata özellikle global şablonların dil subdomain'lerine uyarlanmadan uygulandığı durumlarda ortaya çıkar.
CMS'in otomatik ürettiği breadcrumb'larda nelere dikkat edilmeli?
WordPress, Shopify, Magento ve benzer platformların büyük çoğunluğu breadcrumb'ı otomatik üretir. Bu kolaylık, tek dilli sitelerde ciddi bir sorun yaratmaz. Çok dilli eklentiler devreye girdiğinde ise otomatik üretim her zaman dil bazında doğru çalışmaz.
WordPress ile WPML ya da Polylang kullanan sitelerde en sık karşılaşılan sorun, kategori slug'larının çevrilmediği durumlarda breadcrumb'ın çevrilmemiş slug'ları kullanmasıdır. Örneğin İngilizce "electronics" kategorisi Almanca sürümde "elektronik" olarak çevrilmemişse, Almanca breadcrumb hâlâ "electronics" slug'ını gösterir. Görsel olarak bu düzeltilebilir; ancak BreadcrumbList schema'sındaki item URL'si yanlış slug'ı taşımaya devam edebilir.
Sayfalama da breadcrumb açısından dikkat gerektiren bir senaryodur. Bir kategori sayfasının ikinci sayfası (/de/kategorie/seite/2/) için breadcrumb nasıl kurulmalıdır? İdeal yapı, sayfalandırılmış sayfanın canonical URL'sini son öğe olarak değil, kategorinin kök URL'sini son öğe olarak gösterir — çünkü sayfa 2, kategorinin alt sayfası değil, onun devamıdır. Bu nüansı CMS otomatik olarak çözmez; çoğu durumda manuel şablon müdahalesi gerekir.
Hreflang etiketleri ve breadcrumb schema'sı farklı görevler üstlenir; biri dil sürümleri arasındaki ilişkiyi, diğeri tek bir sürüm içindeki hiyerarşiyi anlatır. Bu iki yapının birbirini desteklemesi için her dil sürümünün hem hreflang kümesinde doğru tanımlanmış olması hem de kendi BreadcrumbList schema'sının o sürüme özgü URL'leri içermesi gerekir.
Breadcrumb, çok dilli SEO'nun görece küçük ama kalıcı bir bakım kalemi olarak değerlendirilmelidir. Yeni bir dil sürümü eklendiğinde, URL yapısı değiştirildiğinde ya da kategori hiyerarşisi yeniden düzenlendiğinde breadcrumb schema kontrolü de bu sürecin bir parçası olmalıdır. Aksi halde küçük tutarsızlıklar birikerek gereksiz tarama yükü ve çelişkili hiyerarşi sinyalleri üretir.
Schema katmanındaki doğruluğu kontrol etmenin en hızlı yolu, Google'ın Zengin Sonuç Test aracını her dil sürümü için ayrı ayrı çalıştırmak ve item URL'lerini o sürümün canonical etiketiyle karşılaştırmaktır. Otomatik breadcrumb üretimi kullanan büyük sitelerde bu karşılaştırmanın periyodik bir denetim adımı olarak planlanması, sorunların erken tespitini sağlar.