WordPress Resim Yüklerken HTTP Hatası Alıyorum, Nasıl Çözerim

Medya kütüphanesine bir görsel sürüklüyorsunuz, yükleme çubuğu sonuna kadar gidiyor ve tam bitecekken kırmızı bir uyarı çıkıyor: "HTTP hatası." Başka hiçbir açıklama yok. Aynı görseli tekrar denediğinizde bazen yükleniyor, bazen yüklenmiyor; küçük bir logo sorunsuz geçerken telefonla çekilmiş bir fotoğraf her seferinde takılıyor. WordPress HTTP hatası resim yükleme sorununun en sinir bozucu tarafı budur: hata mesajı size hiçbir ipucu vermez, çünkü tarayıcı sunucudan beklediği JSON cevabı alamadığında yazacak başka bir şey bulamaz.

Türkçe kaynakların bu konudaki ortak tavsiyesi "birkaç dakika bekleyin, tarayıcınızı değiştirin, farklı bir formatta deneyin" şeklindedir; yani tahmindir. Bu yazıda tahmin yok: önce hatanın teknik olarak ne anlama geldiğini, sonra nedeni kesin olarak bulmanın yolunu (tarayıcı Ağ sekmesi ve sunucu hata kaydı) gösteriyoruz. Ardından beş gerçek nedeni — PHP bellek limiti, Imagick/GD görsel işleyicisi, uploads klasörü izinleri, mod_security kuralı ve max_execution_time/upload_max_filesize sınırları — sırayla eleyip her biri için hem test hem de kalıcı çözüm veriyoruz. Sonunda hatanın hangisinden kaynaklandığını bileceksiniz, "galiba düzeldi" demeyeceksiniz.

HTTP Hatası Aslında Ne Anlama Geliyor#

"HTTP hatası" mesajı, WordPress'in medya yükleyicisinin wp-admin/async-upload.php adresine yaptığı isteğe geçerli bir cevap alamadığı anlamına gelir. Yani dosya sunucuya ulaşmış olabilir; sorun genellikle dosyanın gitmesinde değil, gittikten sonra işlenmesinde çıkar.

WordPress bir görseli aldıktan sonra sırayla şunları yapar: dosyayı geçici dizinden wp-content/uploads/YIL/AY/ klasörüne taşır, görselin boyutlarını okur, 2560 pikselden genişse otomatik olarak küçültür ve son olarak temanızın ve eklentilerinizin tanımladığı her ölçü için ayrı bir küçük resim üretir. Tipik bir kurulumda bu, tek bir yükleme için 6-10 ayrı görsel işleme demektir. Bu adımların herhangi birinde PHP işlemi çökerse, bellek biterse veya süre dolarsa, tarayıcıya JSON yerine boş bir cevap ya da bir PHP hata metni döner ve WordPress bunu "HTTP hatası" olarak gösterir.

Buradan çıkan çok önemli bir sonuç var: küçük görsellerin yüklenip büyüklerin takılması, sorunun sunucu kaynaklarında olduğunun kanıtıdır. Yükleme boyutu sınırına takılmış olsaydınız farklı bir mesaj görürdünüz ("Yüklemeye çalıştığınız dosya boyut sınırını aşıyor"). HTTP hatası, dosyanın kabul edildiğini ama işlenemediğini söyler.

Hatanın Kaynağını 5 Dakikada Kesin Olarak Bulun#

Tahminle uğraşmak yerine sunucunun size ne söylediğine bakın. İki kaynak var ve ikisi de kesin sonuç verir.

1. Tarayıcının Ağ sekmesi. Medya ekranını açın, klavyeden F12'ye basın ve Ağ (Network) sekmesine geçin. Şimdi görseli yükleyin. Listede async-upload.php satırını bulun ve tıklayın. Sağda Yanıt (Response) bölümüne bakın:

2. Sunucu hata kaydı. cPanel'de Ölçümler → Hatalar ekranı son hataları gösterir; daha ayrıntılısı için hosting hesabınızın kök dizinindeki error_log dosyasına bakın. SSH'ınız varsa yüklemeyi yaparken kaydı canlı izleyin:

tail -f ~/public_html/error_log

