Çok dilli bir sitede 404 sayfası genellikle tasarım aşamasının en son düşünülen parçasıdır. Ana dilde bir hata sayfası hazırlanır, sonra bu sayfa diğer dillere kopyalanır ve konu kapanmış sayılır. Ama bu kopyalama işlemi sırasında gözden kaçan birkaç karar, dil versiyonları arasında görünür bir tutarsızlık üretir: bazı dillerde 404 sayfası doğru dilde çıkar, bazılarında ana dile düşer; bazı sürümlerde durum kodu doğru döner, bazılarında sessizce 200 dönüp soft 404 sorununu tetikler.
Sorun küçük görünür çünkü 404 sayfası zaten "hata" anlamına gelir ve hata sayfalarının SEO değeri taşımadığı düşünülür. Bu kısmen doğru, ama eksik bir varsayımdır. 404 sayfası indekslenmemeli, ancak sunduğu durum kodu, dil tespiti ve yönlendirme mantığı diğer tüm dil versiyonlarının tarama sağlığını etkiler. Yanlış kurulmuş bir 404 davranışı, var olan sayfaları da soft 404 gibi işaretletebilir veya bir dil versiyonunun tamamının hatalı taranmasına yol açabilir.
Aşağıda dil bazlı 404 yönetiminin altı temel kararı ele alınıyor: hangi dilde gösterilmeli, hreflang gerekip gerekmediği, durum kodu doğrulaması, hatalı URL'lerin yönlendirilmesi, dil seçicinin rolü ve GSC üzerinden izleme.
404 sayfası hangi URL yapısında hangi dile ait olmalı?
Alt dizin yapısında bu soru genellikle URL'nin kendisiyle cevaplanır. Ziyaretçi /en/urun-x adresine gidip bu sayfa mevcut değilse, sunucunun döndürdüğü 404 sayfası da İngilizce olmalıdır; URL zaten dil bağlamını taşıdığı için, hata sayfasının bu bağlamı görmezden gelip Türkçe içerik döndürmesi hem kullanıcı deneyimini hem de dil tutarlılığı sinyalini bozar. Bu davranış genellikle CMS'in varsayılan hata şablonunun tek bir dilde sabitlenmiş olmasından kaynaklanır; route yapısı dil öneğini tanısa da, 404 handler'ı bu öneği okumadan doğrudan varsayılan dile döner.
Alt domain yapısında durum biraz daha netleşir çünkü her alt domain kendi köküne ait bağımsız bir yapı taşır; en.site.com altında bir 404 zaten o alt domainin şablonuyla çalışır ve dil karışması riski yapısal olarak daha düşüktür. Ama bu güvenlik sahte bir rahatlık üretebilir: her alt domainin 404 şablonunun ayrı ayrı çevrildiğinden ve güncellendiğinden kimse sorumlu değilse, yeni bir dil eklendiğinde 404 şablonu unutulan parça olur ve o dil sürümü İngilizce ya da varsayılan bir hata metniyle kalır.
Doğru yaklaşım, dil tespitini URL yapısından türetmek ve bu tespiti 404 handler'ına da uygulamaktır. Bu, URL yapısı kararlarının doğrudan bir uzantısıdır: URL'nin dil bilgisini nasıl taşıdığına dair kural ne ise, 404 sayfası da aynı kurala göre dil seçmelidir. Farklı bir mantık kurmak, sitenin geri kalanıyla tutarsız bir istisna yaratır.
404 sayfalarında hreflang etiketi konulmalı mı?
Bu soru genellikle iki uç cevaba çekilir: ya "hiçbir zaman gerekmez" ya da "her sayfada olmalı" şeklinde. Gerçek cevap ikisinin arasında, kullanılan 404 mimarisine bağlıdır. Her dilin kendi statik 404 sayfası varsa (örneğin /tr/404.html, /en/404.html) ve bu sayfalar birbirinin doğrudan çevirisiyse, hreflang teknik olarak eklenebilir; ama pratik faydası sınırlıdır çünkü bu sayfaların hiçbiri indekslenmemelidir, dolayısıyla hreflang'ın çözmeye çalıştığı "hangi dil sürümü öncelikli gösterilsin" sorusu burada zaten anlamsızdır.
Daha kritik durum, dinamik 404 sayfalarıdır: kullanıcı hangi URL'ye giderse gitsin aynı tek hata şablonu (genellikle tek bir kanonik adres, örneğin /404.html) devreye girer. Bu senaryoda hreflang eklemek anlamsızdır çünkü ortada birbirine referans veren gerçek alternatif URL'ler yoktur; tek bir hata şablonuna hreflang etiketi iliştirmek, olmayan bir dil kümesini var gibi göstermeye çalışmaktır. Hreflang'ın temel işlevi gerçek içerik sürümleri arasında ilişki kurmaktır; içerik taşımayan bir hata sayfası bu ilişkinin parçası olamaz.
Pratik kural şu şekilde özetlenebilir: 404 sayfası kendi dilinde statik olarak üretiliyor ve gerçek bir dil kümesinin parçasıysa, hreflang eklemenin zararı yoktur ama faydası da azdır. Dinamik ve tek şablonlu bir 404 kullanılıyorsa, hreflang eklenmemelidir; onun yerine enerji, doğru durum kodu ve doğru dil tespiti üzerine harcanmalıdır.
Soft 404 riski: durum kodu dil sürümlerinde nasıl doğrulanır?
Soft 404, bir sayfanın içerik olarak "bulunamadı" mesajı göstermesine rağmen sunucunun HTTP 200 durum kodu döndürmesi durumudur. Google bu sayfaları içerik analiziyle tespit eder ve genellikle "Soft 404" etiketiyle kapsam raporuna ekler. Çok dilli sitelerde bu risk katlanır çünkü her dil sürümünün kendi sunucu yapılandırması, kendi route mantığı ve bazen kendi CDN katmanı vardır; bir dilde doğru 404 kodu dönerken diğerinde yanlışlıkla 200 dönmesi, tek bir yapılandırma dosyasının unutulmasıyla kolayca gerçekleşir.
Bu hata özellikle framework tabanlı sitelerde ortaya çıkar. Sunucu taraflı render eden bir uygulamada dil bazlı route'lar ayrı ayrı tanımlanmışsa, geliştirici bir dil için 404 durumunu doğru işlerken, sonradan eklenen bir dil için bu adımı atlayabilir; sayfa görsel olarak "sayfa bulunamadı" yazsa da HTTP başlığı 200 döner ve Google bu sayfayı normal bir içerik sayfası gibi taramaya çalışır.
Doğrulama basit ama tekrarlanması gereken bir adımdır: her dil sürümünde kasıtlı olarak var olmayan bir URL'ye istek gönderip dönen durum kodunu kontrol etmek. Tarayıcı arayüzü bu kodu göstermez, bu yüzden geliştirici araçlarının ağ sekmesi veya komut satırı araçlarıyla başlık bilgisi okunmalıdır. Bu kontrol, yeni bir dil eklendiğinde veya sunucu/CDN yapılandırması değiştiğinde tekrar edilmesi gereken bir adım olarak teknik denetim listesine eklenmelidir; tek seferlik bir kontrol, sonraki bir yapılandırma değişikliğinde sessizce bozulabilir.
Dil öneki eksik veya hatalı bir URL 404 olduğunda nereye yönlendirilmeli?
Bazı 404 senaryoları dil önekinin kendisiyle ilgilidir: ziyaretçi /de/urun-x adresine gider ama site hiçbir zaman Almanca sürüm sunmamıştır, veya /xx/ gibi geçersiz bir dil kodu URL'ye eklenmiştir. Bu durumda karar, ziyaretçiyi otomatik olarak bir dile yönlendirmek mi, yoksa gerçek bir 404 döndürüp seçim bırakmak mı sorusuna dayanır.
Otomatik yönlendirme cazip görünür çünkü ziyaretçiyi boş elle bırakmaz, ama burada dikkatli olunması gereken nokta, bu yönlendirmenin zorunlu yönlendirme mantığıyla aynı riski taşımasıdır: ziyaretçi bilinçli olarak bir dil kodu denemişse (örneğin bir bağlantıyı yanlış kopyalamış veya eski bir dil kodunu hatırlıyor), onu sorgusuz sualsiz başka bir dile atmak kafa karışıklığı yaratabilir. Daha sağlıklı yol, gerçek bir 404 döndürüp sayfada mevcut dil sürümlerine açık bağlantılar sunmaktır; ziyaretçi hangi dile gitmek istediğine kendisi karar verir.
Geçersiz dil kodu senaryosunda ise (desteklenmeyen bir kod, yazım hatası) 301 yönlendirmesi genellikle yanlış tercihtir çünkü kalıcı bir URL değişikliği yoktur; bu bir hata durumudur ve 404 olarak işaretlenmelidir. 301 kullanmak, aslında var olmayan bir sayfayı var gibi göstermeye çalışmak anlamına gelir ve zamanla gereksiz yönlendirme zincirleri biriktirir.
404 sayfasında dil seçici gösterilmeli mi?
404 sayfası, ziyaretçinin sitenin geri kalanıyla bağlantısını en kolay kaybettiği noktadır; bu yüzden burada bir dil seçici veya en azından mevcut dil sürümlerine giden açık bağlantılar sunmak, standart sayfalardan daha büyük fayda üretir. Ziyaretçi hangi dilden geldiğini biliyordur ama aradığı sayfa o dilde yoksa, en azından ana sayfanın veya ilgili bir kategorinin o dildeki karşılığına yönlendirilmelidir.
Burada tuzak, 404 sayfasının kendisini karmaşık bir gezinme merkezine çevirmektir. Amaç, ziyaretçiye üç ya da dört net seçenek sunmaktır: ana sayfaya dön, arama yap, iletişime geç, mevcut dil sürümlerini gör. Bu seçenekler ne kadar sadeleşirse, ziyaretçinin siteyi terk etme olasılığı o kadar düşer. Karmaşık bir menü veya uzun bir bağlantı listesi, zaten belirsizlik yaşayan bir ziyaretçiyi daha da yorar.
Dil seçicinin 404 sayfasındaki rolü, standart sayfalardaki rolünden farklıdır: standart sayfada seçici mevcut içeriğin diğer dildeki karşılığına gider, 404 sayfasında ise genellikle o dilin ana sayfasına veya en yakın ilgili sayfaya gider çünkü eşleşen bir içerik zaten yoktur. Bu ayrımın açıkça belirtilmesi, ziyaretçinin "bu bağlantı beni aynı sayfanın çevirisine götürecek" gibi yanlış bir beklentiye kapılmasını önler.
GSC'de dil bazlı 404 izleme ve sık yapılan hatalar
Google Search Console'un Kapsam raporu 404 durumunu "Bulunamadı (404)" olarak listeler, ama bu liste varsayılan olarak dil ayrımı yapmaz; tüm dillerin 404'leri aynı kovada görünür. Alt domain yapısında her dil kendi Search Console mülkü olduğundan bu ayrım doğal olarak gelir; alt dizin yapısında ise raporu filtrelemek için URL öneğine göre manuel bir gözden geçirme gerekir. Uluslararası hedefleme raporunu okuma alışkanlığı, burada da işe yarar: dil bazlı düzenli bir tarama, hangi dilde beklenmedik sayıda 404 biriktiğini erken gösterir.
Sık yapılan ilk hata, eski bir dil sürümü kaldırıldığında o dile ait tüm URL'lerin sessizce 404'e düşmesine izin vermektir; bu URL'ler zamanla dış bağlantılar taşıyorsa, kaybedilen link değeri fark edilmeden birikir. İkinci hata, sitemap'te hâlâ listelenen ama artık var olmayan URL'lerin temizlenmemesidir; Google bu URL'leri tekrar tekrar dener, her denemede 404 alır ve tarama bütçesinin bir kısmı bu döngüye harcanır.
Üçüncü hata, farklı dillerdeki 404 sayfalarının canonical etiketini yanlışlıkla ana sayfaya veya başka bir dile işaret edecek şekilde bırakmaktır; bir 404 sayfasının canonical taşıması genellikle gerekmez, ama taşıyorsa kendi adresini işaret etmelidir. Bu üç hatanın hepsi, tek seferlik bir denetimle değil, dil sayısı arttıkça tekrarlanan bir kontrol alışkanlığıyla önlenir.
404 sayfası çok dilli bir sitede küçük bir detay gibi görünse de, aslında dil tespiti mantığının, durum kodu doğruluğunun ve dil seçici tasarımının aynı anda test edildiği bir kesişim noktasıdır. Bir sitenin çok dilli altyapısı ne kadar sağlam kurulmuşsa, 404 davranışı da o kadar tutarlı olur; tersine, 404 sayfasında görülen tutarsızlıklar genellikle daha büyük bir yapısal sorunun ilk görünür belirtisidir.
Yeni bir dil eklendiğinde 404 şablonunun çevrildiğini, durum kodunun doğru döndüğünü ve dil seçicinin güncellendiğini kontrol etmek, ana sayfa veya ürün sayfaları kadar rutin bir adım haline getirilmelidir. Bu kontrolü atlamak, hatanın aylar sonra kapsam raporunda ortaya çıkmasına kadar fark edilmemesine yol açar.