Organik trafik grafiğinde belirgin bir düşüş fark ettiğinizde, ilk refleks genelde algoritma güncellemesi veya rekabet artışı gibi dışsal açıklamalara yönelmektir. Çok dilli bir sitede bu refleks bazen yanlış hedefe götürür, çünkü düşüşün gerçek kaynağı kendi hreflang kurulumunuzdaki sessiz bir bozulma olabilir. Bir dil versiyonu aniden yanlış sayfayı göstermeye başladığında, o versiyonun mevcut sıralaması birkaç hafta içinde eriyip gidebilir; bu erime, dışarıdan bakıldığında genel bir performans kaybı gibi görünür.
Bu tür bir düşüşü doğru tanılamak, önce kaynağı doğrulamayı, sonra etkilenen kümeyi haritalamayı ve en sonunda doğru sırayla düzeltmeyi gerektirir. Yanlış sırayla ilerlemek (örneğin canonical'ı düzeltmeden önce hreflang setini yeniden yazmak) iyileşmeyi geciktirir veya hatanın farklı bir biçimde tekrarlanmasına yol açar. Sıra, tahmin edilenden daha belirleyicidir. Trafik düşüşü fark edildiği andan itibaren izlenmesi gereken tanı ve kurtarma adımları aşağıda inceleniyor.
Trafik düşüşü hreflang kaynaklı mı, önce bu ayrım yapılmalı
Her trafik düşüşü hreflang sorunuyla ilgili değildir; bu yüzden ilk adım yanlış bir teşhisle vakit kaybetmemektir. Düşüş tüm dil versiyonlarında eşit oranda ve aynı anda gerçekleştiyse, kök neden genellikle site geneline yayılan bir problemdir: sunucu kesintisi, algoritma güncellemesi veya teknik SEO'dan bağımsız bir içerik kalitesi sorunu. Hreflang kaynaklı bir düşüş ise karakteristik olarak asimetriktir; bir veya iki dil versiyonu keskin şekilde düşerken diğerleri neredeyse hiç etkilenmemiş görünür.
Bu asimetriyi doğrulamak için Search Console'da performans raporunu ülke veya dil filtresine göre ayrıştırmak gerekir. Almanca sayfa sıralaması çökerken Türkçe ve İngilizce versiyonlar sabit kalıyorsa, sorun Almanca kümesine özgü bir hreflang veya canonical kırılmasına işaret eder. Tüm versiyonlar aynı anda ve aynı eğimde düşüyorsa, hreflang'a bakmadan önce genel teknik denetim listesini gözden geçirmek daha doğru bir başlangıçtır. Asimetri yoksa, hreflang da suçlu değildir.
Düşüşün başladığı tarih hangi değişiklikle çakışıyor?
Asimetrik bir düşüş doğrulandıktan sonra ikinci adım, düşüşün başladığı haftayı kesin olarak belirlemektir. Search Console grafiğinde eğimin kırıldığı günü işaretleyin, sonra o tarihte veya hemen öncesinde yapılan tüm yayınları, deploy kayıtlarını ve CMS güncellemelerini gözden geçirin. Hreflang kaynaklı düşüşler nadiren kendiliğinden oluşur; genelde bir şablon güncellemesi, bir CMS eklenti sürümü değişikliği veya bir CDN yapılandırma değişikliğiyle aynı zaman diliminde başlar.
Bu eşleştirme çoğu zaman gözden kaçar, çünkü hreflang'ı doğrudan değiştirmeyen bir deploy bile yan etki üretebilir. Bir tema güncellemesi head bölümündeki etiket sırasını değiştirebilir, bir eklenti sürümü karşılıklı referans üretimini sessizce bozabilir. Eğer aynı dönemde bir CDN sağlayıcı değişikliği veya cache kuralı güncellemesi yapıldıysa, edge katmanının hreflang başlıklarını nasıl etkileyebileceği ayrıca kontrol edilmelidir; çünkü kaynak kodda hiçbir şey değişmemiş görünse bile, canlı response farklı davranabilir.
En sık üç kök neden: karşılıklı referans kaybı, canonical çatışması, yanlış URL kümesi
Trafik düşüşüne yol açan hreflang hatalarının büyük çoğunluğu üç kategoriden birine girer. Birincisi karşılıklı referans kaybıdır: bir dil versiyonu güncellenirken hreflang bloğu eksik kopyalanmış veya yanlış URL'e işaret etmeye başlamıştır. Bu durumda diğer versiyonlar hâlâ o sayfaya referans verirken, o sayfa geri referans vermez; küme tek yönlü kalır ve no return tag hatası GSC'de görünmeye başlar.
İkincisi canonical çatışmasıdır. Bir şablon güncellemesi veya URL parametre değişikliği, bir sayfanın canonical etiketini kendisi dışında bir URL'e işaret eder hale getirmiş olabilir. Bu durumda hreflang kümesi teknik olarak sağlam görünse de, canonical kararı hreflang setini geçersiz kılar ve Google o dil versiyonunu ayrı bir sayfa olarak değerlendirmeyi bırakır. Bu senaryo özellikle sinsidir, çünkü kaynak kod incelendiğinde hreflang etiketleri hatasız görünür; sorun sadece canonical satırında saklıdır.
Üçüncüsü yanlış URL kümesidir. Bir migrasyon, redirect güncellemesi veya slug değişikliği sonrasında hreflang etiketlerinin bir kısmı artık var olmayan veya farklı bir sayfaya yönlendirilen URL'lere işaret eder. Bu durumda Google, hedef URL'e ulaştığında 404 veya redirect zinciriyle karşılaşır ve kümenin tamamını güvenilmez bulur. Bu üç kategori birbirini dışlamaz; büyük ölçekli sitelerde bir değişiklik genellikle ikisini veya üçünü birden tetikler. Üçü birden olduğunda, her birini ayrı ayrı izlemek gerekir.
GSC ve log verisiyle etkilenen dil versiyonlarını haritalamak
Kök neden kategorisi netleşmeden önce, hangi sayfaların ve hangi dil versiyonlarının etkilendiğini tam olarak haritalamak gerekir. Search Console'un Uluslararası Hedefleme raporu bu haritalamanın ilk katmanıdır; hata sayısının hangi dilde ve hangi tarihte arttığını gösterir. Ama bu rapor örneklem bazlıdır ve tüm etkilenen URL'leri kapsamayabilir; bu yüzden ikinci katman olarak sunucu log verisine bakmak gerekir.
Log analizi ile Googlebot'un hangi URL'leri ne sıklıkla ziyaret ettiğini izlemek, GSC raporunun gösterdiği örneklemden daha geniş bir tablo sunar. Etkilenen dil versiyonuna ait URL'lerde tarama sıklığının düşüş tarihinden itibaren azaldığını görmek, sorunun kapsamını doğrular. Bu iki veri kaynağını birleştirmek, sadece "Almanca versiyon etkilendi" gibi genel bir tespitin ötesine geçip hangi URL grubunun (örneğin sadece ürün sayfaları, sadece belirli bir kategori) etkilendiğini netleştirir.
Bu haritalama adımı atlanıp doğrudan düzeltmeye geçildiğinde, ekipler genellikle sorunun bir kısmını çözer ama kapsamın tamamını kavrayamadığı için aynı hata farklı bir URL grubunda birkaç hafta sonra tekrar ortaya çıkar. Haritalama, düzeltmenin kapsamını da belirler: tek bir şablon dosyasında mı, yoksa birden fazla sayfa türünde mi müdahale gerekiyor? Kapsam belli değilse, düzeltme rastlantısal kalır.
Kurtarma önceliği: önce hangi düzeltme yapılmalı?
Kök neden ve kapsam netleştiğinde, düzeltmelerin sırası iyileşme hızını doğrudan etkiler. İlk öncelik her zaman canonical tutarlılığıdır. Her sayfanın kendi URL'ine kendi canonical'ını verdiğinden emin olmadan hreflang setini düzeltmek anlamsızdır; canonical hatası düzelmediği sürece hreflang kararı Google tarafından geçersiz sayılmaya devam eder. Canonical doğrulandıktan sonra ikinci öncelik karşılıklı referans bütünlüğüdür: her dil versiyonunun birbirine doğru ve eksiksiz işaret ettiği teyit edilmelidir.
Üçüncü öncelik, düzeltilen URL'lerin canlıya doğru şekilde yansıdığını doğrulamaktır; bu adım CDN veya cache katmanı devredeyse özellikle kritiktir, çünkü kaynak kodda yapılan bir düzeltme, önbellek temizlenmeden canlı trafiğe ulaşmaz. Düzeltme deploy edildikten sonra ilgili URL'ler için hedefli bir cache purge yapılmadıysa, günler boyunca eski ve hatalı hreflang seti kullanıcılara ve Googlebot'a sunulmaya devam eder; bu gecikme, düzeltmenin işe yaramadığı yanılgısına yol açar.
Bu üç adım tamamlandıktan sonra son kontrol, düzeltilmiş URL'lerin birkaçını manuel olarak GSC URL İnceleme aracına göndermektir. Bu, toplu bir yeniden tarama garantisi vermez ama Google'ın güncel içeriği en azından temsili birkaç sayfada gördüğünü teyit eder ve genel tarama döngüsünün daha hızlı devreye girmesine küçük bir katkı sağlar.
Düzeltme sonrası iyileşme ne kadar sürer, sabır ile ihmal nasıl ayrılır?
Düzeltme canlıya alındıktan sonra iyileşme anında görünmez; Google'ın bozulan hreflang setini yeniden değerlendirmesi, orijinal kurulumun ilk kez taranmasından genellikle daha hızlı işler ama yine de günler değil haftalar sürer. Yeni bir hreflang kurulumunun ilk 90 gününde beklenen tarama ve indeks sırası, bir düzeltme sonrası iyileşme için de kabaca geçerlidir; farkla, bu kez Google'ın kümeyi sıfırdan değil bozuk bir referans noktasından yeniden değerlendirdiğini akılda tutmak gerekir.
İlk iki hafta içinde beklenen tek şey, GSC hata sayısının düşüşe geçmesidir; trafik veya sıralama bu aşamada henüz hareket etmeyebilir. İkinci ile dördüncü hafta arasında etkilenen dil versiyonunda tarama sıklığının normale dönmesi beklenir. Trafiğin önceki seviyeye dönmesi ise genellikle dördüncü haftadan sonra başlar ve düşüşün süresi kadar zaman alabilir; aylarca süren bir hreflang bozukluğu, birkaç günlük bir bozukluktan daha uzun bir iyileşme eğrisi çizer.
Dördüncü haftadan sonra hâlâ hiçbir hareket yoksa, sabırlı olmakla ihmal etmek arasındaki çizgiyi netleştirmek gerekir. O aşamada düzeltmenin canlıda gerçekten doğru render edildiğini, cache katmanının eski sürümü sunmayı bırakmış olduğunu ve canonical zincirinin başka bir yerde tekrar bozulmadığını yeniden kontrol etmek, beklemeyi uzatmadan önce atılması gereken son adımdır.
Tekrarlamayı önlemek: deploy sürecine hangi kontrol eklenmeli?
Bir hreflang bozulmasının kaynağı büyük olasılıkla tek seferlik bir insan hatası değil, tekrarlanabilir bir deploy sürecidir; bu yüzden kurtarma tamamlandıktan sonra aynı sürecin bir sonraki güncellemede aynı hatayı tekrar üretmeyeceğinden emin olmak gerekir. Şablon veya eklenti güncellemesi öncesinde, staging ortamında hreflang ve canonical çıktısının otomatik veya en azından yarı otomatik bir kontrolden geçmesi, hatanın canlıya ulaşmadan yakalanmasını sağlar.
Bu kontrol karmaşık bir araç gerektirmez; birkaç temsili sayfanın kaynak kodunu her deploy öncesi karşılaştırmak, karşılıklı referansın ve canonical'ın bozulmadığını teyit etmek için genelde yeterlidir. CDN veya cache yapılandırması değiştiğinde ise canlı response'un gerçek header setini test etmek, kaynak kod kontrolünden ayrı bir adım olarak sürece eklenmelidir; çünkü bu iki katman farklı zamanlarda ve farklı ekipler tarafından değiştirilebilir.
Bir trafik düşüşünü doğru sırayla tanılayıp düzeltmek, kaybedilen zamanı geri getirmez ama kaybın büyümesini durdurur. Aynı hatanın altı ay sonra farklı bir şablon güncellemesiyle tekrar yaşanmaması için, düzeltmenin kendisi kadar düzeltmeyi tetikleyen deploy alışkanlığının da gözden geçirilmesi gerekir. Hreflang bakımı, bir kez kurulup unutulan bir yapı değil, her yayın döngüsünde küçük bir doğrulama adımı isteyen sürekli bir disiplindir.