Hosting ve DNS Tarafında 404 Yönetimi

Neden Hosting ve DNS Tarafında 404 Yönetimi Bu Kadar Kritik?

Bir SEO raporunda yüzlerce 404 hatası görmek, çoğu zaman gerçek sorunun yalnızca görünen yüzüdür. Asıl problem; alan adı, DNS, web sunucusu ve uygulama katmanında 404 ve yönlendirmelerin nasıl yönetildiğiyle ilgilidir. Yanlış kurgulanmış 404 davranışı, hem ziyaretçi deneyimini bozar hem de arama motorlarının gözünde sitenizin güvenilirliğini zedeler. Üstelik işin içine soft 404 dediğimiz, gerçekte 404 olması gereken ama 200 dönen sayfalar girdiğinde tablo daha da karmaşıklaşır.

DCHost olarak sahada en sık gördüğümüz sorunlardan biri, kırık linklerin ya hiç yönetilmemesi ya da tüm 404’lerin tek seferde ana sayfaya körü körüne 301 ile yönlendirilmesidir. Bu iki uç yaklaşım da hatalıdır. Doğru olan; DNS seviyesinde hataları azaltmak, web sunucusu seviyesinde anlamlı 301/410 kuralları yazmak ve uygulama tarafında soft 404 üreten senaryoları temizlemektir. Bu yazıda, hosting ve DNS tarafında 404 yönetimini uçtan uca ele alarak, kırık linkleri nasıl verimli bir şekilde 301’e çevirebileceğinizi ve soft 404 hatalarını nasıl önleyebileceğinizi adım adım anlatacağız.

HTTP Durum Kodlarını Netleştirmek: 404, 410, 301, 302, 200 ve Soft 404

Sağlam bir 404 stratejisi kurmanın ilk adımı, HTTP durum kodlarının ne anlama geldiğini netleştirmektir. Bu konuya zaten detaylı olarak değindiğimiz HTTP durum kodları ve SEO etkileri rehberine mutlaka göz atmanızı öneririm. Burada ise 404 yönetimiyle doğrudan ilgili olan kodlara odaklanalım.

• 200 OK: Sayfa başarılı şekilde bulundu ve içerik sunuldu. Arama motorları bu URL’yi indekslemeye devam eder.
• 301 Moved Permanently: Kalıcı yönlendirme. Eski URL’nin otoritesi, yeni URL’ye taşınır. URL değişikliği, HTTPS’e geçiş ve kalıcı mimari değişikliklerde kullanılmalıdır.
• 302 Found / 307 Temporary Redirect: Geçici yönlendirme. Eski URL teoride hala geçerlidir; bu yüzden uzun vadeli URL değişikliklerinde kullanılmamalıdır.
• 404 Not Found: Kaynak bulunamadı; geçici de olabilir kalıcı da. Eğer kalıcı olduğundan eminseniz 410 daha güçlü bir sinyaldir.
• 410 Gone: Kaynak kalıcı olarak kaldırıldı. Artık hiçbir zaman gelmeyecek. Uzun vadede arama motorlarının bu URL’yi bırakmasını hızlandırır.

Soft 404 ise teknik olarak 200 dönen, ama arama motorlarının ‘Bu sayfa aslında yok’ diye etiketlediği durumlardır. Örneğin:

• Boş bir kategori sayfası: ‘Bu kategoride ürün yok’ yazısı dışında içerik yok ama 200 dönüyor.
• Arama sonuçlarında hiçbir sonuç çıkmayan ve alternatif sunulmayan sayfalar.
• 404 gibi görünen ama gerçekten 404 döndürmeyen özel tasarımlı hata sayfaları.

Soft 404, görünürde hata vermediği için çoğu zaman gözden kaçar; ama hem tarama bütçesini boşa harcar hem de SEO performansını ciddi şekilde zayıflatır.

DNS ve Hosting Tarafında 404 Arasındaki Farkı Anlamak

