WordPress Yönetici Paneline Giremiyorum: Sırayla Denenecekler

"WordPress yönetici paneline giremiyorum" cümlesi tek bir sorunu değil, birbirine hiç benzemeyen en az sekiz farklı durumu anlatır. Kimi kullanıcı doğru parolayı yazar ama sayfa hiç tepki vermeden giriş ekranına geri döner. Kimi "Çerezler engellendi" uyarısı alır. Kimi giriş yapar, panel bir saniye görünür ve tekrar wp-login.php sayfasına atılır. Kimi de wp-admin adresini açtığında bambaşka bir alan adına yönlendirilir. Bunların hiçbiri şifre sorunu değildir — ve Türkçe kaynakların büyük kısmı bu yazının tamamını şifre sıfırlamaya ayırdığı için insanlar saatlerini yanlış yerde geçirir.

Bu yazı bir eleme listesidir, bir "12 neden" derlemesi değil. Sırayı bilerek kurdum: en üstteki adımlar en hızlı sonuç verenler ve en az riskli olanlar, aşağı indikçe daha müdahaleci hale geliyor. Özellikle Türkçe internette bir arada hiç ele alınmayan üç duruma ayrı bölüm ayırdım: siteurl/home uyuşmazlığı, çerez alan adı çakışması (www'lu ve www'suz adres karışıklığı) ve güvenlik eklentisinin oturum kayıtlarını bozması. Panelinize giremediğinizde sebep büyük olasılıkla bu üçünden biridir ve hiçbiri parolanızla ilgili değildir.

Önce Semptomu Doğru Tanımlayın#

Doğru çözüm, gördüğünüz ekrana bağlıdır. Aşağıdaki tabloda kendi durumunuzu bulun ve doğrudan ilgili bölüme geçin — sırayla her şeyi denemek zorunda değilsiniz.

Şifrenizi gerçekten hatırlamıyorsanız bu yazı sizin için değil; doğru adres wordpress şifremi unuttum sıfırlama yazısıdır. Aşağıdaki her adım, parolanın doğru olduğu varsayımıyla yazılmıştır.

Adım 1: Tarayıcı Tarafını Elemek#

Bu ilk adım basit görünür ama vakaların yaklaşık dörtte birini burada kapatırım. Amaç, sorunun sitede mi tarayıcıda mı olduğunu 60 saniyede kesinleştirmek.

1. Gizli sekme açın ve https://siteniz.com/wp-login.php adresine gidin. Gizli sekmede eski çerezler ve önbellek devrede olmaz.
2. Farklı bir tarayıcı deneyin. Chrome'da olmuyorsa Firefox'ta deneyin.
3. Farklı bir ağ deneyin. Mobil veriyle telefondan girin. Girebiliyorsanız sorun ofis/ev IP'nizin engellenmiş olmasıdır — doğrudan IP engeli bölümüne atlayın.
4. Sadece o siteye ait çerezleri silin. Tarayıcı ayarlarından tüm geçmişi silmek yerine site bazında temizlemek yeterlidir.

Gizli sekmede giriş yapabiliyorsanız sorun tamamen tarayıcı tarafındadır: eski bir oturum çerezi bozuk kalmıştır. Normal pencerede o siteye ait çerezleri silip yeniden deneyin, konu kapanır.

Hiçbir tarayıcıda ve hiçbir ağda giremiyorsanız sorun sunucudadır; devam edin.

Adım 2: Çerez Alan Adı Çakışması#

Bu, panele girememenin en sık ve en az bilinen sebebidir: www'lu ve www'suz adresin karışması. WordPress oturum çerezini siteurl ayarındaki alan adına yazar. Siz https://www.siteniz.com/wp-login.php üzerinden giriş yaparsınız, WordPress çerezi siteniz.com (www'suz) için yazar, tarayıcı da o çerezi bir sonraki istekte www'lu adrese göndermez. Sonuç: giriş başarılı olur, panele yönlendirilirsiniz ama WordPress sizi tanımaz ve tekrar giriş ekranına atar. Sonsuz döngü.

