Çok dilli bir sitenin teknik altyapısında hreflang genellikle birinci önceliği alır. Schema.org verileri ise ikinci plana düşer; çoğu zaman kaynak dilde hazırlanıp tüm dil sürümlerine olduğu gibi kopyalanır. Google bu kopyayı fark eder. Sayfanın içerik diliyle schema verisinin dili arasındaki tutarsızlık, yapılandırılmış veriyi anlamsız kılar; bu, diller arası duplicate sinyaline yakın bir çelişkidir.
Schema çevirisi yalnızca metni farklı bir dile taşımak değildir. Hangi alanların çevrilmesi gerektiğini, hangilerinin dile bağımsız olduğunu ve yanlış çevirinin hangi SEO sinyalini bozacağını bilmek gerekir. Bu ayrımı yapmayan siteler, teknik açıdan eksiksiz görünen ama arama motoruna yanlış bilgi gönderen bir schema yapısıyla çalışır.
Schema Çevirisi Neden Ayrı Bir Uzmanlık Gerektirir
Yapılandırılmış veri alanlarının büyük çoğunluğu dilden bağımsızdır: URL'ler, fiyat değerleri, tarihler, coğrafi koordinatlar ve teknik özellikler çeviri gerektirmez; fiyat ve para birimi ayrı bir schema kararıdır. Bu alanlar her dil sürümünde aynı kalır; çevrilmesi durumunda hata üretir. Buna karşılık kullanıcıya görünecek metin alanları her dil sürümünde o dilin kendi içeriğini yansıtmalıdır.
Sorun, bu iki grubun her schema türünde farklı şekilde dağılmasıdır. Product schema'sında name çevrilir, sku çevrilmez, description çevrilir, gtin13 çevrilmez. Article schema'sında headline çevrilir, datePublished çevrilmez, articleBody çevrilir, url çevrilmez. Bu dağılımı yanlış okumak (dilden bağımsız bir alanı çevirmek ya da dile bağımlı bir alanı çevirmemek) schema'nın güvenilirliğini düşürür.
Google'ın yapılandırılmış veri işleme hattı, schema içeriğini sayfa içeriğiyle karşılaştırır; dil sürümü şablonu yerelleştirilmeden kopyalanırsa tutarsızlık birikir. Almanca içerik sunan bir sayfada Türkçe description bulunması, içerik-schema tutarsızlığı sinyali üretir. Bu sinyal tek başına bir ceza değildir; ancak biriktiğinde rich result eligibility'yi etkiler.
name ve description: İki Alanın Farklı Davranışı
name alanı schema içindeki en sık kullanılan alandır ve Google'ın SERP'te gösterdiği başlığı doğrudan etkileyebilir. Özellikle Knowledge Graph'a girmiş sayfalarda name, title etiketinin önüne geçer. Bu alanın hedef dilde yazılmamış olması, kullanıcının Türkçe arama yaparken Almanca bir başlık görmesine neden olur.
description alanı meta description'dan bağımsız çalışır; Google ikisini ayrı girdi olarak işler. Kısa ve yoğun bir metin hedefleyin: Google bazı bağlamlarda uzun description değerlerini sessizce kırpar. Her dilin bilgi yoğunluğu farklıdır; Türkçe sözdizimi genellikle daha az kelimeyle eşdeğer anlam taşır. Buna rağmen çevirmen sıkıştırmaya çalışır. Sonuçta ortaya çıkan metin ya jenerik kalır ya da zorlama bir yoğunluk taşır.
Makine çevirisi bu iki alan için farklı başarı oranları üretir. description için genel anlam çoğu durumda korunabilir. name için ise çeviri bağlamı kaybeder: "Site Haritası Oluşturucu" yerine "Harita Oluşturucu Sitesi" gibi semantik hatalar, alanın kısa yapısından dolayı çok daha görünür olur. İnsan gözden geçirmesi name alanı için vazgeçilmezdir.
Hangi Schema Türleri Çeviri Gerektirir
Article ve BlogPosting: headline, description, articleBody çevrilir. datePublished, dateModified, url, image çevrilmez. author alanında kuruluş adı tutulabilir ya da o dile özgü yerel bir iletişim kanalına bağlı ayrı author girişi kullanılabilir; her iki seçenek teknik olarak geçerlidir, ama ikisi arasında tutarsız gidip gelmek sorun yaratır. Çok dilli yapıda schema kümesinin nasıl yapılandırıldığını incelerken dikkat çeken şudur: içerik türü ne zaman tek JSON-LD bloğuna sığar, ne zaman dil sürümüne göre ayrı bloklar gerekir kararını schema türü değil, içerik türü verir.
Product: name, description çevrilir; sku, gtin13, mpn, brand teknik tanımlayıcılar çevrilmez. offers bloğundaki priceCurrency ISO 4217 kodu taşır; bu kodlar evrenseldir, çeviri gerektirmez. Çok dilli ürün sayfalarında içerik kararları verilirken en çok atlanan nokta şudur: offers içindeki availability değerleri (InStock, OutOfStock, PreOrder) Schema.org tarafından tanımlanmış İngilizce sabit değerlerdir ve yerelleştirilmez. Türkçe bir karşılık yazmak bu alanı geçersiz kılar.
FAQPage ayrı bir dikkat ister. Question ve Answer nesneleri, sayfanın görünür içeriğiyle birebir eşleşmelidir; Google bu eşleşmeyi doğrudan kontrol eder. Türkçe sürümde farklı, İngilizce sürümde farklı bir soru-cevap kümesi taşıyorsanız, her dil sürümünün kendi schema'sı o sayfanın gerçek içeriğini yansıtmalı. Tek schema kümesini tüm sürümlere kopyalamak burada özellikle kırılgan; snippet elde edilememesi hem içerik uyuşmazlığından hem de yapılandırılmış veri doğrulama hatasından aynı anda kaynaklanabilir, kaynak ayırt etmek güçleşir.
LocalBusiness şemasındaki name ve description alanları çevrilir; telephone, address ve geo koordinatları yerel gerçekliğe göre dil sürümü bazında farklılaşabilir ama bu dil değişimi değil, pazar farklılaşmasıdır. İki kavramı karıştırmak (her şeyi çevirmeye çalışmak ya da hiçbir şeyi çevirmemek) aynı yapısal hatayı farklı yönlerde üretir.
@type, priceCurrency, availability: Dil Bağımsız Alanlar
Çevrilmemesi gereken alanların listesi kısadır ama sınırı net çizmek zor. @type değerleri (Article, Product, LocalBusiness, Event, FAQPage) Schema.org sözlüğünden gelir ve İngilizce sabittir. Bunları yerelleştirmek schema'yı geçersiz kılar. Aynı mantık tüm URL alanlarına uygulanır: url, sameAs, image, logo hiçbir zaman çevrilmez.
Tarih ve saat alanları da bu gruba girer. datePublished, dateModified, startDate, endDate ISO 8601 formatı taşır; bu format dilden bağımsızdır. "12 Mart 2026" yazmak yerine "2026-03-12" kullanmak hem teknik gerekliliktir hem de tüm dil sürümlerinde sabit kalması gereken tek doğru biçimdir. Görünür tarih formatı sayfanın içeriğinde yerelleştirilebilir; schema'daki format değişmez.
Yerelleştirme ile çeviri arasındaki sınır burada somutlaşıyor. Yerelleştirme fiyat, para birimi, yasal içerik ve kültürel referanslara dokunur; çeviri metin alanlarını hedef dilin sözdizim kurallarına göre yeniden yazar. Schema'da bu iki süreç birbirinden bağımsız yürür. Metin alanlarını çevirir, teknik tanımlayıcılara dokunmazsınız. Ama aynı ekip aynı script'i her alana uyguladığında bu ayrım pratikte kolayca bulanır.
Daha az bilinen bir durum: Event schema'sındaki eventStatus ve eventAttendanceMode alanları da dil bağımsızdır. EventCancelled, EventPostponed, OnlineEventAttendanceMode gibi değerler Schema.org sözlüğünden gelir. Bu değerler sayfanın Türkçe, Almanca ya da İspanyolca yayınlanmasından bağımsız olarak aynı kalır. Etkinlik başlığı ve açıklaması çevrilir; etkinlik durumu kodları asla çevrilmez.
inLanguage: Schema'da Unutulan Satır
Pek çok çok dilli site schema'yı eksiksiz kurar ama inLanguage alanını atlar. Bu alan, içeriğin hangi dilde yazıldığını yapılandırılmış veri düzeyinde bildirir. HTML'deki lang niteliğiyle örtüşmesi beklenir; ikisi arasındaki tutarsızlık içerik dilinin okunmasını güçleştirir.
Değer IETF BCP 47 dil etiketidir. Türkçe için "tr", İngilizce için "en", Almanca için "de". Bölge koduna çoğu zaman gerek yoktur; "tr-TR" yerine "tr" yeterlidir. Ama sayfanın lang niteliği "tr" ise schema'daki inLanguage da "tr" olmalı. Hreflang etiketleri dil sürümlerini birbirine bağlarken, inLanguage alanı her sürümün kendi dilini doğrudan bildirmesini sağlar; ikisi birlikte çalışır, biri diğerinin yerine geçmez.
Bu alanın en fazla atlandığı yer CMS şablonlarıdır. Şablon bir kez oluşturulur, inLanguage ya hiç yazılmaz ya da kaynak dil sabit olarak kodlanır. Dil sürümleri çoğaldığında her sürüm kaynak dilin değerini taşıyan schema'ya sahip olur. Almanca bir sayfa "inLanguage": "tr" bildiriyorsa bu teknik bir hata sayılmaz; ama Google'ın işlem güveni düşer, özellikle rich result değerlendirmesinde bu tür tutarsızlıklar eligibility'yi zayıflatır. Düzeltmesi tek satır, atlanması aylar içinde fark edilir.
FAQPage'de Soru-Cevap Çevirisi
FAQPage schema'sı Google'ın en titiz doğruladığı türlerden biridir. Her Question ve Answer değeri, sayfadaki görünür metnin birebir karşılığı olmalı; parafraz kabul edilmiyor. Türkçe içeriği olan bir sayfada İngilizce FAQ schema taşımak, arama motoruna çelişen iki farklı içerik seti sunmak anlamına gelir.
Soru çevirisi ayrı bir risk noktasıdır. Makine çevirisi genel anlam aktarabilir ama soru kalıbını kaybeder. "What does hreflang do?" yerine "Hreflang ne yapıyor?" çevrilir; ama arama niyetiyle eşleşen Türkçe kalıp farklı bir yapı taşıyor olabilir. Schema'daki soru metni sayfadaki görünür soruyu yansıtmalı; çeviri sırasında soru kalıbı kaymışsa görünür metin ile schema tutarsızlaşır.
Bir FAQPage sayfası kaç dilde yayınlanıyorsa o kadar bağımsız schema kümesi gerekir. Tek kaynak JSON-LD üretip tüm sürümlere enjekte etmek kısa vadede operasyonel kolaylık sağlar; ama her dil sürümünde schema doğrulaması ayrı ayrı yapılmadan bu yaklaşımın riski görünmez kalır. Snippet kaybı genellikle bu tespitten aylarca sonra gelir.
Otomatik Çeviri Script'i Schema'ya Uygulandığında
İçerik çevirisi için kullanılan script'ler zaman zaman JSON-LD bloklarına da uygulanır. Script kaynak dil metnini bulup hedef dile çevirir; JSON'u ayrıştırmadan düz metin olarak işlerse @type değerlerini, ISO tarih string'lerini ve Schema.org URL'lerini de çevirir. Çıktı teknik olarak geçerli JSON görünümünü koruyabilir ama schema açısından bozulmuş değerler taşır.
Tespit zaman alır. Schema Markup Validator hata üretmeyebilir; zorunlu alanlar hâlâ mevcut, format geçerli görünüyor. Ama Google'ın işlem hattı @type değerini tanıyamazsa o schema bloğunu yoksayar. Bu sessiz bir başarısızlıktır; GSC'de hata kaydı oluşmaz, rich result sadece görünmez olur. Nedenini bulmak için structured data doğrulamasını ham HTML kaynağından değil, Google'ın tarayıcısının gördüğü render edilmiş çıktı üzerinden yapmak gerekir.
Korunma yöntemi operasyonel düzeyde kurulur. Çeviri pipeline'ına JSON-LD bloklarını dışlayan bir kural listesi eklemek sorunun büyük bölümünü çözer. Hangi alanların dokunulmaması gerektiğini belirlemek için Schema.org sözlüğünün kontrollü kelime listeleri temel alınabilir: bu alanların değerleri tanımlı ve İngilizce sabittir, çeviri bu değerleri kırar. @type, @context, tarih alanları ve tüm URL değerleri bu korunan listeye girer.
Kısmi çeviri de gözden kaçar. Script bazı alanları çevirir, bazılarını atlar. Ortaya çıkan schema yarısı kaynak dilde, yarısı hedef dilde bir yapı taşır. Google bu karışık yapıyı ne kaynak ne hedef dil olarak net okuyabilir; rich result eligibility değerlendirmesi belirsizleşir ve çoğunlukla reddedilir. Kısmi çevirinin tam çevirisiz bırakmaktan daha riskli olması bu yüzdendir. Tutarlı bir schema, hatalı bir schema'dan her zaman daha iyi başlangıç noktası sunar; ama tutarsız bir schema ikisinin de altında kalır ve tanılanması en güç olanıdır.
Schema çevirisi tek bir soruya bağlıdır: bu alan kullanıcıya görünür metin mi taşıyor, yoksa evrensel teknik bir tanımlayıcı mı? Görünür metin çevrilir, tanımlayıcı çevrilmez. Bu soruyu her alan için ayrı ayrı sormak tek güvenilir yöntemdir; çünkü aynı alan farklı schema türlerinde farklı işlev üstlenebilir. name alanı Product'ta marka kimliğiyle iç içe geçip çeviride özel dikkat gerektirirken, Article'da doğrudan başlığa eşlenir ve çevirisi daha mekanik kalır.
Rich result hedefleyen her dil sürümü schema doğrulamasını kendi içeriğiyle ayrı ayrı geçmeli. Kaynak sürümde çalışan schema'yı çevrilmiş sürüme kopyalayıp doğrulama adımını atlamak en çok görülen ve en geç fark edilen hatadır. Doğrulama maliyeti küçük; gözden kaçırıldığında zaman kaybı büyük. İki adım: önce validator, sonra GSC Coverage raporunda rich result durumu. Bu sıra tersine çevrilemez.
Schema yönetimi çok dilli projeler büyüdükçe operasyonel bir yük haline gelir. On dil sürümü, beş farklı schema türü ve her güncellemeyle yeniden doğrulama yapılması gereken yüzlerce sayfa. Bu ölçekte manuel süreç sürdürülemez. Build pipeline'ına entegre edilmiş otomatik doğrulama, her yayın öncesi JSON-LD bloklarını validator API'si üzerinden geçirir ve hatalı alanları raporlar. Bu yapı kurulmadan ölçek artışı schema kalitesini doğrudan düşürür; ekip büyür, sayfa sayısı artar, ama doğrulama ritüeli sabitlenmiş birkaç sayfayı kontrol etmekten ibarete döner. Hreflang hataları nasıl tespit edilir sorusuyla karşılaştırıldığında schema hataları daha az görünür, ama arama performansına etkisi eşit ağırlıktadır.
Yeni bir schema alanı eklendiğinde tek soru sorulur: bu alan sayfayı okuyan kullanıcıya görünür metin mi taşıyor? Evet ise çevrilir, hayır ise çevrilmez. Bu karar çerçevesini her ekip üyesi içselleştirdiğinde, çeviri sürecine schema bloklarının nasıl dahil edileceği tartışmalı olmaktan çıkar. Canonical yönetimi, hreflang ve schema üç ayrı teknik katman gibi görünür; ama hepsi aynı soruyu farklı yönlerden yanıtlar: Google hangi dil sürümünü, hangi kullanıcıya, hangi bağlamda göstermeli? Schema bu sorunun yapılandırılmış veri katmanındaki cevabıdır. Eksik veya tutarsız bir cevap, diğer katmanlar ne kadar doğru kurulursa kurulsun, rich result eligibility'yi tek başına riske atar.