404 Hatası Nedir? Sebepleri ve Çözüm Yolları

404 hatası nedir?

Bir gece müşteri sitesinin ana sayfası açılıyor, fakat ürün bağlantılarının tamamı 404 dönüyordu. İlk bakışta uygulama çökmüş gibi görünüyordu; logları açınca durum daha sakindi: Nginx isteği alıyor, dosyayı ya da uygulama rotasını bulamadığı için yanıt veriyordu.

404 hatası, istemcinin sunucuya ulaştığı ancak sunucunun istenen kaynağı bulamadığı anlamına gelen HTTP durum kodudur. Genellikle silinmiş veya taşınmış bir sayfa, yanlış yazılmış URL, hatalı yönlendirme ya da web sunucusu yapılandırması nedeniyle görülür. Sunucu çalışıyor olabilir; sorun çoğu zaman belirli kaynağın adresindedir.

Bir ziyaretçi tarayıcıda sayfa adresini açtığında tarayıcı HTTP isteği gönderir. Sunucu isteği alır, fakat URL ile eşleşen dosya, rota veya uygulama kaydı bulamazsa yanıt durumunu 404 Not Found olarak döndürür. MDN dokümantasyonundaki tanım da bu noktaya dayanır: sunucu istenen kaynağı bulamamıştır, fakat kaynağın neden bulunamadığını ayrıca açıklamak zorunda değildir.

Buradaki ayrım önemli. 404, sunucunun mutlaka kapalı olduğunu söylemez. Hatta sunucu, PHP ve veritabanı gayet sağlıklı çalışırken yalnızca bir ürün sayfası için 404 döndürebilir. İstek ile kaynağın kendisini birbirinden ayırmadan yapılan her teşhis biraz tahminden ibaret kalır.

404 hatası neden olur?

Bir URL’nin 404 döndürmesinin tek bir nedeni yoktur. Kullanıcı tarafında basit bir yazım hatası olabilir; sunucu tarafında ise dosya yolu, rewrite kuralı, uygulama rotası veya proxy ayarı devreye girer. En sık karşılaştığım nedenleri aşağıda ayrı ayrı ele aldım.

Yanlış veya eksik URL

Adres çubuğunda tek bir karakterin eksik olması bile yeterlidir. /urunler/telefon ile /urun/telefon aynı kaynak değildir. URL’lerde büyük-küçük harf duyarlılığı da işletim sistemine ve web sunucusuna göre fark yaratabilir. Linux üzerinde urunler.html ile Urunler.html farklı dosyalardır.

Bağlantıyı bir e-posta veya sosyal medya paylaşımından açan kullanıcı, adresin sonuna nokta ya da parantez gibi metin işaretlerini de taşıyabilir. Böyle durumlarda sunucuda hata aramadan önce tarayıcıdaki gerçek URL’yi kopyalayıp incelemek daha hızlıdır.

Sayfa silinmiş veya taşınmış olabilir

İçerik yönetim sistemlerinde slug değişikliği, ürün silme, kategori taşıma veya kalıcı bağlantı yapısının değiştirilmesi eski adresleri geçersiz bırakır. Kaynak gerçekten kalıcı olarak kaldırıldıysa 404 doğru yanıt olabilir. Kaynak yeni bir adrese taşındıysa eski URL için çoğunlukla 301 yönlendirmesi tercih edilir.

Her eski adresi ana sayfaya yönlendirmek iyi bir çözüm değildir. Kullanıcı belirli bir ürün veya yazı arıyorsa ana sayfaya gönderilmesi, teknik olarak başarılı görünen ama pratikte işe yaramayan bir yönlendirme yaratır. Uygun yeni adres varsa oraya, yoksa anlamlı bir 404 sayfasına gitmelidir.

Web sunucusunda dosya yolu veya kök dizin yanlışı

Nginx ya da Apache, isteği yanlış root dizinine bağlıyorsa mevcut dosyayı bulamaz. Örneğin site dosyaları /var/www/example/public altında dururken yapılandırmada kök dizin /var/www/example seçilmişse, beklenen index.php veya statik dosyalar farklı bir yerde aranır.

Nginx’in root, alias ve try_files yönergeleri bu aşamada özellikle önemlidir. Nginx dokümantasyonunda da try_files yönergesinin dosyaları verilen sırayla kontrol edip son parametreye yönlendirebildiği belirtilir. Küçük görünen bir yol farkı, bütün uygulamayı 404 sayfasına çevirebilir.

CMS kalıcı bağlantıları veya rewrite kuralları bozulmuş olabilir

WordPress gibi sistemlerde kullanıcı dostu URL’ler çoğu zaman gerçek bir dosyaya değil, uygulamanın ön denetleyicisine aktarılır. Nginx veya Apache bu aktarımı yapamazsa ana sayfa açılırken yazı ve kategori sayfaları 404 verebilir.

