WordPress 403 Forbidden Hatası: Nedenleri ve Çözümü

Kısa Özet

403 Forbidden, WordPress sitenize bir ziyaretçi ya da siz giriş yapmaya çalıştığınızda sunucunun “isteği aldım, ama burayı sana göstermem yasak” demesidir. Hata kodu net olsa da nedeni nadiren tek başınadır: .htaccess kuralları, hatalı dosya/klasör izinleri, eklenti güvenlik kuralları, mod_security tetikleyicileri, hosting tarafındaki IP/ülke engelleri ya da yanlış yapılandırılmış bir CDN — hepsi aynı 403 ekranını döndürebilir. Bu rehberde 403’ün arka planını, en sık karşılaşılan 9 nedenini ve her biri için adım adım çözüm yollarını bulacaksınız. Hızlı bir kontrol listesi ve sık sorulan sorular bölümü ile bittiğinde, sitenizin neresine bakacağınızı net bilen bir site sahibi olacaksınız.

403 Forbidden Hatası Nedir ve Neden Önemlidir?

HTTP 403 Forbidden, RFC 9110’da tanımlı bir istemci hatası kodudur. Sunucu isteği almıştır, anlamıştır ve kasten reddetmiştir. 401 (Unauthorized) hatasından farkı şudur: 401, “kimliğini doğrula, sonra tekrar dene” anlamına gelir; 403 ise “kim olduğun fark etmiyor, bu kaynağa erişimin yok” der. Bu nedenle 403 ekranıyla karşılaşan ziyaretçiyi yönlendirme adımları farklıdır.

WordPress siteleri için 403 hatasının önemi üç başlıkta toplanır:

• Trafik kaybı: Arama sonuçlarından gelen ziyaretçi, 403 görür ve geri döner. Google Search Console “Soft 404” ya da “Erişilemeyen URL” uyarıları başlar; bu da uzun vadede sıralama erozyonuna yol açar.
• Yönetim kilitlenmesi: 403 sıklıkla /wp-admin veya /wp-login.php üzerinde belirir. Site sahibi kendi paneline giremezse içerik üretimi, eklenti güncellemesi ve güvenlik müdahalesi durur.
• Gizli güvenlik sinyali: 403, çoğu zaman bir saldırı denemesini engelleyen meşru bir tepki olabilir. Sebebini araştırmadan kapatırsanız sitenizi gerçek tehditlere açık bırakırsınız.

403’ü görmezden gelmek yerine, sebebini dosya sistemi, web sunucusu ve uygulama katmanları arasında metodik biçimde aramak gerekir. Bu rehberin sıralaması da bu katman mantığını izler: önce tarayıcı ve cache, sonra .htaccess, sonra dosya izinleri, sonra eklentiler, en son hosting/CDN.

403 Hatasının Tipik Görünümleri

WordPress sitelerinde 403’ün sıkça gördüğünüz çeşitleri:

• “403 Forbidden — You don’t have permission to access this resource” (Apache varsayılanı)
• “Access Denied” ya da “Erişim Reddedildi” başlıklı mod_security veya güvenlik duvarı sayfası
• “Sorry, you are not allowed to access this page.” — WordPress yönetim panelinde rol/izin yetersizliği
• “Forbidden — nginx” sade bir nginx 403 sayfası
• Cloudflare Error 1020 / 1010 — CDN/WAF kaynaklı erişim engeli
• “403 — Reference #…” — hosting sağlayıcısının (çoğunlukla cPanel + ModSec) kendi referans kimliği

Hata mesajının görünümü size nereye bakmanız gerektiğini söyler. nginx başlığı görüyorsanız nginx.conf ve location blokları öncelikli; Cloudflare numarası varsa Firewall Events ekranı; “Reference #” ile karşılaşıyorsanız hosting sağlayıcınızın ModSec günlüklerini istemelisiniz.

Çözüme Başlamadan Önce: Yedek ve Hazırlık

403 hatasıyla mücadelede sık kullanılan adımlar — .htaccess yenileme, dosya izinlerini sıfırlama, eklenti devre dışı bırakma — yapısal değişiklikler içerir. Adım atmadan önce iki şey yapın:

1. Tam yedek alın. Hosting panelinizden bir “Full Backup” oluşturun ya da UpdraftPlus/All-in-One WP Migration gibi bir eklenti ile hem dosyaları hem veritabanını yedekleyin. Geri dönüş yolunuz olsun.
2. Bir not defteri açın. Yaptığınız her değişikliği (dosya, eklenti adı, izin numarası, saat) kaydedin. Sorun büyürse hangi adımın kötüleştirdiğini bulabilesiniz.

Eğer yönetim paneline giremiyorsanız ve yedek almak için FTP/SSH yoksa, hosting sağlayıcınızdan servis dışı bakım başlatmasını ya da en azından üst seviye /public_html klasörünün anlık yedeğini almasını talep edin.

Adım Adım 403 Çözüm Rehberi

1. Tarayıcı Önbelleği ve Çerezleri Temizleyin

Klişe gibi gelse de 403 hatalarının önemli bir kısmı tarayıcı tarafındaki bayat oturum verileri yüzünden tetiklenir. Özellikle yakın zamanda WordPress giriş URL’inizi değiştirdiyseniz ya da güvenlik eklentisi kuralları güncellendiyse, eski çerezler 403 dönen bir oturum yaratabilir.

Önce gizli/incognito sekmede sayfayı açın. Eğer gizli sekmede sorun yoksa normal pencerede tarayıcı geçmişini ve wpneta.com alanına ait çerezleri silin. Mobil/desktop farkı varsa sorun büyük olasılıkla istemcide.

2. URL’yi ve Permalink Yapısını Doğrulayın

Yanlış yazılmış bir URL (örn. /wp-Admin/), büyük/küçük harf duyarlı sunucularda 403 dönebilir. Kalıcı bağlantı (permalink) yapısını yakın zamanda değiştirdiyseniz .htaccess kuralları güncellenmemiş olabilir.

WordPress yönetim paneline girebiliyorsanız Ayarlar > Kalıcı Bağlantılar sayfasına gidip “Değişiklikleri Kaydet” butonuna tıklayın. Bu, hiçbir şey değiştirmeseniz bile .htaccess dosyasını standart WordPress kurallarıyla yeniden yazar.

3. .htaccess Dosyasını Sıfırlayın

Bozuk bir .htaccess kuralı, WordPress’te en sık görülen 403 sebebidir. Eski yedeklerden kalma Deny from all satırları, eski güvenlik eklentilerinden artakalan RewriteRule blokları ya da çift kopyalanmış WordPress kuralları çakışma yaratır.

FTP/SSH ile /public_html/ dizinine bağlanın. Mevcut .htaccess dosyasını .htaccess.bak olarak yeniden adlandırın. Sonra şu standart içerikle yeni bir .htaccess oluşturun:

# 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

Dosyayı kaydedip siteyi yeniden ziyaret edin. 403 ortadan kalktıysa, yeniden adlandırdığınız .htaccess.bak dosyasını metin editöründe açıp hangi blokların sorun yarattığını anlayabilirsiniz. Çoğu zaman suçlu, “Limit Login Attempts” ya da “WP Hardening” gibi eski güvenlik eklentilerinin bıraktığı <Files> blokları olur.

4. Dosya ve Klasör İzinlerini Düzeltin

Linux tabanlı hostinglerde Apache ya da nginx, dosyalara doğru izinlerle erişemediğinde 403 döner. WordPress için standart ve güvenli izinler şudur:

• Klasörler: 755 (sahibi okuma+yazma+çalıştırma; diğerleri okuma+çalıştırma)
• Dosyalar: 644 (sahibi okuma+yazma; diğerleri sadece okuma)
• wp-config.php: 440 ya da 400 (yalnızca sahibi okuyabilir)

SSH erişiminiz varsa kök WordPress dizininde şu komutlarla tüm izinleri toplu sıfırlayabilirsiniz:

# Tüm klasörlere 755 ver
find . -type d -exec chmod 755 {} \;

# Tüm dosyalara 644 ver
find . -type f -exec chmod 644 {} \;

# wp-config.php'yi kilitleyin
chmod 440 wp-config.php

