Olmayan her sayfayı ana sayfaya yönlendirmek aramada neye mal oluyor

Ziyaretçi iki yıl önceki bir linki açıyor ve ana sayfaya düşüyor. Ne bir mesaj var ne bir açıklama, sadece yine ilk sayfa. Bunu yapan kural genelde config dosyasındaki tek satırdır, bir zamanlar error log sussun diye eklenmiştir ve eşleşmeyen her adresi / adresine gönderir. Hiçbir şey bozuk görünmediği için işe yaramış gibi durur. Aramadaki bedeli ise gerçektir, çünkü arama motoru sizin niyetinizi değil durum kodunu okur.

Gerçekte ne oluyor

404 bir bilgidir ve iki okuyucusu vardır. Bot elindeki adresin öldüğünü öğrenir ve sormayı bırakabilir. Sizin izleme tarafınız bir yerde linkin kırıldığını öğrenir ve hangisi olduğunu söyleyebilir. Ana sayfaya yapılan toptan yönlendirme bu iki sinyali de siler, yerine istekle hiç ilgisi olmayan bir sayfada 200 ile biten bir zincir koyar.

Arama motorlarının bu duruma verdiği bir ad var. Soft 404, içerik yokken varmış gibi cevap veren adrestir: 200 ile dönen bir "sayfa bulunamadı" ekranı ya da ana sayfa gibi alakasız bir hedefe yapılan yönlendirme. Google bunu içerikten çıkarır, adresi yine bulunamadı diye kaydeder ve geri döner mi diye bir süre kontrol etmeye devam eder.

Bunun maliyeti, kabaca fark etme sırasıyla:

• Tarama bütçesi hiçbir zaman içerik olmayacak adreslere gider. On sayfalık sitede bu sıfıra yuvarlanır. On binlerce URL'i olan ve eski bir kalıbı sürekli ölü path üreten bir sitede botun her ziyarette yaptığı işin büyük kısmı haline gelir.
• Ana sayfa kopya sinyal toplar. Her ölü adres oraya çözüldüğü için bot her seferinde bu adresin ana sayfanın başka bir adı olup olmadığına karar vermek zorunda kalır.
• Raporlarınız susar. Kırık bir iç link artık access log'da 200 üretir. Alarm çalmaz, hiçbir rapor onu listelemez, linkler bir yıl boyunca çürür.
• Bir yazıya tıklayan kişi hiçbir açıklama olmadan ana sayfayı görür. Çoğu kişi yazıyı yeniden aramak yerine siteden çıkar.

Bu kuralın nereden geldiğini de söylemek gerekir, çünkü genelde iyi niyetlidir. Biri error log'da 404 satırlarını görür, ziyaretçinin boş bir ekranla karşılaşmasını istemez ve "hiç olmazsa ana sayfayı görsün" der. Kararın mantığı insan tarafında kurulur, bedeli makine tarafında ödenir. Bir arama motoru için ana sayfa "buna en yakın şey" değildir, istenen içeriğin bulunamadığı bilgisinin silinmiş halidir. Aynısı ziyaretçi için de geçerli: aradığı yazıyı bulamayan biri, içinde bir arama kutusu ve birkaç yakın başlık olan bir hata sayfasından, hiçbir açıklama içermeyen ana sayfaya göre çok daha fazla fayda görür.

Yönlendirme ayrıca düzeltmek isteyeceğiniz tek şeyi de gizler. Log'daki 404 kaydı referrer taşır, yani ölü adrese hangi sayfanın hâlâ link verdiğini size söyler. Ana sayfaya giden 301 hiçbir şey söylemez.

Nasıl görülür

Tek istek, durum kodu ve yönlendirme hedefi birlikte:

curl -o /dev/null -s -w '%{http_code} %{redirect_url}\n' https://ornek.com/hic-olmayan-sayfa
# 301 https://ornek.com/

Hiç var olmamış bir adreste 301 ya da 302 görmek hatanın kendisidir. Sağlıklı site 404 ve boş bir hedef yazdırır.

Aynı kontrolü ölü olmasını beklediğiniz bir liste üzerinde koşturun: rastgele bir path, log'dan aldığınız eski bir kalıp, sonunda slash olan bir adres, olmayan bir asset.

for path in /olmayan-sayfa /eski-bolum/gitti/ /blog/2019/silinen-yazi /assets/eksik.css; do
  printf '%-32s ' "$path"
  curl -o /dev/null -s -w '%{http_code}\n' "https://ornek.com$path"
done

Sorunun genişliğini access log söyler. Kuralın gerçekte neyi yakaladığını sayın:

awk '$9 == 301 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Çıkan liste hiç gerçek olmamış path'lerle doluysa kural ortalığı toplamıyor demektir. Ölü link probleminizin boyutunu 200'ün arkasına saklıyordur.

Çözüm

Statik bir sitede değişikliğin tamamı iki satır. try_files =404 ile biter, yani eşleşmeyen path bulunamadı döner, error_page de o duruma bir gövde verir:

server {
  root /var/www/site;

  location / {
    try_files $uri $uri/ =404;
  }

  error_page 404 /404.html;

  location = /404.html {
    internal;
  }
}