Belirtileri çok tipiktir:

• Parola yanlış hatası almazsınız — sayfa sadece giriş ekranına döner.
• Bazen "Çerezler engellendiği için giriş yapamıyorsunuz" uyarısı çıkar.
• Adres çubuğunda www'lu ve www'suz hâli arasında gidip gelme olur.

Çözüm: hangi adresin doğru olduğunu belirleyip ona sadık kalmak. Kayıtlı adresinizin www'lu mu www'suz mu olduğunu bilmiyorsanız aşağıdaki adımdaki veritabanı sorgusuyla öğrenirsiniz. Sonra girişi her zaman o adresle yapın.

Kalıcı çözüm için wp-config.php dosyasına çerez tanımlarını elle sabitleyebilirsiniz:

define( 'WP_HOME', 'https://siteniz.com' );
define( 'WP_SITEURL', 'https://siteniz.com' );
define( 'COOKIE_DOMAIN', 'siteniz.com' );
define( 'ADMIN_COOKIE_PATH', '/' );
define( 'COOKIEPATH', '/' );
define( 'SITECOOKIEPATH', '/' );

Bu blok, adresi veritabanından okumak yerine dosyadan sabitler — yani veritabanındaki değer ne olursa olsun WordPress bu adresi kullanır. Sorun çözüldükten sonra WP_HOME ve WP_SITEURL satırlarını bırakabilirsiniz; hatta bırakmanız önerilir, çünkü ileride yanlışlıkla değiştirilmelerini de engeller.

Çerezle ilgili ikinci bir ihtimal daha vardır: wp-config.php içindeki güvenlik anahtarlarının (SALT) değiştirilmesi. Bu anahtarlar değiştiğinde tüm mevcut oturumlar geçersiz olur — ki bazen tam da istediğiniz budur. Ama anahtarlar bozuk formatta yazıldıysa (örneğin tek tırnak eksikse) oturum hiç kurulamaz. Anahtarların her biri tek satırda, define( 'AUTH_KEY', '...' ); biçiminde ve tırnakları tam olmalıdır.

Adım 3: siteurl ve home Uyuşmazlığı#

wp-admin adresini açtığınızda bambaşka bir yere yönlendiriliyorsanız sebep bu ikilidir. WordPress iki adres saklar: home (ziyaretçilerin gördüğü adres) ve siteurl (WordPress dosyalarının bulunduğu adres). Bunlardan biri yanlışsa panele hiç ulaşamazsınız.

Bu değerler şu durumlarda bozulur: SSL kurulup site https'e taşınırken sadece biri güncellenmiş, site taşınırken eski alan adı kalmış, bir eklenti veya tema "Site Adresi" alanını değiştirmiş, ya da bir saldırgan bu değeri kendi adresiyle değiştirmiştir.

phpMyAdmin üzerinden mevcut değerleri görmek için:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl','home');

Yanlışsa düzeltmek:

UPDATE wp_options SET option_value = 'https://siteniz.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://siteniz.com' WHERE option_name = 'home';

Tablo öneki wp_ değilse komutlardaki adı kendi önekinizle değiştirin; paylaşımlı hostinglerde önek çoğu zaman farklıdır. phpMyAdmin'i hiç kullanmadıysanız phpmyadmin kullanımı yazısı arayüzü adım adım anlatıyor; komutu çalıştırmadan önce tablonun dışa aktarımını almanız iyi bir alışkanlıktır.

Veritabanına dokunmak istemiyorsanız wp-config.php içindeki WP_HOME ve WP_SITEURL tanımları aynı işi görür ve veritabanındaki değeri geçersiz kılar — geri alması da bir satır silmek kadar kolaydır. Adresin bir saldırı sonucu değiştiği şüphesi varsa değeri düzeltmekle yetinmeyin: yönetici hesaplarını, wp_users tablosunu ve son değişen dosyaları da kontrol edin.