# Yükleme klasöründe izinleri yeniden uygula
chown -R www-data:www-data wp-content/uploads

Uyarı: Hiçbir zaman 777 izni kullanmayın. Geçici olarak bile olsa, bu izin sunucuda çalışan herkesin dosyanızı değiştirebileceği anlamına gelir ve neredeyse tüm güvenlik tarayıcıları siteyi savunmasız olarak işaretler.

5. index.php ve index.html Çakışmasını Kontrol Edin

Bazı hostinglerde sunucu önce index.html dosyasını arar; bulamazsa index.php‘yi açar. Ancak DirectoryIndex direktifi yanlış yapılandırıldığında ya da kök dizinde hiçbir index.* dosyası bulunmadığında 403 görürsünüz. Kontrol edin:

ls -la /var/www/html/ | grep -E "index\.(php|html)"

Sadece index.html varsa (örn. eski bir “kurulum tamamlandı” sayfası) ve WordPress aktifse, .htaccess dosyanıza şu satırı ekleyin:

DirectoryIndex index.php index.html

6. Eklenti Çakışmasını Devre Dışı Bırakarak Tespit Edin

Güvenlik (Wordfence, iThemes Security, All In One WP Security), önbellek (W3 Total Cache, WP Rocket) ve giriş koruması eklentileri kendi başlarına 403 üretebilir. Yönetim paneline giremiyorsanız tüm eklentileri tek seferde devre dışı bırakmanın en hızlı yolu klasör adını değiştirmektir:

# FTP/SSH ile
cd wp-content/
mv plugins plugins_off
mkdir plugins

Site açıldıysa suçlu eklenti grubudur. plugins_off içindeki klasörleri tek tek plugins altına geri taşıyın ve her seferinde siteyi tekrar test edin. Sorunu üreten eklenti ortaya çıktığında hem WPNeta’da hem de eklentinin destek forumunda aynı şikâyeti aramak çoğu zaman çözüm sağlar.

WP-CLI erişiminiz varsa bu süreç çok daha hızlıdır:

wp plugin deactivate --all
wp plugin activate --all
# ya da tek tek:
wp plugin activate eklenti-adi

7. Tema Sorunlarını Kontrol Edin

Bozuk veya kötü kodlanmış bir temanın functions.php dosyası 403 üretebilir. WordPress’in varsayılan temasına geçmek hızlı bir testtir:

wp theme activate twentytwentyfour

Yönetim paneline giremiyorsanız wp-content/themes/ dizininde aktif temanızın klasör adını değiştirin (örn. my-theme → my-theme_off). WordPress, varsayılan temaya otomatik düşecektir. Sorun çözülürse temanın geliştiricisinden destek isteyin ya da güncel sürüme geçin.

8. mod_security ve WAF Kurallarını İnceleyin

Apache’nin mod_security modülü ve hosting sağlayıcısının üzerine eklediği özel kurallar, “şüpheli” gördüğü istekleri 403 ile reddeder. Tipik tetikleyiciler: dosya yükleme istekleri, blok editöründeki kaynak HTML kayıtları, REST API uç noktaları ve XML-RPC çağrıları.

Hosting sağlayıcınızın panelinde “ModSecurity” sekmesini arayın. Bazı paneller (cPanel, Plesk) tek bir alan adı için ModSec’i geçici olarak kapatmanıza izin verir. Ancak ModSec’i tamamen kapatmak güvenlik için kötü bir fikirdir; bunun yerine hatayı tetikleyen “Rule ID” numarasını destek ekibine bildirip yalnızca o kuralın muafiyetini isteyin.

Sunucuya erişiminiz varsa ModSec günlüğünden son tetiklenen kuralı görebilirsiniz:

tail -n 200 /var/log/apache2/modsec_audit.log | grep -E "id|uri|host"

9. CDN ve Güvenlik Duvarı Ayarlarını Doğrulayın

Cloudflare, Sucuri ya da BunnyCDN gibi servisler, “Bot Fight Mode”, “Under Attack Mode” ya da yanlış konfigüre edilmiş Firewall kuralı yüzünden meşru ziyaretçilere 403 dönebilir. Cloudflare panelinizde Security > Events ekranı, hangi kuralın hangi IP’yi engellediğini gösterir.

