404 Not Found Hatası Nedir, Sitede Nasıl Düzeltilir?

404 Not Found hatası, tarayıcının istediği adresin sunucuda bulunamadığını söyleyen HTTP durum kodudur. Ziyaretçi tarafından bakınca sıkıcı ama zararsız bir "sayfa bulunamadı" ekranıdır; site sahibi tarafından bakınca ise bambaşka bir şeydir. Tek bir 404 hiçbir şey ifade etmez — yıllardır her sitede vardır ve olmalıdır. Ama Search Console'da bir sabah "Bulunamadı (404)" satırının 12'den 4.300'e fırladığını görüyorsanız, o artık bir hata kodu değil, kaybedilmiş trafiğin faturasıdır.

Bu yazı 404 hatasını ziyaretçi gözünden değil, siteyi yöneten kişinin gözünden anlatıyor. Sırasıyla şunları göreceksiniz: gerçek 404 ile soft 404 arasındaki fark ve Google'ın ikisine neden tamamen farklı davrandığı, Search Console'daki "Bulunamadı (404)" raporunun satır satır nasıl okunacağı, ham sunucu logundan 404 listesi çıkarmanın komutu, ve en önemlisi — hangi 404'ün 301 ile yönlendirileceği, hangisinin bilinçli olarak 410 bırakılacağı, hangisine hiç dokunulmayacağı kararını veren mantık. Bu son kısım Türkçe kaynaklarda neredeyse hiç kurulmaz; oysa 404 temizliğinde işin tamamı odur.

404 Not Found Hatası Nedir ve Ne Zaman Üretilir#

404, sunucunun "isteğini aldım, anladım, ama bu adreste bir kaynak yok" demesidir. HTTP durum kodları ailesinde 4xx grubundadır; yani sorumluluk istemci tarafındadır — sunucu çalışıyor, PHP ayakta, veritabanı bağlı, sadece istenen yol karşılığı bir dosya ya da kayıt yok.

Sunucu bir 404 ürettiğinde arka planda şu sıra işler:

1. Web sunucusu (Apache/Nginx/LiteSpeed) gelen yolu disk üzerinde arar.
2. Fiziksel dosya varsa döner. Yoksa uygulamaya devreder (WordPress'te index.php).
3. Uygulama kendi yönlendirme tablosuna bakar. WordPress bunu WP_Query ile yapar; eşleşen yazı/sayfa/terim bulamazsa is_404() doğru olur.
4. Uygulama tema içindeki 404.php şablonunu 404 başlığıyla birlikte basar.

Dördüncü adımdaki "404 başlığıyla birlikte" ifadesi kritiktir ve birazdan anlatacağımız soft 404 sorununun tam olarak kaynağıdır. Tarayıcıda gördüğünüz sayfa metni ile sunucunun gönderdiği durum kodu iki ayrı şeydir. Gerçek durum kodunu görmek için:

curl -s -o /dev/null -w "%{http_code}\n" https://ornek.com/olmayan-sayfa

Bu komut ekrana sadece 404 yazmalıdır. 200 yazıyorsa siteniz "sayfa bulunamadı" görselini gösterirken sunucuya "her şey yolunda" dedirtiyor demektir — sorun tam olarak buradadır.

Ayrıntılı başlıkları görmek isterseniz:

curl -I https://ornek.com/olmayan-sayfa

Çıktının ilk satırı HTTP/2 404 olmalı.

404 Her Zaman Kötü Değildir: Hangi 404 Gerçekten Sorundur#

Kısa cevap: bir 404, ona giden bir bağlantı ya da bir arama trafiği varsa sorundur; yoksa değildir. Google'ın kendisi de yıllardır aynı şeyi söyler — silinmiş içeriğin 404 dönmesi doğru davranıştır ve sitenin genel sıralamasına ceza olarak yansımaz.

Pratikte 404'leri üç kutuya ayırıyorum:

Zararsız 404 (dokunmayın). Bot taramaları, eski wp-content/uploads yollarına atılan tahmin istekleri, /wp-admin.php, /.env, /phpmyadmin gibi güvenlik taramaları, yanlış yazılmış tek seferlik adresler. Bunlar loglarda binlerce satır tutar ama hiçbir SEO değeri taşımaz. Yönlendirmek zaman kaybıdır, hatta zararlıdır — çünkü her birini ana sayfaya atarsanız soft 404 üretirsiniz.

Zararlı 404 (mutlaka düzeltin). Kendi sitenizin menüsünden, içeriğinden ya da sitemap'inden bağlantı verilen adresler. Bunlar ziyaretçiyi duvara toslatır, tarama bütçesini yakar ve site içi bağlantı akışını keser.

Değerli 404 (öncelikle düzeltin). Dışarıdan bağlantı alan ya da eskiden organik trafik getiren, sonra silinen/adresi değişen sayfalar. Bir yazınız yıllarca /blog/eski-yazi adresinde durup bağlantı topladıysa ve siz kalıcı bağlantı yapısını değiştirdiyseniz, o adres artık bir varlıktır ve kaybetmek istemezsiniz.

Bu ayrımı yapmadan 404 temizliğine başlarsanız, günlerinizi bot isteklerini yönlendirmekle geçirirsiniz.

Soft 404 ile Gerçek 404 Arasındaki Fark#

Soft 404, sayfanın kullanıcıya "bulunamadı" göstermesine rağmen sunucunun 200 OK döndürmesidir. Google bunu ayrı bir hata olarak raporlar ve gerçek 404'ten daha kötü kabul eder.

Neden daha kötü? Çünkü gerçek 404'te Google kararını hemen verir: "bu adres yok, indeksten düşür, bir daha nadiren uğra." Soft 404'te ise Google 200 gördüğü için sayfayı geçerli sanıp indekslemeye çalışır, sonra içeriğin boş/anlamsız olduğunu fark edip kendi kendine karar vermek zorunda kalır. Sonuç: tarama bütçesi boşa gider, indekste değersiz adresler birikir, ve gerçekten önemli sayfalarınız daha seyrek taranır.

Türkiye'de soft 404 üreten en yaygın dört durum:

WordPress'te soft 404'ün en sık nedeni, kötü yazılmış bir yönlendirme eklentisi kuralı ya da temanın 404.php dosyasında başlığı ezen bir header() çağrısıdır. Kontrol için tema dosyasında şu satırın varlığına bakın:

<?php
// 404.php dosyasının en üstünde bulunması gereken davranış:
// WordPress bunu normalde kendisi yapar, ama bir eklenti/tema ezmiş olabilir.
if ( is_404() ) {
    status_header( 404 );
    nocache_headers();
}

Eğer functions.php içinde template_redirect kancasına bağlı ve olmayan sayfaları wp_redirect( home_url() ) ile ana sayfaya atan bir kod bulursanız, soft 404 kaynağınız odur. Silin.

Search Console'daki "Bulunamadı (404)" Raporu Nasıl Okunur#

Rapora Dizine Ekleme → Sayfalar → Dizine eklenmedi → Bulunamadı (404) yolundan ulaşırsınız. Ekranda gördüğünüz sayı tek başına anlamsızdır; okunması gereken üç şey vardır.

1. Eğri, sayıdan önemlidir. Yıllardır 300 civarında seyreden bir 404 sayısı normaldir. Önemli olan dikey sıçramadır. Grafikte belirli bir güne denk gelen keskin bir yükseliş varsa, o gün ne yaptığınızı bulun: tema değişimi, kalıcı bağlantı ayarı değişimi, site taşıma, eklenti güncellemesi, ürün toplu silme.

2. Örnek URL listesindeki ortak deseni bulun. Google en fazla 1.000 örnek gösterir. Listeyi indirip (sağ üstteki dışa aktar) desene bakın. Şu gibi ortaklıklar hemen göze çarpar:

• Tümü /2023/11/ ile başlıyor → tarih tabanlı kalıcı bağlantıdan yazı adına geçilmiş.
• Tümü /urun/ ile başlıyor, yenisi /p/ → e-ticaret altyapısı URL şeması değişmiş.
• Tümü /?p= ile başlıyor → eski sorgu tabanlı adresler, kalıcı bağlantı yönlendirmesi kırılmış.
• Tümünde %20 ya da Türkçe karakter var → dosya adı kodlaması bozulmuş.

3. "Yönlendiren sayfa" bilgisine bakın. Örnek URL'ye tıklayıp URL'yi incele dediğinizde Google'ın bu adresi nereden bulduğunu görebilirsiniz. Kaynak sitemap ise sitemap'iniz bayattır; kaynak kendi sayfanız ise site içi bağlantınız kırıktır; kaynak dış bir site ise o adres yönlendirilmeye değer bir varlıktır.

⚠️ Bir uyarı: Search Console verisi gecikmelidir. Düzeltmeyi yapıp "Düzeltmeyi doğrula" dedikten sonra sayının sıfırlanması haftalar sürer. Sayı düşmüyor diye ikinci bir düzeltme dalgası başlatmayın — çift yönlendirme zinciri üretirsiniz.

Sunucu Loglarından 404 Listesi Çıkarma#

Search Console yalnızca Google'ın gördüğü 404'leri gösterir. Ziyaretçilerin ve diğer botların tetiklediklerini görmek için ham erişim logu gerekir. cPanel'de Metrikler → Ham Erişim bölümünden indirebilir, VDS'te doğrudan okuyabilirsiniz.

En çok 404 üreten 30 adresi çıkarmak için:

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

Apache için log formatı aynıysa yol değişir:

awk '$9 == 404 {print $7}' /var/log/apache2/access.log \
  | sort | uniq -c | sort -rn | head -30

Çıktı şuna benzer:

   4127 /wp-login.php
   1893 /.env
    642 /blog/eski-kategori/sayfa-2
    318 /urun/kirmizi-tisort
    204 /wp-content/uploads/2024/03/gorsel-1.jpg

Bu listede ilk iki satır güvenlik taramasıdır — dokunmayın, gerekirse Fail2ban ile engelleyin. Üçüncü ve dördüncü satırlar gerçek içerik adresleridir ve yönlendirilmeleri gerekir. Beşinci satır bir görsel yoludur; medya kütüphanesinden silinmiş ama içeriklerde hâlâ çağrılıyor demektir.

Referrer bilgisini de görmek isterseniz — yani bu kırık bağlantının hangi sayfanızda durduğunu:

awk '$9 == 404 {print $7, "<-", $11}' /var/log/nginx/access.log \
  | grep -v '"-"' | sort | uniq -c | sort -rn | head -20

$11 referrer alanıdır ve "-" olmayan satırlar, birinin gerçekten bir bağlantıya tıkladığını gösterir. Bunlar önceliğinizdir. Sunucu tarafında hata kaydı okumaya yeni başlıyorsanız cPanel hata kayıtları yazısı log dosyalarının nerede tutulduğunu anlatıyor.

Karar Tablosu: 301 mi, 410 mu, Dokunmamak mı#

Bu bölüm yazının çekirdeğidir. Elinizde 404 listesi var; her satır için üç seçenekten birini seçeceksiniz.

İki kural bu tabloyu özetler:

Kural 1 — Alakasız 301 yapmayın. "Nasıl olsa ana sayfaya atarım" yaklaşımı en yaygın hatadır. Google alakasız bir 301'i bağlantı değeri aktarımı olarak kabul etmez, soft 404 sayar. 200 farklı silinmiş ürünü ana sayfaya atmak, 200 tane soft 404 üretmektir.

Kural 2 — 410 bir yenilgi değil, bir karardır. 410 Gone, "bu içerik vardı, kalıcı olarak kaldırıldı, bir daha aramayın" demektir. Google 404'e göre daha kesin bir sinyal olarak alır ve o adresi tarama listesinden daha çabuk çıkarır. Bilinçli olarak sildiğiniz — kalitesiz eski yazılar, kapatılan hizmet sayfaları, taşınmayacak arşiv — için doğru cevap 410'dur.

Apache'de 410 vermek:

# .htaccess
Redirect 410 /blog/2019/eski-kampanya
Redirect 410 /urun/uretimden-kalkti

Nginx'te:

location = /blog/2019/eski-kampanya { return 410; }
location = /urun/uretimden-kalkti   { return 410; }

301 Yönlendirmeyi Doğru Kurma#

Yönlendirmeyi üç katmandan birinde yapabilirsiniz ve doğru katman, sitenizin sunucusuna bağlıdır.

Apache / LiteSpeed (paylaşımlı hosting). .htaccess dosyasına yazılır. WordPress kurallarının üstüne koyun, yoksa WordPress isteği önce yakalar:

# .htaccess — WordPress bloğunun ÜSTÜNE
RewriteEngine On

# Tekil adres
Redirect 301 /blog/eski-yazi /rehber/yeni-yazi

# Kalıp: tarih tabanlı yapıdan yazı adına geçiş
RewriteRule ^[0-9]{4}/[0-9]{2}/(.+)$ /$1 [R=301,L]

# Kalıp: eski ürün dizini
RewriteRule ^urun/(.*)$ /p/$1 [R=301,L]

Kural yazarken karışıklığa düşerseniz .htaccess yönlendirme yazısı sözdizimini ayrıntılı anlatıyor.

Nginx (VDS/sunucu). .htaccess çalışmaz; kural sunucu yapılandırmasına girer:

server {
    # Tekil
    location = /blog/eski-yazi {
        return 301 /rehber/yeni-yazi;
    }

    # Kalıp
    location ~ ^/urun/(.*)$ {
        return 301 /p/$1;
    }
}

Değişiklikten sonra mutlaka sözdizimini sınayın, sonra yeniden yükleyin:

nginx -t && systemctl reload nginx

nginx -t başarısız olursa reload çalıştırmayın — çalışan yapılandırmayı bozarsınız ve site 502 vermeye başlar.

WordPress (eklenti tabanlı). Küçük hacimde en pratik yol budur, özellikle sunucu dosyasına erişiminiz yoksa. Ancak her istek PHP'ye kadar geldiği için sunucu katmanına göre yavaştır. Yüzlerce kuralınız varsa sunucu katmanına taşıyın. WordPress'e özgü ayrıntılar için WordPress 301 yönlendirme yazısına bakın.

Kurduğunuz her yönlendirmeyi tek satırla doğrulayın:

curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}\n" https://ornek.com/blog/eski-yazi

