Sunucuyu açıyorsunuz, silinmiş bir ürünün adresine giriyorsunuz ve sitenin 404 sayfası yerine Apache'nin varsayılan sayfasını görüyorsunuz: «Not Found. The requested URL was not found on this server.» Ya da daha kötüsü, site tüm yanlış adresler için 200 kodu döndürüyor ve Google binlerce kopya sayfayı indeksliyor. Sorun genellikle ErrorDocument ayarında, hata dosyasının kendisinde değil.
Her şeyden önce bir şeyi netleştirelim: özel hata sayfası sadece görünen yüz değildir. Beraberindeki durum kodu yanlışsa, ne yaparsanız yapın ters sonuç alırsınız. Bu makale tam olarak o sınır hakkındadır.
Özel hata sayfası neden doğru durum kodu olmadan işe yaramaz
Kullanıcı var olmayan bir adrese ulaştığında, sunucu yanıt başlığına HTTP/1.1 404 Not Found yazmalıdır. Bu kod 200 olursa, hem tarayıcı hem de Google botu sayfanın sağlam olduğunu düşünür. Sonucunu Search Console'da görürsünüz: hiçbiri gerçek içeriğe sahip olmayan ve sitenin tarama bütçesini yiyen on binlerce «indekslenmiş sayfa».
Doğru yol, hata dosyasını yönlendirme ile değil, ErrorDocument direktifi ile tanıtmaktır. İkisi arasındaki farkı aşağıda göreceksiniz.
ErrorDocument ile Redirect 404 arasındaki fark
Burada hata yapıyorlar: .htaccess içine Redirect 404 /404.html yazıp rahatlıyorlar. Bu direktif bir 302 yönlendirmesi oluşturur; yani sunucu önce 302 kodu verir, sonra tarayıcı /404.html adresini 200 kodu ile alır. Google yanlış adresi «geçici olarak taşınmış» olarak algılar ve indeks kuyruğunda tutar. İşareti de şudur: kapsam raporunda 404 adresleriniz «yönlendirildi» kategorisinde görünür, «bulunamadı» değil.
En doğru biçim şu satırdır:
ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html
ErrorDocument 403 /errors/403.htmlYol alan adı kökünden başlamalı ve eğik çizgi ile başlamalıdır. ErrorDocument 404 errors/404.html şeklinde ilk eğik çizgi olmadan yazarsanız, Apache bunu göreli olarak yorumlar ve istenen adresin derinliğine bağlı olarak sonuç değişir. Bu küçük hata, hata sayfasının yalnızca site kökünde çalışmasına ve daha derin yollarda varsayılan sayfanın tekrar dönmesine neden olur.
Kullanıcıyı geri getiren içerik, onu terk eden sayfa değil
İyi bir 404 sayfası sadece üç şey yapar. Birincisi, bir cümlede ne olduğunu söyler. İkincisi, önüne üç ya da dört gerçek yol koyar. Üçüncüsü, bir arama veya iletişim yolu sunar. Gerisi süslemedir.
- Sayfa başlığı kullanıcının beklediği şey olmalıdır: «Aradığınız sayfa bulunamadı».
- Ana sayfaya, ana kategorilere ve e-ticaret siteniz varsa alışveriş sepetine bağlantı.
- Sitenin dahili sonuçlarına bağlanan basit bir arama formu.
- Adres silinmiş bir ürüne benziyorsa, mevcut en yakın ürüne bağlantı.
Pratikte işe yarayan şey, adrese dayalı akıllı öneridir. İstenen adres mevcut yollardan biriyle büyük ölçüde benzeşiyorsa, onu önerin. Site adresleri listesi üzerinde similar_text() veya levenshtein() kullanan küçük bir PHP betiği, çoğu durumda kullanıcıyı doğru hedefe ulaştırır. Bedeli, adres listesini bir yerde tutmanız ve güncel tutmanız gerektiğidir; birkaç bin sayfanın altındaki siteler için buna değer, küçük siteler için değmez.
500 sayfasını hafife almayın
500 sayfasının 404'ten temel bir farkı vardır: suçlu kullanıcı değil, sizsiniz. Burada hiçbir teknik ayrıntı göstermemelisiniz. Sayfadaki Fatal error: Uncaught Error: Call to undefined function mesajı hem teknik itibarı zedeler hem de kötüye kullanım yolu açar.
php.ini içinde veya ini_set ile şu iki değeri ayarlayın:
display_errors = Off
log_errors = On
error_log = /home/USERNAME/logs/php_errors.logLog yolunu kendi hosting'inizin gerçek yolu ile değiştirin. Hosting'inizde hangi php.ini direktifinin etkili olduğundan emin değilseniz, php.ini ayarları referansı her direktifi varsayılan değeri ve pratik etkisiyle listeler.
Az söylenen bir nokta: ErrorDocument 500 yalnızca Apache hatayı kendisi ürettiğinde çalışır. PHP ölümcül bir hatayla ölür ve eksik çıktı gönderirse, Apache bunu sağlam yanıt olarak değerlendirebilir ve özel sayfanız gösterilmez. Bu durumu kapsamak için betik düzeyinde de bir error handler kaydetmeli veya auto_prepend_file kullanmalısınız.
htaccess'te mi yoksa hosting panelinde mi ayarlanmalı?
Her iki yol da mevcuttur ve aralarındaki seçim koşullarınıza bağlıdır.
| Yöntem | Avantaj | Sınırlama |
|---|---|---|
.htaccess içinde ErrorDocument | Hızlı, dosyayla taşınabilir, yönetici erişimi gerektirmez | Her alan adı için ayrı ayrı tekrarlanmalıdır; AllowOverride kısıtlıysa çalışmaz |
| VirtualHost'ta ayar | Sunucu düzeyinde, tüm alan adlarında tek seferde | Root erişimi veya sunucu yönetim paneli gerektirir |
| Hosting panelinde ayar | Dosyaya dokunmadan, teknik olmayan kullanıcılar için uygun | Daha az esneklik, bazen yalnızca sabit yol kabul eder |
Linux hosting üzerinde çalışıyor ve dosyalara erişiminiz varsa, ben .htaccess'i seçerim. Nedeni basit: tek bir dosyayla ayarları Git'te tutabilir ve test ile prodüksiyon ortamları arasında taşıyabilirsiniz. Bir sunucuda onlarca alan adınız varsa ve hepsinin ortak bir hata sayfası olmasını istiyorsanız, VirtualHost düzeyinde ayarlı özel sunucu daha az zahmetlidir.
Sık karşılaştığım pratik bir sınırlama: site bir CDN arkasındayken özel hata sayfanız kullanıcıya hiç ulaşmayabilir. Bazı CDN'ler 404 ve 500 yanıtlarını kendi sayfalarıyla değiştirir. Doğru ayardan sonra hâlâ yabancı bir sayfa görüyorsanız, önce curl -I https://example.com/not-found ile yanıt başlığını kontrol edin ve sunucunuzun hangi kodu gönderdiğini görün.
Gerçekten çalıştığını doğrulama
Ayarı yazdıktan sonra tahmin etmeyin. Test edin:
curl -sI https://example.com/this-page-does-not-exist | head -n 1
curl -s https://example.com/this-page-does-not-exist | grep -i "Aradığınız sayfa"İlk satır HTTP/2 404 döndürmelidir. HTTP/2 200 görürseniz, kodu değiştiren bir yönlendirme veya rewrite'ınız var demektir. En yaygın suçlu, her şeyi index.php'ye gönderen ve o da kontrol etmeden 200 kodu veren .htaccess kuralıdır. Bir framework kullanıyorsanız, bu bazı router'ların varsayılan davranışıdır ve htaccess'te değil, kodun kendisinde düzeltilmelidir.
Sunucunun ağ katmanında ne söylediğini görmek ve sorunun DNS'ten olmadığından emin olmak için DNS ve ağ kontrol aracı en hızlı yoldur. Ve 500 hatasının yapılandırmadan değil bir PHP eklentisinden geldiğinden emin olmak istiyorsanız, etkin eklenti listesini PHP eklentilerini kontrol rehberi ile karşılaştırın.
Sürekli tekrarlanan üç hata
- 404 sayfasından 404 sayfasına bağlantı vermek. Sitenizin menüsü kendileri 404 olan adreslere bağlantı veriyorsa, kullanıcı döngüye girer. Menüyü hata sayfasından kaldırın veya yalnızca sağlam bağlantıları tutun.
- 500 sayfasına
noindexkoymak. 500 sayfası indekslenmemelidir, ancak bu meta etiketle değil durum koduyla yapılır. 500 kodu doğruysa, Google kendisi indekslemez. - Alt alan adlarını unutmak. Kök
.htaccessiçindekiErrorDocument,blog.example.comüzerinde etkili olmaz. Her alt alan adı kendi dosyasını ister.
404 sayfası ve SEO hakkında bir not: bir sayfayı bilerek sildiyseniz ve backlink'i olduğunu biliyorsanız, 404 yanlıştır. Orada 301 vermelisiniz. 404, gerçekten var olmaması gereken adresler içindir.
Sık sorulan sorular
Özel hata sayfasının SEO sıralamasına etkisi var mı?
Sayfanın kendisinin doğrudan etkisi yoktur; etkisi olan durum kodudur. 404 sayfanız 404 kodu döndürürse, Google onu indeksten çıkarır ve sorun olmaz. 200 kodu döndürürse, içeriksiz sayfalar indekste birikir ve tarama bütçesi boşa gider.
ErrorDocument ayarından sonra neden hâlâ Apache'nin varsayılan sayfasını görüyorum?
Üç yaygın nedeni vardır: dosya yolu eğik çizgi ile başlamıyor, hata dosyası doğru yola yüklenmemiş, veya Apache yapılandırmasındaki AllowOverride .htaccess'ten ErrorDocument okunmasına izin vermiyor. Basit bir test dosyası ve curl -I ile üçünü de birkaç dakikada eleyebilirsiniz.
Site açılmıyorken 500 sayfasını nasıl oluştururum?
Hata dosyası saf HTML olmalı ve hiçbir bağımlılığı olmamalıdır; ne PHP, ne veritabanı çağrısı, ne harici CSS dosyası. 500 sayfanız bozulan şeye bağımlıysa, asla gösterilmez. Satır içi stilli basit bir HTML dosyası oluşturun ve onu tanıtın.
Her alan adı için farklı hata sayfası olabilir mi?
Evet. .htaccess içindeki ErrorDocument her alan adına ayrı ayrı uygulanır, yani o alan adına özel hata dosyasını köküne koymanız yeterlidir. Sadece ayrı DocumentRoot'a sahip alt alan adlarının ayrı dosya istediğini unutmayın.
Hemen şimdi tarayıcınızda var olmayan bir adres açın ve yanıt başlığını curl -I ile görün. İlk sayı 404 değilse, diğer işleri durdurun ve önce onu düzeltin.