Çok Dilli Sitelerde Yapısal Veri (Schema) Kullanımı

Çok dilli sitelerde yapısal veri çoğu zaman görünmeyen ama yorumlanmayı etkileyen bir katmandır. Kullanıcı sayfayı başlık, metin ve görseller üzerinden okur; arama motoru ise bunlara ek olarak schema işaretlerini de bağlam sinyali olarak değerlendirir. Sorun şu ki ekipler bu katmanı ya tamamen ihmal eder ya da kaynak dildeki JSON-LD bloklarını bütün pazarlara aynen taşır.

Bu ikinci yaklaşım özellikle tehlikelidir. Sayfanın görünen yüzeyi Almanca olabilir, ama yapısal veri içindeki ad, açıklama, breadcrumb adı veya offer bilgisi İngilizce kalmıştır. Teknik olarak schema var görünür. Fakat arama motoruna iletilen bağlam ile kullanıcının gördüğü içerik farklılaşır. Yapısal veri bu durumda güç üretmek yerine güveni zedeler.

Yapısal veri, hreflang ya da canonical gibi sinyallerin yerine geçmez. Ama onlarla çelişmemelidir. Çok dilli projede schema kullanımı, "hangi entity bu sayfada temsil ediliyor, bu entity'nin hangi alanları yerelleştirilmeli, hangi alanları sabit kalmalı" sorularına net cevap vermekle başlar.

Schema çok dilli yapıda neden önemlidir?

Çünkü arama motoru yalnızca kelimeleri değil, varlıkları da anlamaya çalışır. Bir ürün sayfası ürün olarak, bir makale sayfası makale olarak, bir breadcrumb yapısı sayfanın hiyerarşisi olarak işaretlendiğinde içerik daha açık yorumlanır. Çok dilli projede bu yorumlama daha da değerlidir; çünkü aynı marka ya da ürün farklı dil yüzeyleriyle birden fazla pazarda görünür.

Schema burada iki işi aynı anda yapar. Bir yandan sayfanın ne olduğunu açıklar, diğer yandan o açıklamanın hedef dil ve pazarla tutarlı olmasına yardım eder. Fakat bu ancak verinin gerçekten yerelleşmiş olmasıyla çalışır. İngilizce ürün adıyla işaretlenmiş Fransızca sayfa, teknik olarak JSON-LD taşısa da bağlamsal temizliğini kaybeder.

Özellikle ürün, makale, breadcrumb ve organization benzeri temel yapılar çok dilli projelerde en sık karşılaşılan alanlardır. Hepsinde aynı hata kalıbı görülür: şablon tek kez kurulmuş, sonra tüm sürümlerde aynen çoğaltılmıştır. Arama motoru tarafında ise sayfaların gerçekten farklı pazarlara ait olduğu yeterince net okunmaz.

Hangi alanlar yerelleşmeli, hangileri sabit kalmalı?

Çok dilli yapıda her schema alanı aynı biçimde davranmaz. Bazı alanlar evrensel kalabilir; bazıları mutlaka yerelleşmelidir. Marka adı çoğu zaman sabit kalır. Resmî kurum adı ya da ürün kimliği de belirli koşullarda aynı kalabilir. Ama başlık, açıklama, breadcrumb adı, fiyat birimi, bölgesel teslimat koşulu ve destekleyici metinler yerelleştirme ister.

Ürün örneği bunun için nettir. Aynı ürün farklı ülkelerde farklı para birimi, farklı teslimat bölgesi ve bazen farklı varyant bilgisiyle sunulabilir. Bu durumda schema içindeki offer alanını kaynak pazardan kopyalamak, kullanıcının gördüğü sayfa ile arama motoruna söylenen veri arasında ayrışma yaratır.

Bu ayrımı kurmak önemlidir. Çünkü her alanı gereksiz yere yerelleştirmek de hataya açıktır, hepsini kaynak dilden taşımak da. Esas mesele, entity bilgisini bozmadan kullanıcı yüzeyiyle uyumlu işaretleme yapmaktır.

Schema, hreflang ve canonical ile nasıl birlikte çalışır?

Yapısal veri çoğu zaman bu iki katmanla karıştırılır. Oysa roller ayrıdır. Hreflang alternatif dil veya ülke sürümlerini birbirine tanıtır. Canonical, tercih edilen URL'yi işaret eder. Schema ise sayfanın içindeki entity'yi ve sayfa tipini açıklar. Birbirlerinin yerine geçmezler.