Beklenen çıktı: 301 -> https://ornek.com/rehber/yeni-yazi. 302 görüyorsanız kuralınız geçici yönlendirme kurmuş demektir ve bağlantı değeri aktarılmaz.

Toplu 404 Krizleri: Site Taşıma ve Kalıcı Bağlantı Değişimi#

404 sayısının bir gecede patlamasının Türkiye'de gördüğüm dört klasik sebebi var.

1. Kalıcı bağlantı yapısı değiştirildi. WordPress'te Ayarlar → Kalıcı Bağlantılar ekranından yapı değiştirmek, o ana kadarki tüm adreslerin ölmesi demektir. WordPress bunların bir kısmını kendi içinde tahmin ederek yönlendirir ama tarih tabanlıdan yazı adına geçişte çoğu kırılır. Yapıyı değiştirmeden önce eski adres listesini çıkarın; WordPress kalıcı bağlantı ayarları yazısı hangi yapının hangi riski taşıdığını anlatıyor.

2. Site taşındı, adres şeması değişti. Alt dizinden kök dizine ya da tersine taşımalarda /blog/ ön eki düşer veya eklenir. Taşımadan önce eski sitemap dosyasını saklayın — 404 listenizin karşılaştırma tabanı odur. Taşıma sürecinin tamamı için web sitesi taşıma rehberine bakabilirsiniz.

