503 Service Unavailable Hatası Nedir? Nedenleri ve Çözümü

503 Service Unavailable hatası nedir?

503 Service Unavailable, sunucunun isteği şu anda karşılayamadığını bildiren HTTP durum kodudur. Sunucu çalışıyor, ancak aşırı yük, bakım ya da kaynak sınırı yüzünden yanıt veremiyor. Bu durum geçici sayılır, bu yüzden bazen sayfayı yenilemek yeterli olur.

Kod, 5xx sınıfındaki sunucu hatalarından biridir. 4xx hatalarında sorun genellikle isteğin kendisindedir, 5xx hatalarında ise sorun sunucu tarafındadır. MDN, 503 yanıtını sunucunun isteği işlemeye hazır olmaması diye tanımlar. MDN 503 sayfası ve RFC 9110 503 bölümü bu tanımın birincil kaynaklarıdır.

Tarayıcıda bu kodu farklı mesajlarla görürsünüz. Örneğin "Service Unavailable", "HTTP Error 503", "Service Temporarily Unavailable" ya da "Site geçici olarak kullanılamıyor" yazısı çıkabilir. Hosting firmanız özel bir hata sayfası kullanıyorsa mesaj tamamen farklı görünebilir, ama altındaki durum kodu aynıdır.

Bu yazı üç okur grubuna hitap eder. Ziyaretçi olarak ne yapacağınızı, site sahibi olarak neyi kontrol edeceğinizi ve sunucuyu kendiniz yönetiyorsanız hangi komutlarla teşhis koyacağınızı anlatır. Ayrıca bakım sırasında 503 kullanmanın SEO açısından neden doğru olduğunu da açıklar.

503 Service Unavailable hatasından kim sorumlu: ziyaretçi mi, site sahibi mi, sunucu yöneticisi mi?

Ziyaretçiyseniz sorumluluk size ait değildir, çünkü hata sunucu tarafında doğar. Sorunu asıl çözecek kişiler site sahibi ile sunucu yöneticisidir. Ancak her rolün yapabileceği farklı şeyler vardır. Önce kendi rolünüzü belirleyin, çünkü yanlış yerde vakit kaybetmek hatayı uzatır.

Ziyaretçi olarak sitenin sahibine ulaşabiliyorsanız hatayı bildirin. Site sahibi olarak hostingi bir sağlayıcıdan alıyorsanız, kaynak sınırı ile ilgili son sözü o sağlayıcı söyler. Dolayısıyla panelde göreceğiniz grafikler önemli bir kanıttır.

503 Service Unavailable hatası neden olur?

Hata, sunucunun isteği o an işleyememesinden doğar ve nedenler birkaç ana başlıkta toplanır. En sık görülenler aşağıdaki gibidir. Her biri için ilerleyen bölümlerde ayrı ayrı teşhis yolu veriyoruz.

• Sunucu ya da PHP işçileri aşırı yük altında kalır ve yeni isteği kuyruğa alamaz.
• Hosting paketinin işlemci, bellek ya da eşzamanlı işlem sınırı dolar.
• Site bilerek ya da yanlışlıkla bakım modunda kalır.
• Bot, tarayıcı ya da saldırı trafiği kaynakları tüketir.
• Arka uç servisi (PHP-FPM, uygulama sunucusu, veritabanı) çökmüş ya da yanıt vermiyordur.
• Bir eklenti, tema ya da güncelleme sonrası uygulama kilitlenir.
• Ters vekil sunucu ya da yük dengeleyici, arkadaki sunucuyu sağlıksız görür.

Bu listede ilk iki madde paylaşımlı hostingde, son iki madde VPS ve özel sunucularda daha sık çıkar. Yine de sınır kesin değildir. Aynı belirti farklı kök nedenlerden gelebilir, bu yüzden tahmin yerine ölçüm yapmanız gerekir.

Aşırı yük ve hosting kaynak limiti 503 hatasına nasıl yol açar?