Ülke bazlı engelleme eklediyseniz hedef pazarınızdan trafiğin engellenip engellenmediğini kontrol edin. Çoğu zaman aşırı sıkı bir Rate Limiting ya da WAF Managed Rule, blog yorumlarını ya da WooCommerce ödeme adımlarını boğar.

Geçici test için Cloudflare’i bypass edin: hosts dosyanıza sunucunuzun gerçek IP’sini girin ve siteyi açın. 403 kaybolduysa sorun CDN/WAF tarafında demektir.

10. Hosting Sağlayıcısı IP veya Ülke Engellemelerini Sorun

Bazı paylaşımlı hosting sağlayıcıları, kendi sunucu seviyelerinde belirli IP aralıklarını ya da ülkeleri engeller. Eğer 403 yalnızca belirli kullanıcılarda ortaya çıkıyorsa (örn. bir mobil operatörden gelenler), büyük ihtimalle hosting tarafında IP itibar listesine takılıyorlar demektir. Sağlayıcınızla iletişime geçip etkilenen IP’leri muafiyet listesine eklemelerini isteyin.

Sunucu Loglarını Doğru Okuyun

403 hatasının kaynağını net biçimde tespit etmenin en hızlı yolu sunucu loglarını incelemektir. WordPress’in kendi debug.log‘u uygulama tarafını anlatır; web sunucusunun erişim ve hata logları ise gerçek 403 kararının nerede ve neden alındığını gösterir.

Apache Erişim ve Hata Logları

cPanel kullanıyorsanız hata loglarına “Errors” bölümünden ulaşabilirsiniz. SSH erişiminizde tipik konumlar şunlardır:

tail -f /var/log/apache2/access.log | grep " 403 "
tail -f /var/log/apache2/error.log
tail -f /usr/local/apache/logs/error_log

Erişim logundaki bir satırın yapısı şöyledir:

192.0.2.10 - - [26/Apr/2026:09:14:51 +0000] "GET /wp-admin/ HTTP/1.1" 403 1124 "-" "Mozilla/5.0..."

Burada 403 dönüş kodudur. Aynı anı hata logunda aratırsanız, çoğunlukla “client denied by server configuration” ya da “ModSecurity: Access denied with code 403” gibi açıklayıcı bir satır bulursunuz. Bu satır size suçlu kuralın hangi modülde olduğunu söyler.

nginx Logları

nginx tabanlı sistemlerde aynı bilgi şu konumdadır:

tail -f /var/log/nginx/access.log | grep " 403 "
tail -f /var/log/nginx/error.log

nginx 403’ü genellikle location bloklarında deny all; direktifi ya da yanlış try_files sıralamasından kaynaklanır. nginx -t komutu ile yapılandırma sözdizimini test edebilir, hosting sağlayıcınızdan değişiklikleri uygulamasını isteyebilirsiniz.

WordPress Debug Log Analizi

Yukarıda eklediğiniz WP_DEBUG_LOG sabiti sayesinde wp-content/debug.log dosyası oluşur. 403 hatasının yaşandığı dakikalardaki kayıtları görmek için:

tail -n 300 wp-content/debug.log | grep -iE "forbidden|denied|capability|permission"

“PHP Warning: … permission denied” satırları, WordPress’in dosya sistemine yazmaya çalıştığı ama izin alamadığı yerleri işaret eder. Bu çoğunlukla bir sonraki adım için yol haritası verir.

WP-CLI ile Hızlı Tanı

WP-CLI, WordPress’i komut satırından yönetmenizi sağlar ve panele giremediğiniz 403 senaryolarında en güçlü aracınızdır. Hosting sağlayıcınızda kurulu değilse SSH ile şu adımlarla kurabilirsiniz:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Kurulduğunda 403 ile ilgili hızlı kontrolleri tek satırda yapabilirsiniz:

# Kurulum bütünlüğünü doğrula
wp core verify-checksums

# Eklenti ve tema bütünlüğü
wp plugin verify-checksums --all