WordPress’te kalıcı bağlantı ayarlarını kaydetmek, bazı Apache kurallarının yeniden oluşturulmasına yardımcı olabilir. Nginx kullanılan bir VPS’te ise bu işlem tek başına yeterli değildir; ilgili location bloğu ve PHP ön denetleyicisine yapılan yönlendirme ayrıca kontrol edilmelidir. Önce yedek almak, sonra yapılandırmayı değiştirmek gerekir. Bir ayarı kaydetmek için panelde düğmeye basmak geri dönüş planı değildir.

DNS değişikliği yanlış sunucuya götürüyor olabilir

Bazen 404 üreten sunucu, sitenin doğru sunucusu bile değildir. DNS kaydı eski VPS’i, CDN’i, staging makinesini veya varsayılan sanal host’u gösteriyorsa ziyaretçi beklemediği bir sunucunun 404 sayfasını görür.

DNS tarafında isim çözümleme sorunlarını ayırmak için dig ile başlayan basit kontroller yeterli olabilir. DNS kayıtlarını değiştirdiyseniz önbellek süreleri nedeniyle farklı ağlardan farklı sonuçlar görülebilir. Bu noktada DNS_PROBE_FINISHED_NXDOMAIN Hatası Nasıl Çözülür? başlıklı içerikteki NXDOMAIN ile 404 arasındaki ayrımı da hatırlamak faydalıdır: NXDOMAIN, alan adının çözümlenemediğini; 404 ise HTTP sunucusuna ulaşıldığını gösterir.

Proxy, CDN veya uygulama rotası kaynaklı 404

Reverse proxy kullanan yapılarda istek önce Nginx’e, CDN’e veya yük dengeleyiciye gelir; ardından uygulama sunucusuna aktarılır. Proxy üzerindeki location eşleşmesi yanlışsa istek uygulamaya hiç ulaşmadan 404 üretilebilir. Uygulama ulaşıyor fakat rota tanımlı değilse bu kez 404’ü uygulamanın kendisi döndürür.

Yanıt başlıkları, hatanın hangi katmanda oluştuğuna dair ipucu verir. Server, Via, özel CDN başlıkları veya uygulamaya özgü hata başlıkları tek başına kesin kanıt değildir; fakat loglarla birlikte oldukça değerlidir.

404 hatası nasıl kontrol edilir?

Tarayıcıdaki hata sayfasına bakıp hemen dosya silmek veya sunucuyu yeniden başlatmak genellikle kötü bir başlangıçtır. Ben önce isteğin gerçekten nereye gittiğini, hangi HTTP durumunu aldığını ve yanıtın hangi katmandan geldiğini ayırırım.

1. URL’yi doğrudan test edin

Önce adresi kopyalayın, gereksiz boşlukları temizleyin ve alan adıyla birlikte tam olarak test edin. Komut satırından yalnızca başlıkları görmek için curl -I kullanabilirsiniz.

curl -I https://example.com/eski-sayfa

Yanıtta HTTP/2 404 veya HTTP/1.1 404 Not Found görüyorsanız sunucu isteği almış ve 404 döndürmüştür. -I gövdeyi indirmeden başlıkları istediği için ilk kontrolü hızlandırır; fakat bazı uygulamalar HEAD isteklerini GET ile farklı işleyebilir. Şüpheli durumda normal GET isteğini de deneyin:

curl -sS -D - -o /dev/null https://example.com/eski-sayfa

Bu komut yanıt başlıklarını ekrana yazıp gövdeyi /dev/null‘a gönderir. Özellikle Location başlığında beklenmedik bir yönlendirme olup olmadığına bakarım.

2. Yönlendirmeleri görünür hale getirin

Bir URL doğrudan 404 dönmeyebilir; önce birkaç yönlendirmeden geçip son adımda 404’e ulaşabilir. curl‘ün -L seçeneği yönlendirmeleri takip eder, -w ise son durum kodunu yazdırır.

curl -sS -L -o /dev/null -w 'final=%{http_code} url=%{url_effective}n' https://example.com/eski-sayfa

Burada önemli olan yalnızca son kod değildir. Ara yanıtları da görmek istiyorsanız -D - seçeneğiyle her yanıtın başlıklarını inceleyin. 301 veya 302 zinciri gereksiz uzuyorsa sorun 404’ten önce başlamış olabilir.

3. DNS ve hedef IP’yi doğrulayın

Alan adının hangi IP’ye çözüldüğünü kontrol edin:

dig +short example.com A
dig +short example.com AAAA

Çıktıda beklemediğiniz bir IPv6 adresi varsa bazı istemciler sitenin farklı sunucusuna gidebilir. A ve AAAA kayıtlarının aynı hizmete ait olup olmadığını doğrulayın. DNS tarafını kontrol ederken 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? başlıklı içerikteki upstream yaklaşımı da akılda tutulabilir; 502 ve 404 farklı katmanları işaret eder, fakat ikisi de reverse proxy yapılandırmasıyla ilişkili olabilir.

