Yayımlama Başarısız Oldu: Yanıt Geçerli Bir JSON Yanıtı Değildir Hatası

Yazıyı bitirdiniz, Yayımla düğmesine bastınız ve editörün üst tarafında kırmızı bir uyarı belirdi: "Yayımlama başarısız oldu. Yanıt geçerli bir JSON yanıtı değildir." İngilizce kurulumlarda aynı satır "Updating failed. The response is not a valid JSON response." şeklinde çıkar. Bazen taslak kaydederken, bazen görsel yüklerken, bazen de yalnızca belirli bir yazıda görünür.

İlk refleks genellikle sayfayı yenilemek olur — ve içerik çoğu zaman aslında kaydedilmiştir, çünkü hata kaydetme işleminin kendisinde değil, sunucunun geri verdiği cevabın biçimindedir. Editör sunucudan JSON bekler, karşılığında HTML bir hata sayfası veya bir PHP uyarı metni alır ve bunu ayrıştıramadığı için "kaydedemedim" der. Yani kaydetme bazen olmuştur bazen olmamıştır; editör emin olamadığı için başarısız sayar.

İnternette bu hataya verilen en yaygın cevap "Klasik Editör eklentisini kurun"dur. Bu, hatayı çözmez — yalnızca hatayı gösteren aracı ortadan kaldırır. REST API kırıksa mobil uygulama, site sağlığı ekranı, zamanlanmış yayınlar ve pek çok eklenti de kırıktır; siz sadece görmezsiniz. Bu yazı bunun yerine bir teşhis zinciri kuruyor: önce sunucunun gerçekte ne döndürdüğünü göreceğiz, sonra olası nedenleri en az riskliden en riskliye doğru sırayla eleyeceğiz.

Bu Hata Tam Olarak Neyi Söylüyor?#