Bununla birlikte çelişmemeleri gerekir. Bir sayfa Almanca sürüm olarak hreflang ile tanımlanmışsa, schema içindeki headline ve breadcrumb adlarının İngilizce kalması zayıf sinyal üretir. Canonical kendini işaret ediyorsa ama Product işaretinde başka ülkeye ait fiyat ve para birimi kullanılıyorsa, sayfa yine tutarsız görünür.

Özellikle çok büyük kümelerde bu ilişkiyi manuel yönetmek zorlaşır. Hreflang ilişkilerinin eksiksiz tanımlanmış olması kritik hale gelir. Alternatif dil kümeleri büyüdükçe işaretleme formatını merkezi biçimde üretmek hata oranını düşürür; ama yapısal verinin kendi yerelleştirme mantığı ayrıca kontrol edilmelidir.

Kısacası, schema temiz diye hreflang sorunu çözülmez; hreflang temiz diye schema ihmal edilemez. Çok dilli yapı bu katmanların birlikte uyumlu kalmasıyla güçlenir.

Hangi schema türleri çok dilli yapıda en çok kullanılır?

İçerik tipine göre değişse de en yaygın yapıların başında Article veya BlogPosting, BreadcrumbList, Product, Organization ve WebSite gelir. Her biri farklı görev taşır. Blog içeriğinde makale ve breadcrumb öne çıkar. Ürün odaklı yapılarda product ve offer bilgileri kritiktir. Kurumsal yapılarda organization işareti daha görünür rol oynar.

Çok dilli projede burada yapılan hata, her sayfaya aynı schema setini yüklemektir. Blog sayfasında ürün işaretlemek, kategori sayfasında anlamsız article alanları taşımak veya her varyanta birebir aynı breadcrumb isimlerini basmak dosyayı kalabalıklaştırır ama kalitesini artırmaz.

Daha iyi yaklaşım, sayfa tipine uygun minimum ama doğru yapıyı kullanmaktır. Gereksiz zenginlik değil, temiz bağlam işe yarar. Bu mantık teknik denetimde de avantaj sağlar. Çünkü teknik kontrol sırasında hangi işaretin hangi yüzeyde yaşaması gerektiği daha net görünür.

En sık yapılan schema hataları nelerdir?

İlk hata, kaynak dildeki başlık ve açıklamayı bütün sürümlere aynen taşımaktır. Bu hata bazen görünmez çünkü sayfa yüzeyinde her şey çevrilmiş olabilir. Ama JSON-LD içinde eski metinler yaşar. Arama motoru açısından bu, bakım eksikliği ve zayıf tutarlılık sinyalidir.

İkinci hata, farklı ülke sürümlerinde aynı offer bilgisini kullanmaktır. Fiyat, para birimi, stok durumu veya teslimat bölgesi değişiyorsa schema bunu da yansıtmalıdır. Aksi halde sayfa ile yapılandırılmış veri farklı ülkeleri anlatıyor gibi görünür.

Üçüncü hata, aynı entity'yi her dil sürümünde anlamsız biçimde farklılaştırmaktır. Marka adı, yayıncı kimliği veya kalıcı kurumsal bilgiler sabit kalması gerekirken, her pazarda rastgele değiştirildiğinde yapı kırılır. Yerelleştirme ile özdeşliği bozmak aynı şey değildir.

Dördüncü hata, breadcrumb ve iç link yapısının bir şey, schema breadcrumb'unun başka bir şey söylemesidir. Kullanıcı sayfada "Kaynaklar > Hreflang" yolunu görür, schema içinde ise eski kategori adları durur. Bu tip ayrışmalar küçük görünür ama büyük projede şablon hatasının işaretidir.

Beşinci hata, schema'yı zengin sonuç umuduyla aşırı doldurmaktır. Çok fazla alan eklemek, alakasız tipleri kullanmak ya da güncellenmeyen blokları sayfada tutmak, kaliteyi artırmaz. Tam tersine bakım yükünü büyütür. Çok dilli yapıda sade ama doğru işaretleme çoğu zaman daha güvenlidir.

Pratik bir kontrol modeli nasıl kurulmalı?