Hata kaydı boşsa WordPress'in kendi hata günlüğünü açın. wp-config.php dosyasında /* That's all, stop editing! */ satırının üstüne şunları ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Bu ayarla hatalar wp-content/debug.log dosyasına yazılır ve ziyaretçiye görünmez. Yüklemeyi tekrar deneyin, sonra dosyayı okuyun. Teşhis bitince bu üç satırı mutlaka kaldırın. Hata kaydı okuma yöntemlerinin tamamı için cPanel hata kayıtları yazısına bakabilirsiniz.

Neden 1: PHP Bellek Limiti Yetersiz#

En sık karşılaşılan nedendir ve belirtisi nettir: küçük görseller yüklenir, 2-3 MB'ın üzerindeki fotoğraflar takılır. Sebep dosya boyutu değil, görselin piksel boyutudur. Bir görseli işlemek için PHP onu belleğe açar ve kabaca genişlik × yükseklik × 4 bayt kadar yer kaplar. 6000×4000 piksellik bir telefon fotoğrafı diskte 4 MB olsa bile bellekte 90 MB'ın üzerine çıkar — ve WordPress bunu her küçük resim ölçüsü için tekrar tekrar yapar.

Mevcut limiti görmek için Araçlar → Site Sağlığı → Bilgi → Sunucu ekranına bakın; "PHP bellek sınırı" satırında yazan değer 256M'nin altındaysa artırın.

wp-config.php içinde:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT ön yüz içindir; medya yüklemesi yönetim panelinde çalıştığı için asıl etkili olan WP_MAX_MEMORY_LIMIT değeridir. İkisini birden tanımlayın.

Bu yetmezse PHP'nin kendi sınırına dokunmanız gerekir. Sunucu PHP'yi FPM veya CGI olarak çalıştırıyorsa (paylaşımlı hostingte neredeyse her zaman böyledir) site kökünde .user.ini dosyası oluşturun:

memory_limit = 256M
max_execution_time = 300
max_input_time = 300

Sunucu mod_php kullanıyorsa aynı ayarlar .htaccess dosyasına yazılır:

php_value memory_limit 256M
php_value max_execution_time 300

⚠️ Yanlış yönteme yazarsanız site 500 hatası verir. .htaccess içindeki php_value satırları mod_php dışında çalışmaz ve Apache'yi hata verdirir. Hangisinin geçerli olduğunu bilmiyorsanız önce .user.ini deneyin, çalışmazsa hosting panelinizin PHP Ayarları / MultiPHP INI Editor ekranını kullanın — orada aynı değerleri arayüzden değiştirebilirsiniz ve hata riski yoktur. PHP tarafındaki tüm ayarların anlamı için PHP ini ayarları yazısına göz atın.

Hızlı doğrulama testi: Aynı fotoğrafı bir görsel düzenleyicide 1600 piksel genişliğe küçültüp tekrar yükleyin. Sorunsuz geçiyorsa neden kesinlikle bellektir.

Neden 2: Imagick Yerine GD'ye Geçmek Neden İşe Yarıyor#

WordPress görselleri işlemek için iki kütüphaneden birini kullanır: ImageMagick (PHP tarafındaki adı Imagick) ve GD. Varsayılan tercih Imagick'tir, çünkü kalite ve renk profili yönetimi daha iyidir. Ama Imagick paylaşımlı sunucularda iki sorun çıkarır: her işlem için birden çok iş parçacığı açar ve bellek kullanımı GD'ye kıyasla belirgin biçimde yüksektir. Hosting sağlayıcısının koyduğu işlem/bellek sınırlarına takılan Imagick, işlem tamamlanmadan öldürülür ve tarayıcıya boş cevap döner — yani "HTTP hatası".

Türkçe kaynaklarda bu kodun kendisi geçiyor ama neden işe yaradığı yazmıyor. Çalışma mantığı şu: wp_image_editors filtresi, WordPress'in hangi işleyiciyi önce deneyeceğini belirleyen sıralı bir dizidir. GD'yi başa alarak Imagick'i hiç çağırmamasını sağlarsınız.

Temanızın functions.php dosyasına (tercihen bir alt temanın veya küçük bir kişisel eklentinin içine) ekleyin:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD', 'WP_Image_Editor_Imagick' );
} );