Gutenberg, klasik editörün aksine sayfayı formla göndermez. Yazıyı kaydederken tarayıcıdan /wp-json/wp/v2/posts/123 gibi bir adrese arka planda istek atar ve JSON formatında bir cevap bekler. Cevap { karakteriyle başlamıyorsa JavaScript tarafı ayrıştırmayı bırakır ve bu genel mesajı basar.

Yani mesaj size şunu söylüyor: "Sunucuya sordum, cevap geldi ama JSON değildi." Cevabın ne olduğunu söylemiyor. Doğru çözüme giden tek yol, o cevabı kendi gözünüzle görmektir. Olasılıklar şunlar:

Bu tablodaki her satırın çözümü farklıdır. Doğru satırı bulmadan çözüm denemek, işe yarasa bile hangi şeyin işe yaradığını bilmemenize yol açar.

İlk Adım: /wp-json/ Adresini Tarayıcıda Açın#

Teşhisin tamamı bu adımda başlar. Tarayıcınızın adres çubuğuna sitenizin REST kökünü yazın:

https://ornek.com/wp-json/

Sağlıklı bir kurulumda karşınıza uzun bir JSON çıktısı gelir; içinde "name", "description", "namespaces" ve routes listesi vardır. Tarayıcı bunu ham metin ya da katlanabilir bir ağaç olarak gösterir.

Sorunlu bir kurulumda ise şunlardan birini görürsünüz: "Sayfa bulunamadı" başlıklı bir tema 404 sayfası, "Forbidden" yazan bir Apache sayfası, bomboş beyaz ekran ya da JSON'un hemen üstünde Warning: ... ile başlayan bir satır.

Aynı kontrolü komut satırından yapmak, HTTP durum kodunu ve başlıkları da gösterdiği için daha bilgilendiricidir:

# Durum kodu ve başlıklarla birlikte REST kökünü çek
curl -sI https://ornek.com/wp-json/ | head -20

# Yanıtın ilk satırlarını gör (JSON mı HTML mi?)
curl -s https://ornek.com/wp-json/wp/v2/types | head -c 400; echo

# Belirli bir yazıya erişim
curl -s -o /dev/null -w "%{http_code}\n" https://ornek.com/wp-json/wp/v2/posts/123

Bu üç komutun çıktısı, aşağıdaki bölümlerden hangisine gitmeniz gerektiğini söyler. Sonucu bir kenara not edin.

Tarayıcının Ağ Sekmesi Daha Kesin Konuşur#

Hata yalnızca kaydederken çıkıyorsa, tarayıcıda F12 ile geliştirici araçlarını açın, Network (Ağ) sekmesine geçin ve kaydetmeyi tekrar deneyin. Listede wp-json içeren isteği bulun, üzerine tıklayın ve Response sekmesine bakın. Editörün ayrıştıramadığı ham cevap tam olarak oradadır — çoğu zaman sorunun cevabı ilk satırda yazılıdır.

Kalıcı Bağlantıları Yeniden Kaydetme ve .htaccess'i Yenileme#

/wp-json/ adresinde tema 404 sayfası görüyorsanız, sorun neredeyse kesinlikle yeniden yazma kurallarındadır. REST API kısa URL biçimini (/wp-json/) kullanabilmek için sunucunun her isteği index.php'ye yönlendirmesi gerekir; bu kural bozulduğunda istek WordPress'e hiç ulaşmaz.

En düşük riskli çözüm budur, bu yüzden ilk sırada: Ayarlar → Kalıcı Bağlantılar ekranını açın ve hiçbir şeyi değiştirmeden Değişiklikleri Kaydet düğmesine basın. Bu, kuralların yeniden yazılmasını tetikler. Komut satırından:

wp rewrite flush --hard
wp option get permalink_structure

permalink_structure boş dönerse yapı "Sade" moddadır. Bu durumda REST API /?rest_route=/wp/v2/posts biçimini kullanır ve çalışması gerekir — ama tema veya eklenti tarafında sorun çıkarabilir. Yapı seçimi ve olası 404'ler için WordPress kalıcı bağlantı ayarları yazısına bakın.

Kural yenilemek işe yaramadıysa .htaccess dosyasını doğrudan kontrol edin. Standart WordPress bloğu şudur:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Bu blok yoksa dosya yeniden oluşturulmalıdır; varsa ama üstünde bir eklentiden kalma yönlendirme kuralları duruyorsa, o kurallar isteği WordPress'e ulaşmadan başka yere çevirmiş olabilir. Dosyayı yedekleyip WordPress bloğu dışındaki satırları geçici olarak devre dışı bırakın ve tekrar test edin. Dosyanın yapısı ve güvenli düzenleme yöntemi için .htaccess dosyası oluşturma yazısı yardımcı olur.

Sunucunuz Nginx ise .htaccess diye bir şey yoktur; yönlendirme sunucu yapılandırmasındadır ve şu bloğa ihtiyaç duyar:

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

Authorization Başlığının Düşürülmesi#

Bazı Apache yapılandırmaları Authorization başlığını PHP'ye iletmez. Bu, eklenti veya uygulama şifresiyle yapılan REST isteklerinde yetkisizlik hatasına yol açar. .htaccess içindeki WordPress bloğunun üstüne eklenecek şu iki satır sorunu çözer:

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

ModSecurity ve WAF Kuralları: 403 veya 406 Yanıtı#

Testte 403 ya da 406 gördüyseniz, istek WordPress'e ulaşmadan sunucu üzerindeki web uygulama güvenlik duvarı tarafından engelleniyor demektir. ModSecurity, kaydettiğiniz içerikte kendisine şüpheli görünen bir kalıp bulduğunda isteği keser ve HTML bir hata sayfası döndürür — editör de bunu JSON sanıp ayrıştırmaya çalışır.

Bu senaryonun ayırt edici belirtisi çok karakteristiktir: hata her yazıda değil, yalnızca belirli içerikte çıkar. İçinde kod bloğu, <script> etiketi, SQL benzeri metin, bir iframe gömme kodu veya belirli kelimeler geçen yazılar kaydedilemezken düz metin yazılar sorunsuz kaydedilir. Aynı yazıdan o bölümü silip denediğinizde kaydetme çalışıyorsa neredeyse kesin teşhistir.

Doğru çözüm, güvenlik duvarını kapatmak değil, günlükten tetiklenen kural kimliğini bulup yalnızca o kuralı ilgili yol için muaf tutmaktır. Kural ID'sini modsec_audit.log dosyasından bulma, muafiyet sözdizimi ve paylaşımlı hostingde sağlayıcıdan ne isteneceği ModSecurity 403 ve 406 hatası çözümü yazısında ayrıntılı anlatılıyor.

Paylaşımlı bir pakette güvenlik günlüklerine erişiminiz yoksa, destek ekibine giderken şu üç bilgiyi hazır götürün: hatanın oluştuğu tam zaman damgası, sitenizi ziyaret ettiğiniz IP adresi ve engellenen URL (/wp-json/wp/v2/posts/123). Bu üçüyle ilgili kural saniyeler içinde bulunur; "sitem kaydetmiyor" cümlesiyle aynı sonuç günler alır.

siteurl ve home Uyuşmazlığı, Karma İçerik#

Editör REST isteğini sitenin kendi bildirdiği adrese gönderir. Bu adres yanlışsa istek ya başka bir yere gider ya da tarayıcı tarafından engellenir.

İki değeri kontrol edin:

wp option get siteurl
wp option get home

İkisi de aynı protokol ve aynı alan adı biçimini kullanmalıdır. Sık karşılaşılan bozukluklar: biri http://, diğeri https://; biri www ile, diğeri www olmadan; ya da site HTTPS'e geçirilmiş ama bu iki değer http:// olarak kalmış.

Site HTTPS üzerinden açılırken REST isteği http:// adresine gidiyorsa tarayıcı bunu karma içerik (mixed content) olarak engeller ve isteğe hiç cevap gelmez. Konunun tamamı için karma içerik hatası yazısına bakabilirsiniz.

Panele giremeyecek durumdaysanız değerleri wp-config.php üzerinden geçici olarak sabitleyebilirsiniz:

define( 'WP_HOME', 'https://ornek.com' );
define( 'WP_SITEURL', 'https://ornek.com' );

Bu sabitler veritabanındaki değerleri geçersiz kılar ve panelde ilgili alanları düzenlenemez hale getirir. Sorunu doğruladıktan sonra veritabanı değerlerini düzeltip bu satırları kaldırmanız daha temiz olur.

Bir de yönlendirme zinciri sorunu vardır: .htaccess içindeki HTTP→HTTPS ya da www yönlendirmesi REST isteğini de yönlendiriyorsa, bazı istemciler POST gövdesini yönlendirme sonrası taşımaz ve kaydetme sessizce başarısız olur. Yönlendirme kurallarınızın tek adımda ve doğru sırada çalıştığından emin olun; zincirlenmiş iki yönlendirme bu hatanın bilinen bir kaynağıdır.

Güvenlik Eklentisi REST API'yi Kapatmış Olabilir#

Birçok güvenlik eklentisi, "REST API'yi devre dışı bırak" ya da "oturum açmamış kullanıcılara REST erişimini kapat" gibi bir seçenek sunar. Bu ayarlar kullanıcı numaralandırma saldırılarına karşı önerildiği için sıklıkla açılır; ancak kaba uygulandığında editörün kendi isteklerini de engeller.

Belirti şudur: /wp-json/ adresi tarayıcıda {"code":"rest_login_required"} veya benzeri bir JSON hatası döndürür — yani REST API çalışıyor ama erişime kapalı. Bu durumda çözüm, eklentinin ayarında kapatmayı yalnızca oturum açmamış ziyaretçilerle sınırlamaktır; oturum açmış editörler etkilenmemelidir.

Sorunun bir eklentiden gelip gelmediğini kanıtlamanın standart yolu ikili elemedir:

# Aktif eklentileri listele
wp plugin list --status=active --format=table

# Tümünü geçici olarak kapat (çıktıyı saklayın!)
wp plugin deactivate --all

# Test ettikten sonra teker teker geri aç
wp plugin activate eklenti-adi

Canlı sitede tüm eklentileri kapatmak ziyaretçi deneyimini bozar. Mümkünse bunu bir kopya kurulumda yapın; mümkün değilse trafiğin en düşük olduğu saati seçin ve kapatmadan önce aktif eklenti listesini kaydedin. Aynı testi tema için de yapın: varsayılan bir temaya geçmek, functions.php içindeki bir çıktının cevabı kirletip kirletmediğini gösterir.

PHP Hatası JSON'un Önüne Düştüğünde: debug.log#

Geriye en sinsi neden kalıyor. Bir eklenti veya tema, REST isteği işlenirken bir PHP uyarısı üretiyorsa ve sunucuda hataların ekrana yazdırılması açıksa, o uyarı metni JSON'un önüne eklenir. Cevap teknik olarak geçerli JSON içerir ama başında şöyle bir satır vardır:

Warning: Undefined array key "meta" in /home/kullanici/public_html/wp-content/plugins/ornek/ornek.php on line 84
{"id":123,"date":"2026-08-18T10:00:00",...}

Editör açısından bu geçersiz JSON'dur. Aynı şekilde bir fatal error cevabın tamamını değiştirir ya da boş bırakır.

Bunu doğrulamanın yolu hataları ekrana değil dosyaya yazdırmaktır. wp-config.php içinde /* That's all, stop editing! */ satırının üstüne ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Buradaki kritik satır WP_DEBUG_DISPLAY değerinin false olmasıdır. true bırakırsanız hataları görürsünüz ama aynı zamanda JSON'u kirletmeye devam edersiniz — yani teşhis aracınız sorunun kendisi haline gelir. Bu ayarla hatalar wp-content/debug.log dosyasına yazılır:

# Kaydetmeyi tekrar deneyin, sonra son satırları okuyun
tail -n 50 wp-content/debug.log

# Fatal hataları süzün
grep -iE "fatal|uncaught" wp-content/debug.log | tail -20

Çıktıdaki dosya yolu size sorumlu eklentiyi ya da temayı doğrudan söyler. Sunucu tarafındaki hata kayıtlarına da bakmayı ihmal etmeyin; PHP-FPM veya Apache günlükleri bazen debug.log'a hiç düşmeyen bellek ve zaman aşımı hatalarını gösterir. cPanel kullanıyorsanız panelin Hata Kayıtları (Errors) ekranı en hızlı yoldur.

Teşhis bittiğinde bu dört satırı kaldırın. Açık bırakılan debug.log hem büyür hem de dosya yollarınızı ve sorgu ayrıntılarını dışarıya sızdırabilir.

Bellek ve Zaman Aşımı Sınırları#

Uzun bir yazıyı, çok sayıda blok içeren bir sayfayı ya da büyük bir görseli kaydederken hata çıkıyor ve kısa içerikte çıkmıyorsa, sorun sınırlarda olabilir. İstek zaman aşımına uğradığında sunucu 504, gövde çok büyük olduğunda 413 döndürür — ikisi de HTML sayfadır, ikisi de aynı JSON hatası olarak görünür. Ağ sekmesindeki durum kodu bunu netleştirir; 413 görüyorsanız yükleme sınırlarına, 504 görüyorsanız PHP çalışma süresine bakın.

Çözüm Sırası: En Az Riskliden En Riskliye#

Adımları rastgele denemek yerine şu sırayı izleyin. Her adımdan sonra kaydetmeyi tekrar test edin ve çalıştığında durun — sorunu çözen adım, kök nedeni de söylemiş olur.

Orta riskli adımlara geçmeden önce tam yedek alın. 8, 9 ve 10. adımlar yanlış uygulandığında siteyi tamamen erişilemez hale getirebilir; 9. adımdaki bir hata panele girişinizi de kapatır.

Klasik Editöre Geçmek Neden Çözüm Değil?#

Bu hatanın en çok önerilen "çözümü" Klasik Editör'e dönmektir ve işe yarıyor gibi görünür: klasik editör kaydetmeyi normal form gönderimiyle yaptığı için REST API'ye ihtiyaç duymaz, hata da kaybolur.

Ama kırık olan şey editör değil, REST API'dir ve onu kullanan tek şey editör değildir:

• Site Sağlığı ekranı ve pek çok tanılama aracı REST üzerinden çalışır.
• Zamanlanmış yayınlar ve arka plan görevleri etkilenebilir.
• Mobil uygulama ve masaüstü yazma araçları bağlanamaz.
• WooCommerce, form eklentileri, sayfa oluşturucular ve blok tabanlı temalar kendi REST uç noktalarını kullanır; bunlar sessizce çalışmayı bırakır.
• ModSecurity kaynaklıysa, aynı kural er ya da geç başka bir isteği de engelleyecektir.

Klasik editörün meşru kullanım alanları vardır — eski meta box'lara bağlı iş akışları, alışkanlık, belirli eklenti uyumlulukları — ve bunlar WordPress klasik editör yazısında ele alınıyor. Ancak bir hatayı gizlemek o listede yer almaz. Kök nedeni bulun, düzeltin; klasik editöre geçmek istiyorsanız bunu ondan sonra bir tercih olarak yapın.

REST API'nin nasıl çalıştığını ve hangi uç noktaları sunduğunu daha iyi anlamak, bu tür sorunları teşhis etmeyi kalıcı olarak kolaylaştırır; WordPress REST API yazısı bu temeli kuruyor.

Sıkça Sorulan Sorular#

Hata çıkıyor ama yazım kaydedilmiş görünüyor, neden?#

Çünkü hata kaydetme işleminde değil, sunucunun döndürdüğü cevabın biçimindedir. Veritabanına yazma tamamlanmış, ardından cevap üretilirken bir uyarı ya da güvenlik engeli araya girmiş olabilir. Editör cevabı doğrulayamadığı için başarısız sayar. Bu durumda içerik genelde kayıtlıdır ama güvenmeyin: sayfayı yenileyip son hâlini kontrol edin.

/wp-json/ adresi JSON döndürüyor, yine de kaydedemiyorum. Sırada ne var?#

REST kökü sağlamsa sorun tek bir uç noktada veya isteğin kendisindedir. Tarayıcıda F12 ile Ağ sekmesini açıp kaydetmeyi tekrar deneyin ve wp-json isteğinin ham yanıtına bakın. Durum kodu 403 ise güvenlik duvarı, 413 ise gövde boyutu, 504 ise zaman aşımı işaret eder. Yanıtın başında bir PHP uyarısı varsa debug.log ile kaynağı bulun.

Bu hata her yazıda değil sadece bazılarında çıkıyor, bu neyi gösterir?#

Neredeyse kesin olarak içerik tabanlı bir güvenlik duvarı engelini gösterir. ModSecurity gibi araçlar gönderdiğiniz metinde şüpheli bir kalıp bulduğunda isteği keser. Kod bloğu, iframe gömme kodu veya SQL benzeri ifade içeren yazılarda tipiktir. Şüphelendiğiniz bölümü geçici olarak çıkarıp kaydetmeyi deneyin; çalışıyorsa teşhis doğrulanmış olur.

WP_DEBUG açmak canlı sitede güvenli mi?#

WP_DEBUG_DISPLAY değerini false ve display_errors değerini 0 yaptığınız sürece ziyaretçiler hiçbir şey görmez; hatalar yalnızca dosyaya yazılır. Riskli olan, debug.log dosyasının erişilebilir kalması ve zamanla büyümesidir. Teşhis biter bitmez ayarları kaldırın ve günlük dosyasını silin. Mümkünse bu testi kopya bir kurulumda yapın.

Eklentileri kapatmadan suçluyu bulmanın yolu var mı?#

Evet, çoğu zaman debug.log doğrudan dosya yolunu verir ve suçluyu ismen söyler. Ayrıca tarayıcının Ağ sekmesindeki yanıt gövdesi, hatayı üreten eklentinin klasör adını içerebilir. Bu ikisi sonuç vermezse ikili eleme kaçınılmazdır; ancak önce en son kurduğunuz veya güncellediğiniz eklentiyle başlamak süreyi belirgin biçimde kısaltır.

Sunucum Nginx, .htaccess yok. Ne yapmalıyım?#

Nginx .htaccess okumaz; yönlendirme kuralları sunucu yapılandırma dosyasındadır ve değiştirmek için sunucu erişimi gerekir. REST isteklerinin index.php'ye ulaşması için try_files $uri $uri/ /index.php?$args; satırı bulunmalıdır. Yönetimli bir pakette bu dosyaya erişemezsiniz; /wp-json/ adresinin 404 döndürdüğünü belirterek sağlayıcınızın destek ekibine başvurun.