HTTP Durum Kodları: SEO ve Hosting İçin 301, 302, 404, 410 ve 5xx Rehberi

HTTP Durum Kodları Nedir ve SEO/Hosting İçin Neden Bu Kadar Önemli?

Bir web projesi planlama toplantısında genellikle mimari, veritabanı yapısı, önbellekleme ve güvenlik konuşulur; ama HTTP durum kodları çoğu zaman kimsenin gündemine gelmez. Oysa arka planda her isteğin sonunda sunucunuzun döndürdüğü bu üç haneli kodlar, hem SEO performansınızı hem de hosting altyapınızın sağlığını doğrudan etkiler. Arama motorları sitenizi tararken, hangi URL’yi ne kadar sıklıkla tekrar deneyeceğine, hangi sayfaları dizinden çıkaracağına ve otoriteyi (link gücünü) hangi URL’lere aktaracağına bu kodlara bakarak karar verir.

Yanlış yapılandırılmış 301/302 yönlendirmeleri sizi fark etmeden organik trafikten eder, kontrolsüz 404’ler ve soft 404’ler tarama bütçenizi (crawl budget) boşa harcar, uzun süren 5xx sunucu hataları ise sitenizi kullanıcı ve bot gözünde güvenilmez hale getirir. DCHost altyapısında yüzlerce projeyi taşırken en çok fark yaratan unsurlardan birinin, “sadece birkaç satır” görünen durum kodu ve yönlendirme kuralları olduğunu defalarca gördük. Bu yazıda, özellikle 301, 302, 404, 410 ve 5xx kodlarını hem SEO hem de hosting tarafında nasıl doğru yöneteceğinizi, pratik örneklerle adım adım anlatacağız.

HTTP Durum Kodlarının Sınıfları: 2xx, 3xx, 4xx, 5xx Kısaca

Önce büyük fotoğrafı netleştirelim. HTTP durum kodları temelde 5 ana sınıfa ayrılır:

• 1xx – Bilgilendirici: Tarayıcıya isteğin alındığını, işlemin devam ettiğini söyler. SEO açısından kritik değildir, pratikte çok nadir dokunursunuz.
• 2xx – Başarılı: Özellikle 200 OK, “istek başarıyla işlendi” anlamına gelir. Arama motorlarının en çok görmek istediği koddur.
• 3xx – Yönlendirme: 301, 302, 307 gibi kodlarla bir URL’yi başka bir URL’ye taşır ya da geçici olarak yönlendirirsiniz. SEO’nun kalbi büyük ölçüde burada atar.
• 4xx – İstemci Hatası: 404, 410 gibi kodlar, isteğin geçersiz olduğunu veya kaynağın bulunamadığını ifade eder. Yanlış kullanılırsa tarama bütçesini boşa harcar.
• 5xx – Sunucu Hatası: 500, 502, 503, 504 gibi kodlar sunucunuzun isteği işleyemediğini gösterir. Hosting altyapısı, kapasite planlaması ve uygulama hatalarıyla birebir ilişkilidir.

Bu yazıda 3xx, 4xx ve 5xx sınıfına odaklanacağız; çünkü domain değişiminden URL yeniden yazımına, bakım anlarından trafik patlamalarına kadar hem SEO hem hosting tarafında en çok problem çıkaran kısım burası.

301 Yönlendirme: Kalıcı Taşınmanın SEO Dilindeki Karşılığı

301 Moved Permanently, “Bu içerik kalıcı olarak başka bir URL’ye taşındı” demektir. Arama motorları için bu sinyal, eski URL’nin otoritesinin ve backlink gücünün yeni URL’ye aktarılması gerektiği anlamına gelir. DCHost tarafında en çok şu senaryolarda 301 kurguluyoruz:

• Alan adı değişimi (example.com → example.com.tr)
• HTTP’den HTTPS’e geçiş
• www / non-www tercihi (www.example.com → example.com veya tersi)
• Eski URL yapısından yeni URL yapısına geçiş (ör. /index.php?id=10 → /blog/http-durum-kodlari/)

Alan adı değişimi süreçlerinde, alan adı değiştirirken SEO kaybetmemek için hazırladığımız detaylı rehberde de anlattığımız gibi, 301 haritası baştan sona eksiksiz planlanmalıdır. “Tüm alan adını ana sayfaya yönlendirelim, nasıl olsa çözer” yaklaşımı çoğu zaman otorite kaybı ve sıralama dalgalanması anlamına gelir.

301 Ne Zaman Kesinlikle Kullanılmalı?