3. Türkçe karakterli dosya adları. görsel-şık.jpg gibi bir dosya, sunucu kodlaması değişince g%C3%B6rsel-%C5%9F%C4%B1k.jpg olarak çağrılır ve bulunamaz. Yeni sunucuda dosya sistemi kodlaması farklıysa toplu görsel 404'ü buradan gelir. Çözüm: dosya adlarını ASCII'ye çevirin ve içerikteki referansları veritabanında toplu güncelleyin.

4. HTTPS/www geçişi eksik yapıldı. http://ornek.com, https://ornek.com, https://www.ornek.com birbirine yönlendirilmemişse her biri ayrı bir site gibi davranır ve iç bağlantılar çapraz kırılır.

Toplu kriz durumunda ilk yapılacak şey panik yönlendirme değil, kalıp bulmaktır. 4.000 kırık adresin 3.800'ü tek bir RewriteRule ile kapanıyorsa, tek tek liste yapmak haftalar kaybettirir.

Özel 404 Sayfası Nasıl Hazırlanır#

Özel 404 sayfası SEO'yu düzeltmez ama ziyaretçi kaybını azaltır. İyi bir 404 sayfasında şunlar olmalı: site arama kutusu, ana kategorilere bağlantılar, en popüler 5 içerik, ve iletişim yolu. Olmaması gerekenler: otomatik ana sayfa yönlendirmesi (soft 404 üretir), geri sayım sayacı, ve "hata oluştu" dışında bilgi vermeyen boş bir ekran.