Bu değişiklikten sonra yükleme çalışıyorsa sorunun kaynağı kesinleşmiş demektir. GD, Imagick'e göre biraz daha düşük kaliteli çıktı üretir ama fark çıplak gözle ancak yan yana karşılaştırıldığında fark edilir; buna karşılık çok daha az bellek harcar.

Imagick'i tamamen bırakmak istemiyorsanız iş parçacığı sayısını sınırlamayı deneyin. .htaccess dosyasına:

SetEnv MAGICK_THREAD_LIMIT 1

Bu satır Imagick'in tek çekirdek kullanmasını sağlar; çoğu paylaşımlı sunucuda "işlem sınırı aşıldı" kaynaklı kesilmeleri ortadan kaldırır. Sunucunuzda hangi kütüphanenin kurulu olduğunu Site Sağlığı → Bilgi → Medya İşleme ekranından görebilirsiniz.

Neden 3: uploads Klasörü İzinleri ve Sahipliği#

Hata kaydında Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server? gibi bir satır görüyorsanız neden dosya izinleridir. Bu, özellikle siteyi elle taşıdıktan veya bir yedeği geri yükledikten sonra ortaya çıkar: dosyalar sunucuya farklı bir kullanıcıyla yüklendiği için PHP'nin yazma hakkı kalmaz.

Doğru izinler şunlardır:

SSH ile toplu düzeltme:

cd ~/public_html
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

İzinler doğru göründüğü halde hata sürüyorsa asıl sorun sahiplik olabilir. Klasörün sahibi PHP'yi çalıştıran kullanıcı değilse 755 izni işe yaramaz, çünkü yazma hakkı yalnızca sahibindedir. Kontrol edin:

ls -ld wp-content/uploads

Çıktıdaki kullanıcı adı, hosting hesabınızın kullanıcı adıyla aynı olmalıdır. root veya başka bir isim görüyorsanız düzeltme yetkisi sizde olmayabilir; bu durumda hosting sağlayıcınıza "uploads klasörünün sahipliği hesap kullanıcısına ayarlansın" diye bildirin — tek komutluk bir iştir.

⚠️ İnternette sıkça önerilen chmod 777 çözümünü uygulamayın. Bu izin, sunucudaki herhangi bir kullanıcının klasöre dosya yazmasına izin verir ve paylaşımlı ortamlarda doğrudan bir güvenlik açığıdır; ayrıca birçok sunucu 777 izinli klasörlerdeki PHP dosyalarını hiç çalıştırmaz. İzin mantığının tamamı WordPress dosya izinleri yazısında anlatılıyor.

Bir de klasörün var olmama ihtimali vardır: wp-content/uploads klasörü silinmişse ve üst klasöre yazma hakkı yoksa WordPress alt klasörleri oluşturamaz. FTP'den elle uploads klasörünü oluşturup 755 verin.

Neden 4: mod_security veya Sunucu Güvenlik Duvarı Engelliyor#