Şu durumlarda 301 kullanmak neredeyse tartışmasız doğru karardır:

• Kalıcı domain değişimi: Marka kararı alındıysa ve eski domain sadece geçici bir kampanya için kullanılmayacaksa.
• Kalıcı URL yapısı değişimi: Örneğin /kategori/yazi-adi → /blog/yazi-adi gibi yapı değişimleri.
• HTTP → HTTPS geçişi: SSL sonrası tüm HTTP isteklerini HTTPS’e 301 ile yönlendirmek gerekir. Bu konuyu SSL sertifikası ve güvenli HTTPS rehberimizde de detaylandırıyoruz.
• www / non-www tercihi: Tek bir kanonik (asıl) versiyon seçilmeli ve diğeri 301 ile oraya akmalıdır.

301 ve SEO: Otorite, Backlink ve Canonical İlişkisi

301 yönlendirme, teoride eski URL’nin otoritesinin büyük kısmını yeni URL’ye taşır. Ancak pratikte, yanlış kurgulanan 301 zincirleri şu sorunlara yol açabilir:

• 301 zincirleri: A → B → C → D gibi 3–4 adımlı geçişler hem tarama bütçesini boşa harcar hem de her adımda risk taşır. En ideali A’nın doğrudan D’ye 301 olmasıdır.
• 301 döngüleri: A → B, B → A gibi sonsuz çemberler, kullanıcıyı da botu da çıkmaza sokar.
• Alakasız yönlendirme: Eski bir blog yazısını doğrudan ana sayfaya yönlendirmek yerine, en yakın içerik ya da kategoriye yönlendirmek genellikle daha sağlıklıdır.

Arama motorlarının tarafında canonical sinyallerini netleştirmek için, 301 ile yönlendirdiğiniz hedef URL’de rel=”canonical” etiketinin de kendisini işaret ettiğinden emin olun. Domain ve URL stratejisini kurarken alan adı stratejisi rehberimizde anlattığımız prensiplerle 301 planını birlikte düşünmek uzun vadede çok işinizi kolaylaştırır.

301 Örneği: Apache (.htaccess) ve Nginx

Basit bir HTTP → HTTPS yönlendirmesi için:

# Apache .htaccess örneği
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

# Nginx örneği
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

DCHost üzerinde Apache veya Nginx kullansanız da, bu tarz kuralları canlıya almadan önce staging ortamında test etmenizi; mümkünse Zero-Downtime yaklaşımı için TTL stratejileri rehberimizde anlattığımız plana benzer bir yol izlemenizi öneririz.

302 Yönlendirme: Geçici Denemeler İçin Doğru, Kalıcı Taşımalar İçin Yanlış Araç

302 Found (veya modern yorumuyla 302 Temporary Redirect), “Bu içerik geçici olarak başka bir URL’de” demektir. Arama motorları bu sinyali şu şekilde yorumlar:

• Esas URL halen eski adrestir.
• Backlink otoritesinin kalıcı aktarımı beklenmez.
• Durumun geçici olduğu varsayılır; bot eski URL’yi taramaya devam eder.

En sık yaptığımız gözlem şu: Aslında kalıcı bir domain veya URL değişikliği yapılmıştır, ama geliştirici taraf “şimdilik 302 atalım” diyerek geçici kodu bırakır ve öylece unutulur. Sonuç: Aylar sonra bile Google’ın eski URL’leri kanonik görmeye devam etmesi, otorite transferinin yavaş ya da eksik olması ve sıralama dalgalanmaları.

302 Ne Zaman Mantıklıdır?

Gerçekten geçici senaryolarda 302 çok işe yarar:

• A/B testleri: Aynı içeriğin iki tasarımını test ederken kullanıcıları geçici URL’lere yönlendirmek.
• Kısa süreli kampanyalar: /kampanya → /yaz-kampanyasi-2025 gibi, süresi sınırlı bir dönem için.
• Bakım sırasında geçici yönlendirme: Uzun sürecek ama kalıcı olmayan bir bakım sürecinde kullanıcıyı geçici bilgilendirme sayfasına almak.

Kural basit: Değişiklik kalıcıysa 301, geçiciyse 302. Bu ikisini karıştırmak en klasik SEO hatalarından biridir.

404 Hataları: Kaçınılmaz Ama Yönetilebilir

404 Not Found, sunucunun istenen kaynağı bulamadığını söyler. Doğru kullanıldığında tamamen normal ve zararsızdır; her sitenin belirli ölçüde 404 üretmesi doğaldır. Problem, 404’lerin:

• Kontrolden çıkması (binlerce/kaynakların büyük kısmı),
• Yanlış yerde kullanılması (aslında 301 olması gereken durumlarda),
• Sunucunun 200 OK döndürmesine rağmen içeriğin aslında bulunamaması (soft 404),

durumlarında başlar. Arama motorları boşa çıkan her istekte tarama bütçesini tüketir. Özellikle büyük sitelerde, log analizi yapmadan, 404 patlamalarını izlemeden ilerlemek risklidir.

Soft 404 Nedir ve Neden Tehlikeli?

Soft 404, sunucunun 200 OK döndürmesine rağmen, sayfanın içeriğinde “Bu sayfa bulunamadı”, “Ürün stokta yok” gibi mesajlar yer almasıdır. Yani teknik olarak her şey yolunda görünür ama gerçekte kullanıcı aradığı içeriğe ulaşamaz. Bu durumda:

• Arama motorları sayfayı normal içerik gibi dizine ekleyebilir,
• Kullanıcı deneyimi düşer, hemen çıkma oranı artar,
• Uzun vadede sayfa soft 404 olarak işaretlenir ve tarama/dizinleme süreçleri karmaşıklaşır.

Stoktan kalıcı olarak kalkan ürünler, silinen kategori sayfaları gibi durumlarda “404 mü 410 mu?” sorusu gündeme gelir. Buna birazdan 410 başlığında detaylı bakacağız.

Özel 404 Sayfası Nasıl Olmalı?

SEO dostu bir 404 sayfası şu özelliklere sahip olmalı:

• Gerçekten 404 döndürmeli: HTML’de 404 tasarımı gösterip HTTP seviyesinde 200 OK vermemeli.
• Site arama kutusu içermeli: Kullanıcının aradığı içeriği kolayca tekrar bulmasını sağlayın.
• Öne çıkan kategorilere/linklere yer vermeli: Özellikle e-ticarette popüler kategorilere gidiş yolları sunun.
• Log’lanmalı: Hangi URL’lerin 404 ürettiğini görebilmeniz için loglama ve izleme şart.

404 kaynaklarının nedenini incelerken, DNS hataları ve yanlış yapılandırmalarla karıştırmamak için DNS kayıtları rehberimizde anlattığımız temel DNS kontrollerini de mutlaka uygulayın. Bazı 404’ler aslında DNS tarafındaki küçük bir A/AAAA veya CNAME hatasından kaynaklanabiliyor.

410 Gone: Bilerek Sildiğiniz İçerikler İçin Temizlik Aracı

410 Gone, “Bu içerik kasıtlı olarak kaldırıldı ve geri dönmeyecek” anlamına gelir. Yani 404’ten daha sert ve niyet beyan eden bir koddur. Özellikle şu durumlarda 410 kullanmak mantıklı olabilir:

• Artık sunmak istemediğiniz, eski ve değersiz landing sayfaları,
• Hukuki sebeplerle tamamen silmeniz gereken içerikler,
• Uzun süredir 404 veren ve geri dönmesi planlanmayan URL’ler.

Arama motorları genellikle 410 kodunu gördüklerinde, ilgili URL’yi dizinden çıkarma kararını 404’e göre daha hızlı verir. Bu da özellikle temizlik yapmak istediğiniz, spam’e dönüşmüş veya gereksiz sayfalar için avantajdır. Ancak dikkat: Eğer ilgili içerik için yakın zamanda bir geri dönüş planınız varsa, 410 yerine 301 (uygun başka bir sayfaya) veya zamanla gerçek 404 daha mantıklı olabilir.

410 ile İçerik Temizliği Stratejisi

Büyük sitelerde zamanla işe yaramayan, trafik almayan ve link getirmeyen yüzlerce sayfa birikir. Bunları yönetmek için:

1. Analytics ve Search Console verilerinden trafik almayan URL’leri çıkarın.
2. Backlink’i olan ama trafik almayanlar için: İlgili ve canlı bir sayfaya 301 yönlendirme düşünün.
3. Backlink’i olmayan, trafik almayan ve geri dönmeyecek içerikleri 410’a çekin.
4. Log’lar ve tarama raporları ile 410’ların davranışını izleyin.

Bu yaklaşımı, alan adı mimarisi tarafında subdomain-alt dizin kararlarıyla birlikte düşünürseniz, hem SEO hem de hosting kaynak kullanımında ciddi sadeleşme sağlayabilirsiniz.

5xx Sunucu Hataları: Hosting, Kapasite ve SEO İlişkisi