Her hosting paketi işlemci, bellek ve eşzamanlı işlem için bir sınır koyar. Sitenize aynı anda gelen istek sayısı bu sınırı aşarsa sunucu yeni istekleri reddeder. Bu durumda ziyaretçi 503 görür, çünkü sunucu çalışır ama işi kabul edemez.

MDN de bellek, işlemci ve bağlantı havuzu gibi eşiklerin dolmasını 503 nedenleri arasında sayar. Paylaşımlı hostingde bir komşu hesabın yoğun trafiği sizi etkileyebilir, ancak modern paketler hesapları birbirinden yalıtır. Yalıtımın nasıl çalıştığını CageFS yazımızda anlattık.

Kampanya günleri tipik bir örnektir. Reklam ya da e-posta ile ani trafik geldiğinde sayfalar önbellekten gelmiyorsa her ziyaret PHP ve veritabanı çalıştırır. Birkaç dakika içinde limit dolar, ardından 503 başlar. Reklam bütçeniz o sırada boşa gider, çünkü tıklama gelir ama sayfa açılmaz.

Bant genişliği ayrı bir sınırdır. Aylık transfer kotası dolarsa bazı sağlayıcılar siteyi durdurur. Bu konuyu bant genişliği rehberimizde ayrıntılı anlattık, burada yalnızca kontrol listenize eklemenizi öneririz.

Bakım modu ve güncellemeler 503 hatasına yol açar mı?

Evet, açar ve çoğu zaman bu bilinçli bir davranıştır. Birçok sistem güncelleme sırasında siteyi kısa süre bakım moduna alır ve 503 döndürür. Sorun, bakım modundan çıkış adımı yarım kaldığında başlar.

WordPress çekirdek güncellemesi sırasında kök dizinde geçici bir .maintenance dosyası oluşturur. Güncelleme kesilirse bu dosya kalabilir ve site "bakımda" mesajıyla açılmaya devam eder. Dosya yöneticisinden bu dosyayı silmek genellikle sorunu çözer, ama önce güncellemenin neden kesildiğine bakın.

Kesilme nedenleri genellikle şunlardır:

• PHP çalışma süresi ya da bellek sınırı güncellemeye yetmedi.
• Eklenti güncellemesi sırasında bağlantı koptu.
• Disk alanı doldu ve dosyalar yazılamadı.
• Güvenlik duvarı güncelleme isteğini engelledi.

Güncellemeden önce yedek almak bu riski küçültür. Yedek planı için web sitesi yedekleme stratejisi yazımıza bakabilirsiniz.

Bot ve DDoS trafiği 503 Service Unavailable hatası üretir mi?

Üretebilir. Bir bot ağı ya da kötü ayarlanmış bir tarayıcı saniyeler içinde yüzlerce istek gönderirse sunucu kaynakları tükenir. Gerçek ziyaretçiler de bu yüzden 503 görür. Bu durumda sorun sizin kodunuzda değil, trafiğin niteliğindedir.

Önce trafiğin gerçekten saldırı olup olmadığını anlayın. Erişim günlüğünde tek bir IP ya da küçük bir IP bloğundan gelen anormal istek yoğunluğu ipucu verir. Ancak meşru bir arama motoru botu da yoğun tarama yapabilir. Googlebot'u doğrulama yöntemini Googlebot rehberimizde anlattık.

Savunma katmanları şunlardır:

• Hız sınırlayıcı kurallar ve şüpheli IP'leri otomatik engelleyen araçlar
• Uygulama güvenlik duvarı kuralları
• Ağ seviyesinde saldırı emiciler ve dağıtık altyapı

İlk katman için Fail2ban ve CSF güvenlik duvarı yazılarımıza, uygulama katmanı için ModSecurity yazımıza bakın. Ağ katmanındaki dağıtık yapı için Anycast DNS yazısı iyi bir başlangıçtır.