# .htaccess'i WordPress'e yeniden yazdır
wp rewrite flush --hard

# Aktif eklentileri listele
wp plugin list --status=active --field=name

# Belirli bir eklentiyi devre dışı bırak
wp plugin deactivate eklenti-adi

# Veritabanında kalan eski oturumları temizle
wp transient delete --all

Bu komutların çoğu yöneticisiz çalışır ve yan etkisiz tanı yapmanızı sağlar. Özellikle wp core verify-checksums, çekirdek dosyalardan birinin değiştirilip değiştirilmediğini söyler. Beklenmedik checksum hataları, bir saldırı sonucu eklenmiş arka kapı dosyalarına işaret edebilir; bu da ayrı bir 403 kaynağıdır.

403 ve SEO İlişkisi

Google’ın tarayıcısı (Googlebot) bir URL’de 403 ile karşılaştığında o sayfayı dizinden çıkarmaya başlar. Kısa süreli 403’ler bile Search Console‘da “Erişilemiyor” raporunda görünür ve önemli sayfalarınızda kayıtlı uyarı sayısı artar. Bu kötüleşmeyi azaltmak için:

• Robots.txt’i koruyun: Robots dosyanız 403 dönüyorsa Googlebot kuralları okuyamaz ve siteyi tamamen taramayı durdurabilir. https://wpneta.com/robots.txt mutlaka 200 dönmelidir.
• Sitemap.xml’i izleyin: XML site haritanız 403 üretmesin. cPanel “WordPress Toolkit” üzerinden ya da Yoast/Rank Math ayarlarından sitemap erişilebilirliğini doğrulayın.
• Google Search Console URL Inspection: Etkilenen URL’i Search Console’a girip “Live Test” çalıştırın. Googlebot’un gördüğü yanıt kodunu burada görürsünüz.
• Geçici 403’leri 503’e çevirin: Bakım için bir sayfayı geçici kapatıyorsanız 403 yerine 503 Service Unavailable + Retry-After başlığı kullanın. Google bu kombinasyonu “şu anda kapalı, sonra tekrar dene” olarak yorumlar ve dizinden çıkarmaz.

Hosting Türüne Göre 403 Farkları

Paylaşımlı Hosting (Shared)

Kaynaklar paylaşıldığı için sağlayıcı, sunucu seviyesinde sıkı güvenlik kuralları uygular. ModSecurity neredeyse her zaman aktiftir ve istisna eklemek için destek bileti açmanız gerekir. php.ini ve nginx.conf üzerinde yetkiniz yoktur; çoğu çözüm hosting paneli üzerinden yapılır.

Yönetilen WordPress Hosting (Managed)

Kinsta, WP Engine, Pressidium gibi yönetilen platformlar kendi WAF’larını sunar. 403’ler genellikle “WordPress beyaz listesi” üzerinden yönetilir. Geliştirici dosya değişikliği için SSH/SFTP açık olsa da çoğu sunucu yapılandırmasını panel arayüzünden değiştirirsiniz.

VPS ve Bulut (DigitalOcean, AWS, Hetzner)

Tam yönetim sizdedir. nginx, apache, php-fpm, fail2ban ve UFW gibi tüm bileşenleri konfigüre edebilirsiniz. Bu özgürlük 403’lerde tanıyı hızlandırır ama bakım sorumluluğu da artar. Loglara doğrudan erişim ve systemctl status nginx gibi komutlar günlük araç setinizdir.

Sorun Giderme Kontrol Listesi

Aşağıdaki listeyi yukarıdan aşağıya kontrol edin. Çoğu 403 vakası ilk altı adımda çözülür.

• Tarayıcı önbelleği ve wpneta.com çerezleri temizlendi mi?
• Gizli sekmede 403 hâlâ görülüyor mu?
• Permalink ayarları yeniden kaydedildi mi?
• .htaccess dosyasının yedeği alınıp standart sürümle değiştirildi mi?
• Klasör izinleri 755, dosya izinleri 644, wp-config.php 440 mı?
• Tüm eklentiler devre dışı bırakılıp tek tek tekrar açıldı mı?
• Aktif tema varsayılan temayla değiştirildi mi?
• Hosting panelinde ModSecurity geçici olarak kapatıldı mı?
• CDN/WAF (Cloudflare, Sucuri) Firewall Events günlüğü incelendi mi?
• Hosting sağlayıcısından son saatlerde değişen sunucu kuralı (php-fpm, mod_security, suhosin) olup olmadığı soruldu mu?