404 temelde HTTP katmanında verilen bir yanıttır. Yani tarayıcının web sunucusuna ulaşabilmiş olması gerekir. DNS tarafındaki sorunlarda ise genellikle 404 bile göremezsiniz; bunun yerine tarayıcı ‘siteye ulaşılamıyor’ veya ‘DNS_PROBE_FINISHED_NXDOMAIN’ gibi hatalar gösterir. Bu ayrımı doğru anlamazsanız, sorunu yanlış yerde ararsınız.

DNS kaynaklı ‘404 sanılan’ hatalar

• Alan adının A/AAAA kayıtlarının yanlış IP’ye işaret etmesi
• Altdomain için CNAME kaydının eksik olması
• Alan adı süresinin bitmesi veya nameserver kayıtlarının yanlış olması

Bu tip durumlarda gerçek anlamda 404 üretemezsiniz; çünkü istek web sunucunuza hiç ulaşmaz. Bu senaryoları teşhis etmek için hem DNS kayıtları A’dan Z’ye rehberine hem de DNS yayılım süresi ve hızlandırma makalelerine göz atmak çok faydalıdır.

Wildcard DNS ve istenmeyen soft 404 fırtınaları

Bir diğer sık hata; tüm altdomain’leri tek bir IP’ye düşüren wildcard DNS kayıtlarıdır (örneğin *.ornek.com). Eğer web sunucunuzda bu altdomain’ler için özel bir sanal host yoksa, çoğu zaman tek bir ‘default’ site açılır. Sonuç:

• Var olmayan alt alanlar bile 200 döner,
• Arama motorları bu URL’leri keşfederse binlerce anlamsız sayfa indekslenir,
• Soft 404 ve içerik kopyası sorunları tetiklenir.

Bu yüzden DNS tarafında wildcard kayıtları kullanıyorsanız, web sunucunuzun varsayılan sanal host’unu mutlaka doğru şekilde 404 veya 301 döndürecek biçimde yapılandırmanız gerekir.

Kırık Linkleri Tespit Etmek: Loglar, Crawler’lar ve Arama Konsolu

404 yönetimi, tespit etmediğiniz sürece mümkün değildir. Hosting tarafında işin en güçlü kaynağı, web sunucusu loglarıdır. Apache ve Nginx access log’ları, hangi URL’nin hangi durum kodunu ne zaman döndürdüğünü net şekilde gösterir. Bu konuyu detaylı anlattığımız sunucu loglarını okuma rehberini mutlaka okumanızı öneririm.

1. Web sunucusu loglarından 404 analizi

SSH erişimi olan VPS veya dedicated sunucularda, 404 hatalarını hızlıca görmek için örnek bir komut akışı şöyle olabilir:

# Apache access log'da 404 hatalarını listele
cat /var/log/apache2/access.log | grep ' 404 '

# Nginx için örnek
cat /var/log/nginx/access.log | grep ' 404 '

Daha sonra bu satırları bir script ile işleyip en çok 404 üreten URL’leri, bu URL’lere gelen istek sayısını ve referer bilgisini çıkarabilirsiniz. Özellikle referer alanı; kırık linkin nereden geldiğini (iç link mi, harici link mi) anlamak için çok değerlidir.

2. Google Search Console ve soft 404 raporları

Google Search Console; 404, soft 404 ve 5xx hatalarını size doğrudan raporlar. Ancak bu raporlar genellikle gecikmelidir ve yalnızca Google’ın taradığı URL’leri kapsar. Dolayısıyla Search Console verisini, sunucu loglarıyla birleştirerek yorumlamak en sağlıklı yaklaşımdır.

3. Crawler araçları ve site içi kırık linkler

Özellikle büyük sitelerde, site içi kırık linkleri bulmak için crawler araçları kullanmak çok etkilidir. Bu araçlar tüm iç linkleri gezerek 404 veren linkleri raporlar. Sonrasında bu URL’ler için ya 301 kuralı yazarsınız ya da linkleri doğru URL’lerle güncellersiniz.