503 Service Unavailable hatasını adım adım nasıl teşhis edersiniz?

Teşhisi sırayla yapın, çünkü her adım bir sonrakinin kapsamını daraltır. Önce hatanın herkese mi yoksa yalnızca size mi göründüğünü anlayın. Ardından sunucu tarafına geçin.

1. Siteyi başka bir ağdan ve başka bir cihazdan açın; hata herkese görünüyor mu kontrol edin.
2. Bir site çöktü mü aracıyla dışarıdan erişimi sınayın.
3. Hosting panelinde kaynak kullanımı grafiğine bakın; işlemci, bellek ve işlem sınırı dolmuş mu inceleyin.
4. Hata günlüğünü okuyun; aynı hatanın tekrar ettiği satırları bulun.
5. Son değişikliği düşünün: eklenti, tema, güncelleme ya da yeni bir kampanya var mı?
6. Bakım modu dosyasının ya da ayarının açık kalıp kalmadığını kontrol edin.
7. Bot trafiğini erişim günlüğünden inceleyin.

Bu sırayı korumak size zaman kazandırır. Çünkü çoğu vakada ilk üç adımdan biri nedeni gösterir. Son değişikliği hatırlamak da şaşırtıcı derecede işe yarar, zira 503 sorunlarının büyük bölümü bir güncelleme ya da trafik artışından hemen sonra başlar.

Ziyaretçi olarak 503 hatası alırsanız ne yaparsınız?

Yapabileceğiniz şey sınırlıdır, çünkü sorun sunucudadır. Yine de birkaç basit adım işe yarayabilir. Önce birkaç dakika bekleyin ve sayfayı yenileyin. Geçici aşırı yük çoğu zaman kendiliğinden geçer.

• Sayfayı yeniden yükleyin ve bir iki dakika sonra tekrar deneyin.
• Aynı siteyi mobil veriyle açarak kendi ağınızı elemeye çalışın.
• Başka bir sayfayı deneyin; tüm site mi yoksa tek sayfa mı etkilenmiş görün.
• Alışveriş yapıyorsanız ödeme adımında sayfayı art arda yenilemeyin; çift işlem riski doğar.
• Sorun uzarsa site sahibine sosyal medya ya da telefonla haber verin.

Tarayıcı önbelleğini temizlemek 503 hatasını genellikle çözmez. Çünkü hata sizin tarayıcınızdan değil, sunucudan gelir. Yine de eski bir hata sayfası takılı kalmış olabilir, bu yüzden sert yenileme denemek zarar vermez.

Site sahibi olarak 503 hatasını nasıl çözersiniz?

Çözüm nedene bağlıdır. Bu yüzden önce teşhis, sonra müdahale sırasını izleyin. Aşağıdaki tablo yaygın nedenleri ve ilk müdahaleyi özetler.

Eklenti kaynaklı bir şüphe varsa tek tek devre dışı bırakarak ilerleyin. Böylece suçlu eklentiyi bulursunuz. Ayrıca yedeğiniz varsa son çalışan sürüme dönmek en hızlı çıkış yoludur. Bu adımı uygulamadan önce mutlaka güncel bir yedek alın.

Sunucu günlüklerinde 503 kayıtlarını nasıl bulursunuz?

Kendi VPS sunucunuzu yönetiyorsanız günlükler en güvenilir kanıttır. Aşağıdaki komutlar yaygın bir erişim günlüğü biçimini varsayar. Günlük dosyasının yolu dağıtıma ve web sunucusuna göre değişir, bu yüzden kendi yapılandırmanızdaki yolu kullanın.

# Erişim günlüğünde 503 dönen istekleri sayar (birleşik günlük biçiminde 9. alan durum kodudur)
awk '$9 == 503' /var/log/nginx/access.log | wc -l

# En çok 503 alan adresleri listeler
awk '$9 == 503 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Hata günlüğünün son satırlarını gösterir
tail -n 100 /var/log/nginx/error.log