Adım 4: Eklenti veya Tema Kaynaklı Engel#

Panel açılırken beyaz sayfa, kritik hata veya yarım yüklenmiş bir ekran görüyorsanız suçlu neredeyse her zaman bir eklentidir. Özellikle güvenlik, önbellek ve giriş sınırlama eklentileri panele erişimi doğrudan etkiler.

Panele giremediğiniz için eklentileri panelden kapatamazsınız; FTP veya cPanel Dosya Yöneticisi kullanacaksınız:

1. wp-content/plugins klasörünün adını plugins-kapali yapın.
2. wp-login.php sayfasını yenileyin ve giriş yapmayı deneyin.
3. Girebiliyorsanız suçlu bir eklentidir. Klasör adını plugins olarak geri alın — eklentiler pasif kalır, ayarları kaybolmaz.
4. Panelden eklentileri birer birer etkinleştirin, her birinden sonra çıkış yapıp yeniden girmeyi deneyin.

Aynı testi tema için wp-content/themes/aktif-tema klasörünün adını değiştirerek yaparsınız; WordPress varsayılan temaya düşer.

SSH erişiminiz varsa bu işlem tek satırdır:

wp plugin deactivate --all
wp plugin activate eklenti-adi
wp theme activate twentytwentyfour

WP-CLI panel açılmasa bile çalışır, çünkü doğrudan veritabanına yazar. Temel komutlar için wp-cli kullanımı yazısına bakabilirsiniz. Panel açılırken doğrudan "kritik hata" mesajı alıyorsanız o senaryonun ayrıntılı çözümü wordpress kritik hata oluştu yazısındadır.

Adım 5: Güvenlik Eklentisinin Oturum Kayıtlarını Bozması#

Bu, Türkçe kaynaklarda hiç geçmeyen ama sahada sık karşılaştığım bir durum. Güvenlik eklentileri iki şey yapar: giriş denemelerini kendi tablolarında tutar ve çoğu zaman oturum yönetimine karışır. Eklenti yarım güncellendiğinde, tablosu bozulduğunda veya kendi ayarları sıfırlandığında sonuç şu olur: doğru parolayı yazarsınız, eklenti oturumu açar, ama kendi kaydına yazamadığı için bir sonraki istekte oturumu geçersiz sayar. Yine sonsuz döngü — ama bu kez çerez sorunundan farklı olarak, gizli sekmede de düzelmez.

Nasıl ayırt edilir:

• Tüm eklentileri kapattığınızda (Adım 4) giriş çalışıyorsa ve tek tek açarken güvenlik eklentisinde bozuluyorsa teşhis kesindir.
• Eklentinin kendi tablosu (..._login_attempts, ..._sessions gibi) SHOW TABLE STATUS çıktısında "in use" veya bozuk görünüyorsa.

Çözüm sırası şudur: önce eklentiyi FTP'den kapatıp panele girin, sonra panelden yeniden etkinleştirin — çoğu eklenti etkinleşirken kendi tablolarını yeniden oluşturur. Düzelmezse eklentiyi silip temiz kurun; ayarları veritabanında kaldığı için genellikle geri gelir. Bu arada wp_usermeta tablosunda eklenti tarafından yazılmış artık oturum kayıtları da kalabilir:

SELECT user_id, meta_key
FROM wp_usermeta
WHERE meta_key = 'session_tokens';

Bu satırı kendi kullanıcınız için silmek, tüm cihazlardaki oturumlarınızı sonlandırır ve temiz bir başlangıç sağlar:

DELETE FROM wp_usermeta WHERE meta_key = 'session_tokens' AND user_id = 1;

user_id değerini kendi kullanıcı kimliğinizle değiştirin. Bu işlem parolanızı etkilemez, sadece açık oturumları temizler; bir sonraki girişte WordPress kaydı sıfırdan oluşturur.

Adım 6: IP Adresiniz Engellenmiş Olabilir#