internal hata sayfasının doğrudan istenmesini engeller, böylece kendi başına bir sayfa gibi dizine girmez. Durum 404 olarak kalır çünkü onu değiştiren bir şey yoktur. Bozuk config'lerin genelde kaçırdığı yer tam olarak burasıdır ve iki şekilde kaçırılır:

• error_page 404 =200 /404.html; doğru gövdeyi yanlış durumla sunar. Hata =200 kısmının kendisidir ve genelde "özel hata sayfam görünsün" sorusuna verilmiş bir cevaptan kopyalanır.
• error_page 404 /index.html; ise tek sayfalık uygulamaların botlar düşünülmeden kurulduğunda aldığı halidir. Her ölü adres 200 ile uygulama kabuğuna dönüşür.

Tek sayfalık uygulama durumu gerçek bir zorluk ve bedava çözümü yok. Sunucunun hangi path'lerin sayfa olduğunu bilmesi gerekir, çünkü durum kodu JavaScript çalışmadan çok önce gönderilir. Route listesi build sırasında belliyse her route için bir dosya yazın, kalan her şey =404 ile düşsün. Route'lar veritabanından geliyorsa listeyi deploy sırasında üretin ya da isteği uygulama sunucusu cevaplasın ve durumu kendisi koysun. Yapamayacağınız şey, 200 çoktan gitmişken kararı tarayıcıda vermektir.

Yönlendirmenin de yeri var, ölçüt eşdeğer bir sayfanın olup olmaması:

1. İçerik taşındı ve hâlâ duruyor: birebir o adrese 301, bölüm ana sayfasına değil.
2. Bir bölüm gerçekten yerini alan bir sayfayla birleşti: yerine geçen sayfaya 301.
3. İçerik temelli olarak gitti ve yerine bir şey gelmedi: 404, ya da "gitti" demek istiyorsanız 410.
4. Adres zaten hiç var olmadı, yazım hatası ya da sitenizi tarayan bir bot: her zaman 404.

Toptan yönlendirmeyi kapatmadan önce log'ları okuyun. Gerçek bir referrer'dan hâlâ trafik alan ölü path'ler eşdeğerine giden bir 301'i hak eder. Geri kalan her şey zaten alacağı 404'ü hak ediyor.

Çalıştığını nasıl doğrularsınız

Üç istek. Olmayan sayfa 404 döner, gerçek sayfa 200 döner, gerçekten taşınmış bir sayfa da hedefi ana sayfa olmayan bir 301 döner:

curl -sI https://ornek.com/olmayan-sayfa | head -1
# HTTP/2 404

curl -sI https://ornek.com/ | head -1
# HTTP/2 200

curl -o /dev/null -s -w '%{http_code} %{redirect_url}\n' https://ornek.com/eski-adres
# 301 https://ornek.com/yeni-adres

Sonra 404 sayfasını tarayıcıda, ağ paneli açıkken açın. Hata sayfası tam bir sayfa olmalı: kendi stil dosyası ve görselleri 200 dönmeli, siteye dönüş için bir yol sunmalı. Asset'leri eksik bir hata sayfası aynı hatanın bir alt katmanıdır.

Nelere dikkat etmeli

• Config'inizin üstündeki bir katman bunların hepsini geçersiz kılabilir. "404'te index'i sun" diyen bir CDN kuralı ya da vhost dosyasının sahibi olan bir hosting paneli yazdığınızı ezer, panel sürümü de ilk sertifika yenilemesinde geri gelir. Panel ile dosya çeliştiğinde kazanan panel olur.
• Sadece geçici olarak erişilemeyen bir şey için 404 dönmeyin. Arkasındaki servis çökmüş bir sayfa 503 dönmeli, yoksa bot kesintiyi silme olarak okur ve bir saat sonra geri gelecek sayfaları dizinden düşürmeye başlar.
• try_files $uri $uri/ =404 satırı yanlış root ile temiz bir 404 yerine hiç açmak istemediğiniz dosyaları sunabilir. Root yanlış dizini gösterdiğinde .env dosyasını sızdıran satır da aynı satırdır.
• Bir yönlendirmeyi sonradan tersine çevirmek başlı başına bir tuzak, çünkü tarayıcı kalıcı yönlendirmeyi siz fikir değiştirdikten çok sonra da saklar. Taşımanın kesin olduğundan emin değilseniz önbelleğe alınan bir 301'i geri almanın çok zor olduğunu hatırlayın.
• Değişiklikten sonra 404 oranını izleyin. Yükselecek, zaten amaç da bu. Asıl bakılacak sayı, bu 404'lerin içinde referrer'ı kendi sayfalarınız olanların payı ve o pay sıfıra yakın olmalı.

Durum kodları bir arayüzdür ve muhatabı sizin açıklamanızı hiç okumayacak makinelerdir. 404 size log'da bir satıra mal olur, karşılığında sormayı bırakan bir bot, kırık linki adıyla söyleyebilen bir izleme aracı ve ne olduğunu tahmin etmek zorunda kalmayan bir ziyaretçi verir. Toptan yönlendirme ise sessiz bir error log satın alır, bedelini de yıllarca canlı görünen ölü adreslerle öder. İkisi arasında seçim yaparken tek soru şu: eşdeğer bir sayfa var mı. Varsa oraya yönlendirin, yoksa durumu açıkça söyleyin.