4. Sunucu loglarını isteğin saatiyle eşleştirin

Nginx için yaygın log yolları /var/log/nginx/access.log ve /var/log/nginx/error.log dosyalarıdır. Dağıtım ve hosting paneline göre yollar değişebilir. İsteği tekrar gönderip aynı anda logu izlemek, tahmin yürütmekten daha güvenilirdir:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Access log satırında URL, durum kodu ve istemci IP’si; error log’da ise dosya yolu veya upstream bilgisi görülebilir. Access log’da 404 olup error log’da hiçbir kayıt olmaması her zaman sorun değildir. Nginx, beklenen bir dosya bulunamadığında yalnızca erişim kaydı bırakabilir.

Benzer bir kontrolü Apache’de /var/log/apache2/access.log ve /var/log/apache2/error.log üzerinden yapabilirsiniz. PHP-FPM logları ise uygulamanın isteği alıp almadığını ayırmaya yardımcı olur.

5. Dosya ve izinleri kontrol edin

Statik bir dosya için önce gerçekten var olup olmadığına bakın:

sudo stat /var/www/example/public/assets/app.css
sudo namei -l /var/www/example/public/assets/app.css

stat dosyanın mevcut olduğunu, namei -l ise yolun her bileşenindeki izinleri gösterir. Dosya mevcut olduğu halde web sunucusu okuyamıyorsa çoğu zaman 403 görürsünüz; fakat uygulama veya özel hata yapılandırması bunu 404 olarak maskeleyebilir. Sorunu anlamadan chmod -R 777 çalıştırmayın. Bu yaklaşım izin modelini düzeltmez, yalnızca yeni güvenlik sorunları açar.

Sunucu tarafında 404 nasıl düzeltilir?

Doğru çözüm, isteğin hangi katmanda kaybolduğuna göre değişir. Aşağıdaki sıra, dosya tabanlı bir site ile framework veya CMS kullanan uygulamalarda ortak bir başlangıç noktasıdır.

Dosya gerçekten taşındıysa

Eski URL’nin yeni ve eşdeğer bir karşılığı varsa 301 yönlendirmesi ekleyin. Nginx’te basit bir örnek şöyledir:

location = /eski-sayfa {
    return 301 /yeni-sayfa;
}

Değişiklikten sonra yapılandırmayı önce test edin:

sudo nginx -t
sudo systemctl reload nginx

nginx -t başarılı dönmeden reload çalıştırmayın. Bir müşterinin staging sandığı sanal host’ta Nginx değişikliği yaparken önce hostname’i kontrol etmeyi alışkanlık haline getirmemiştim; production prompt’undaki kırmızı renk o gün yerleşti. Şimdi yapılandırma değişikliğinden önce hedefi, sonra dosyayı kontrol ediyorum.

Uygulama rotası kayıpsa

Framework kullanan uygulamalarda route tanımını ve üretim ortamındaki base URL ayarlarını kontrol edin. İstek /api/v1/users yerine yanlışlıkla /api/users adresine gidiyorsa web sunucusunda dosya aramak vakit kaybettirir. Uygulama loglarında route eşleşmesi veya controller bulunamadığına dair kayıt arayın.

Uygulama yeni sürüme geçirildikten sonra route cache’i veya derlenmiş varlıklar eski kalabilir. Kullandığınız framework’ün resmi temizleme komutunu, önce yedek ve bakım planıyla uygulayın. Genel bir rm -rf komutunu kopyalayıp çalıştırmak, 404 sorununu daha büyük bir veri kaybına çevirebilir.

WordPress’te kalıcı bağlantıları kontrol edin

WordPress yönetim panelinde kalıcı bağlantı ayarlarını açıp değişiklik yapmadan yeniden kaydetmek bazı kurulumlarda rewrite kurallarını yeniler. Bu işlemden önce Nginx kullanılıyorsa uygulamanın ilgili location bloğunu da inceleyin; Apache içinse .htaccess dosyasının varlığı ve okunabilirliği önemlidir.

Birden fazla site aynı VPS’te barınıyorsa yanlış server block seçimi de gözden kaçabilir. Alan adı isteği beklenmeyen virtual host’a düşüyorsa doğru dosya yerinde olsa bile ziyaretçi varsayılan sitenin 404 sayfasını görür.

404 sayfası nasıl hazırlanmalı?

Her 404’ü düzeltmek mümkün değildir. Silinmiş bir içerik için kullanıcıya boş beyaz sayfa göstermek yerine, ne olduğunu açıklayan ve bir sonraki adımı sunan özel bir 404 sayfası hazırlamak daha sağlıklıdır.