Mobil veriyle girebiliyor ama kendi bağlantınızdan giremiyorsanız IP'niz engellenmiştir. Bunun üç ayrı kaynağı olabilir ve üçü farklı yerlerden çözülür:

Kendi IP'nizi öğrenmek için herhangi bir "IP adresim nedir" sorgusu yeterlidir. Ev bağlantılarında IP genellikle dinamiktir; modemi yeniden başlatmak yeni bir IP alarak engeli anında aşmanızı sağlayabilir — kalıcı çözüm değildir ama panele girip engeli kaldırmanız için yeterli süre kazandırır.

Engelleri kalıcı olarak yönetmek için cPanel'in IP Engelleyici ekranındaki listeyi gözden geçirmek gerekir; oraya yanlışlıkla eklenmiş bir aralık tüm ofisinizi dışarıda bırakabilir. Sunucu düzeyindeki güvenlik duvarına erişiminiz yoksa barındırma sağlayıcınıza IP'nizi bildirip listeden çıkarılmasını istemeniz gerekir.

Adım 7: Yönlendirme Döngüsü ve HTTPS#

Tarayıcı "ERR_TOO_MANY_REDIRECTS" veya "bu sayfa çalışmıyor, çok fazla yönlendirme yaptı" diyorsa, panele bile ulaşamıyorsunuz demektir. Sebep genellikle iki yönlendirme kuralının birbirini kovalamasıdır:

• .htaccess dosyasında hem www ekleyen hem kaldıran kural bulunması.
• SSL eklentisinin https'e yönlendirmesi ile sunucu tarafındaki yönlendirmenin çakışması.
• siteurl değeri http iken sunucunun her isteği https'e çevirmesi.

Hızlı test: kök dizindeki .htaccess dosyasının adını htaccess-eski yapın ve sayfayı yenileyin. Döngü durduysa suçlu o dosyadadır. WordPress'in varsayılan .htaccess 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

Dosyayı bu içerikle sıfırlayıp panele girdikten sonra Ayarlar > Kalıcı Bağlantılar ekranını açıp kaydete basın; WordPress kuralları yeniden yazar. Bu adım aynı zamanda yazı adreslerinin 404 vermesini de önler. Döngünün diğer tipik sebepleri için err too many redirects hatası yazısına bakabilirsiniz.

Adım 8: Kullanıcı Gerçekten Var mı#

"Kullanıcı adı geçersiz" uyarısı alıyorsanız, sorun parolada değil hesabın kendisindedir. Kullanıcı silinmiş, rolü değiştirilmiş ya da e-posta adresi değiştirilmiş olabilir. Bir saldırı sonrası ilk yapılan şeylerden biri de budur.

Kullanıcı listesini görmek için:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

Listede tanımadığınız yeni bir yönetici varsa durum ciddidir; bu bir güvenlik ihlali işaretidir. Rolleri kontrol etmek için:

SELECT u.user_login, m.meta_value
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities';

Çıktıda kendi kullanıcınızın karşısında administrator yazmıyorsa rolünüz düşürülmüştür. En temiz çözüm, SSH varsa WP-CLI ile yeni bir yönetici oluşturmaktır:

wp user create acilyonetici [email protected] --role=administrator --user_pass='UzunVeGucluParola'

Bu kullanıcıyla panele girip durumu düzelttikten sonra geçici hesabı silin. Tanımadığınız yönetici hesapları bulduysanız iş panele girmekle bitmez; tüm parolaları değiştirmeniz, güvenlik anahtarlarını yenilemeniz ve dosyaları taramanız gerekir.

Adım 9: Panel Açılıyor Ama Zaman Aşımına Düşüyor#

Bazen panel "girilmiyor" değil, çok yavaş olduğu için açılmıyordur. Ekran uzun süre beklettikten sonra 504 veya boş sayfa verir. Bu bir giriş sorunu değil, kaynak veya dış istek sorunudur.

En sık üç sebep:

1. Dış API'ye takılma. Bir eklenti lisans sunucusuna bağlanmaya çalışır, o sunucu cevap vermez ve her panel isteği zaman aşımına kadar bekler. Günlükte cURL error 28 görürsünüz.
2. wp_options tablosunun şişmesi. Silinmiş eklentilerden kalan autoload verisi her istekte çekilir.
3. Kaynak limiti. Paylaşımlı pakette eşzamanlı süreç sınırına takılırsınız; ön yüz önbellekten açılırken panel açılmaz.

cURL error 28 gördüğünüzde suçlu, son kurulan lisanslı eklentidir; onu geçici olarak kapatmak paneli anında hızlandırır. wp_options şişkinliğini ölçmek için:

SELECT COUNT(*) AS adet, ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS mb
FROM wp_options
WHERE autoload = 'yes';

Bu değerin birkaç megabaytı aşması, her sayfa yüklemesinde o veriyi çektiğiniz anlamına gelir ve paneli gözle görülür biçimde yavaşlatır. Genel panel yavaşlığını ölçmek ve nedenini ayırmak için gtmetrix wordpress hız testi yazısındaki yöntem işinizi görür.

Sıkça Sorulan Sorular#

Doğru şifreyi yazıyorum ama giriş ekranına geri dönüyorum neden#

Bu davranış neredeyse her zaman çerez sorunudur, parola sorunu değildir. WordPress girişi kabul eder, oturum çerezini yazar, ama tarayıcı o çerezi bir sonraki istekte geri göndermez ve sistem sizi tanımaz. En sık sebebi www'lu adresten giriş yapıp çerezin www'suz alan adına yazılmasıdır. Çözüm, siteurl ayarındaki adresle birebir aynı adresten giriş yapmak ve gerekiyorsa wp-config.php içinde COOKIE_DOMAIN tanımını sabitlemektir. Bir güvenlik eklentisinin oturum tablosunu bozması da aynı belirtiyi üretir.

wp-admin adresi beni başka bir siteye yönlendiriyor#

Bu durum veritabanındaki siteurl veya home değerinin değiştirilmiş olduğunu gösterir. Bir eklenti, tema veya çoğu zaman zararlı bir kod bu alanı kendi adresiyle değiştirdiğinde WordPress her isteği oraya yönlendirir. phpMyAdmin ile wp_options tablosundaki iki satırı doğru adresle güncelleyin ya da wp-config.php içine WP_HOME ve WP_SITEURL tanımlarını ekleyin; dosyadaki tanım veritabanındakini geçersiz kılar. Değeri düzelttikten sonra sitenin nasıl değiştirildiğini araştırın, çünkü aynı açık kapalı değilse birkaç gün içinde tekrarlar.

Panele girebilmek için tüm eklentileri kapatmak veri kaybettirir mi#

Hayır, eklentileri klasör adı değiştirerek kapatmak hiçbir ayarınızı silmez. Eklenti ayarları veritabanında wp_options tablosunda durur ve eklenti yeniden etkinleştirildiğinde olduğu gibi geri gelir. Kayıp riski yalnızca eklentiyi panelden silerseniz ve o eklenti kaldırılırken kendi verisini temizliyorsa doğar. Bu yüzden teşhis aşamasında silme değil, devre dışı bırakma yöntemi kullanılır; klasör adını geri aldığınızda her şey yerli yerindedir.

Yönetici kullanıcım silinmiş görünüyor ne yapmalıyım#

Öncelikle veritabanındaki wp_users tablosunu kontrol edip kullanıcının gerçekten silinip silinmediğini doğrulayın; bazen kullanıcı durur, sadece rolü aboneye düşürülmüştür. SSH erişiminiz varsa WP-CLI ile yeni bir yönetici hesabı oluşturmak en hızlı yoldur; yoksa phpMyAdmin üzerinden wp_users ve wp_usermeta tablolarına elle kayıt eklemek gerekir. Ancak tanımadığınız bir yönetici hesabı da görüyorsanız durum bir yetkisiz erişim olayıdır: tüm parolaları değiştirin, güvenlik anahtarlarını yenileyin ve dosyaları tarayın.

