--- title: "WordPress admin-ajax.php 400 Hatası: 8 Teknik Kontrol" id: "2566" type: "post" slug: "wordpress-admin-ajax-400-hatasi" published_at: "2026-11-08T02:20:53+00:00" modified_at: "2026-11-08T02:20:56+00:00" url: "https://zeymedya.com/wordpress-admin-ajax-400-hatasi/" markdown_url: "https://zeymedya.com/wordpress-admin-ajax-400-hatasi.md" excerpt: "WORDPRESS · ADMIN-AJAX.PHP · HTTP 400 · AJAX DEBUGGING WordPress admin-ajax.php 400 hatası, web sitesi veya yönetim panelinde çalışan bir AJAX isteğinin HTTP 400 Bad Request yanıtıyla sonuçlanmasıdır. Sorun; eksik action parametresi, kayıtlı olmayan AJAX işleyicisi, oturum farkı veya güvenlik..." taxonomy_category: - "Web Tasarım ve Site Yönetimi" taxonomy_post_tag: - "WordPress admin-ajax.php 400 hatası" --- WordPress admin-ajax.php 400 Hatası: 8 Teknik Kontrol ## WordPress admin-ajax.php 400 Hatası Nasıl Çözülür? **Kısa cevap:** Chrome veya başka bir tarayıcıda geliştirici araçlarını açın. **Network** panelinde `admin-ajax.php` isteğini bulun. İsteğin **Request Payload veya Form Data** bölümünde geçerli bir `action` parametresi bulunup bulunmadığını kontrol edin. Ardından **Response** bölümündeki yanıtı inceleyin. Yanıt `0` ve durum kodu 400 ise eksik veya kayıtlı olmayan AJAX aksiyonu olasılığı önceliklidir. Giriş yapan kullanıcıda çalışıp ziyaretçide başarısız olan işlemlerde `wp_ajax_nopriv_` kancasını kontrol edin. Yanıt `-1` ve durum kodu 403 ise standart nonce doğrulaması araştırılmalıdır. İstek WordPress’e ulaşmadan reddediliyorsa WAF, ModSecurity, CDN ve güvenlik günlüklerini inceleyin. **400 + 0** Geçersiz action veya eksik AJAX işleyicisi olasılığı. **403 + -1** Standart WordPress AJAX nonce kontrolü başarısızlığı. **500** PHP fatal error, uygulama veya sunucu hatası olasılığı. **admin-ajax.php dosyasını silmek, yeniden adlandırmak veya erişimini bütünüyle engellemek doğru bir çözüm değildir.**Bu dosya, WordPress çekirdeği ve çeşitli eklentiler tarafından kullanılır. Hatanın kaynağı belirlenmeden dosyanın değiştirilmesi başka işlevleri bozabilir. ## WordPress admin-ajax.php Nedir ve Ne İşe Yarar? `admin-ajax.php`, WordPress’in klasik AJAX isteklerini işlemek için kullandığı çekirdek dosyadır. AJAX, web sayfası tamamen yenilenmeden tarayıcı ile sunucu arasında veri alışverişi yapılmasına olanak sağlar. WordPress yönetim panelinde ve ön yüzde çeşitli dinamik işlemler bu sistemden yararlanabilir. ### admin-ajax.php hangi işlemlerde kullanılır? ### Dinamik formlar Bazı form eklentileri gönderimleri AJAX üzerinden işleyebilir. ### Canlı arama Kullanıcı yazdıkça sonuçları getiren sistemlerde kullanılabilir. ### Yönetim işlemleri Eklenti ayarları, içerik işlemleri ve bazı panel özellikleri. ### Heartbeat API WordPress oturum, içerik kilidi ve bazı yönetim etkileşimlerini destekler. ### admin-ajax.php dosyası nerede bulunur? ``` /wp-admin/admin-ajax.php ``` Dosyanın genel WordPress kurulumu içindeki yolu budur. Ancak alt dizinde kurulu veya özel URL yapılandırması kullanan sitelerde gerçek adres farklı olabilir. Bu nedenle AJAX URL’si kod içinde sabit yazılmak yerine WordPress’in `admin_url()` işleviyle oluşturulmalıdır. ### WordPress AJAX isteğini nasıl yönlendirir? Tarayıcı, isteğin içinde `action` adlı bir parametre gönderir. WordPress bu değere göre hangi PHP işleyicisinin çağrılacağını belirler. ``` AJAX URL: https://example.com/wp-admin/admin-ajax.php İstek: action=zm_example_search WordPress hook: wp_ajax_zm_example_search Giriş yapmamış ziyaretçi: wp_ajax_nopriv_zm_example_search ``` **admin-ajax.php 400 hatası, WordPress’in çekirdek mekanizmasından kaynaklanabileceği gibi eklenti veya sunucu tarafından da oluşturulabilir.**Bu yüzden yalnızca durum koduna bakarak eklenti kaldırmak veya sunucu ayarlarını değiştirmek doğru değildir. ## WordPress AJAX Hatalarında Belirtiye Göre İlk Teşhis | Belirti | Olası neden | İlk kontrol | | --- | --- | --- | | HTTP 400, yanıt 0 | Eksik action veya kayıtlı olmayan işleyici | Payload ve AJAX hook kayıtları | | HTTP 403, yanıt -1 | Nonce doğrulaması başarısız olabilir. | Nonce alanı ve oturum | | Giriş yapan kullanıcıda çalışıyor, ziyaretçide 400 | nopriv işleyicisi eksik olabilir. | wp_ajax_nopriv hook’u | | Yalnızca bir eklentinin işleminde hata | Özel işleyici veya JS hatası | Action sahibi eklenti | | Yanıt HTML güvenlik sayfası | WAF veya güvenlik filtresi | Response Headers ve WAF logu | | Uzun süre açık sayfada hata oluşuyor | Eski nonce veya oturum | Yeni oturum ve sayfa yükleme | | HTTP 500 veya boş yanıt | PHP ya da sunucu hatası | debug.log ve PHP error log | ## WordPress admin-ajax.php 400 Hatası İçin 8 Teknik Kontrol 1### AJAX İsteğinde action Parametresi Eksik veya Geçersiz Olabilir **WordPress admin-ajax.php 400 hatası** için ilk kontrol, gönderilen isteğin `action` parametresidir. WordPress çekirdek kodu, `action` değerinin boş olmamasını ve geçerli bir skaler değer olmasını bekler. Bu koşul karşılanmazsa WordPress doğrudan HTTP 400 yanıtı oluşturabilir. #### Hatalı istek örnekleri ``` Eksik action: POST /wp-admin/admin-ajax.php Form Data: keyword=seo ``` ``` Boş action: action= keyword=seo ``` #### Doğru action örneği ``` POST /wp-admin/admin-ajax.php Form Data: action=zm_example_search keyword=seo ``` Ancak yalnızca action parametresinin gönderilmesi yeterli değildir. Aynı adlı işleyicinin WordPress tarafından kayıtlı olması da gerekir. #### Nasıl kontrol edilir? 1. **Tarayıcı geliştirici araçlarını açın.** Network paneline girin. 2. **Hata veren işlemi tekrar oluşturun.** İlgili AJAX isteğini bulun. 3. **Payload bölümünü inceleyin.**`action` alanı mevcut mu? 4. **Action değerini kontrol edin.** Boş, yanlış veya beklenenden farklı mı? 5. **İlgili eklentinin PHP kaydıyla karşılaştırın.** Aynı action adı kullanılıyor mu? **Tarayıcıya admin-ajax.php adresini doğrudan yazdığınızda 400 ve 0 görmek tek başına hata kanıtı değildir.**Çünkü adresi normal şekilde açtığınızda gerekli `action` parametresi gönderilmemiş olur. Doğru teşhis, gerçek WordPress işlemine ait AJAX isteğiyle yapılmalıdır. 2### wp_ajax ve wp_ajax_nopriv Hook’ları Doğru Kaydedilmemiş Olabilir WordPress, AJAX işlemlerini kullanıcı oturumuna göre farklı kancalara yönlendirir. Giriş yapan kullanıcılarda `wp_ajax_`, giriş yapmamış kullanıcılarda `wp_ajax_nopriv_` kullanılır. #### İki farklı kullanıcı durumu | Kullanıcı | Hook | Gereklilik | | --- | --- | --- | | Giriş yapmış | wp_ajax_example | Oturum açmış kullanıcıya uygun işleyici | | Ziyaretçi | wp_ajax_nopriv_example | Herkese açık işlem için nopriv kaydı | #### Örnek PHP hook kayıtları ``` add_action( 'wp_ajax_zm_example_search', 'zm_example_search_handler' ); add_action( 'wp_ajax_nopriv_zm_example_search', 'zm_example_search_handler' ); ``` Bu kayıtlar, aynı AJAX işleminin giriş yapan ve giriş yapmamış kullanıcılarda çalışmasını sağlayabilir. Ancak her işlem herkese açık olmamalıdır. Örneğin yöneticiye özel veri değiştirme işlemlerinde `nopriv` tanımlanması güvenlik riski oluşturabilir. #### Yaygın hata senaryosu GİRİŞ YAPAN VE ZİYARETÇİ FARKI **Yönetici hesabında:** Form çalışıyor. **Gizli tarayıcı penceresinde:** HTTP 400, yanıt 0. **Olası neden:** `wp_ajax_` kayıtlı ancak herkese açık olması gereken işlem için `wp_ajax_nopriv_` bulunmuyor. **400 hatasını çözmek için bütün AJAX işlemlerini nopriv olarak kaydetmeyin.**Yalnızca giriş gerektirmeyen işlemler herkese açık olmalıdır. Yetkili işlemlerde nonce doğrulaması yanında `current_user_can()` gibi yetki kontrolleri uygulanmalıdır. 3### Nonce Doğrulaması Başarısız Oluyor veya Oturum Bilgisi Güncelliğini Kaybediyor Olabilir WordPress AJAX işlemlerinde nonce, isteğin beklenen kullanıcı etkileşiminden geldiğini doğrulamaya yardımcı olur. Genellikle `wp_create_nonce()` ile oluşturulan değer, JavaScript üzerinden isteğe eklenir. Sunucu tarafında `check_ajax_referer()` kullanılarak doğrulanır. #### Nonce gönderimi örneği ``` action=zm_example_search _ajax_nonce=GENERATED_NONCE_VALUE keyword=seo ``` #### Nonce kontrolü örneği ``` check_ajax_referer( 'zm_example_search_nonce', '_ajax_nonce' ); ``` Burada nonce oluşturulurken kullanılan aksiyon adı ile doğrulamada kullanılan adın eşleşmesi gerekir. #### Önemli: 400 ve 403 ayrımı WordPress’in varsayılan `check_ajax_referer()` davranışında başarısız kontrol, AJAX isteğini **HTTP 403 ve -1** yanıtıyla sonlandırabilir. Dolayısıyla gerçek yanıt HTTP 400 ise nonce’un doğrudan neden olduğu sonucuna varılmamalıdır. Ancak özel eklentiler nonce hatalarını farklı HTTP kodlarıyla döndürebilir. #### Nonce neden geçersiz olabilir? - Sayfa uzun süre açık kalmıştır. - Tarayıcı oturumu değişmiştir. - Kullanıcı çıkış yapıp yeniden giriş yapmıştır. - Eski HTML içindeki nonce önbellekten gelmiştir. - JavaScript yanlış parametre adını göndermektedir. - Nonce oluşturma ve kontrol aksiyonları farklıdır. - Oturum çerezleri beklenen şekilde gönderilmemektedir. **Nonce, kullanıcı yetkilendirmesinin yerine geçmez.**WordPress resmî belgeleri, nonce değerlerinin erişim kontrolü veya kimlik doğrulama mekanizması olarak tek başına kullanılmaması gerektiğini belirtir. Hassas işlemler ayrıca kullanıcı yetkisiyle korunmalıdır. 4### AJAX URL’si, HTTP Metodu veya Request Payload Yanlış Oluşturulmuş Olabilir AJAX işlemi için doğru URL’ye istek gönderilmesi gerekir. WordPress ön yüzde yönetim panelindeki `ajaxurl` JavaScript değişkenini her zaman otomatik sağlamaz. Bu yüzden eklenti geliştiricileri AJAX adresini WordPress üzerinden istemciye iletmelidir. #### Doğru URL oluşturma ``` admin_url( 'admin-ajax.php' ) ``` #### Hatalı sabit URL örneği ``` const ajaxUrl = '/wp-admin/admin-ajax.php'; ``` Bu yaklaşım WordPress alt dizinde kuruluysa yanlış adrese istek gönderebilir. #### HTTP metodunu kontrol edin AJAX işleyicisi `POST` verisi beklerken isteğin `GET` ile gönderilmesi hatalı işlemeye neden olabilir. WordPress `action` değerini istek verisinden okur. Ancak özel işleyicinin beklediği diğer alanlar doğru biçimde iletilmelidir. #### JSON ve form verisi farkı | İstek biçimi | Davranış | Kontrol | | --- | --- | --- | | FormData | Alanlar form verisi olarak gönderilir. | Payload içinde action var mı? | | URLSearchParams | Form kodlamasıyla gönderilebilir. | Content-Type ve alan adları | | JSON body | PHP tarafından ayrıca çözümleme gerekebilir. | WordPress action değerini okuyabiliyor mu? | Özellikle yalnızca JSON gövdesi gönderilen isteklerde `action` PHP’nin standart `$_REQUEST` alanında bulunmayabilir. Böyle bir durumda WordPress işleyiciye ulaşmadan HTTP 400 döndürebilir. **AJAX isteğini başka bir REST API endpoint’ine rastgele taşımayın.**WordPress REST API ile klasik admin-ajax.php farklı yönlendirme ve yetkilendirme mekanizmalarına sahiptir. Mimarinin değişmesi gerekiyorsa bu işlem ayrı geliştirme olarak planlanmalıdır. 5### WordPress Eklentisi, Tema veya JavaScript Çakışması AJAX İşlemini Bozuyor Olabilir WordPress sitelerinde birçok eklenti kendi AJAX işleyicilerini kaydeder. Bir eklenti güncellendiğinde JavaScript dosyası, PHP işleyicisi veya action adı değişmiş olabilir. Eski JavaScript dosyası hâlâ kullanılıyorsa ön yüz ile sunucu tarafı arasında uyumsuzluk oluşabilir. #### Yaygın eklenti sorunları - JavaScript farklı action gönderir. - PHP hook kaydı kaldırılmıştır. - Eklenti dosyası yüklenmemektedir. - Bir JavaScript hatası isteğin verisini bozmuştur. - Güncelleme sonrası eski JS sürümü kalmıştır. - İki eklenti aynı action adını kullanmaktadır. - İşleyici yetki veya doğrulama hatası döndürmektedir. #### Eklenti kaynaklı sorun nasıl izole edilir? 1. **Hatanın başladığı zamanı belirleyin.** Güncelleme veya kurulum yapıldı mı? 2. **Hata veren AJAX action değerini kaydedin.** Eklentiyle ilişkisini araştırın. 3. **Tarayıcı Console hatalarını inceleyin.** Öncesinde JavaScript hatası var mı? 4. **Staging ortamı oluşturun.** Canlı siteyi etkilemeden test yapın. 5. **Şüpheli bileşenleri kontrollü izole edin.** Tek değişken yaklaşımı uygulayın. 6. **Sorun çözüldüğünde kaynak kodu doğrulayın.** Kalıcı çözümü eklenti veya tema düzeyinde uygulayın. #### GeneratePress veya başka tema sorunlu olabilir mi? Tema adı tek başına AJAX hatasının nedeni değildir. Ancak temaya eklenmiş özel JavaScript, `functions.php` içindeki PHP kodu veya üçüncü taraf özellikler hatalı AJAX akışı oluşturabilir. **Canlı mağazada veya yoğun trafikli sitede tüm eklentileri topluca kapatmayın.**Formlar, ödeme işlemleri, güvenlik sistemleri ve müşteri deneyimi etkilenebilir. İzolasyon testlerini öncelikle staging ortamında gerçekleştirin. 6### ModSecurity, WAF veya Güvenlik Eklentisi AJAX İsteğini Engelliyor Olabilir AJAX isteği WordPress PHP işleyicisine ulaşmadan sunucu veya güvenlik katmanında reddedilebilir. Özellikle Web Application Firewall sistemleri, şüpheli kabul ettikleri istekleri engelleyebilir. ModSecurity, CDN güvenlik sistemleri veya WordPress güvenlik eklentileri bu süreçte rol oynayabilir. #### Hangi durumlarda güvenlik filtresi şüphesi artar? - Yalnızca belirli form verileri hata veriyorsa - İstek metninde HTML veya özel karakterler varsa - Büyük POST gövdesinde hata oluşuyorsa - WAF günlüklerinde eşleşen engelleme varsa - Yanıt WordPress yerine güvenlik sisteminden geliyorsa - Belirli IP veya oturumlarda sorun yaşanıyorsa #### WAF kontrol sırası 1. **Başarısız isteğin zamanını kaydedin.** Sunucu loguyla eşleştirin. 2. **Response Headers bölümünü inceleyin.** Yanıtın hangi katmandan geldiğini araştırın. 3. **WAF güvenlik olaylarını kontrol edin.** Aynı isteğe ait engelleme var mı? 4. **ModSecurity kural kimliğini belirleyin.** Eşleşen kural mevcut mu? 5. **Yanlış pozitif engellemeyi doğrulayın.** Gerçek güvenlik tehdidi olmadığından emin olun. 6. **Gerekirse dar kapsamlı istisna uygulayın.** Hosting veya güvenlik sağlayıcısıyla değerlendirin. **HTTP 400 hatasını gidermek için ModSecurity veya WAF sistemini tamamen devre dışı bırakmayın.**Soruna neden olan belirli güvenlik kuralı doğrulanmalıdır. Gerekli istisna, en dar kapsamda uygulanmalıdır. #### HTTP 400 her zaman WAF kaynaklı mıdır? Hayır. WordPress çekirdeği de HTTP 400 üretebilir. Bu nedenle gerçek yanıt gövdesi ve güvenlik günlükleri karşılaştırılmalıdır. 7### LiteSpeed Cache, CDN veya Eski JavaScript ve Nonce Verileri Soruna Yol Açıyor Olabilir WordPress performans eklentileri JavaScript dosyalarını küçültebilir, erteleyebilir veya geciktirebilir. Uygun yapılandırılmadığında bu işlemler AJAX isteğinin beklediği veri ve zamanlamayı etkileyebilir. Özellikle nonce değerinin eski HTML içeriğinde kalması doğrulama sorunlarına neden olabilir. #### LiteSpeed Cache ile ilgili olası senaryolar - Eski JavaScript dosyası önbellekten geliyor. - Yeni PHP action adıyla eski JS kodu eşleşmiyor. - Geciktirilen JS, AJAX isteğinden önce hazır olmuyor. - Önbellekte eski nonce veya oturum bilgisi bulunuyor. - CDN farklı sürümde JavaScript sunuyor. - Dinamik sayfa yanlış cache kapsamına alınmış. #### Önbellek kaynaklı hata nasıl kontrol edilir? 1. **Başarısız isteğin action değerini not edin.** Gerçek hatayı belirleyin. 2. **Sayfayı güncel içerikle yeniden yükleyin.** Yeni JS ve nonce kullanılıyor mu? 3. **Farklı oturumda test edin.** Gizli pencere veya ayrı tarayıcı profili kullanın. 4. **Önbellek katmanlarını karşılaştırın.** WordPress, sunucu ve CDN ayrı ayrı değerlendirilmelidir. 5. **Staging üzerinde ilgili optimizasyonu izole edin.** Tek ayar değiştirin. 6. **Hata düzelirse dar kapsamlı yapılandırma yapın.** Gereksiz tüm performans ayarlarını kapatmayın. **admin-ajax.php isteğinin kendisiyle eski HTML/JavaScript içeriğinin önbellekten gelmesi farklı sorunlardır.**AJAX isteği WordPress’e ulaşsa bile eski JavaScript’in yanlış action göndermesi HTTP 400 oluşturabilir. Böyle durumda çözüm admin-ajax.php dosyasını değiştirmek değildir. 8### Network Yanıtı, PHP Hata Günlükleri ve Sunucu Kayıtları Birlikte İncelenmemiş Olabilir AJAX hatalarında kesin teşhis için yalnızca tarayıcı Console mesajına bakmak yeterli olmayabilir. Network isteği, WordPress hata günlükleri ve sunucu kayıtları birlikte değerlendirilmelidir. #### Network panelinde kontrol edilecekler - Request URL - Request Method - Status Code - Request Payload - Response Body - Response Headers - İsteği başlatan JavaScript dosyası - İsteğin gönderildiği zaman #### PHP hata günlüğü nasıl etkinleştirilir? WordPress resmî belgeleri, geliştirme ve sorun giderme ortamlarında hata günlüğü kullanılmasını açıklar. ``` define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 ); ``` Bu ayarlar, `wp-config.php` içinde WordPress’in yüklenmesinden önce tanımlanmalıdır. **Mevcut WP_DEBUG tanımları varsa bunları tekrar eklemeyin.** Hata kayıtları genellikle aşağıdaki dosyada tutulur. ``` /wp-content/debug.log ``` #### PHP logunda ne aranmalı? - Fatal error veya uncaught exception - İlgili eklenti dosyasının yolu - Hata veren fonksiyon veya sınıf - AJAX isteğiyle aynı zaman damgası - Dosya ve satır numarası #### WordPress logu boşsa ne yapılmalı? WordPress logunun boş olması her zaman hata bulunmadığını göstermez. İstek PHP’ye ulaşmadan engellenmiş olabilir. Ayrıca PHP hata günlükleri farklı sunucu konumunda tutuluyor olabilir. Bu durumda hosting error log, WAF kaydı ve ilgili erişim kayıtları incelenmelidir. **Canlı sitede debug.log dosyasını herkese açık bırakmayın.**Günlükler dosya yolları, yapılandırma ayrıntıları veya hassas bilgiler içerebilir. Hata ayıklama bittikten sonra ilgili ayarlar eski güvenli duruma alınmalı, günlük erişimi korunmalıdır. ## WordPress admin-ajax.php 400, 403, 404 ve 500 Hataları Arasındaki Fark Nedir? AJAX isteklerinde görülen HTTP durum kodları ilk teşhis için önemli ipuçları sunar. Ancak bu kodlar tek başına kesin kök nedeni belirlemez. | HTTP kodu | Anlamı | İlk kontrol | | --- | --- | --- | | 400 | Bad Request | Action, kayıtlı hook, istek formatı ve yanıt gövdesi | | 401 | Kimlik doğrulaması gerekli | Oturum veya özel yetkilendirme katmanı | | 403 | İstek reddedildi | Nonce, yetki, güvenlik sistemi | | 404 | Adres bulunamadı | AJAX URL, WordPress dizini ve sunucu yönlendirmesi | | 429 | Çok fazla istek | Rate limit, WAF ve yoğun AJAX trafiği | | 500 | Sunucu uygulama hatası | PHP fatal error ve sunucu günlükleri | | 502 / 504 | Ağ geçidi veya zaman aşımı | Proxy, PHP-FPM, sunucu ve istek süresi | ### HTTP 200 ama işlem başarısızsa? HTTP 200 her zaman uygulamanın işlemi başarıyla tamamladığını göstermez. Örneğin bir AJAX işleyicisi aşağıdaki yanıtı HTTP 200 ile döndürebilir. ``` { "success": false, "data": { "message": "İşlem doğrulanamadı." } } ``` Bu durumda ağ isteği tamamlanmıştır ancak uygulama işlemi başarısız kabul etmiştir. WordPress `wp_send_json_error()` işlevi, geliştirici ayrıca durum kodu belirtmedikçe otomatik olarak HTTP 400 üretmek zorunda değildir. **HTTP durum kodu ile JSON success alanını ayrı kontrol edin.**Ağ katmanında başarılı olan bir istek, uygulama katmanında hata sonucu döndürebilir. ## Chrome DevTools ile admin-ajax.php 400 Hatası Nasıl Tespit Edilir? Tarayıcı geliştirici araçları, AJAX hatasının gerçek istek ve yanıtını görmeyi sağlar. ### 12 adımda Network analizi 1. **Hata veren sayfayı açın.** Form veya AJAX işleminin bulunduğu sayfaya gidin. 2. **Geliştirici araçlarını açın.** Chrome’da F12 veya Inspect kullanın. 3. **Network sekmesine geçin.** Ağ isteklerini görüntüleyin. 4. **Fetch/XHR filtresini seçin.** Dinamik istekleri ayırın. 5. **Gerekirse Preserve log etkinleştirin.** Sayfa yönlendirmesinde kayıtların kaybolmasını önleyin. 6. **Hata veren işlemi yeniden oluşturun.** Örneğin formu test verisiyle gönderin. 7. **admin-ajax.php isteğini seçin.** İstek listesinden açın. 8. **Headers bölümünü kontrol edin.** URL, HTTP metodu ve durum kodunu kaydedin. 9. **Payload bölümünü açın.** Action, nonce ve gereken alanların bulunup bulunmadığını kontrol edin. 10. **Response bölümünü inceleyin.** 0, -1, JSON veya HTML güvenlik sayfası mı? 11. **Initiator bilgisini kontrol edin.** Hangi JavaScript dosyası isteği başlatmış? 12. **Sonuçları zaman ve oturumla eşleştirin.** Gerekirse sunucu loguyla karşılaştırın. ### Örnek teşhis kaydı TEMSİLİ NETWORK BULGUSU **Request URL:** `https://example.com/wp-admin/admin-ajax.php` **Method:** POST. **Status:** 400 Bad Request. **Response:** `0` **Payload:** `action=example_form_submit` **Sonraki kontrol:** İşleyicinin WordPress tarafından kayıtlı olup olmadığı ve oturum türüne uygun hook. **HAR dosyasını veya tam Network kaydını herkese açık paylaşmayın.**Bu kayıtlar oturum çerezleri, nonce değerleri, kullanıcı verileri ve yetkilendirme başlıkları içerebilir. Teknik destek paylaşımından önce hassas alanlar temizlenmelidir. ## WordPress’te Doğru AJAX İşleyicisi Nasıl Yazılır? Aşağıdaki örnekler, WordPress AJAX sisteminin doğru kullanımını açıklamak için hazırlanmıştır. Makale içindeki kodlar otomatik olarak çalışmaz. Canlı sitede uygulamadan önce geliştirici tarafından uyarlanmalıdır. ### 1. AJAX işleyicisinin kaydedilmesi ``` add_action( 'wp_ajax_zm_example_search', 'zm_example_search_handler' ); add_action( 'wp_ajax_nopriv_zm_example_search', 'zm_example_search_handler' ); function zm_example_search_handler() { check_ajax_referer( 'zm_example_search_nonce', '_ajax_nonce' ); $keyword = isset( $_POST['keyword'] ) ? sanitize_text_field( wp_unslash( $_POST['keyword'] ) ) : ''; if ( '' === $keyword ) { wp_send_json_error( array( 'message' => 'Arama metni boş.' ), 400 ); } wp_send_json_success( array( 'keyword' => $keyword ) ); } ``` Bu örnekte boş anahtar kelime için geliştirici tarafından bilinçli olarak HTTP 400 döndürülmektedir. Dolayısıyla bu tür bir yanıt çekirdek action hatasından farklıdır. ### 2. AJAX URL ve nonce değerinin JavaScript’e iletilmesi ``` wp_localize_script( 'zm-example-script', 'zmAjaxData', array( 'ajaxUrl' => admin_url( 'admin-ajax.php' ), 'nonce' => wp_create_nonce( 'zm_example_search_nonce' ) ) ); ``` Burada `zm-example-script` adlı JavaScript dosyasının önceden WordPress’e kaydedilmiş ve sayfaya eklenmiş olması gerekir. ### 3. JavaScript fetch örneği ``` const body = new URLSearchParams({ action: 'zm_example_search', _ajax_nonce: zmAjaxData.nonce, keyword: 'wordpress seo' }); fetch(zmAjaxData.ajaxUrl, { method: 'POST', credentials: 'same-origin', body }) .then(async response => { const result = await response.json(); if (!response.ok || !result.success) { throw new Error('AJAX işlemi başarısız'); } return result.data; }) .then(data => { console.log(data); }) .catch(error => { console.error(error.message); }); ``` Bu örnekte `URLSearchParams` form kodlamasına uygun istek gövdesi oluşturur. WordPress böylece `action` parametresini standart istek alanından okuyabilir. ### 4. Yetkili işlemlerde ek kontrol ``` if ( ! current_user_can( 'manage_options' ) ) { wp_send_json_error( array( 'message' => 'Yetkisiz işlem.' ), 403 ); } ``` Bu tür yetki kontrolleri yalnızca ilgili işlemin gerçekten gerektirdiği yetkiyle eşleştirilmelidir. Her kullanıcıya açık sorgu işlemi için yönetici yetkisi istemek doğru değildir. **wp_send_json_success() ve wp_send_json_error() yanıtları AJAX işleyicisini uygun şekilde sonlandırır.**Böylece geliştirici yanıt formatını daha tutarlı yönetebilir. Ancak bu işlevler doğru hook, nonce ve yetki kontrollerinin yerini tutmaz. ## admin-ajax.php Hatası Giderilirken Hangi Güvenlik Önlemleri Alınmalı? WordPress AJAX sorunlarını çözmeye çalışırken güvenlik önlemlerinin devre dışı bırakılması yeni riskler oluşturabilir. Özellikle yönetici işlemlerini herkese açık hâle getirmek veya nonce kontrolünü kaldırmak güvenli değildir. ### Kaçınılması gereken yöntemler - admin-ajax.php dosyasını tamamen değiştirmek - Bütün AJAX işlemlerini nopriv yapmak - Nonce doğrulamasını rastgele kaldırmak - Tüm WAF kurallarını kalıcı kapatmak - Canlı sitede debug bilgilerini herkese göstermek - Çerez ve oturum verilerini herkese açık paylaşmak - PHP veya eklenti dosyalarını yedeksiz değiştirmek - Canlı ödeme ve müşteri formlarında kontrolsüz test yapmak ### Önerilen güvenli yöntem 1. **Güncel yedek alın.** Dosyalar ve veritabanı korunmalıdır. 2. **Staging ortamında hata oluşturun.** Mümkünse canlı trafiği etkilemeyin. 3. **Gerçek action değerini belirleyin.** Hatalı işlemin sahibini bulun. 4. **HTTP kodunu ve yanıtı doğrulayın.** Tahmine göre işlem yapmayın. 5. **Tek değişkenli test uygulayın.** Her adımın etkisini ölçün. 6. **Çözümü en dar kapsamda uygulayın.** Güvenlik önlemlerini koruyun. 7. **Hem giriş yapan hem ziyaretçi testini tamamlayın.** Uygun erişim modelini doğrulayın. **Güvenlik nedeniyle reddedilen bir isteği çalıştırmak için tüm doğrulamaları devre dışı bırakmak çözüm değildir.**Amaç, gerçek hatanın giderilmesi ve beklenen güvenlik modelinin korunmasıdır. ## WordPress admin-ajax.php 400 Hatası: 8 Neden ve Çözüm Tablosu | Olası neden | Kontrol | Çözüm | | --- | --- | --- | | Action parametresi eksik | Network Payload | Doğru action değerini gönderin. | | AJAX hook kayıtlı değil | wp_ajax ve wp_ajax_nopriv | Uygun oturum türüne ait işleyiciyi kaydedin. | | Nonce veya oturum sorunu | Nonce alanı, yanıt ve 403 ayrımı | Doğru nonce ve oturum akışını kullanın. | | Yanlış URL veya payload | Request URL, Method, Body | admin_url ve uygun form kodlamasını kullanın. | | Eklenti veya JS çakışması | Initiator, Console, staging | Hatalı eklenti veya özel kodu düzeltin. | | WAF veya ModSecurity engeli | Güvenlik günlükleri | Doğrulanmış yanlış pozitif için dar istisna uygulayın. | | Cache veya eski nonce | JS sürümü, CDN, dinamik sayfa | İlgili cache ve etiket zamanlamasını düzeltin. | | PHP veya sunucu hatası | debug.log, error log, Network Response | Gerçek hata kaynağını giderin. | ## WordPress admin-ajax.php 400 Hatası İçin 12 Adımlık Test Planı WordPress AJAX hatalarında ilk hedef, hatayı üreten gerçek isteğin belirlenmesidir. Aynı anda çok sayıda eklenti, cache ve sunucu ayarı değiştirmek teşhisi zorlaştırır. 1. **Hatanın görüldüğü işlemi belirleyin.** Form, arama, yönetim veya eklenti işlemi mi? 2. **DevTools Network panelini açın.** Gerçek AJAX isteğini yakalayın. 3. **Status Code ve Response Body kaydedin.** 400 + 0 mu, başka yanıt mı? 4. **Action parametresini kontrol edin.** Var, geçerli ve doğru mu? 5. **Action için kayıtlı hook’u doğrulayın.** PHP işleyici gerçekten yükleniyor mu? 6. **Giriş yapan ve ziyaretçi durumlarını karşılaştırın.** nopriv eksik olabilir mi? 7. **Nonce doğrulamasını inceleyin.** 403 ve -1 yanıtını ayırın. 8. **Request URL ve veri formatını doğrulayın.** GET, POST, JSON veya form verisi. 9. **İsteği başlatan JavaScript’i bulun.** Eklenti veya tema ilişkisini belirleyin. 10. **Cache ve WAF katmanlarını inceleyin.** Kaynak doğrulanmadan kapatmayın. 11. **PHP ve sunucu günlüklerini kontrol edin.** Aynı zamanlı hata kayıtlarını eşleştirin. 12. **Düzeltmeden sonra güvenli test yapın.** Yetkili ve ziyaretçi senaryolarını doğrulayın. **Başarılı çözüm nasıl anlaşılır?**İlgili AJAX işlemi, doğru action ve yetki kapsamında çalışmalı; beklenen veriyi doğru HTTP ve uygulama yanıtıyla döndürmelidir. Ayrıca güvenlik kontrolleri korunmalı, giriş yapan ve ziyaretçi kullanım senaryoları uygun biçimde test edilmelidir. ## WordPress admin-ajax.php 400 Hatası İçin 20 Maddelik Kontrol Listesi - Hata veren gerçek AJAX isteği bulundu mu? - HTTP durum kodu doğrulandı mı? - Response Body incelendi mi? - action parametresi mevcut mu? - action değeri doğru mu? - İlgili PHP AJAX işleyicisi kayıtlı mı? - Giriş yapan kullanıcı için wp_ajax kaydı var mı? - Gerekliyse wp_ajax_nopriv kaydı var mı? - Nonce alanı ve aksiyon adı kontrol edildi mi? - HTTP 400 ile 403 ayrımı yapıldı mı? - Request URL doğru mu? - GET/POST ve veri formatı doğru mu? - İsteği başlatan JavaScript dosyası belirlendi mi? - Console hataları incelendi mi? - Özel kod ve eklenti güncellemeleri değerlendirildi mi? - WAF ve ModSecurity logları kontrol edildi mi? - LiteSpeed Cache ve CDN kaynaklı eski veri araştırıldı mı? - PHP debug.log ve sunucu error log karşılaştırıldı mı? - Staging üzerinde kontrollü test gerçekleştirildi mi? - Çözüm sonrası güvenlik ve işlevsellik doğrulandı mı? ## WordPress AJAX ve Teknik Hatalar İçin İlgili Zeymedya Rehberleri ### WordPress REST API 403 Hatası REST API erişimi, güvenlik filtreleri ve yetkilendirme sorunları. [REST API 403 rehberi](https://zeymedya.com/wordpress-rest-api-403-hatasi/) ### WordPress Güncelleme Sonrası 500 Hatası PHP hataları, eklenti uyumsuzlukları ve güncelleme sonrası sunucu sorunları. [WordPress 500 rehberi](https://zeymedya.com/wordpress-guncelleme-sonrasi-500-hatasi/) ### GTM Önizlemede Çalışıyor, Canlıda Çalışmıyor JavaScript, etiket yayını, tetikleyici ve canlı site sorunları. [GTM canlı site rehberi](https://zeymedya.com/gtm-onizlemede-calisiyor-canlida-calismiyor/) ### WordPress Kalıcı Bağlantı 404 Hatası Yönlendirme, permalink, sunucu ve URL yapılandırma kontrolleri. [Kalıcı bağlantı rehberi](https://zeymedya.com/wordpress-kalici-baglanti-404-hatasi/) ### WordPress Zamanlanmış Yazı Yayınlanmıyor WP-Cron, sunucu zamanlaması ve arka plan görevleri. [Zamanlanmış yazı rehberi](https://zeymedya.com/wordpress-zamanlanmis-yazi-yayinlanmiyor/) ### WooCommerce Ödeme Sayfası Yükleniyor Checkout JavaScript, AJAX istekleri, ödeme ve eklenti çakışmaları. [WooCommerce ödeme rehberi](https://zeymedya.com/woocommerce-odeme-sayfasi-yukleniyor/) WordPress web sitelerinin tasarımı, teknik yapılandırması ve yönetimi hakkında [WordPress Web Tasarım Hizmetleri](https://zeymedya.com/wordpress-web-tasarim-hizmetleri/) sayfamızı inceleyebilirsiniz. Web sitesi kullanıcı deneyimi ve form dönüşümlerinin geliştirilmesi için [Dönüşüm Optimizasyonu](https://zeymedya.com/donusum-optimizasyonu/) hizmet sayfamıza göz atabilirsiniz. ## WordPress admin-ajax.php 400 Hatası Hakkında Sık Sorulan Sorular WordPress admin-ajax.php 400 hatası nedir?WordPress AJAX isteğinin HTTP 400 Bad Request yanıtıyla sonuçlanmasıdır. Eksik action, kayıtlı olmayan işleyici veya farklı güvenlik ve uygulama sorunları nedeniyle oluşabilir. admin-ajax.php neden 400 ve 0 döndürüyor?WordPress çekirdeği, geçerli action bulunmadığında veya kullanıcı oturumuna uygun AJAX işleyicisi kayıtlı olmadığında HTTP 400 ve 0 döndürebilir. admin-ajax.php adresini açınca 0 yazması normal mi?Evet. Adresi normal tarayıcı sekmesinde action parametresi olmadan açarsanız WordPress 400 ve 0 yanıtı verebilir. Bu durum tek başına site hatası değildir. WordPress AJAX action parametresi zorunlu mu?Klasik WordPress admin-ajax.php isteklerinde geçerli action değeri gerekir. WordPress bu değer üzerinden ilgili işleyiciyi çağırır. wp_ajax ve wp_ajax_nopriv arasındaki fark nedir?`wp_ajax_` giriş yapmış kullanıcılar için, `wp_ajax_nopriv_` ise giriş yapmamış kullanıcılar için kullanılır. Her işlem iki gruba da açılmamalıdır. admin-ajax.php -1 hatası ne anlama gelir?WordPress standart nonce kontrolünde başarısız olduğunda AJAX isteğini -1 yanıtıyla sonlandırabilir. Bu işlem varsayılan olarak HTTP 403 üretir. Nonce hatası admin-ajax.php 400 oluşturur mu?WordPress standart `check_ajax_referer()` doğrulamasında başarısızlık genellikle HTTP 403 ve -1 sonucunu oluşturur. Ancak özel bir eklenti nonce sorununu HTTP 400 olarak da döndürebilir. WordPress formu yöneticiye açıkken ziyaretçide neden çalışmıyor?Herkese açık olması gereken işlem için `wp_ajax_nopriv_` kaydı eksik olabilir. Giriş yapan ve yapmayan kullanıcı durumları ayrı kontrol edilmelidir. LiteSpeed Cache admin-ajax.php 400 hatasına neden olabilir mi?Eski JavaScript, önbellekte kalan nonce veya hatalı JS zamanlaması AJAX isteğini etkileyebilir. Ancak her 400 hatasının LiteSpeed kaynaklı olduğu varsayılmamalıdır. ModSecurity admin-ajax.php isteğini engelleyebilir mi?Evet. WAF veya ModSecurity belirli istekleri engelleyebilir. Ancak gerçek engelleme sunucu güvenlik kayıtlarıyla doğrulanmalıdır. admin-ajax.php 400 hatası için .htaccess değiştirmek gerekir mi?Her zaman gerekmez. Önce action, hook, nonce, istek URL’si ve yanıt kaynağı incelenmelidir. Sunucu yönlendirmesi ile ilişkisi doğrulanmayan .htaccess değişikliklerinden kaçının. WordPress admin-ajax.php 400 hatası SEO’yu etkiler mi?Hata, kullanıcıya sunulan arama, form, filtreleme veya içerik yükleme işlevlerini bozuyorsa kullanıcı deneyimini etkileyebilir. Ancak her AJAX 400 yanıtının doğrudan Google sıralama kaybı yarattığı söylenemez. admin-ajax.php yerine WordPress REST API kullanılabilir mi?Evet. Yeni geliştirmelerde uygun işlemler WordPress REST API üzerinden tasarlanabilir. Ancak mevcut AJAX işleminin REST API’ye taşınması ayrı bir geliştirme ve güvenlik değerlendirmesi gerektirir. admin-ajax.php hatası devam ederse hangi bilgiler hazırlanmalı?HTTP kodu, action değeri, yanıt gövdesi, istek zamanı, sorunlu eklenti, WordPress sürümü ve ilgili hata günlükleri hazırlanmalıdır. Oturum çerezleri ve özel bilgiler paylaşılmamalıdır. ## Sonuç: WordPress admin-ajax.php 400 Hatasında Önce Action ve Hook Kontrol Edilmelidir **WordPress admin-ajax.php 400 hatası**, farklı teknik katmanlardan kaynaklanabilen bir AJAX sorunudur. WordPress çekirdek kodunda, eksik veya geçersiz action değeri HTTP 400 yanıtı oluşturabilir. Kayıtlı olmayan AJAX işleyicileri ve giriş yapan kullanıcı ile ziyaretçi arasındaki hook farklılıkları da benzer sonuçlar verebilir. Nonce doğrulama hataları ise standart WordPress uygulamasında HTTP 403 ve -1 yanıtıyla ayırt edilebilir. Bu nedenle doğru teşhis için tarayıcı Network panelindeki gerçek istek, durum kodu, payload ve response bilgileri birlikte incelenmelidir. Eklenti, tema, WAF, LiteSpeed Cache ve sunucu günlükleri ancak somut bulgularla ilişkilendirildikten sonra değiştirilmelidir. **Doğru action, doğru AJAX hook, güvenli nonce ve yetki doğrulaması, uygun istek formatı ve kontrollü sunucu teşhisi**, WordPress AJAX işlemlerinin güvenilir şekilde çalışmasına yardımcı olur. ## WordPress Web Sitenizin Teknik Sorunlarını ve Performansını Daha Etkili Yönetin WordPress web sitelerinde AJAX işlemleri, JavaScript, güvenlik katmanları ve sunucu yapılandırması birlikte değerlendirilmelidir. **Zeymedya Reklam Ajansı**, WordPress web tasarım, SEO, Google Ads ve dönüşüm optimizasyonu hizmetleri sunmaktadır. WordPress web tasarım ve teknik site yönetimi hakkında [WordPress Web Tasarım Hizmetleri](https://zeymedya.com/wordpress-web-tasarim-hizmetleri/) sayfamızı inceleyebilirsiniz. Web sitesi kullanıcı deneyimi, form ve dönüşüm süreçlerinin geliştirilmesi için [Dönüşüm Optimizasyonu](https://zeymedya.com/donusum-optimizasyonu/) hizmet sayfamıza göz atabilirsiniz. [Zeymedya ile İletişime Geçin](https://zeymedya.com/iletisim/) ## WordPress admin-ajax.php Sorunları İçin Resmî Teknik Kaynaklar 1. [WordPress Developer – AJAX](https://developer.wordpress.org/plugins/javascript/ajax/) WordPress AJAX işleyişi, action parametresi, nonce kullanımı ve istemci tarafı istekleri. 2. [WordPress Developer – Server Side PHP and Enqueuing](https://developer.wordpress.org/plugins/javascript/enqueuing/) AJAX URL’sinin oluşturulması, wp_localize_script, PHP işleyici kayıtları ve veri iletimi. 3. [WordPress Core – admin-ajax.php Source](https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/admin-ajax.php) Geçersiz action ve kayıtlı olmayan AJAX hook’larında HTTP 400 yanıtının oluştuğu çekirdek kod. 4. [WordPress Developer – wp_ajax_{$action}](https://developer.wordpress.org/reference/hooks/wp_ajax_action/) Oturum açmış kullanıcılar için AJAX işleyici kaydı. 5. [WordPress Developer – wp_ajax_nopriv_{$action}](https://developer.wordpress.org/reference/hooks/wp_ajax_nopriv_action/) Giriş yapmamış ziyaretçiler için AJAX işleyici kaydı. 6. [WordPress Developer – check_ajax_referer()](https://developer.wordpress.org/reference/functions/check_ajax_referer/) AJAX nonce doğrulaması, varsayılan -1 yanıtı ve HTTP 403 davranışı. 7. [WordPress Developer – Nonces](https://developer.wordpress.org/apis/security/nonces/) Nonce oluşturma, kontrol etme, süre ve güvenlik sınırlamaları. 8. [WordPress Developer – wp_send_json_error()](https://developer.wordpress.org/reference/functions/wp_send_json_error/) AJAX işlemlerinde JSON hata yanıtları ve isteğe bağlı HTTP durum kodları. 9. [WordPress Developer – wp_send_json_success()](https://developer.wordpress.org/reference/functions/wp_send_json_success/) Başarılı AJAX yanıtlarının standart JSON biçimi. 10. [WordPress Developer – Debugging in WordPress](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) WP_DEBUG, WP_DEBUG_LOG, PHP hata kayıtları ve güvenli hata ayıklama. **Güncellik notu:** WordPress sürümleri, AJAX işleyicileri, PHP gereksinimleri ve üçüncü taraf eklenti davranışları zaman içinde değişebilir. Canlı sitede işlem yapmadan önce kullanılan WordPress sürümünü, eklenti yapılandırmasını ve resmî geliştirici belgelerini kontrol edin. ##### Benzer yazılar [https://zeymedya.com/wordpress-site-yedekleme/](https://zeymedya.com/wordpress-site-yedekleme/) #### [WordPress Site Yedekleme Nasıl Yapılır? Manuel ve Otomatik Yöntemler](https://zeymedya.com/wordpress-site-yedekleme/) - 12 Kasım 2026 [https://zeymedya.com/wix-mi-wordpress-mi/](https://zeymedya.com/wix-mi-wordpress-mi/) #### [Wix mi WordPress mi? Web Sitesi Kurmak İçin Hangisi Daha İyi?](https://zeymedya.com/wix-mi-wordpress-mi/) - 12 Kasım 2026 [https://zeymedya.com/ssl-sertifikasi-nedir/](https://zeymedya.com/ssl-sertifikasi-nedir/) #### [SSL Sertifikası Nedir? HTTPS Ne İşe Yarar ve Nasıl Kurulur?](https://zeymedya.com/ssl-sertifikasi-nedir/) - 12 Kasım 2026 ## Bir yanıt yazın[Yanıtı İptal Et](/wordpress-admin-ajax-400-hatasi/#respond)