5xx sınıfı hatalar, sunucunuzun isteği işleyemediğini gösterir. En yaygınları:

• 500 Internal Server Error: Uygulama hataları, yanlış dosya izinleri, bozuk .htaccess kuralları gibi çok genel sunucu hataları.
• 502 Bad Gateway: Genellikle reverse proxy (Nginx) ile arka uç (PHP-FPM, Node.js vb.) arasındaki iletişim sorunlarında ortaya çıkar.
• 503 Service Unavailable: Bakım modunda ya da sunucu aşırı yük altındayken verilen, doğru kullanıldığında SEO için “nazik” sayılabilecek hata kodu.
• 504 Gateway Timeout: Arka uçtan zamanında cevap alınamadığında oluşan timeout hatası.

Arama motorları bu hataları geçici sorun olarak yorumlar; ancak hata uzun sürer veya sık tekrar ederse, ilgili URL’leri daha az taramaya başlar, sıralamalarda düşüşler görülebilir. Özellikle yüksek trafikli sitelerde 5xx hatalarının çoğu, cPanel’de kaynak limitlerinin aşılması, yetersiz CPU/RAM/I/O veya yanlış PHP-FPM ayarlarından kaynaklanır.

5xx Hataları Neden SEO İçin Kritik?

Düzenli tekrar eden 5xx hatalarının tipik sonuçları:

• Tarama sıklığında azalma: Bot, sürekli hata aldığı domaini daha nadir ziyaret eder.
• Önemli sayfalarda sıralama kaybı: Özellikle kategori ve ürün sayfalarında 5xx patlaması ciddi trafik kayıpları doğurur.
• Core Web Vitals etkisi: Yanıt sürelerinin uzaması, TTFB’nin şişmesi hem kullanıcı deneyimini hem SEO’yu etkiler. Bu tarafı Core Web Vitals ve hosting altyapısı rehberimizde detaylı anlattık.

Bu yüzden 5xx’leri sadece “sunucu arada bir hata veriyor” diye küçümsemeyin; log’lar, izleme sistemleri ve doğru kapasite planlamasıyla mutlaka üzerine gidin.

503 ve Bakım Sayfası Stratejisi

Planlı bir bakım yapmanız gerektiğinde, yanlış yapılan en yaygın şey sitenin 200 OK kodlu bir “Bakımdayız” sayfasına alınmasıdır. Bu, arama motorları için kafa karıştırıcıdır. Doğru yaklaşım:

• HTTP seviyesinde 503 Service Unavailable döndürmek,
• Yanıt başlığına uygun bir Retry-After değeri eklemek,
• Kullanıcıya dost bir bakım sayfası göstermek.

Böylece botlara, “Bu durum geçici, şu süre sonra tekrar dene” demiş olursunuz. Uzun sürmesi beklenen çalışmalarda, bakım planını stale-while-revalidate ve stale-if-error gibi cache stratejileriyle birleştirmek, özellikle CDN kullanan projelerde neredeyse sıfıra yakın kesinti hissi sağlar.

5xx Hatalarını Azaltmak İçin Hosting Tarafında Neler Yapılmalı?

DCHost tarafında 5xx şikayetiyle gelen projelerde önce şu kontrol listesini çalıştırıyoruz:

1. Kaynak limitleri: CPU, RAM, I/O, EP limitleri düzenli olarak tavana vuruyor mu? Bunu görmek için panel istatistiklerini ve log’ları inceliyoruz.
2. Uygulama log’ları: PHP/Laravel, WordPress, Node.js hata log’larında tekrar eden istisnalar var mı?
3. Veritabanı performansı: Yavaş sorgular, kilitlenen tablolar var mı? (Bu tarafı için MySQL/PostgreSQL tuning rehberlerimize bakılabilir.)
4. Reverse proxy ayarları: Nginx/Apache timeout, keep-alive, buffer ayarları uygun mu?
5. Önbellekleme: Tam sayfa cache, obje cache, CDN etkin mi? Gereksiz dinamik yük sunucuya bindiriliyor mu?

İzleme ve alarm tarafını ise, VPS izleme ve uyarı rehberimizde anlattığımız gibi Prometheus/Grafana tarzı çözümlerle kurduğunuzda, 5xx patlamalarını SEO’ya yansımadan fark edip müdahale etmeniz çok daha kolay olur.

HTTP Durum Kodları, SEO ve Hosting’i Aynı Masada Konuşturmak