Çok fazla giriş denemesi yaptım ve engellendim süre beklemek zorunda mıyım#

Beklemek zorunda değilsiniz, engeli kaldırmanın birkaç yolu vardır. Engel bir güvenlik eklentisinden geliyorsa FTP ile o eklentinin klasör adını değiştirerek devre dışı bırakabilir, panele girip kendi IP'nizi beyaz listeye ekleyebilirsiniz. Engel sunucu güvenlik duvarından geliyorsa barındırma panelinizden ya da destek talebiyle kaldırılması gerekir. Geçici çözüm olarak farklı bir ağdan (mobil veri) bağlanmak veya modemi yeniden başlatarak yeni bir IP almak da işe yarar.

wp-admin yerine özel bir giriş adresi kullanıyordum ve unuttum#

Giriş adresini değiştiren eklenti devre dışı kaldığında adres varsayılan wp-login.php haline döner. Bu yüzden en pratik yol, FTP ile o eklentinin klasör adını geçici olarak değiştirip standart adresten giriş yapmaktır. Panele girdikten sonra eklentiyi tekrar etkinleştirip özel adresi ayarlar ekranından öğrenebilirsiniz. Adresi kalıcı olarak değiştirecekseniz bir yere kaydedin ve tercihen ekibinizden bir kişide daha bulunsun; tek kişinin hafızasında duran giriş adresi er geç bu soruna dönüşür.

Panel açılıyor ama çok yavaş ve sık sık zaman aşımına düşüyor#

Bu bir erişim sorunu değil performans sorunudur ve üç yerde aranır. Birincisi dış isteklerdir: bir eklentinin ulaşamadığı lisans veya güncelleme sunucusu her panel isteğini bekletir, günlükte cURL error 28 olarak görünür. İkincisi wp_options tablosundaki şişmiş otomatik yüklenen veridir; birkaç megabaytı aşması paneli belirgin biçimde yavaşlatır. Üçüncüsü paketin kaynak sınırıdır — ön yüz önbellekten hızlı açılırken panel her istekte PHP çalıştırdığı için önce o etkilenir.

Kapanış#

Panele girememek tek bir arıza değil, benzer görünen sekiz farklı arızanın ortak belirtisidir; bu yüzden çözümün anahtarı doğru sırayla elemektir. Gizli sekme testiyle tarayıcı tarafını kapatın, sonra çerez alan adı çakışmasına ve siteurl/home değerlerine bakın — bu iki neden tek başına vakaların büyük kısmını açıklar. Ardından eklenti/tema elemesi, güvenlik eklentisinin oturum kayıtları, IP engeli, yönlendirme döngüsü ve kullanıcı kaydı sırasıyla gelir. Bu sırayı takip ederseniz gereksiz yere veritabanına dokunmadan çözersiniz; sırayı atlayıp doğrudan SQL çalıştırmak ise düzelttiğinizden fazlasını bozma riskini taşır.

Bu kesintilerin çoğu, aslında panele erişimden önce alınacak önlemlerle hiç yaşanmaz: sabit bir kanonik adres, düzgün yapılandırılmış SSL, günlük yedek ve panele bir kullanıcı daha tanımlamak. Bu bakımı kendiniz yürütmek istemiyorsanız WordPress bakım hizmetimiz güncelleme, yedek ve güvenlik takibini üstlenir. Sitenizi hız ve kaynak açısından rahatlatmak istiyorsanız WordPress hosting paketleri bu iş yükü için yapılandırılmıştır; www/HTTPS yönlendirme karmaşasını kökten bitirmek için de doğru kurulmuş bir SSL sertifikası gerekir. Kötü bir günde geri dönebileceğiniz bir noktanız yoksa yedekleme çözümümüz en kritik güvencedir.