403 Hatasının Yeniden Oluşmasını Önlemek

Sürdürülebilir Yedekleme ve Test Disiplini

403’ün geri dönmesini engellemenin en güvenli yolu, değişiklikleri canlıya almadan önce test edebileceğiniz bir staging ortamı kurmaktır. Çoğu kaliteli hosting sağlayıcısı tek tıkla staging klonu sunar. Eklenti güncellemelerini, tema değişikliklerini ve sunucu ayarı revizyonlarını önce stagingde deneyin.

Yedekleme planınızda günlük otomatik dosya + veritabanı yedeği, dış konumda saklama (Amazon S3, Google Drive, BackBlaze) ve aylık restore testi olmalı. Yedek var ama açılmıyor diye yeni 403 vakaları yaratan onlarca site sahibi gördük; bir yedeğin işe yaradığını ancak geri yükleyince anlarsınız.

Düzenli Güncelleme ve Eklenti Hijyeni

WordPress çekirdeği, eklentiler, temalar ve PHP sürümü güncel tutulmalı. Bakımsız bırakılan bir güvenlik eklentisi, modern PHP sürümlerinde uyumsuz .htaccess kuralları ekleyerek 403’e neden olabilir. Üç aydan uzun süredir güncellenmemiş eklentileri arşivleyin ya da bakımı sürdürülen alternatifleriyle değiştirin.

Doğru wp-config Sabitleri

403 ve diğer erişim hatalarını tespit etmenizi kolaylaştıran yapılandırma sabitlerini wp-config.php içine ekleyin:

// Hata günlüğünü dosyaya yaz, ekranda gösterme
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Dosya düzenlemeyi panelden kapatın (güvenlik)
define( 'DISALLOW_FILE_EDIT', true );

// SSL üzerinden yönetim panelini zorunlu kılın
define( 'FORCE_SSL_ADMIN', true );

Bu sabitler ekrana hata yazmadan tüm hataları wp-content/debug.log dosyasına kaydeder. 403 ile karşılaşan ziyaretçinin durumunu sonradan inceleyebilirsiniz.

Güvenlik Eklentisi Yapılandırması

Wordfence, Sucuri ya da iThemes Security gibi eklentilerin “Brute Force Protection” ve “Limit Login Attempts” özellikleri 403’ü tetikleyebilir. Yapılandırmanızda şu üç şeye dikkat edin:

1. Beyaz listeye kendi statik IP’nizi ekleyin; aksi halde sürekli kendinizi engellersiniz.
2. Eklentinin “Block country” listesi varsa, gerçek hedef pazarınızı engellememeye dikkat edin.
3. Eklentinin .htaccess üzerinde değişiklik yapma izninin gerçekten gerekli olup olmadığını gözden geçirin.

Sıkça Sorulan Sorular (SSS)

Sadece WordPress yönetim paneli 403 dönüyor, ön yüz çalışıyor — neden?

Bu durum büyük olasılıkla güvenlik eklentisinin “Login URL’i değiştir” özelliğinden ya da hosting sağlayıcısının /wp-admin dizinine eklediği koruma kuralından kaynaklanır. Çoğu kaliteli hosting paneli “WordPress Toolkit” altında bu korumayı geçici devre dışı bırakmanıza izin verir. Ek olarak, en son değiştirdiğiniz wp-login.php URL’sini hatırlamıyorsanız, hosting sağlayıcısından oturum çerezlerinizin sıfırlanmasını isteyin.

WooCommerce ödeme sayfasında 403 alıyorum, başka bir yerde sorun yok.

Bu klasik bir mod_security tetiklemesidir. Ödeme formunda gönderilen bazı alanlar (özellikle isim ya da adres içinde özel karakterler), WAF kurallarının “SQL injection denemesi” gibi yorumlamasına yol açar. Hosting sağlayıcınızdan ModSec ID’leri 949110, 980130 ve 200004 için /checkout URL’i muafiyeti isteyin.