Apache'de özel sayfayı tanımlamak:

ErrorDocument 404 /404.html

Nginx'te:

error_page 404 /404.html;
location = /404.html {
    internal;
}

internal yönergesi önemlidir: /404.html adresinin doğrudan ziyaret edilip 200 dönmesini engeller.

WordPress'te tema klasöründeki 404.php dosyası otomatik kullanılır; ayrı bir tanım gerekmez. Sadece o dosyanın içinde ana sayfaya yönlendirme kodu olmadığından emin olun.

Sıkça Sorulan Sorular#

404 hatası siteyi Google'da düşürür mü#

Hayır, tek başına bir sıralama cezası değildir. Google silinmiş içeriğin 404 dönmesini normal ve doğru davranış kabul eder. Ceza gibi görünen kayıp aslında dolaylıdır: trafik getiren bir sayfa 404 verdiğinde o sayfanın trafiği sıfırlanır, dış bağlantıları boşa gider ve tarama bütçesi ölü adreslere harcanır. Yani zarar sitenin tamamına değil, o adrese ve ona bağlı akışa gelir.

Soft 404 nedir ve neden gerçek 404'ten kötüdür#

Soft 404, sayfanın ekranda "bulunamadı" yazmasına rağmen sunucunun 200 OK durum kodu döndürmesidir. Gerçek 404'ten daha kötüdür çünkü Google'ı kararsız bırakır: durum kodu geçerli dediği için sayfayı indekslemeye çalışır, içeriği değersiz bulup vazgeçer ve bu döngü her taramada tekrarlanır. En yaygın nedeni, olmayan adresleri ana sayfaya 301 ile yönlendirmektir. curl -I ile durum kodunu ölçerek anında teşhis edilir.

Bütün 404'leri ana sayfaya yönlendirmek doğru mu#

Hayır, bu en sık yapılan hatadır. Google alakasız bir hedefe yapılan 301'i bağlantı değeri aktarımı olarak kabul etmez ve o adresi soft 404 olarak raporlar. Yönlendirme yalnızca hedef sayfa, kaybolan sayfanın gerçek karşılığıysa anlamlıdır. Karşılığı olmayan içerik için doğru cevap 404 bırakmak ya da 410 Gone döndürmektir.

410 hatası ne zaman kullanılmalı#

410 Gone, içeriğin kalıcı olarak kaldırıldığını ve geri gelmeyeceğini bildirmek istediğinizde kullanılır. Bilinçli silinen eski kampanya sayfaları, üretimden kalkan ürünler ve temizlenen düşük kaliteli arşiv içerikleri için uygundur. Google 410'u 404'ten daha kesin bir sinyal sayar ve adresi tarama listesinden daha hızlı düşürür. Emin değilseniz 404 bırakmak da güvenlidir; 410 sadece süreci hızlandırır.

