400 durum kodu, istemciden gelen isteğin sunucu tarafından işlenemeyecek kadar hatalı, eksik veya anlaşılmaz olduğunu bildiren bir HTTP yanıtıdır. Tarayıcı, bir mobil uygulama ya da bir tarama botu sunucuya istek gönderdiğinde, bu isteğin söz dizimi, başlık bilgileri veya gövde içeriği HTTP standartlarına uymuyorsa sunucu işlemi başlatmadan “400 Bad Request” yanıtı döndürür. Yani sorunun kaynağı, sunucunun işlem kapasitesi değil, kendisine ulaşan isteğin yapısıdır.
Bu hata ziyaretçiler için kesintisiz bir deneyimi bozar, site yöneticileri için ise teknik bir tanı gerektirir. Kodun neyi ifade ettiğini, hangi koşullarda üretildiğini ve arama motorlarının bu yanıtı nasıl yorumladığını bilmek, hem kullanıcı kaybını hem de tarama verimliliği sorunlarını önlemenin ilk adımıdır.
HTTP 400 Durum Kodunun Teknik Tanımı
HTTP yanıt kodları beş ana sınıfa ayrılır. 4xx grubu, hatanın istemci kaynaklı olduğunu belirtir. 400 kodu bu grubun genel hata yanıtıdır; sunucu isteğin neden geçersiz olduğunu daha spesifik bir koda (örneğin 401, 403, 404 veya 414) bağlayamadığında devreye girer. Sunucu bu durumda isteği reddeder ve çoğu zaman yeniden denenmeden aynı sonucun alınacağını varsayar.
Teknik açıdan sunucu, gelen isteği ayrıştırırken (parsing) bir söz dizimi hatası, geçersiz bir karakter ya da tutarsız bir başlık alanıyla karşılaşırsa işlemi keser. Yanıt gövdesinde genellikle sade bir hata sayfası yer alır; ancak sunucu yapılandırmasına göre özel bir hata şablonu da gösterilebilir. Tüm HTTP kodlarının genel mantığını ayrıntılı biçimde görmek için 2xx, 3xx, 4xx ve 5xx yanıtlarını SEO açısından ele alan HTTP durum kodları rehberine göz atabilirsiniz.
400 Hatasının Farklı Görünümleri
Aynı hata, kullanılan sunucu yazılımına ve tarayıcıya göre farklı ifadelerle karşımıza çıkar. Bu varyasyonlar sorunun kaynağına dair ipucu verebilir.
- 400 Bad Request
- HTTP Error 400 – Bad Request
- Bad Request – Invalid URL
- Bad Request – Your browser sent a request that this server could not understand
- Request Header or Cookie Too Large
- HTTP Error 400. The request hostname is invalid
“Request Header or Cookie Too Large” mesajı, çoğunlukla çerez boyutunun sunucunun kabul ettiği sınırı aştığına işaret eder. “Invalid URL” ifadesi ise adres satırındaki karakterlerin veya kodlamanın hatalı olduğunu düşündürür.
400 Hatasına Yol Açan Başlıca Nedenler
Hatanın tek bir sebebi yoktur. İstemci, ağ katmanı ve sunucu yapılandırması birlikte değerlendirilmelidir. Aşağıdaki başlıklar, pratikte en sık karşılaşılan senaryoları kapsar.
Hatalı veya Geçersiz URL Yapısı
URL içinde izin verilmeyen karakterlerin bulunması en yaygın nedenlerden biridir. Boşluk, kaçış karakteri olmadan kullanılan özel semboller, hatalı yüzde kodlaması (percent-encoding) ya da bozuk bir sorgu dizesi, sunucunun isteği ayrıştırmasını engeller. Özellikle manuel olarak oluşturulan parametreli bağlantılar ve kopyalama sırasında bozulan adresler bu soruna açıktır. UTM parametrelerinin dinamik biçimde üretildiği kurulumlarda da kodlama hataları 400 yanıtına yol açabilir.
Bozuk veya Aşırı Büyük Çerezler
Tarayıcı, her istekle birlikte alan adına ait çerezleri sunucuya gönderir. Çerez verisi zamanla büyür ya da bozulursa, toplam başlık boyutu sunucunun limitini aşar. Birçok sunucu bu durumda isteği doğrudan reddeder. Aynı siteye farklı alt alan adlarından çok sayıda çerez yazılması, oturum yönetimi hataları ve takip betiklerinin biriktirdiği veriler bu tabloyu tetikleyebilir.
Tarayıcı Önbelleği ve DNS Önbelleği Sorunları
Eski ya da tutarsız önbellek kayıtları, tarayıcının yanlış bilgilerle istek oluşturmasına neden olabilir. Yerel DNS önbelleğindeki hatalı kayıtlar da özellikle alan adı yeni taşındıysa “hostname is invalid” türü yanıtlara yol açar.
Dosya Yükleme Limitleri
Sunucuya gönderilen dosya, izin verilen boyutu aşarsa bazı yapılandırmalar 413 yerine genel bir 400 yanıtı üretebilir. Form gönderimleri, medya yükleme alanları ve API uç noktaları bu açıdan kontrol edilmelidir.
Sunucu Yapılandırması ve Güvenlik Katmanları
Web uygulama güvenlik duvarları (WAF), ters vekil sunucular (reverse proxy), CDN servisleri ve yük dengeleyiciler, şüpheli ya da standart dışı istekleri 400 koduyla engelleyebilir. Başlık uzunluğu limitleri, desteklenmeyen HTTP sürümleri ve geçersiz Host başlığı bu kapsamdadır. Sunucu düzeyindeki kural yönetimi için .htaccess dosyasının yönlendirme, güvenlik ve hız ayarlarındaki rolü iyi bir başlangıç noktasıdır.
Hatalı API ve Form İstekleri
Uygulama tarafında JSON gövdesinin bozuk olması, zorunlu alanların eksik gönderilmesi veya Content-Type başlığının gövdeyle uyuşmaması, API’lerde 400 yanıtının temel nedenleridir. Modern web uygulamalarında istemci taraflı kodun ürettiği isteklerin doğruluğu, JavaScript’in çalışma mantığı ile yakından ilişkilidir.
400 Hata Kodunu Benzer Durum Kodlarından Ayırmak
400 yanıtı sıklıkla diğer 4xx kodlarıyla karıştırılır. Doğru tanı için farkları net bilmek gerekir.
| Durum Kodu | Anlamı | Temel Sebep | Çözüm Odağı |
|---|---|---|---|
| 400 | Bad Request | İstek söz dizimi veya yapısı hatalı | URL, çerez, başlık ve gövde kontrolü |
| 401 | Unauthorized | Kimlik doğrulaması eksik veya geçersiz | Giriş bilgileri ve yetkilendirme |
| 403 | Forbidden | Erişim izni yok | Dosya izinleri ve erişim kuralları |
| 404 | Not Found | Kaynak bulunamadı | Yönlendirme ve içerik varlığı |
| 414 | URI Too Long | URL izin verilen uzunluğu aştı | Parametre ve adres kısaltma |
Bir sayfa gerçekte yokken 200 yanıtı veriyorsa durum tamamen farklıdır; bu senaryo için Soft 404 hatasının tespiti ve çözüm yöntemleri ayrı bir değerlendirme gerektirir.
Ziyaretçiler İçin Adım Adım Çözüm Yöntemleri
Hata, istemci tarafında oluşuyorsa kullanıcı birkaç basit müdahaleyle sorunu giderebilir. Aşağıdaki adımlar, en olası nedenden en az olası nedene doğru sıralanmıştır.
- URL’yi kontrol edin: Adres satırında yazım hatası, fazladan karakter veya bozuk kodlama olup olmadığına bakın ve bağlantıyı yeniden yazın.
- Sayfayı yenileyin: Geçici bir iletişim kesintisi nedeniyle oluşan hatalar yenilemeyle çözülebilir.
- Çerezleri temizleyin: Yalnızca ilgili alan adına ait çerezleri silmek, boyut kaynaklı sorunları çoğunlukla ortadan kaldırır.
- Önbelleği temizleyin: Tarayıcı önbelleğini boşaltarak eski kayıtların isteği bozmasını engelleyin.
- DNS önbelleğini sıfırlayın: İşletim sisteminin DNS önbelleğini temizleyerek hatalı çözümlemeleri giderin.
- Tarayıcı eklentilerini devre dışı bırakın: Reklam engelleyiciler ve güvenlik eklentileri istek başlıklarını değiştirebilir.
- Farklı tarayıcı veya cihaz deneyin: Sorunun istemciye özgü olup olmadığını bu şekilde ayırt edebilirsiniz.
- Yüklenen dosyanın boyutunu küçültün: Yükleme sırasında oluşan hatalarda dosyayı sıkıştırın ya da daha düşük boyutlu bir sürüm kullanın.
Site Yöneticileri İçin Teknik Tanı ve Giderme Süreci
Birden fazla kullanıcı aynı hatayı alıyorsa sorun büyük olasılıkla istemcide değil, site altyapısındadır. Bu durumda sistematik bir tanı süreci izlenmelidir.
Sunucu Günlüklerini İnceleyin
Erişim ve hata kayıtları, hangi isteğin hangi nedenle reddedildiğini en net biçimde gösterir. İstek satırı, kullanıcı aracısı (user-agent), yanıt kodu ve zaman damgası birlikte okunduğunda hatanın belirli bir URL kalıbına, belirli bir bota ya da belirli bir cihaz grubuna özgü olup olmadığı anlaşılır. Kayıtların yapısı ve yorumlanması için sunucu log dosyalarının SEO açısından analizi yol gösterici bir kaynaktır.
Başlık ve Çerez Limitlerini Gözden Geçirin
Nginx, Apache ve IIS gibi sunucuların her birinde istek satırı ve başlık boyutu için varsayılan limitler bulunur. Uygulamanız büyük çerezler veya uzun yetkilendirme belirteçleri kullanıyorsa bu değerlerin artırılması gerekebilir. Daha kalıcı çözüm ise çerez içeriğini küçültmek, gereksiz takip verilerini temizlemek ve oturum bilgilerini sunucu tarafında tutmaktır.
Ara Katmanları Test Edin
CDN, WAF ve ters vekil sunucu devredeyken hata üretiliyorsa isteği doğrudan kaynak sunucuya göndererek karşılaştırma yapın. Hata yalnızca ara katmanda oluşuyorsa kural setleri, istek normalizasyonu ve başlık yeniden yazma ayarları incelenmelidir.
Uygulama Kodunu ve Form Doğrulamalarını Denetleyin
Beklenmeyen biçimde bozuk istekler üreten bir form, bir betik veya üçüncü taraf entegrasyonu olabilir. Tarayıcı geliştirici araçlarındaki ağ sekmesi ile gönderilen isteğin ham halini inceleyin; Content-Type, karakter kodlaması ve parametre biçimleri doğru mu kontrol edin. Gerekirse istek doğrulama mantığına, sunucunun ne istediğini açıkça anlatan hata mesajları ekleyin.
Özel Hata Sayfası Hazırlayın
Varsayılan, sade bir 400 sayfası kullanıcıyı çıkmaza sokar. Marka diliyle uyumlu, hatanın muhtemel nedenini kısaca açıklayan ve ana sayfaya ya da arama alanına yönlendiren özel bir sayfa, hemen çıkma oranını düşürür. Bu yaklaşım kullanıcı deneyimi ilkeleriyle de örtüşür. Sayfanın HTTP durum kodunun doğru biçimde 400 olarak döndürüldüğünden emin olun; hata şablonunun 200 ile servis edilmesi yeni sorunlara yol açar.
400 Hatasının SEO Üzerindeki Etkisi
Tek bir kullanıcının tarayıcısında görülen geçici bir 400 hatası, arama sıralamalarını doğrudan etkilemez. Ancak hata, arama motoru botlarına da yansıyorsa tablo değişir. Googlebot bir URL’yi tarayıp 400 yanıtı aldığında, bu sayfayı dizine eklemez; daha önce dizinde yer alıyorsa zamanla dizinden çıkarabilir. Sorun yaygınsa ilgili URL grupları taranamaz hale gelir ve organik görünürlük kaybı yaşanır.
Bir diğer risk, tarama bütçesi üzerindeki olumsuz etkidir. Bot, geçerli sayfalar yerine hata üreten URL’lere kaynak harcarsa önemli içeriklerin keşfi gecikebilir. Bu konuda tarama bütçesi optimizasyonu kapsamlı bir çerçeve sunar. Hatalı biçimde üretilmiş iç bağlantılar, bozuk parametreli URL’ler ve yanlış yazılmış kanonik adresler, 400 yanıtlarının sitenizde çoğalmasına sebep olabilir.
İzleme tarafında Search Console’daki kapsam ve dizinleme raporları, botun karşılaştığı hata türlerini listeler. Raporlardaki “sunucu hatası” ve “gönderilen URL bulunamadı” gibi kalemleri düzenli takip etmek gerekir. Rapor mesajlarının nasıl yorumlanacağı için Search Console sayfa dizinleme raporu rehberi işinizi kolaylaştırır.
400 Hatalarını Önlemeye Yönelik Kalıcı Önlemler
Hataları ortaya çıktıktan sonra düzeltmek yerine, oluşmalarını engelleyen bir altyapı kurmak daha verimlidir. Aşağıdaki uygulamalar kurumsal sitelerde tutarlı sonuç verir.
- Sitedeki tüm iç bağlantıları ve kanonik adresleri periyodik olarak tarayarak bozuk URL kalıplarını tespit edin.
- Parametreli URL üretiminde karakter kodlamasını merkezi bir fonksiyonla yönetin.
- Çerez sayısını ve boyutunu sınırlayın, gereksiz takip çerezlerini kaldırın.
- Sunucu ve ara katman başlık limitlerini gerçek kullanım verilerine göre belirleyin.
- Form ve API girdileri için istemci ve sunucu tarafında çift katmanlı doğrulama uygulayın.
- Hata oranlarını izleyen uyarı sistemleri kurun ve 4xx artışlarında otomatik bildirim alın.
Teknik denetimlerde tarayıcı tabanlı bir tarama aracı, hatalı yanıt veren URL’leri toplu halde listelemek için oldukça işlevseldir. Screaming Frog ile teknik SEO denetimi bu amaçla sıkça tercih edilir. Ayrıca robots.txt yapılandırmasında yanlış kurallar, botların gereksiz parametreli adreslere yönelmesine yol açabileceğinden robots.txt dosyasının doğru kullanımı da hata önleme planının parçası olmalıdır.
400 Hatası Sık Sorulan Sorular
400 Bad Request hatası sitemin sıralamasını düşürür mü?
Tek seferlik ve izole bir kullanıcı hatası sıralamayı etkilemez. Botların sürekli 400 aldığı sayfalar ise dizinden çıkabilir ve bu durum ilgili sayfaların organik trafiğini azaltır. Bu nedenle hata oranlarını düzenli izlemek gerekir.
400 hatası ile 404 hatası aynı şey midir?
Hayır. 404, istenen kaynağın sunucuda bulunamadığını gösterir. 400 ise isteğin kendisinin hatalı ya da anlaşılmaz olduğunu belirtir. İlkinde sorun içeriğin varlığıyla, ikincisinde isteğin biçimiyle ilgilidir.
Hatayı ziyaretçi mi yoksa site sahibi mi çözmelidir?
Sorun yalnızca belirli bir cihazda veya tarayıcıda görülüyorsa çerez ve önbellek temizliği yeterli olabilir. Birden fazla kullanıcı aynı hatayı alıyorsa sunucu yapılandırması, uygulama kodu ve ara katmanların site sahibi tarafından incelenmesi gerekir.
Çerez temizlemek neden hatayı giderir?
Aşırı büyümüş veya bozulmuş çerezler, istek başlığının sunucu limitini aşmasına neden olur. Çerezler silindiğinde başlık boyutu normale döner ve sunucu isteği tekrar işleyebilir.
Doğru Tanı ile Sağlıklı Bir Teknik Altyapı
400 durum kodu, sunucunun istemciden gelen isteği güvenle işleyemediğini bildiren, çoğu zaman basit nedenlere dayanan ama göz ardı edildiğinde tarama ve kullanıcı deneyimi açısından maliyetli hale gelebilen bir yanıttır. URL yapısı, çerez yönetimi, başlık limitleri, güvenlik katmanları ve uygulama doğrulamaları birlikte ele alındığında hatanın kaynağı büyük ölçüde belirlenebilir. Düzenli log analizi, Search Console takibi ve periyodik teknik denetimler, bu tür yanıtların hem ziyaretçiler hem de arama motoru botları için görünür bir soruna dönüşmeden çözülmesini sağlar. Hatanın doğasını doğru okumak, siteyi daha tutarlı, erişilebilir ve sürdürülebilir bir teknik zemine taşır.