403 yerine “Sorry, you are not allowed to access this page.” görüyorum.

Bu mesaj WordPress’in kendi izin sisteminden gelir, sunucu kaynaklı 403 değildir. Kullanıcı rolünüz (örneğin “Subscriber”) o sayfaya erişim hakkı vermez. Yetki gerektiren işlem için “Editor” ya da “Administrator” rolüne sahip olmanız gerekir. User Role Editor gibi eklentilerle yanlış kapatılmış bir capability de aynı mesajı üretebilir.

FTP ile bağlanırken 403 alıyorum, web sitesi açılıyor.

FTP/SFTP 403’ü genellikle dizin izinlerinin kullanıcıyı dışarıda bıraktığı durumlarda görülür. Hosting paneliniz “File Manager” üzerinden klasörü görüntülüyorsa ancak FTP kullanıcısı göremiyorsa, kullanıcı sahipliği (chown) yanlış demektir. Hosting sağlayıcınızdan ana FTP kullanıcısının sahipliğini düzeltmesini isteyin.

Cloudflare aktifken 403 görüyorum, kapatınca düzeliyor — kalıcı çözüm nedir?

Cloudflare WAF Managed Rules, OWASP Core Rule Set’in agresif sürümünü kullanıyor olabilir. Önce Security > Events günlüğünden tetiklenen kural ID’sini bulun. Genellikle WordPress REST API ya da Gutenberg editör çağrıları için wp-admin/admin-ajax.php ve wp-json/* uç noktalarına özel “Skip” kuralı yazmak çözer. Tüm WAF’ı kapatmak yerine spesifik istisnalar tanımlayın.

Site bir süre çalıştıktan sonra 403’e dönüyor — sebebi ne olabilir?

Bu desen, sunucu tarafında fail2ban ya da hosting sağlayıcısının “auto-ban” kuralının kendi IP’nizi engellediğine işaret eder. Sık başarısız giriş denemeleri, art arda 404 dönen istekler ya da şüpheli kullanıcı ajanı (User Agent) bu mekanizmaları tetikler. Sunucu loglarınızda fail2ban[xxxx]: Ban <sizin-ip> satırını arayın; bulursanız hosting sağlayıcınızdan kendi IP’nizi jail.local beyaz listesine eklemesini isteyin.

Kaynak Önerileri

403 hatasını derinlemesine kavramak ve WordPress yönetiminizi olgunlaştırmak için aşağıdaki başlıklara da göz atmanızı öneririz:

• WordPress 500 Internal Server Error rehberi — WPNeta arşivinde detaylı tanı ve çözüm adımları.
• WordPress 502 Bad Gateway hatası rehberi — sunucu üst katmanı problemleri için.
• WordPress 503 Service Unavailable rehberi — bakım modu ve kaynak limiti incelemeleri.
• WordPress 504 Gateway Timeout rehberi — uzun sorgular ve php-fpm zaman aşımı için.
• WordPress yedekleme rehberi — otomatik ve manuel yedek alma yöntemleri.
• MDN Web Docs — HTTP 403 Forbidden referansı.
• OWASP — ModSecurity Core Rule Set dokümanı.

Sonuç

403 Forbidden hatası, ilk bakışta endişe verici görünse de bir çıkmaz değildir; aksine sunucunuzun “burayı korumam gerekiyor” demesidir. Bu rehberde paylaştığımız sıralı yaklaşım — tarayıcıdan başlayıp .htaccess, dosya izinleri, eklenti, tema ve son olarak hosting/CDN katmanına inerek — büyük çoğunluğu kısa sürede çözer. Yedek alma, staging’de test etme ve wp-config.php debug sabitlerini açık tutma alışkanlığı kazanırsanız hem 403’ü hem de gelecekte gelebilecek diğer hataları profesyonelce yönetirsiniz. Sitenizin sağlığı, küçük ama düzenli denetimlerin toplam sonucudur — bu rehberi bir kontrol listesi olarak yer imine ekleyin ve aylık bakımınızda kullanın.