Durum kodları çoğu zaman sadece “backend’in işi” gibi görünse de, aslında SEO, içerik ekibi, ürün tarafı ve altyapı ekibinin kesiştiği noktadır. DCHost’ta bir projeyi taşırken ya da yeni kurarken şu prensiplerle ilerliyoruz:

• SEO tarafıyla beraber URL haritası çıkarmak: Hangi URL’ler kalıyor, hangileri 301/410 olacak, hangileri tamamen kapanacak netleştiriyoruz.
• Hosting altyapısını SEO gereksinimleriyle eşleştirmek: Sunucu lokasyonu, disk tipi, CPU/RAM gibi konuları SEO için hosting seçimi rehberimizde anlattığımız kriterlere göre seçmek, 5xx riskini en baştan azaltıyor.
• Tarama bütçesini koruyacak yapı kurmak: Gereksiz 404/410 üretmeyen, 301 zinciri oluşturmayan, net ve temiz bir URL mimarisiyle yola çıkmak.
• Bakım ve taşıma süreçlerini planlamak: Domain değişimi, sunucu taşıma gibi riskli operasyonlarda, taşıma planını önceden hazırlayıp test etmek.

Sunucu lokasyonunun SEO’ya etkisini merak ediyorsanız, sunucu lokasyonu ve SEO rehberimize göz atmanız, HTTP kodları stratejinizi coğrafi hedefleme ile uyumlu kurgulamanıza yardımcı olacaktır.

Pratik Kontrol Listesi: Yayına Çıkmadan Önce HTTP Kodlarınız Hazır mı?

Yeni bir siteyi canlıya alırken veya büyük bir revizyon yaparken, aşağıdaki kontrol listesini elinizin altında tutun:

1. 301 haritası: Eski → yeni URL eşleştirmeleri dosyalanmış, test edilmiş mi?
2. HTTP → HTTPS: Tüm HTTP istekleri tek adımda doğru HTTPS URL’sine 301 oluyor mu?
3. www / non-www: Tek bir kanonik versiyon seçildi mi; diğeri 301 ile oraya gidiyor mu?
4. Geçici yönlendirmeler: Kalıcı değişikliklerde yanlışlıkla 302 kullanılmadığından emin misiniz?
5. 404 ve 410: Silinen veya taşınan içerikler için doğru kod kullanılıyor mu? Özel 404 sayfanız gerçekten 404 mü döndürüyor?
6. 5xx izlemesi: Canlıya çıkışta 5xx yükselişlerini görebileceğiniz log ve izleme araçlarınız hazır mı?
7. Bakım senaryosu: Gerekirse 503 + Retry-After ile nazik bir bakım modu devreye alabiliyor musunuz?

Bu kontrol listesini bir kere oluşturup kendi projenize göre uyarladığınızda, her yeni release’te veya taşıma operasyonunda tekrar kullanabilir, HTTP durum kodlarını “unutulan detay” olmaktan çıkarıp süreçlerin doğal bir parçası haline getirebilirsiniz.

Sonuç: HTTP Durum Kodlarını Doğru Yönetin, SEO ve Hosting Birlikte Kazansın

HTTP durum kodları, günlük iş akışında pek konuşulmasa da projenizin sağlığını yansıtan en net sinyallerden biridir. 301 ve 302 ile arama motorlarına “Bu URL’nin hikâyesi ne?” sorusunun cevabını verirsiniz; 404 ve 410 ile hangi içeriklerin artık sahneden çekildiğini anlatırsınız; 5xx ile de hosting altyapınızın ne kadar sağlam kurulduğunu gösterirsiniz. DCHost olarak gördüğümüz gerçek şu: Durum kodlarını ciddiye alan ekipler, alan adı değişimi, mimari revizyon, sunucu taşıma gibi riskli süreçlerden çok daha az hasarla, çoğu zaman da kazançlı çıkar.

Eğer siz de domain değişimi, URL yapısı revizyonu, sunucu/mimari değişiklik gibi bir adım planlıyorsanız ve HTTP kodları konusunda kafanızda soru işaretleri varsa, projenizi bizimle aynı masaya yatırmanız yeterli. Mevcut loglarınızı, Search Console verilerinizi ve altyapınızı birlikte inceleyip; 301/302 stratejinizden 404/410 temizlik planınıza, 5xx riskinden bakım senaryonuza kadar net ve uygulanabilir bir yol haritası çıkarabiliriz. Böylece SEO ekipleriniz, geliştiricileriniz ve DCHost altyapınız aynı dili konuşur; siz de hem sıralamalarda hem de kesintisiz erişilebilirlik tarafında daha sakin bir yolculuğa geçersiniz.