Apache/.htaccess ile 404 ve 301 Yönetimi

Paylaşımlı hosting ve cPanel ortamlarında 404 ve 301 yönetimi çoğunlukla .htaccess dosyası üzerinden yapılır. DCHost altyapısında da Apache ve LiteSpeed tabanlı planlarda benzer yapı kullanılır. Doğru yazılmış birkaç kural ile hem kırık linkleri toparlayabilir hem de soft 404 riskini azaltabilirsiniz.

Özel 404 sayfası tanımlamak

İlk adım, kullanıcı dostu ve gerçekten 404 döndüren bir hata sayfası üretmektir:

ErrorDocument 404 /404.php

Burada önemli nokta; 404.php dosyasının PHP veya framework tarafında 200 değil, gerçekten 404 döndürmesidir. Örneğin PHP’de:

<?php
http_response_code(404);
?>
<!doctype html>
<html>
  <head><title>Sayfa Bulunamadı</title></head>
  <body>
    <h1>Sayfa bulunamadı</h1>
    <p>Aradığınız sayfa taşınmış veya silinmiş olabilir.</p>
  </body>
</html>

Birçok projede hata sayfası şık tasarlanıyor ama 200 dönüyor; bu da doğrudan soft 404 sebebi oluyor.

Eski URL’leri yeni URL’lere 301 ile yönlendirmek

URL yapınızı değiştirdiyseniz veya sayfaları yeniden yapılandırdıysanız, eski URL’leri tek tek 404 bırakmak yerine mantıklı 301 yönlendirmeleri yazmak gerekir. Bu konuyu detaylı ele aldığımız SEO kaybı olmadan URL yapısı değiştirme rehberini okumanızda fayda var. Basit bir örnek:

Redirect 301 /eski-urun.html /yeni-urun

# Belirli bir dizini komple yeni dizine taşımak
RedirectMatch 301 ^/blog/eski-kategori/(.*)$ /blog/yeni-kategori/$1

Burada dikkat etmeniz gerekenler:

• Eski URL’yi içerik olarak en yakın yeni URL’ye yönlendirin; alakasız sayfaya yönlendirme kullanıcıyı da arama motorunu da mutsuz eder.
• Tüm 404’leri ana sayfaya yönlendirmekten kaçının; bu yaygın ama yanlış bir pratiktir ve soft 404 olarak işaretlenebilir.

www/çıplak alan adı ve HTTP → HTTPS yönlendirmeleri

Canonical domain ve HTTPS geçişinde yapılan yönlendirmeler, 404 stratejinizle doğrudan bağlantılıdır. Yanlış kurgulanmış yönlendirmeler hem redirect loop yaratabilir hem de gerçek 404’lerin önüne set çekebilir. Bu konuda detaylı olarak ele aldığımız www mi çıplak alan adı mı? ve HTTP’den HTTPS’ye geçiş rehberlerini incelemek doğru kurguyu netleştirmenize yardımcı olur.

Nginx ile 404 Yönetimi ve Soft 404’leri Engellemek

VPS veya dedicated sunucu üzerinde Nginx kullanıyorsanız, 404 ve 301 yönetimi server block seviyesinde yapılır. DCHost VPS ve dedicated çözümlerinde bu yapı üzerinde tam kontrol sağlarsınız.

Özel 404 sayfası ve gerçek 404 döndürmek