İlk komut, hatanın ne kadar yaygın olduğunu söyler. İkinci komut, hangi adreslerin etkilendiğini gösterir. Böylece sorun tüm sitede mi yoksa belirli bir sayfada mı, hemen anlarsınız.

Günlüğü elle okumak zor geliyorsa bir günlük çözümleyici kullanın. Log analizi aracımız erişim günlüğünü tarayıcıda yükleyip özetler. Paylaşımlı hostingde günlüğe erişiminiz yoksa paneldeki hata günlüğü bölümüne ya da destek ekibine başvurun.

Retry-After başlığı nedir ve 503 yanıtında nasıl kullanırsınız?

Retry-After, sunucunun istemciye ne kadar süre sonra yeniden denemesini söylediği HTTP yanıt başlığıdır. Değer olarak saniye cinsinden bir bekleme süresi ya da bir tarih ve saat verebilirsiniz. MDN, 503 yanıtında bu başlığın mümkünse kurtarma süresini içermesini önerir.

Örneğin bakımın bir saat süreceğini biliyorsanız başlığa 3600 yazarsınız. Google'ın yardım sayfası da kısa süreli kapatmada 503 ile birlikte retry-after başlığını yaklaşık bir tarih ya da süreyle kullanmayı önerir. Başlığı MDN Retry-After sayfasında inceleyebilirsiniz.

Başlık bir söz değil, bir tahmindir. Bu nedenle gerçekçi bir süre yazın. Süreyi çok kısa tutarsanız botlar boşuna geri gelir, çok uzun tutarsanız sitenizin yeniden taranması gecikir. Süreyi bilmiyorsanız en iyi tahmininizi kullanın ve bakım uzarsa güncelleyin.

Bakım sırasında neden 503 doğru, 404 ya da 200 yanlıştır?

Çünkü durum kodu, arama motoruna ve tarayıcılara sayfanın akıbetini anlatır. 503 "şu an yok, sonra gel" demektir. 404 "bu sayfa yok" der, 200 ise "her şey yolunda, bu içerik gerçek" anlamına gelir. Bakım sayfasına yanlış kod verirseniz arama motoru yanlış sonuç çıkarır.

Sahte 200 sorunu özellikle tehlikelidir. Bakım mesajı 200 koduyla döndüğünde Google bunu gerçek içerik sanabilir. Bu durumun "yumuşak 404" ile ilişkisini soft 404 yazımızda anlattık.

Google 503 Service Unavailable hatasına nasıl davranır?

Google'ın dokümanına göre 5xx ve 429 sunucu hataları tarayıcıların taramayı geçici olarak yavaşlatmasına yol açar. Tarama hızındaki düşüş, hata veren adres sayısıyla orantılıdır. Yani hata ne kadar yaygınsa Googlebot o kadar geri çekilir.

Aynı sayfa önemli bir uyarı da içerir: Google'ın dizinleme hattı, kalıcı olarak sunucu hatası veren adresleri dizinden çıkarır. Dolayısıyla 503 uzun süre sürerse geçici bir hata olmaktan çıkar. Ayrıntıyı Google'ın HTTP durum kodları sayfasında okuyabilirsiniz.

Süre konusunda Google'ın "işi geçici olarak durdurma" sayfası net konuşur. Siteyi tamamen kapatmak yalnızca çok kısa süre, en fazla birkaç gün için uygundur. Birkaç haftalık tam kapatma dizinlemeyi olumsuz etkileyebilir. Kısa kapanışta 503 ve retry-after önerilir.

Robots.txt dosyası da ayrı bir konudur. Google'ın robots.txt dokümanına göre dosya 5xx döndürürse Google ilk 12 saat siteyi taramayı durdurur. Sonraki 30 gün son iyi sürümü kullanır. Bu nedenle robots.txt adresini bakım kuralının dışında tutmayı düşünün. Ayrıca tarama sıklığı düşüşü yazımıza göz atın.