Ağ sekmesinde async-upload.php isteğine 403 veya 406 cevabı geliyorsa ve cevabın gövdesi JSON değil bir HTML hata sayfasıysa, isteği WordPress değil sunucudaki güvenlik duvarı reddediyordur. Apache üzerindeki mod_security modülü, yüklenen dosyanın içinde şüpheli gördüğü bir imza (örneğin görselin EXIF verisi içinde HTML/JS'e benzeyen bir metin) bulduğunda isteği keser.

Bu nedenin tipik belirtisi çok özeldir: aynı boyuttaki bazı görseller geçer, bazıları geçmez ve geçmeyenler her denemede aynı şekilde takılır. Bellek sorununda davranış boyutla orantılıdır; burada dosyaya özeldir.

Doğrulamak için görseli bir düzenleyicide açıp "farklı kaydet" ile yeniden oluşturun (bu EXIF verisini temizler) ve yükleyin. Geçiyorsa neden mod_security'dir. Aynı testi dosya adını sadeleştirerek de yapın: Türkçe karakter, boşluk ve %, &, + gibi işaretler içeren dosya adları hem güvenlik duvarını hem de sunucuyu rahatsız edebilir. urun-fotografi-01.jpg gibi sade bir ad her zaman daha güvenlidir.

Çözüm sizin elinizde değildir; hosting sağlayıcınıza hata kaydındaki rule id numarasıyla birlikte başvurmanız gerekir. Hata kaydında şuna benzer bir satır olur:

ModSecurity: Access denied with code 403 ... [id "218500"] [msg "Request Missing an Accept Header"]

Bu numarayı ilettiğinizde kural sadece sizin hesabınız için devre dışı bırakılabilir. Kendi sunucunuzu yönetiyorsanız kuralı site bazında kapatabilirsiniz, ancak güvenlik duvarını tamamen devre dışı bırakmak yerine yalnızca ilgili kural numarasını hedefleyin.

Neden 5: Süre Aşımı, Yükleme Sınırları ve REST API#

Yükleme çubuğu uzun süre bekleyip sonra hata veriyorsa neden süredir. max_execution_time varsayılan olarak 30 saniyedir ve çok sayıda küçük resim üreten bir kurulumda büyük bir görsel için bu süre yetmez. Değeri 300 saniyeye çıkarmak çoğu durumda çözer; ayarın nasıl yazılacağını yukarıdaki bellek bölümünde anlattık.

Yükleme boyutu sınırlarını da kontrol edin. Medya Ekle ekranının altında "Maksimum yükleme dosya boyutu" yazar; bu değer PHP'nin upload_max_filesize ve post_max_size ayarlarından küçük olanına eşittir. İkisini birlikte artırmanız gerekir, çünkü post_max_size daha küçükse upload_max_filesize değerinin bir anlamı kalmaz:

upload_max_filesize = 64M
post_max_size = 128M
max_execution_time = 300

Bu sınırlarla ilgili ayrıntılar PHP upload_max_filesize yazısında. Nginx kullanıyorsanız bir de sunucu tarafında client_max_body_size ayarı vardır; PHP değerlerini artırsanız bile bu küçük kalırsa 413 hatası alırsınız:

client_max_body_size 128M;

Son olarak REST API'yi kontrol edin. Blok editörü medya yüklemesini REST API üzerinden yapar; bu uç nokta bir güvenlik eklentisiyle kapatılmışsa yükleme başarısız olur. Site Sağlığı ekranı bu durumu "REST API beklenmedik bir sonuç döndürdü" uyarısıyla bildirir. Aynı görsel klasik editörden veya Medya → Yeni Ekle ekranından yükleniyorsa suçlu REST API kısıtlamasıdır.

Nedeni Eleme Sırası: Hızlı Karar Akışı#

Bütün bunları sırayla denemek yerine şu akışı izleyin; ortalama beş dakikada doğru nedene ulaşırsınız.

1. Küçük bir görsel (200 KB, 800 piksel) yükleyin. Geçiyorsa sorun kaynak sınırlarındadır (bellek veya süre), geçmiyorsa izin ya da güvenlik duvarıdır.
2. Ağ sekmesinden async-upload.php cevabını okuyun. Yukarıdaki tablo size doğrudan bölümü söyler.
3. Tüm eklentileri devre dışı bırakın ve varsayılan temaya geçin. Yükleme düzeliyorsa bir eklenti karışıyordur; eklentileri tek tek açarak bulun. Yöntemin ayrıntısı WordPress eklenti çakışması yazısında.
4. GD filtresini ekleyin. Düzeliyorsa neden Imagick'tir.
5. Bellek ve süre limitlerini artırın. Düzeliyorsa neden kaynaktır ve kalıcı çözüm limitleri makul bir seviyede tutmaktır.
6. Hâlâ çözülmediyse hata kaydını sağlayıcınıza iletin. Elinizde error_log satırı varken destek süreci dakikalar sürer; "resim yüklenmiyor" demekle "şu rule id ile 403 alıyorum" demek arasında günlerce fark vardır.

Kalıcı Çözüm ve Tekrarı Önleme#

Hata geçtikten sonra aynı duvara tekrar toslamamak için üç alışkanlık edinin.

Görselleri yüklemeden önce boyutlandırın. Web'de hiçbir görselin 2000 pikselden geniş olmasına gerek yoktur. Telefondan çıkan 6000 piksellik fotoğrafı olduğu gibi yüklemek, hem bu hatayı davet eder hem de sitenizi yavaşlatır. Yükleme öncesi küçültme, bu sorunu kökten bitiren tek adımdır.

Otomatik küçültme eşiğini kullanın. WordPress 2560 pikselden geniş görselleri kendiliğinden küçültür. Bu davranış işinize yaramıyorsa (örneğin baskı kalitesinde görsel saklıyorsanız) kapatabilirsiniz, ama kapatmak bellek tüketimini artırır:

add_filter( 'big_image_size_threshold', '__return_false' );

Çoğu site için doğru karar bu filtreyi eklememektir; varsayılan davranış zaten sizi koruyor.

Gereksiz küçük resim ölçülerini azaltın. Bazı temalar ve sayfa oluşturucular her yükleme için on beşten fazla ölçü tanımlar. Her ölçü ayrı bir görsel işleme demektir; kullanılmayanları kaldırmak hem yükleme hatalarını hem de disk kullanımını belirgin biçimde düşürür.

Sıkça Sorulan Sorular#

HTTP hatası neden bazı görsellerde çıkıp bazılarında çıkmıyor#

Çünkü hatanın nedeni dosyanın kendisiyle değil, o dosyayı işlemenin maliyetiyle ilgilidir. Büyük piksel boyutlu bir görsel bellekte küçük bir logodan onlarca kat fazla yer kaplar ve sunucunun sınırına takılır; küçük olan aynı işlemi rahatça tamamlar. Eğer boyuttan bağımsız olarak hep aynı dosyalar takılıyorsa neden farklıdır: muhtemelen o dosyaların EXIF verisi ya da adı güvenlik duvarı kuralını tetikliyordur. Ayrımı yapmak için aynı görseli küçülterek ve yeniden kaydederek iki ayrı test yapın.

Imagick yerine GD kullanmak görsel kalitesini düşürür mü#

Evet ama fark pratikte çok küçüktür. GD, özellikle keskin geçişli grafiklerde ve renk profili olan fotoğraflarda Imagick'e göre biraz daha az hassas sonuç üretir; iki çıktı yan yana konmadan bu farkı görmek zordur. Buna karşılık GD belirgin biçimde daha az bellek harcadığı için paylaşımlı hostingte yükleme hatalarını ortadan kaldırır. Kalite sizin için kritikse görselleri yüklemeden önce kendi bilgisayarınızda optimize edip WordPress'e işleyecek fazla iş bırakmamak en iyi çözümdür.

uploads klasörüne 777 izni versem sorun çözülür mü#

Çözebilir ama vermeyin, çünkü bunun bedeli ciddi bir güvenlik açığıdır. 777 izni, sunucudaki başka bir hesabın veya çalışan herhangi bir işlemin o klasöre dosya yazabilmesi anlamına gelir; paylaşımlı ortamlarda bu, sitenize zararlı dosya yerleştirilmesinin bilinen yollarından biridir. Ayrıca birçok sunucu güvenlik yapılandırması 777 izinli dizinlerdeki dosyaları hiç çalıştırmaz, yani sorunu çözmek yerine büyütebilirsiniz. Doğru değerler klasörler için 755, dosyalar için 644'tür; bunlar yetmiyorsa sorun izinde değil sahipliktedir.

Aynı görsel FTP ile yüklendiğinde çalışıyor, panelden yüklenmiyor#

Bu, sorunun dosya taşımada değil görsel işlemede olduğunu kanıtlar. FTP dosyayı diske kopyalar ve orada durur; WordPress ise dosyayı aldıktan sonra küçük resimleri üretir, meta verisini veritabanına yazar ve medya kütüphanesine kaydeder. Bu ek adımlar bellek, süre veya görsel kütüphanesi sınırlarına takılabilir. FTP ile yüklenen görsel medya kütüphanesinde de görünmez, çünkü veritabanı kaydı oluşmamıştır; bu yüzden FTP kalıcı bir çözüm değil, yalnızca teşhis için kullanışlı bir testtir.

Hata kaydında hiçbir şey yazmıyorsa ne yapmalıyım#

Önce doğru kayda baktığınızdan emin olun; hosting hesabının kök dizinindeki error_log ile sitenin bulunduğu dizindeki error_log farklı dosyalar olabilir. Kayıt gerçekten boşsa wp-config.php içinde WP_DEBUG_LOG ayarını açarak WordPress'in kendi günlüğünü wp-content/debug.log dosyasına yazdırın ve yüklemeyi tekrar deneyin. Yine hiçbir şey yazmıyorsa PHP işlemi kayıt yazamadan öldürülüyor demektir; bu durum genellikle bellek sınırının aşılmasına ya da sunucudaki işlem sınırına işaret eder ve doğrudan hosting sağlayıcısının kayıtlarından görülebilir.

Yükleme sınırını artırdım ama Medya ekranında eski değer görünüyor#

Ayarın yazıldığı yer geçerli değilse veya PHP önbelleği yenilenmediyse böyle olur. Değişikliği .htaccess içine yazdıysanız ve sunucu PHP'yi FPM olarak çalıştırıyorsa satırlar tamamen yok sayılır; bu durumda .user.ini dosyasını kullanmanız gerekir. .user.ini değişiklikleri de anında değil, sunucunun belirlediği kısa bir süre sonra devreye girer. En kesin yol hosting panelindeki PHP ayarları ekranını kullanmaktır; oradan yapılan değişiklik hem doğru yere yazılır hem de PHP havuzunu yeniler.

Blok editörde hata alıyorum ama klasik editörde alamıyorum#

Bu durumda sorun neredeyse kesin olarak REST API erişimindedir. Blok editörü yüklemeyi REST API üzerinden yapar; klasik editör ise doğrudan async-upload.php adresini kullanır. Bir güvenlik eklentisi veya kimlik doğrulama başlıklarını silen bir sunucu yapılandırması REST API'yi kapattığında yalnızca blok editörü etkilenir. Site Sağlığı ekranındaki REST API uyarısını kontrol edin.

Görsel yüklendi ama medya kütüphanesinde bozuk simge olarak görünüyor#

Bu, yüklemenin tamamlandığını ancak küçük resim üretiminin başarısız olduğunu gösterir ve genellikle aynı kaynak sınırlarından kaynaklanır. Dosya wp-content/uploads klasöründe durur, veritabanı kaydı oluşmuştur, ama önizleme boyutları yaratılamamıştır. Bellek limitini artırdıktan sonra medya kütüphanesinde görsele girip "Görseli düzenle → Kaydet" diyerek ölçüleri yeniden ürettirebilirsiniz. Sorun görsellerin tarayıcıda hiç görünmemesi biçimindeyse neden büyük olasılıkla yükleme değil, adres veya izin kaynaklıdır.

Kapanış#

WordPress'in "HTTP hatası" mesajı bir teşhis değil, bir sessizliktir: sunucu beklenen cevabı veremediğinde tarayıcının yazabildiği tek şeydir. Bu yüzden çözümü tahminle değil, cevabı okuyarak bulunur. Tarayıcının Ağ sekmesinde async-upload.php isteğine bakmak ve sunucu hata kaydını açmak, çoğu durumda nedeni tek bakışta ortaya çıkarır. Bundan sonrası mekaniktir: 500 ve bellek uyarısı görüyorsanız limitleri yükseltin, 403/406 görüyorsanız güvenlik duvarı kuralını sağlayıcınıza bildirin, "unable to create directory" görüyorsanız izin ve sahipliği düzeltin, uzun bekleyip kesiliyorsa süreyi artırın, hiçbiri değilse görsel işleyicisini GD'ye alın.

Uzun vadede bu hatayı bir daha görmemenin yolu, sunucuya gereksiz iş yaptırmamaktan geçer: görselleri yüklemeden önce makul bir genişliğe küçültmek, kullanılmayan küçük resim ölçülerini kaldırmak ve bellek limiti bol bir ortamda çalışmak. Görsel ağırlıklı bir siteniz varsa ve limitler sürekli karşınıza çıkıyorsa WordPress hosting paketleri bu iş yükü için ayarlanmış PHP değerleriyle gelir; kaynak sınırlarını kendiniz belirlemek istiyorsanız VDS sunucu ile bellek ve işlem sınırları tamamen sizin kontrolünüzde olur. Bu ayarlarla hiç uğraşmak istemiyorsanız WordPress bakım hizmeti güncelleme, optimizasyon ve bu tür arızaların çözümünü üstlenir.