server {
    listen 80;
    server_name ornek.com www.ornek.com;

    root /var/www/ornek.com/public;

    error_page 404 /404.html;

    location = /404.html {
        internal;
    }

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Burada error_page 404 /404.html; satırı, 404 durum kodunu koruyarak kullanıcıya özel hata sayfası gösterir. Dikkat edilmesi gereken nokta; 404.html dosyasının return 200 gibi bir kural ile yeniden 200’e çevrilmemesidir.

Eski URL’leri 301 ile taşımak

server {
    listen 80;
    server_name ornek.com;

    # Tekil yönlendirme
    location = /eski-urun {
        return 301 /yeni-urun;
    }

    # Eski dizini komple taşımak
    location ~ ^/blog/eski-kategori/(.*)$ {
        return 301 /blog/yeni-kategori/$1;
    }
}

Nginx tarafında genellikle yapılan hata; rewrite kurallarının yanlış kullanılması sonucu sonsuz yönlendirme döngüleri yaratmak veya 404 olması gereken URL’leri de istemeden yönlendirmektir. Bu nedenle önce loglarda en çok 404 üreten URL’leri çıkarıp, yalnızca anlamlı olanları yönlendirmeye almak en temiz çözümdür.

Soft 404 Hatalarının En Yaygın Nedenleri ve Çözümleri

Gerçek 404’leri 301 veya 410 ile doğru yönetmek kadar, soft 404 üretmemek de önemlidir. Arama motorları ‘Bu sayfa aslında yok ama 200 dönüyor’ dediği anda, hem tarama bütçeniz hem de sıralama sinyalleriniz zarar görür.

1. Boş kategori ve etiket sayfaları

E-ticaret ve blog sitelerinde en sık gördüğümüz sorunlardan biri, içi boş kategori ve etiket sayfalarıdır. Örneğin:

• Kategoride hiç ürün yok, sadece ‘Bu kategoride ürün bulunmamaktadır’ yazıyor.
• Eski bir kampanya için açılmış kategori artık kullanılmıyor.

Çözümler:

• Kategori tamamen kapatıldıysa, ilgili URL’yi en yakın alakalı kategoriye 301 ile yönlendirin veya 410 döndürün.
• Geçici olarak boşsa, ilgili ürünler eklenecekse 200 dönebilen ama zengin bir içerik hazırlayın (önerilen ürünler, popüler kategoriler vb.).

2. Boş arama sonuçları ve filtre sayfaları

Site içi arama sayfalarında veya filtreleme parametrelerinde hiçbir sonuç çıkmıyorsa ve sayfa yalnızca ‘Sonuç bulunamadı’ diyorsa, bu sayfalar da soft 404 olarak işaretlenebilir. Daha iyi bir yaklaşım:

• Kullanıcıya alternatif ürün veya içerikler sunmak,
• Popüler kategorilere veya en çok satılan ürünlere link vermek,
• Gerekirse bu tip sayfaları noindex, follow ile işaretlemek.

3. Yanlış kurgulanmış bakım ve maintenance sayfaları

Planlı bakım sırasında sitenizi maintenance moduna alırken, SEO’yu bozmadan hareket etmek önemlidir. Burada 503 Service Unavailable kodu çoğu zaman en doğru seçenektir. Bu konuyu detaylı anlattığımız bakım modu ve planlı kesinti rehberine göz atabilirsiniz. Bakım sayfasının 200 dönmesi, arama motorlarının bu sayfayı normal içerik sanmasına ve soft 404/kalitesiz içerik sinyallerine yol açabilir.

4. Tüm 404’lerin ana sayfaya yönlendirilmesi

En tehlikeli soft 404 sebeplerinden biri budur. Tüm 404’leri otomatik olarak ana sayfaya 301 ile yönlendiren birçok hazır tema ve eklenti var. Kısa vadede ‘404 sayfam yok, ne güzel’ gibi görünse de uzun vadede:

• Arama motorları bu yönlendirmeleri alakasız bulur,
• Soft 404 ve zayıf kullanıcı sinyalleri oluşur,
• Hem eski hem yeni URL’nin otoritesi zarar görür.

Doğru yaklaşım; sadece anlamlı eşleşmesi olan eski URL’leri yeni, ilgili URL’lere yönlendirmektir. Gerçekten karşılığı olmayan URL’ler ise düzgün tasarlanmış bir 404 sayfasıyla 404 kalmalıdır.

DNS ve Hosting Katmanında 404 Yönetimi İçin Önerilen Süreç

Dağınık .htaccess kuralı yazmak veya tek seferlik Nginx ayarı yapmak yerine, 404 yönetimini bir süreç olarak tasarladığınızda hem operasyonel yükünüz hem de SEO riski azalır. DCHost tarafında müşterilerimizle çalışırken genellikle şu akışı öneriyoruz:

1. DNS ve alan adı katmanını doğrulayın

• Alan adınızın A/AAAA ve CNAME kayıtlarını gözden geçirin.
• Wildcard kayıt kullanıyorsanız, varsayılan sanal host’un davranışını netleştirin.
• Yeni alan adı taşıma veya isim değişikliği yapıyorsanız, alan adı değiştirirken SEO kaybetmemek rehberindeki adımları izleyin.

2. Log analiziyle gerçek 404 haritası çıkarın

• Son 30-90 günlük web sunucusu loglarını çekin.
• En çok istek alan 404 URL’leri ve referer kaynaklarını listeleyin.
• Harici sitelerden gelen önemli linkleri özellikle işaretleyin.

3. Her 404 için strateji belirleyin

• Alakasız/yanlış yazım URL’ler: Temiz bir 404 sayfası yeterli.
• Eski ama değerli içerikler: En yakın yeni içerik veya kategoriye 301.
• Kalıcı olarak kapanmış sayfalar: 410 veya ilgili genel bilgilendirme sayfasına 301.

4. Yönlendirme kurallarını versiyonlayın ve test edin

Özellikle büyük projelerde, .htaccess veya Nginx konfigürasyonunu doğrudan canlıda değiştirmek yerine:

• Önce staging ortamında değişiklikleri deneyin,
• Yönlendirme zinciri ve loop olup olmadığını test edin,
• Değişiklikleri bir versiyon kontrol sistemi (Git vb.) altında tutun.

DCHost VPS ve dedicated sunucularda, bu tür CI/CD akışlarını kurmak için sağladığımız SSH ve root erişimi sayesinde çok esnek mimariler kurabilirsiniz.

SEO, Kullanıcı Deneyimi ve DCHost Altyapısında 404 Yönetimini Oturtmak

404 yönetimi çoğu zaman ‘SEO görevi’ gibi görülür; oysa işin kalbi hosting, DNS ve web sunucusu mimarinizdedir. Doğru kurgulanmış bir altyapı ile:

• DNS hatalarından kaynaklanan erişim sorunlarını minimize eder,
• Web sunucusu seviyesinde temiz ve okunabilir 301/404/410 kuralları uygular,
• Uygulama tarafında soft 404 üreten senaryoları kontrol altına alırsınız.

DCHost olarak; paylaşımlı hosting, VPS, dedicated ve colocation altyapılarımızda, bu tarz ince ayarları yapabileceğiniz esnek ortamlar sunuyoruz. İsterseniz cPanel üzerinden basit yönlendirme kurallarıyla başlayabilir, isterseniz VPS üzerinde Nginx/Apache konfigürasyonlarını tamamen sizin kontrolünüze bırakabiliriz. Özellikle yeni bir mimari değişiklik, alan adı taşıma veya büyük URL revizyonu planlıyorsanız, 404 ve 301 stratejisini en baştan tasarlamak kritik bir adımdır.

Mevcut sitenizde yoğun 404, soft 404 veya karmaşık yönlendirme zincirleri varsa; log analizi, DNS kontrolleri ve web sunucusu kural tasarımı için DCHost ekibiyle birlikte adım adım ilerleyebilirsiniz. Altyapınızı daha sağlıklı bir 404 yönetimiyle güçlendirmek ve organik trafiğinizi koruyarak büyütmek için, projelerinize en uygun hosting veya VPS çözümlerini birlikte planlamaktan memnuniyet duyarız.