Bakım modunu doğru şekilde nasıl kurarsınız?

Doğru bakım sayfası üç şeyi birlikte yapar: 503 kodu döndürür, kısa ve anlaşılır bir mesaj gösterir ve mümkünse Retry-After başlığı ekler. Aşağıdaki Nginx örneği bu üçlüyü sağlar. Alan adı ve dizin yolları örnektir, kendi yapınıza uyarlayın.

server {
    listen 80;
    server_name example.com;

    error_page 503 /bakim.html;

    location = /bakim.html {
        root /var/www/maintenance;
        internal;
        add_header Retry-After 3600 always;
    }

    location / {
        return 503;
    }
}

Apache kullanıyorsanız aynı mantığı .htaccess dosyasında kurabilirsiniz. Bakım bitince bu satırları kaldırmayı unutmayın.

ErrorDocument 503 /bakim.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/bakim\.html$
RewriteRule ^ - [R=503,L]

Uygulama katmanında çalışıyorsanız PHP içinde de aynı iki işlemi yaparsınız: durum kodunu 503 olarak ayarlarsınız, ardından Retry-After başlığını eklersiniz. Bakım bittiğinde yapılandırmayı eski haline döndürün ve ana sayfanın 200 döndürdüğünü bir araçla doğrulayın.

VPS üzerinde 503 hatasında servis, bellek ve disk durumunu nasıl kontrol edersiniz?

Kendi VPS sunucunuza erişiminiz varsa üç şeye bakın: servisler çalışıyor mu, bellek yetiyor mu, disk doldu mu? Bu üç kontrol 503 vakalarının büyük bölümünü açıklar. Komutları yalnızca yönetim yetkiniz olan sunucuda çalıştırın.

# Web sunucusunun durumunu gösterir
systemctl status nginx

# Sistem yükünü gösterir (son 1, 5 ve 15 dakika ortalaması)
uptime

# Bellek kullanımını megabayt olarak gösterir
free -m

# Disk doluluğunu gösterir
df -h

PHP-FPM servisinin adı dağıtıma ve sürüme göre değişir. Bu yüzden önce systemctl list-units çıktısında adını bulun. Servis pasifse günlükte neden durduğunu okuyun, sonra yeniden başlatın. Nedenini bilmeden yeniden başlatmak sorunu yalnızca erteler.

Bellek bitmişse işletim sistemi süreçleri sonlandırabilir. Bu durumda servis kendiliğinden kapanır ve 503 başlar. Disk dolduğunda ise günlükler ve oturum dosyaları yazılamaz, dolayısıyla uygulama kilitlenir. Kontrolü düzenli yapmak için bir izleme aracı kurmanız iyi olur.

Servis ayarlarını bilmiyorsanız deneme yanılma yapmayın. Yanlış bir yapılandırma siteyi tamamen kapatabilir. Emin değilseniz sunucu yöneticinize ya da sağlayıcınıza danışın.

503 ile 500, 502, 504 ve 429 arasındaki fark nedir?

Bu kodlar birbirine benzer görünür, ancak anlamları farklıdır ve çözüm yolları da değişir. Yanlış kodu araştırırsanız yanlış yerde vakit harcarsınız. Aşağıdaki tablo ayrımı özetler.

MDN, hız sınırlaması için 429'un 503'ten daha uygun olduğunu belirtir. Dolayısıyla "çok fazla istek" durumunu kasıtlı olarak sınırlıyorsanız 429 kullanmak daha doğrudur. Hatanın kökeni ağ geçidindeyse 502 ve 504 sonuçlarını ayrı ayrı inceleyin.

Yavaş site ve hosting seçimi 503 riskini nasıl etkiler?

