Hreflang etiketleri eklenmiş, karşılıklı referanslar doğru kurulmuş, canonical'lar da yerli yerinde. Ama GSC Coverage raporu hâlâ aynı sayfaları "duplicate" olarak işaretliyor. Bu tablo kafa karıştırıcı görünüyor çünkü hreflang'ın tam olarak bu sorunu çözmesi bekleniyor.
Aslında hreflang böyle bir taahhüt vermiyor. Duplicate içerik tespiti ile hreflang işlemesi, Google'ın farklı pipeline'larında çalışan bağımsız süreçlerdir. Biri diğerini otomatik olarak iptal etmez. Hreflang "bu içerik farklı bir kitleye yönelik" sinyali verirken, duplicate algoritması bağımsız olarak "bu iki sayfa çok benzer" kararını vermeye devam eder.
Bu iki sürecin nerede ve nasıl çakıştığını anlamak, sorunu doğru yerde çözmenin önkoşuludur. Canonical'ı mı kontrol etmek gerekiyor, çevirinin derinliğini mi, yoksa dahili link yapısını mı? Yanıt, GSC'de görünen kayıt türüne ve altta yatan asıl nedene göre değişir.
Duplicate tespiti ve hreflang işlemesi Google'da ayrı süreçler olarak çalışır
Google'ın tarama sistemi, bir sayfayı işlerken birçok sinyal paralel olarak değerlendirir. Hreflang etiketi "bu sayfanın belirli bir dil ve bölge hedefine yönelik olduğunu" bildirir. Ancak Google'ın içerik karşılaştırma sistemi, sayfaların metinsel benzerliğini ayrı bir hesaplama ile değerlendirir. Bu iki hesaplama birbiriyle doğrudan konuşmaz.
Pratik karşılığı şudur: Google, /tr/ ve /en/ sayfalarınızı hreflang üzerinden birbirinin alternatifi olarak tanıyabilir; aynı zamanda bu iki sayfayı içerik benzerliği açısından duplicate olarak sınıflandırabilir. İkisi aynı anda geçerlidir çünkü farklı sistemler farklı sorular sorar.
Hreflang'ın varlığı, duplicate kararını engellemiyor. Locale bilgisi, içerik benzerliği skorunun üzerine yazılmıyor. Bunun anlamı şu: hreflang altyapısı mükemmel çalışıyor olabilir, yani Google doğru sayfayı doğru kullanıcıya gösteriyor olabilir; GSC'deki duplicate kaydı ise ayrı bir katmana işaret eden, tamamen bağımsız bir değerlendirmenin çıktısıdır.
Sorunu çözmek için bu iki sürecin hangisinde sorun yaşandığını belirlemek gerekir. "Hreflang'ı düzeltirsem duplicate gider" varsayımı çoğu durumda yanlış adıma yol açar çünkü sorun zaten hreflang'da değildir.
Canonical yanlış sayfayı işaret ediyorsa hreflang alternate bildirimi geçersiz kalır
Google, duplicate sayfalar arasında canonical kararını verirken hreflang'dan önce canonical etiketine bakar. Canonical sinyali daha güçlüdür. Dolayısıyla canonical zincirinde bir tutarsızlık varsa, hreflang ne kadar doğru yapılandırılmış olursa olsun sonuç değişmez.
Yaygın hata şu biçimde karşımıza çıkıyor: Bir çok dilli yapıda /en/urun/ sayfası, canonical olarak /tr/urun/ sayfasını işaret ediyor. Bu konfigürasyonda Google, /en/urun/ sayfasının asıl sürümünün /tr/urun/ olduğunu anlıyor. Hreflang ne derse desin, canonical kararı zaten verilmiş oluyor.
Çok dilli yapıda canonical yönetiminin temel kuralı basittir: her sayfa canonical olarak kendisini göstermeli. /tr/urun/ sayfasının canonical'ı /tr/urun/ olmalı; /en/urun/ sayfasının canonical'ı /en/urun/ olmalı. Hreflang ise bu iki sayfanın birbirinin alternatifi olduğunu bildiren ayrı bir sinyal olarak çalışır.
Kontrol edilmesi gereken senaryo yalnızca bu değil. Bazı CMS'ler, dil versiyonları oluşturulurken varsayılan dil sayfasını her versiyonun canonical'ı olarak otomatik atıyor. Bu yapılandırma, kullanıcıya doğru sayfayı gösteriyor olabilir; ancak Google'ın duplicate kararında yanlış canonical sinyali üretildiği için Coverage raporunda istenmediyen kayıtlar birikir.
Canonical zincirini doğrulamak için URL Inspection aracını her dil versiyonu için ayrı ayrı çalıştırın. "Google-selected canonical" alanı, sizin belirlediğiniz canonical ile örtüşmüyorsa sorun canonical katmanındadır. Hreflang'a geçmeden önce bu katmanı temizleyin.
İçerik benzerliği eşiği: çeviri yeterliyse duplicate sayılmaz, değilse sayılır
Google'ın duplicate tespiti yalnızca anahtar kelime örtüşmesine bakmıyor. Cümle yapısı, liste öğelerinin sıralaması, sayısal veriler, tablo içerikleri, meta açıklamalar ve sayfa başlıkları da bu karşılaştırmaya dahil. Yüzeysel bir çeviri yaptığınızda bu öğelerin büyük çoğunluğu yapısal olarak aynı kalır.
Makine çevirisi bu problemi sıkça üretiyor. Çeviri motorları cümle anlamını aktarırken aynı paragraf sırasını, aynı liste düzenini, aynı sayısal değerleri koruyor. Google bu yapısal örüntüyü ölçüyor ve iki sayfa "benzer içerik" eşiğinin üzerine çıkıyor.
Pratik bir eşik vermek zor; Google bu değeri açıklamıyor. Ancak deneyimsel olarak şunu söylemek mümkün: özgün oluşturulmuş içerikler çok daha az sorun yaratıyor. Hedef kitlenin gerçekten farklı sorular sorduğu bir yapıda, bir dilin içeriği diğerinin birebir çevirisi olmak zorunda değil. Türk pazarına yönelik bir ürün sayfası ile Alman pazarına yönelik bir ürün sayfası farklı ikna argümanları, farklı fiyat referansları, farklı güven sinyalleri içeriyor olmalı.
Yüzeysel çeviri ile üretilmiş içeriklerde şunları değiştirmek eşiği aşmak için genellikle yeterli oluyor: giriş paragrafı özgün bir açıyla yeniden yazılıyor, liste öğelerinin sırası içerik önceliğine göre yeniden düzenleniyor, hedef kitleye özgü bir örnek veya bağlam ekleniyor. "Ne kadar farklı olmalı?" sorusunun kesin bir yanıtı yok; ancak yapısal benzerliklerin azalmasıyla birlikte sorunun kendiliğinden gerilediği görülüyor.
Dahili link yapısı dil sınırlarını aşıyorsa sinyal çakışması yaratır
Google, dil bazlı içerik sınıflandırmasını kısmen dahili link yapısından çıkarıyor. /tr/ sayfalarından /en/ sayfalarına verilen dahili linkler, bu iki içerik grubunun birbirinden bağımsız silo'lar olarak algılanmasını zorlaştırıyor. Bu durum, canonical ve hreflang doğru yapılandırılmış olsa bile ek duplicate sinyali üretebiliyor.
Çok dilli dahili link stratejisinin temel kuralı şudur: her dil sürümü kendi içinde bağlantılı olmalı. /tr/urun/ sayfası diğer Türkçe sayfalara link vermeli; /en/urun/ sayfası diğer İngilizce sayfalara. Dil sınırını geçen dahili linkler yalnızca gerçekten zorunlu olduğunda ve kasıtlı olarak kullanılmalı.
Bu hatanın en sık görüldüğü yer global navigasyon bileşenleri. Header veya footer'da dile göre filtrelenmemiş link listeleri yer alıyorsa, her sayfa her dil versiyonuna link vermiş olabilir. Tarayıcı bu linkleri takip eder, Google sayfalar arasındaki dil sınırını daha az net algılar.
Kontrol için şu soruyu sorun: Herhangi bir Türkçe sayfanızdan İngilizce sayfalara kaç link gidiyor? Bu sayı beklenenden fazlaysa link yapısı incelenmeye değer. Dil bazlı silo kurgusunu yeniden kurmak, hreflang sinyalinin daha temiz bir ortamda işlenmesine de katkı sağlıyor.
GSC'de hangi duplicate kaydını görüyorsunuz: kayıt türü tanıyı değiştirir
GSC Coverage raporunda "duplicate" etiketli üç farklı kayıt türü yer alıyor. Bunlar farklı sorunlara işaret ediyor ve çözüm adımları da ayrışıyor. Hreflang kaynaklı sorunları tespit etmek için önce bu ayrımı netleştirmek gerekiyor.
Duplicate without user-selected canonical: Google birden fazla benzer sayfa buldu ve canonical belirtilmemiş. Bu durumda Google kendi canonical kararını veriyor; seçtiği sayfa sizin tercih ettiğiniz olmayabilir. Hreflang bu seçimi doğrudan etkilemiyor. Düzeltme: her sayfaya açık canonical etiketi ekleyin.
Duplicate, Google chose different canonical than user: Siz canonical belirlediniz ama Google farklı bir sayfayı seçti. Bu kayıt genellikle içerik benzerliğinin çok yüksek olduğu, canonical sinyalinin zayıf kaldığı veya link gücünün başka bir sayfada toplandığı durumlarda çıkıyor. Hreflang burada da belirleyici değil; canonical zinciri ve içerik farklılaştırması öncelikli.
Alternate page with proper canonical tag: Bu kayıt çoğunlukla sorun değildir. Bu GSC statüsünün ne anlama geldiğini ayrıntılı incelediğimizde görüldüğü gibi, hreflang'la işaretlenmiş bir sayfanın canonical'ını kendine vermesi durumunda bu kayıt beklenen çıktıdır. Eğer sayfa arama sonuçlarında görünüyor ve doğru locale'e servis ediliyorsa müdahale gerekmez.
Tanı koymak için şu soruyu sorun: GSC'deki bu kayıt, gerçek bir trafik kaybına mı yol açıyor? Sayfa URL Inspection'da "indexed" görünüyor ve doğru arama sonuçlarında çıkıyor mu? Kayıt zararsız bir statü mü, yoksa indeksleme problemi mi? Bu ayrım, gerçek bir sorun olup olmadığını ve hangi adımın önce atılması gerektiğini belirliyor.
Senaryoya göre düzeltme sırası: önce canonical, sonra hreflang, sonra içerik
Üç temel senaryo ve her biri için pratik adım sırası şöyle özetlenebilir:
Senaryo 1: Canonical zincirinde tutarsızlık var. URL Inspection'da "Google-selected canonical" kendi sayfanızdan farklı bir adres gösteriyorsa, hreflang'a dokunmadan önce canonical'ı düzeltin. Her dil versiyonunun canonical'ının kendisine işaret ettiğini doğrulayın. CMS'in otomatik canonical mantığını inceleyin; varsa varsayılan dil sayfasına yönlendirmeyi kaldırın. Değişiklik yapıldıktan sonra Search Console'dan yeniden tarama isteyin ve birkaç hafta içinde kaydın düşüp düşmediğini izleyin.
Senaryo 2: İçerik benzerliği çok yüksek. Canonical doğru ama Google yine de farklı sayfayı tercih ediyorsa, önce içerikleri karşılaştırın. Giriş paragrafı, meta açıklama, sayfa başlığı ve liste öğeleri neredeyse özdeşse lokalizasyon derinliğini artırın. Hedef pazara özgü örnekler, bölgesel referanslar, farklı ikna argümanları ekleyin; bu, çeviriden yerelleştirmeye geçmenin pratik karşılığıdır. Bu adım makine çevirisiyle üretilmiş içeriklerde genellikle en hızlı sonucu veriyor.
Senaryo 3: Dahili link yapısı dil sınırını aşıyor. Navigation bileşenlerini ve footer link listelerini dil bazında filtreleyin. Varsa dil değiştirici menüde hreflang alternate bilgisinden faydalanın; kullanıcıya verilen link kümesini dile göre ayırın. Bu adım hemen etkisini göstermez; Google'ın yeni yapıyı taraması ve sinyalleri yeniden değerlendirmesi birkaç hafta alabilir.
Her üç senaryoda da şu sıra geçerlidir: önce canonical katmanını temizleyin, ardından hreflang yapılandırmasını doğrulayın, son adım olarak içerik farklılaştırmasına bakın. Ters sırada çalışmak çoğu zaman gerçek sorunu görmezden gelirken hreflang etiketlerinde gereksiz değişikliklere yol açıyor.
Hreflang, duplicate sorununu çözen bir araç değil; doğru canonical ve yeterli lokalizasyonla birlikte çalışan bir sinyal katmanıdır. Bu üç unsur hizalı olduğunda Google'ın hem locale kararı hem içerik sınıflandırması düzgün çalışır. Duplicate kaydı ise genellikle bu üçlü içinde en zayıf halkaya işaret eder.
GSC Coverage raporu bir hata listesi değil, bir sinyal haritası olarak okunmalı. Her kayıt türü farklı bir soruyu gündeme getiriyor: canonical doğru mu, içerik gerçekten farklı mı, link yapısı dil silolarını koruyor mu? Bu sorular sırayla yanıtlandığında duplicate uyarısının arkasındaki gerçek sorun netleşiyor.
Pratik beklenti yönetimi açısından şunu belirtmek gerekiyor: düzeltme adımları atıldıktan sonra GSC Coverage raporunun güncellenmesi birkaç hafta ile birkaç ay arasında sürebilir. Google'ın sayfaları yeniden taraması, sinyalleri güncellemesi ve kaydı arşive taşıması zaman alır. Bu sürede sayfaların gerçekten indeksleniyor ve doğru lokallere servis ediliyor olması, bekleyip beklemeyeceğinize dair en sağlıklı gösterge olmaya devam eder.