Önce hangi sayfa tiplerinde hangi schema bloklarının yaşayacağını netleştirmek gerekir. Sonra bu blokların hangi alanlarının yerelleştirileceği belirlenir. Böylece editoryal ekip, geliştirici ekip ve SEO tarafı aynı sözlük üzerinden konuşur.

1. Her sayfa tipi için izin verilen schema tiplerini listeleyin.
2. Yerelleşmesi gereken alanları ayrı çıkarın: headline, description, breadcrumb adı, offer bilgileri gibi.
3. Her dil kümesinden örnek sayfa açıp görünen metin ile JSON-LD içeriğini birlikte karşılaştırın.
4. Canonical, hreflang ve schema alanlarının aynı pazarı anlattığını doğrulayın.
5. Şablon değişikliği sonrası çok sayfalı kontrol yapın; tek örnekle yetinmeyin.

Bu model çok karmaşık görünmeyebilir. Zaten amacı bu değildir. Yapısal veri tarafında sorunların çoğu teori eksikliğinden değil, tekrar eden küçük dikkatsizliklerden kaynaklanır. Rutin kontrol burada büyük fark yaratır.

Ürün ve offer senaryoları neden ayrı dikkat ister?

Çok dilli yapılarda en kırılgan schema alanlarından biri offer katmanıdır. Aynı ürün bir ülkede vergi dahil fiyatla, başka bir ülkede vergi hariç gösteriliyor olabilir. Stok durumu pazara göre değişebilir. Teslimat bölgesi ya da iade şartı farklı olabilir. Sayfa yüzeyi bunları yerelleştirip JSON-LD tarafında eski ülke verisini taşımaya devam ediyorsa, tutarsızlık doğrudan ürün varlığının içine yazılmış olur.

Bu yüzden product schema kullanılan projelerde dil çevirisi tek başına yeterli görülmemelidir. Fiyat, para birimi, availability, seller ve bölgesel destek alanları hedef pazardaki gerçek yüzeyle birlikte düşünülmelidir. Özellikle aynı ürünün onlarca varyantı varsa, küçük bir şablon hatası yüzlerce sayfaya aynı yanlış offer bilgisini yayabilir.

Buradaki pratik yaklaşım nettir: kullanıcı sayfada ne görüyorsa arama motoru da schema içinde onu görmelidir. Fazlası değil, başkası hiç değil.

Aynı mantık breadcrumb ve publisher katmanında da geçerlidir. Kullanıcı İspanyolca kategori yolu görürken schema içinde İngilizce breadcrumb isimleri kalıyorsa, sayfanın bağlamı iki ayrı dilde anlatılmış olur. Publisher kimliği ise çoğu zaman sabit kalabilir; ama açıklayıcı yardımcı alanlar pazara göre değişiyorsa bunlar da gözden geçirilmelidir.

Büyük projelerde bu ayrımı belgelemek hayat kurtarır. Hangi alan sabit, hangi alan yerel, hangi alan koşullu değişir? Bu sözlük yazılmadığında her geliştirici ve içerik editörü aynı soruya farklı cevap verir. Sonra yapılandırılmış veri şablonu teknik olarak çalışır ama yönetilebilir olmaktan çıkar.

Çok dilli sitelerde yapısal veri kullanımı, teknik gösteriş alanı değildir. Amaç arama motoruna daha fazla şey söylemek değil, doğru şeyi tutarlı biçimde söylemektir.

Sayfanın görünen yüzeyi, hedef pazarı, hreflang kümesi ve schema blokları aynı hikâyeyi anlattığında yapısal veri gerçekten değer üretir. Güç burada oluşur.

Çok dilli projede schema başarısı, zengin sonuç avından çok veri dürüstlüğüyle ilgilidir. Hangi entity'yi temsil ettiğinizi, bunu hangi pazarda nasıl anlattığınızı ve bu anlatının her dil sürümünde ne kadar tutarlı kaldığını ölçebiliyorsanız yapı olgunlaşmış demektir.

Bir başka deyişle, schema katmanı görünmeyen ama birikimli çalışan bir kalite filtresidir. Kullanıcı bunu fark etmeyebilir; fakat arama motorunun sayfayı yorumlama netliği açısından etkisi küçümsenmemelidir. Çok dilli projede temiz schema çoğu zaman sessiz avantaj üretir.