Yavaş çalışan bir site aynı anda daha çok işlem tutar. Her istek uzun sürdüğü için eşzamanlı işlem sınırı daha çabuk dolar. Dolayısıyla yavaşlık, 503 hatasının sessiz habercisi olabilir. Önce yavaşlığı çözmek, kaynak limitine takılma riskini azaltır.

Nedenleri sunucu kaynaklı yavaşlık yazımızda topladık. Hız ile arama sonuçları arasındaki ilişkiyi site hızı ve SEO yazısında, satış üzerindeki etkisini ise e-ticarette sayfa hızı yazısında bulabilirsiniz.

Hosting paketi seçerken yalnızca fiyata bakmayın. Eşzamanlı işlem sınırı, bellek, işlemci ve trafik politikası sizin 503 riskinizi belirler. Seçim ölçütlerini hosting seçimi rehberimizde ayrıntılı anlattık. Kampanya planlıyorsanız sağlayıcıya önceden haber vermek iyi bir alışkanlıktır.

503 hatasını önlemek için hangi önbellek ve izleme ayarlarını yaparsınız?

Önleme, hatanın kökündeki kaynak tüketimini azaltmaktır. En etkili yöntem sayfaların her ziyarette yeniden üretilmesini engellemektir. Önbellek bunu sağlar. Ayrıca izleme, hata başladığında sizi hemen uyarır.

• Sayfa önbelleği kurun; reklam ve e-posta trafiğinde sunucu yükünü düşürür.
• PHP kod önbelleğini açın; ayrıntı için OPcache yazımıza bakın.
• Nesne önbelleği için Redis ve Memcached karşılaştırmasını inceleyin.
• Önde duran bir HTTP önbelleği için Varnish rehberimiz yardımcı olur.
• Dışarıdan erişim denetimi yapan bir izleme hizmeti kurun ve uyarıyı telefona bağlayın.
• Kampanyadan önce kaynak limitini ve trafik tahminini karşılaştırın.

Bu adımlar hatanın tekrarını küçültür, ancak sıfırlamaz. Kimi zaman gerçekten daha büyük bir pakete ihtiyaç vardır. Bu kararı veriyle verin, çünkü sezgiyle yükseltmek hem para hem zaman kaybettirir.

WordPress sitesinde 503 Service Unavailable hatası nasıl çıkar ve nasıl çözülür?

WordPress sitelerinde 503 hatası çoğunlukla üç yoldan gelir: yarım kalan güncelleme, ağır bir eklenti ya da PHP işlem sınırının dolması. Belirti, güncelleme sonrası ya da trafik arttığında ortaya çıkar. Yönetim paneline girebiliyorsanız önce eklentileri inceleyin.

Panele giremiyorsanız dosya yöneticisi ya da FTP ile wp-content klasörüne gidin ve plugins klasörünün adını geçici olarak değiştirin. Böylece tüm eklentiler devre dışı kalır. Site açılırsa suçlu bir eklentidir. Klasörün adını geri çevirin, ardından eklentileri tek tek etkinleştirerek hangisinin soruna yol açtığını bulun.

Site yine açılmıyorsa temayı ve çekirdek güncellemesini düşünün. Bakım dosyası kalmışsa onu silin. Hata günlüğünde bellek sınırı mesajı görürseniz PHP bellek sınırını hosting panelinden artırmayı deneyin. Bu ayarın üst sınırını sağlayıcınız belirler, bu yüzden değişmiyorsa destek talebi açın.

WooCommerce gibi ağır eklentiler sepet ve ödeme sayfalarında önbellekten yararlanamaz. Dolayısıyla bu sayfalar daha çok işlemci tüketir. Bu nedenle e-ticaret sitelerinde kaynak sınırını özellikle kampanya öncesinde gözden geçirin.

E-ticaret sitesinde 503 hatası reklam bütçesini ve satışları nasıl etkiler?

