Magento 2 üzerinde çok dilli bir mağaza kurarken hreflang'ın çalışmaması genellikle etiket sözdiziminden kaynaklanmaz. Sorun, Magento'nun kendi çok mağaza mimarisinin, hreflang'ın beklediği "bir dil, bir sabit URL" mantığıyla aynı katmanda düşünülmemesinden çıkar. Store View, Store Group ve Website üçlüsü platformun temel iskeletidir, ama bu iskelet SEO ekibi için değil, katalog ve envanter yönetimi için tasarlanmıştır.
Bu fark pratikte şöyle görünür: geliştirici ekip yeni bir dil için store view açar, locale ayarını doğru seçer, temayı bağlar ve mağaza görsel olarak sorunsuz çalışır. Hreflang etiketi ise Magento çekirdeğinde hiçbir zaman otomatik üretilmez; bu adım atlanırsa dil versiyonları birbirinden habersiz, tek başına duran sayfalar olarak kalır.
Aşağıda store view hiyerarşisinin dil yönetimiyle ilişkisi, bu ilişkinin hreflang'a neden doğrudan yansıması gerektiği, locale ayarının kod eşlemesiyle nasıl kesiştiği ve kurulum sonrası hangi kontrollerin yapılması gerektiği ele alınıyor.
Magento 2'de Store View, Store Group ve Website hiyerarşisi dil yönetimini nasıl şekillendirir?
Magento'nun mimarisi üç katmanlıdır: en üstte Website, onun altında Store (Store Group olarak da anılır), en altta ise Store View yer alır. Website katmanı genellikle domain veya marka ayrımını temsil eder; Store katmanı bir katalog kök kategorisiyle eşleşir; Store View ise ziyaretçinin gerçekten gördüğü, kendi locale'i, kendi tema ayarı ve kendi fiyat/vergi kuralı olabilen en granüler birimdir.
Dil yönetimi bu üçlüde çoğunlukla Store View seviyesinde yapılır. Bir Store Group altında birden fazla Store View açılıp her birine ayrı bir locale atanabilir; aynı katalog, aynı kök kategori, farklı dillerde sunulur. Bu yaklaşım Magento dokümantasyonunda önerilen standart çok dilli kurulum şeklidir, çünkü ürün verisini tekrar girmeden dil bazlı içerik (ürün adı, açıklama, meta veri) attribute seviyesinde store view'a göre override edilebilir; bu katman çok dilli ürün sayfası kararlarıyla aynı yerde kesişir.
Ama bu granülerlik bir maliyetle gelir: her store view'ın kendi Base URL'i olabilir (Stores > Configuration > General > Web > Base URLs, scope: store view), ve bu URL bir alt dizin, bir alt domain veya tamamen ayrı bir domain olabilir. Hreflang'ın ihtiyaç duyduğu "her dile ayrı, kalıcı, kendine referans veren URL" şartı burada teknik olarak sağlanabilir, ama bu sağlanmışlığın otomatik bir hreflang çıktısına dönüşmesi için ayrıca bir mekanizma kurulması gerekir. Magento çekirdeği bu store view'ları birbirine bağlayan hiçbir SEO etiketi üretmez; store view'lar birbirinin varlığından habersiz, izole domain kümeleri gibi davranır.
Bu hiyerarşi hreflang üretimi için neden yapısal bir zorunluluk oluşturur?
Hreflang'ın çalışması, aynı ürünün veya sayfanın farklı dil sürümleri arasında karşılıklı bir referans ağı kurulmasına bağlıdır. Magento'da bu ağın kurulabilmesi için önce hangi store view'ın hangi store view'ın "dil kardeşi" olduğu tanımlanmalıdır; bu bilgi platformda hazır bir alan olarak durmaz, entity mapping ile elle oluşturulmalıdır.
Store view'lar arası eşleme genellikle ürünün store_id ilişkisi üzerinden kurulur: aynı temel ürün (product entity), farklı store view'larda farklı görünüm attribute'larıyla var olur, ama bu görünümler arasında bağlantı ürün seviyesinde zaten mevcuttur. Kategori ve CMS sayfaları için durum daha karmaşıktır; bir kategori bir store group'a atanır, ama aynı kategori farklı bir store group'ta farklı bir URL key ile de var olabilir. Hreflang üretimi bu iki farklı senaryoyu (aynı entity, farklı store view / farklı entity, benzer içerik) ayırt edebilmelidir, aksi halde ürün sayfaları için doğru çalışan bir çözüm kategori sayfalarında kırılır.
Website katmanı ayrımı ek bir karmaşıklık ekler. Farklı Website'lere yayılmış store view'lar arasında bağlantı kurmak, aynı Website altındaki store view'lar arasında kurmaktan daha zordur, çünkü bazı kurulumlarda her Website ayrı bir veritabanı bağlantısı veya ayrı bir domain ile çalışır. Bu senaryoda hreflang eşlemesi, ürün ID'lerinin Website'ler arası karşılığını tutan ayrı bir tablo veya attribute gerektirir; bu tablo katalog güncellendiğinde senkron tutulmazsa, zamanla eksik veya yanlış eşleşen hreflang çiftleri birikir.
Bu üç katmanın pratikte nasıl ayrıştığını görmek için tipik bir Avrupa mağazası örneği faydalıdır. Bir Website Almanya ve Avusturya pazarları için, ayrı bir Website ise İngiltere pazarı için kurulmuş olabilir; her Website altında bir Store Group, o Store Group altında ise dil bazlı Store View'lar bulunur. Almanya Website'i altındaki Almanca ve İngilizce store view'ları birbirine bağlamak nispeten kolaydır, çünkü aynı veritabanı bağlantısını ve aynı katalog kök kategorisini paylaşırlar. Ama Almanya Website'indeki Almanca sayfayı İngiltere Website'indeki İngilizce sayfaya bağlamak, iki bağımsız katalog yapısı arasında elle kurulmuş bir eşleme ister; bu eşleme genellikle ürünün SKU değeri veya harici bir kimlik üzerinden yapılır, çünkü dahili entity ID'leri iki Website arasında örtüşmeyebilir.
Locale Options ayarı hreflang koduyla nasıl eşleşir?
Stores > Configuration > General > General > Locale Options altında her store view için seçilen locale (örneğin de_DE, en_US, tr_TR), Magento'nun tarih biçimi, sayı biçimi ve çeviri dosyası seçimini belirler. Bu değer doğrudan bir hreflang kodu değildir. Hreflang tire kullanır, alt çizgi değil; dil kodu küçük harf, bölge kodu büyük harf: de-DE, en-GB, tr-TR. Magento locale'sindeki alt çizgi bu forma dönüştürülmeden hreflang attribute'una yazılırsa etiket standarda uymaz. Dönüşüm elle veya bir extension katmanında yapılmalıdır.
Daha sık rastlanan hata, birden fazla store view'ın aynı locale'e sahip olmasıdır. Örneğin İngilizce konuşulan üç farklı pazar (ABD, İngiltere, Avustralya) için üç store view açılmış ama üçü de en_US locale'inde bırakılmışsa, hreflang eşlemesi bu üç store view'ı birbirinden ayıramaz; sistem hangi store view'ın en-US, hangisinin en-GB, hangisinin en-AU olduğunu locale alanından çıkaramaz; aynı dilde farklı ülkeleri ayırmak burada ayrı bir kod katmanı ister, çünkü üçü de aynı değeri taşır. Bu durumda hedef dil/bölge kodu, locale'den bağımsız ayrı bir attribute veya konfigürasyon değeri olarak tanımlanmalıdır.
Locale seçimiyle store view'a atanan Base URL arasında da bir tutarlılık beklenir. Bir store view tr_TR locale'inde ama Base URL'i /en/ önekiyle yapılandırılmışsa, bu tutarsızlık doğrudan hreflang hatası üretmez ama kurulumu okuyan herkes için (hem geliştirici hem arama motoru) kafa karıştırıcı bir sinyal oluşturur. Locale, URL öneki ve hreflang kodu üçü aynı mantığı yansıtmalıdır.
Bölgesel varyantlarda bu eşleme daha da hassaslaşır. de_DE ve de_AT locale'leri Magento'da iki farklı değer olarak tanınır ve iki farklı çeviri dosyasına, iki farklı sayı/para birimi biçimine bağlanabilir; ama bu ayrım otomatik olarak de-DE ve de-AT hreflang kodlarına dönüşmez, çünkü dönüşüm katmanı devreye girmediği sürece Magento locale değerini hiçbir SEO alanına yazmaz. Bir mağaza Almanya ve Avusturya için ayrı store view açmışsa ama hreflang üretimi ikisini de tek bir de koduna indirgiyorsa, bölgesel ayrım fiilen kaybolur ve arama motoru iki pazarı birbirinden ayıramaz.
Hreflang etiketleri Magento'da nasıl üretilir: native eksiklik ve çözüm yolları
Magento 2 çekirdeği, canonical etiket üretimini destekler ama hreflang için hazır bir mekanizma sunmaz. Bu boşluk üç şekilde doldurulur: layout XML üzerinden özel bir block eklemek, mevcut bir head block'unu override etmek veya Magento Marketplace'teki hazır bir hreflang modülünü kurmak. Üçü de sonuçta <head> içine <link rel="alternate" hreflang="..." href="..."> satırlarını yazar, ama veri kaynakları farklıdır.
Özel block yaklaşımında geliştirici, mevcut sayfanın entity ID'sini (ürün, kategori veya CMS sayfa ID'si) alıp bu ID'nin diğer store view'lardaki karşılığını sorgular ve her karşılık için store view'ın Base URL'i ile birleştirilmiş bir href üretir. Bu yaklaşım tam kontrol sağlar ama entity eşleme mantığının (ürün ID'si sabit kalıyor mu, yoksa store view başına farklı ID mi kullanılıyor) doğru anlaşılmasını gerektirir; EAV yapısında aynı ürün genellikle aynı ID'yi korur, ama özel içe aktarma süreçleriyle kurulmuş mağazalarda bu varsayım her zaman geçerli olmayabilir.
Hazır modül yaklaşımı daha hızlı kurulur ama modülün store view eşlemesini nasıl yaptığını (otomatik mi, manuel konfigürasyon tablosu mu) anlamadan bırakmak riskli olur. Bazı modüller yalnızca aynı Website içindeki store view'lar arasında otomatik eşleme yapar, Website sınırını geçen eşlemeleri manuel tanım ister. Bu sınırın fark edilmemesi, çok Website'li kurulumlarda bir kısım dilin hreflang ağına hiç girmemesine yol açar.
Hangi yöntem seçilirse seçilsin, üretilen etiketin kendine referans veren (self-referencing) satırı içermesi zorunludur; her dil sürümü kendi URL'ine de bir hreflang satırıyla işaret etmelidir, sadece diğer dillere değil. Bu satırın unutulması, Prestashop ve WooCommerce gibi diğer platformlarda da sık görülen ve genellikle fark edilmesi en zor hatalardan biridir, çünkü etiket bloğu "dolu" görünür, sadece bir satır eksiktir.
Store view kod eşlemesi nerede hataya düşer?
Stores > All Stores ekranında her store view'a bir "Code" (store code) atanır; Add Store Code to Urls ayarı açıksa bu kod URL'in bir parçası olarak görünür (site.com/de/urun gibi). Bu store code, locale ile aynı şey değildir ve birbirine karıştırılması hreflang eşlemesinde sık görülen bir hata kaynağıdır. Store code germany gibi keyfi bir string olabilirken, hreflang'ın beklediği kod ISO standardına uygun de veya de-DE olmalıdır; modül veya özel kod bu ikisini birbirine eşleyecek açık bir konfigürasyon olmadan doğrudan store code'u hreflang değeri olarak kullanırsa, standart dışı bir etiket üretilir.
İkinci hata noktası, store view silindiğinde veya devre dışı bırakıldığında eski eşleme kayıtlarının temizlenmemesidir. Bir kampanya için açılan geçici bir store view daha sonra kapatıldığında, ona referans veren hreflang satırları başka sayfalarda hâlâ üretiliyor olabilir; bu satırlar 404 veya yönlendirmeye düşen bir href'e işaret eder ve Google bu tür kırık alternatifleri güvenilmez bulur.
Üçüncü hata noktası, staging ve production ortamları arasında store view konfigürasyonunun birebir taşınmamasıdır. Staging'de test amaçlı eklenen bir store view, production'a deploy sırasında farklı bir Base URL veya farklı bir store code ile canlıya çıkarsa, hreflang üretim kodu eski değerlere göre yazılmış olabilir. Bu tutarsızlık, deploy sonrası ilk taramada fark edilmeyip haftalar sonra Search Console raporlarında ortaya çıkabilir.
Kurulum sonrası kontrol: her store view'ın hreflang çıktısı nasıl doğrulanır?
İlk kontrol, her store view için en az bir ürün ve bir kategori sayfasının kaynak kodunu açıp hreflang bloğundaki her href değerinin gerçekten o store view'ın Base URL'i altında çalıştığını teyit etmektir. Bir href tarayıcıda açıldığında 404 veriyorsa veya farklı bir store view'a yönlendiriyorsa, entity eşlemesinde bir kopukluk var demektir.
İkinci kontrol, aynı sayfanın tüm dil sürümlerinde self-referencing satırının mevcut olduğunu doğrulamaktır. Bu genellikle tarayıcı geliştirici araçlarında "hreflang" araması yaparak veya sayfa kaynağını kelime bazında tarayarak yapılır; her sürümde kendi diline işaret eden bir satır bulunmalı, sadece karşı dillere değil.
Üçüncü kontrol, store code ile hreflang kodu arasındaki eşlemenin bir tablo halinde belgelenmesidir. Bu tablo, yeni bir store view açıldığında hangi hreflang kodunun kullanılacağını önceden netleştirir ve URL yapısı kararı alınırken store code seçimini de bu netlik üzerinden yapmayı sağlar. Aynı tablo, ileride bir store view kapatıldığında hangi hreflang referanslarının da kaldırılması gerektiğini hatırlatan bir kontrol listesine dönüşür.
Dördüncü kontrol, Search Console'daki Kapsam raporunun "Alternatif sayfa, uygun canonical etiketine sahip" veya dönüş etiketi eksikliği kategorilerinde Magento store view'larına özgü bir birikim gösterip göstermediğini periyodik olarak izlemektir. Website sınırını geçen eşlemelerde bu hataların yoğunlaşması, o sınırın ötesindeki store view çiftlerinin hâlâ manuel eşleme beklediğinin işaretidir.
Son olarak, Magento'ya özgü bu store view mimarisinin genel hreflang mantığından tamamen ayrı bir sistem olmadığını görmek, teşhisi kolaylaştırır. Hreflang'ın temel çalışma kuralları her platformda aynıdır; değişen tek şey, bu kuralların Magento'nun Website, Store Group ve Store View katmanlarına nasıl haritalandığıdır. Bu haritalama net kurulduğunda, genel hata tespit sürecinin Magento'ya uygulanması da doğrudan mekanik bir kontrol listesine dönüşür.