• Sayfanın bulunamadığını açıkça söyleyin; kullanıcıyı belirsiz bir hata metniyle bırakmayın.
• Site araması, ana kategori bağlantıları veya ana sayfa bağlantısı ekleyin.
• 404 sayfasının kendi kaynak dosyaları için yeni 404 zinciri oluşturmadığını test edin.
• Silinmiş URL’leri sürekli ana sayfaya yönlendirmek yerine yalnızca uygun eşdeğer içerik varsa 301 kullanın.
• 404 yanıtını 200 olarak döndürmeyin; bu durum soft 404 olarak algılanabilir ve ölçüm sonuçlarını bozabilir.

404 kayıtlarını izlemek de içerik bakımına yardımcı olur. Aynı eski URL her gün tekrar tekrar isteniyorsa eski bir dış bağlantı, bozuk bir menü veya yanlış bir kampanya adresi olabilir. Arama motoru tarayıcıları için de doğru HTTP durumunu döndürmek, kaynağın mevcut olup olmadığını net biçimde bildirir.

404, 403, 410 ve 500 arasındaki fark nedir?

Bu kodlar birbirinin yerine kullanılmamalıdır. RFC 9110, HTTP durum kodlarını sınıflandırırken 4xx grubunu istemci isteğiyle ilişkili hatalar için, 5xx grubunu ise sunucunun isteği karşılayamamasıyla ilişkili hatalar için kullanır.

403 gördüğünüzde dosyanın mevcut olup olmadığını ve izinleri; 500 gördüğünüzde uygulama loglarını; 502 gördüğünüzde upstream bağlantısını inceleyin. Hepsine 404 çözümü uygulamak, teşhis sürecini uzatır.

404 hatasını önlemek için neler yapılabilir?

• URL yapısını değiştirmeden önce eski adreslerin listesini çıkarın.
• Taşınan sayfalar için kaynak ve hedef URL’leri içeren bir 301 planı hazırlayın.
• Dağıtım sonrasında kritik sayfaları curl veya otomatik HTTP kontrolleriyle test edin.
• Web sunucusu yapılandırmasını sürüm kontrolünde tutun ve değişiklikten önce nginx -t gibi doğrulama komutlarını çalıştırın.
• 404 loglarını düzenli inceleyin; aynı adresin tekrarlanması bir bağlantı hatasına işaret edebilir.
• Staging ortamında permalink, statik dosya, API ve görsel URL’lerini gerçek alan adı yapısına yakın biçimde deneyin.
• DNS değişikliklerinden sonra A ve AAAA kayıtlarını, CDN origin ayarlarını ve doğru virtual host’u birlikte kontrol edin.

İç bağlantılar değiştikçe küçük bir tarama aracı kullanmak da faydalıdır. Büyük sitelerde her sayfayı elle açmak gerçekçi değildir; fakat otomasyonun raporunu insan gözüyle kontrol etmek gerekir. Bir URL’nin 404 vermesi, onun kesinlikle gereksiz olduğu anlamına gelmez.

Sık Sorulan Sorular

404 hatası benim internetimden mi kaynaklanır?

Genellikle hayır. 404, HTTP sunucusunun isteği aldığını ve istenen kaynağı bulamadığını bildirir. DNS çözümlenmiyor, bağlantı kurulamıyor veya ağ isteği engelleniyorsa farklı hata türleri görürsünüz.

404 hatası SEO açısından zararlı mı?

Var olmayan bir URL’nin 404 döndürmesi tek başına anormal değildir. Sorun, önemli ve hâlâ erişilmesi gereken sayfaların yanlış yapılandırma nedeniyle 404 vermesi ya da taşınan içeriklerin uygun yönlendirme olmadan kaybolmasıdır.

404 yerine 301 yönlendirmesi ne zaman kullanılmalı?

Eski içeriğin eşdeğer ve geçerli bir yeni adresi varsa 301 kullanılabilir. Gerçek bir karşılık yoksa her adresi ana sayfaya yönlendirmek yerine doğru bir 404 veya içerik kalıcı biçimde kaldırıldıysa uygun durumlarda 410 döndürmek daha tutarlıdır.

404 hatası nasıl bulunur?

Önce curl -I veya tarayıcı geliştirici araçlarıyla durum kodunu doğrulayın; ardından DNS kaydını, web sunucusu yapılandırmasını ve access/error loglarını kontrol edin. İsteğin hangi katmanda 404’e dönüştüğünü bulduğunuzda çözüm genellikle dosya yolu, yönlendirme veya uygulama rotası seviyesinde netleşir.

Kaynaklar

• MDN – 404 Not Found — developer.mozilla.org
• Nginx – try_files Direktifi — nginx.org
• RFC 9110 – 404 Not Found — rfc-editor.org
• WordPress – Nginx Yapılandırması — developer.wordpress.org