E-ticarette 503 hatası doğrudan gelir kaybıdır. Kullanıcı reklama tıklar, ancak sayfa açılmaz. Siz tıklama bedelini ödersiniz, ziyaretçi ise rakibe gider. Hatanın sepet ya da ödeme adımında çıkması durumu daha da pahalı yapar.

Basit bir örnek hesap yapalım. Günlük 500 tıklama aldığınızı ve tıklama başına 5 TL ödediğinizi varsayın. Sitede bir saat boyunca hata varsa ve o saatte günlük trafiğin yirmide biri geliyorsa, yaklaşık 125 TL'lik tıklama sonuçsuz kalır. Rakamlar yalnızca örnektir, ancak mantık aynıdır: hata süresi ile reklam yoğunluğu çarpılır.

Önlem olarak kampanya başlamadan önce hız ve yük testi yapın, önbelleği açın ve izleme uyarılarını kurun. Ayrıca büyük bir kampanyada reklam bütçesini bir anda artırmak yerine kademeli artırın. Böylece sunucunun yeni trafiğe alışmasına zaman tanırsınız. Bu planı Google Ads yönetimi sürecinizin bir parçası yapın.

Siteniz çökerken reklamlar çalışıyorsa kampanyayı geçici olarak duraklatmak mantıklıdır. Sorun çözülünce kampanyayı yeniden açarsınız. Böylece boşa harcama durur.

503 hatasından sonra Search Console'da hangi kontrolleri yaparsınız?

Hata geçtikten sonra Google'ın siteyi nasıl gördüğünü kontrol etmeniz gerekir. Search Console'daki tarama istatistikleri raporu, Googlebot'un sunucunuzla yaşadığı sorunları gösterir. Orada sunucu hatalarının ne zaman arttığını ve tarama hacminin nasıl değiştiğini görürsünüz.

1. Tarama istatistikleri raporunda hata zamanına denk gelen sunucu hatası artışını bulun.
2. Sayfa dizinleme raporunda yeni "sunucu hatası (5xx)" kayıtları var mı bakın.
3. Önemli bir adresi URL denetimi aracıyla canlı olarak sınayın.
4. Hata bittikten sonra sitenin 200 döndürdüğünü doğrulayın.
5. Sonraki günlerde tarama hacminin eski seviyeye dönüp dönmediğini izleyin.

Tarama hacmi hemen toparlanmazsa şaşırmayın. Google'ın dokümanına göre sunucu hatası tarama hızını yavaşlatır, bu yüzden toparlanma biraz zaman alabilir. Detaylı kullanım için Search Console rehberimize bakın. Dizine girmeyen sayfalar için dizinlenmeyen sayfalar yazımız yardımcı olur.

503 Service Unavailable hatasında ne zaman işi hosting sağlayıcınıza bırakmalısınız?

Dürüst cevap şudur: sunucu ayarına dokunmak size ait değilse dokunmayın. Paylaşımlı hostingde servis yeniden başlatmak, kaynak sınırını değiştirmek ya da sunucu günlüklerini incelemek çoğunlukla sağlayıcının işidir. Panelden göremediğiniz bir şeyi zorlamak yeni sorun doğurabilir.

Şu durumlarda destek talebi açın:

• Panelde kaynak kullanımı düşük görünüyor, ama 503 sürüyor.
• Hata birden fazla siteyi aynı anda etkiliyor.
• Sunucu servislerine erişiminiz yok ve günlük okuyamıyorsunuz.
• Saldırı şüphesi var ve engelleme yetkiniz sınırlı.
• Hata birkaç saatten uzun sürüyor ve SEO riski doğuyor.

Destek talebine saat aralığını, etkilenen adresleri ve yaptığınız değişiklikleri yazın. Böylece sağlayıcı daha hızlı sonuca ulaşır. Biz bir dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yüzden sunucuyu sizin yerinize yönetmeyiz. Hata sonrası arama görünürlüğünü korumak ve teknik SEO kontrollerini yapmak için SEO danışmanlığı sayfamıza göz atabilirsiniz.