Search Console'daki 404 sayısı düzeltmeden sonra neden düşmüyor#

Search Console verisi gecikmelidir ve rapor, Google'ın adresi yeniden taramasıyla güncellenir. Düzeltmeyi doğrula dedikten sonra listenin temizlenmesi birkaç haftayı bulabilir, düşük yetkili sitelerde daha uzun sürer. Bu süre boyunca ikinci bir yönlendirme dalgası başlatmayın; üst üste kural yazmak yönlendirme zinciri üretir ve durumu kötüleştirir. Yaptığınız düzeltmeyi curl ile doğruladıysanız beklemek doğru davranıştır.

Bot taramalarının ürettiği 404'leri engellemek gerekir mi#

Genelde gerekmez; /wp-login.php, /.env, /xmlrpc.php gibi adreslere gelen istekler otomatik güvenlik taramalarıdır ve 404 dönmeleri zaten istenen sonuçtur. Ancak bu istekler saniyede onlarca gelmeye başlıyorsa sunucu kaynağı tüketirler; o noktada Fail2ban ya da sunucu düzeyinde bir hız sınırı devreye alınmalıdır. Bu adresleri yönlendirmek kesinlikle yanlıştır, çünkü yönlendirme sunucuya 404'ten daha pahalıya mal olur.

Kırık görsel bağlantıları da 404 sayılır mı#

Evet, sunucu açısından eksik bir görsel de tam olarak 404 üretir ve erişim logunda aynı satırda görünür. SEO etkisi sayfa 404'üne göre çok daha düşüktür ama sayfa görsel yüklenmediği için görsel aramada kaybolur ve kullanıcı deneyimi bozulur. Log çıktısında .jpg, .png, .webp uzantılı satırlar birikiyorsa medya kütüphanesinden silinmiş ama içeriklerde çağrılmaya devam eden dosyalar var demektir. Çözüm veritabanında toplu adres güncellemesi yapmak ya da dosyayı eski yoluna geri koymaktır.

404 sayfasına noindex etiketi eklemeli miyim#

Hayır, gerekli değildir ve gereksiz bir katman ekler. 404 durum kodunun kendisi zaten Google'a "bu adresi indeksleme" demektedir; üstüne noindex koymak bir şey kazandırmaz. Buna karşılık /404.html gibi özel hata sayfanız doğrudan ziyaret edildiğinde 200 dönüyorsa, o adres indekslenebilir hale gelir — çözüm noindex eklemek değil, Nginx'te internal yönergesiyle o sayfaya doğrudan erişimi kapatmaktır.

Kapanış#

404 yönetiminin özü tek bir cümlede toplanır: her 404'ü düzeltmeye çalışmayın, hangisinin değerli olduğuna karar verin. Search Console raporundan ve ham erişim logundan çıkardığınız listeyi üçe ayırın — taşınmış içerik 301 alır, kalıcı silinmiş içerik 410 alır, bot ve yazım hatası kaynaklı adresler olduğu gibi 404 kalır. Ardından her yönlendirmeyi curl ile tek tek doğrulayın; kurduğunuzu sandığınız kuralın gerçekten 301 döndüğünü görmeden işi bitmiş saymayın. Soft 404 tuzağını da unutmayın: ekranda hata gösterip sunucudan 200 göndermek, hiç düzeltme yapmamaktan daha zararlıdır.

Bu işi kendiniz yürütmek istemiyorsanız ya da toplu 404 krizi bir site taşıma sonrası çıktıysa, süreci devredebileceğiniz noktalar var. Adres şeması değişmeden, eski yönlendirme haritası korunarak yapılan bir geçiş için site taşıma hizmetimize, WordPress tarafında kalıcı bağlantı ve yönlendirme bakımının düzenli yapılması için WordPress bakım paketimize bakabilirsiniz. Arama görünürlüğü tarafında kırık bağlantı temizliği ve indeks sağlığı takibi SEO hizmetimizin kapsamındadır.