Site Adresini Yanlış Değiştirdim, Siteye Giremiyorum

Ayarlar → Genel ekranındaki "WordPress Adresi" veya "Site Adresi" kutusuna yanlış bir değer yazıp Kaydet'e bastınız ve sayfa yenilendiğinde ne site açılıyor ne de yönetim paneline girebiliyorsunuz. Tarayıcı ya boş bir sayfa gösteriyor, ya ERR_NAME_NOT_RESOLVED diyor, ya da sizi durmadan başka bir adrese fırlatıp "çok fazla yönlendirme" hatası veriyor. WordPress site adresi yanlış girildiğinde ortaya çıkan bu tablo, kullanıcının panelden geri alma şansını da elinden aldığı için gerçekten kilitleyicidir: değeri düzeltmek için girmeniz gereken ekran, tam olarak o değer yüzünden erişilemez durumdadır.

Bu yazı o kısır döngüyü kırmanın iki ayrı yolunu, hangisinin geçici hangisinin kalıcı olduğunu ayırt ederek anlatıyor. Yıllardır gördüğüm en yaygın senaryo şu: kullanıcı bir forum başlığından wp-config.php'ye WP_HOME ve WP_SITEURL satırlarını ekliyor, site açılıyor, mesele kapandı sanıyor. Oysa o iki satır veritabanındaki bozuk değeri düzeltmez, sadece üzerini örter — ve dururken Ayarlar ekranındaki iki kutu gri (düzenlenemez) görünür, üstelik sunucu ya da alan adı değişince sorun bir kat daha karışık biçimde geri döner. Aşağıda önce erişimi hızlıca geri açacağız, sonra kaydı gerçekten düzelteceğiz, en sonunda da düzeltmenin ardından geriye kalan permalink, karışık içerik ve yönlendirme artıklarını temizleyeceğiz.

Site Adresi ve WordPress Adresi Alanları Ne İşe Yarar#

Bu iki alan aynı şey değildir ve karışmaları hatanın yarısıdır. Veritabanında wp_options tablosunda iki ayrı satır olarak durur:

Çoğu kurulumda ikisi de birebir aynıdır. Farklılaştıkları tek yaygın durum, WordPress'in /blog gibi bir alt dizine kurulup ana sayfanın kök dizinden sunulmasıdır. siteurl yanlışsa yönetim paneli komple gider; home yanlışsa panele girebiliyor ama ziyaretçi tarafı yanlış adrese savruluyor olabilirsiniz. Hangi alanı bozduğunuzu hatırlamıyorsanız endişelenmeyin — birazdan ikisini birden okuyup düzelteceğiz.

Önemli bir ayrıntı: WordPress bu değerleri sadece bağlantı üretmek için kullanmaz. Tema ve eklenti dosyalarının (CSS, JavaScript) adresi, medya kütüphanesindeki görsellerin adresi, giriş formunun gönderim hedefi, REST API'nin kök adresi — hepsi siteurl üzerinden kurulur. Bu yüzden tek harflik bir yazım hatası sitenin tamamını tanınmaz hale getirir.

Yanlış Adres Girildiğinde Tam Olarak Ne Oluyor#

Gördüğünüz belirti, yaptığınız hatanın türünü ele verir. Aşağıdaki tablo sahada en sık karşılaştığım eşleşmeler:

Son satır özellikle can sıkıcıdır. Adresi bir Word belgesinden veya sohbet penceresinden kopyalayıp yapıştırdıysanız sonuna görünmez bir boşluk ya da ​ (sıfır genişlikli boşluk) takılmış olabilir. Panelde bakınca değer doğru görünür; veritabanında SELECT çektiğinizde tırnaklar arasındaki fazlalık ortaya çıkar.

Bir de klasik yanlış anlama var: WordPress bu alana yazdığınız adresi doğrulamaz. Alan adının size ait olup olmadığına, DNS'te çözülüp çözülmediğine, sertifikanın kurulu olup olmadığına bakmaz. Ne yazarsanız onu kaydeder. Bu yüzden "acaba yanlış mı yazdım" diye tereddüt ettiğiniz an, Kaydet'e basmadan önce adresi ayrı bir sekmede açıp denemek en ucuz sigortadır.

Hızlı Yama: wp-config.php ile Erişimi Geri Açma#

En hızlı çözüm, veritabanındaki değeri geçersiz kılan iki sabiti wp-config.php dosyasına eklemektir. Dosyaya hosting panelinizin Dosya Yöneticisi'nden veya FTP ile ulaşabilirsiniz; cPanel kullanıyorsanız cPanel Dosya Yöneticisi üzerinden düzenlemek en pratiğidir.

1. public_html (veya WordPress'in kurulu olduğu dizin) içindeki wp-config.php dosyasını bulun.
2. Düzenlemeden önce bir kopyasını indirin. Bu dosya veritabanı bilgilerini taşır; bozarsanız site tamamen kapanır.
3. Dosyayı düzenleyin ve aşağıdaki iki satırı, /* That's all, stop editing! */ yorumunun üstüne ekleyin:

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

4. Kaydedin ve tarayıcı önbelleğini temizleyerek https://ornek.com/wp-admin adresini açın.

Bu değişiklik anında etkilidir çünkü WordPress bu sabitler tanımlıysa wp_options tablosunu hiç okumaz. Alan adınızın sonunda eğik çizgi olmamalı ve protokol (http / https) sitede gerçekten çalışan protokol olmalı. Sertifikanız yoksa https yazmayın; önce http ile girip düzeltmeleri yapın, sertifikayı sonra devreye alın.

⚠️ Şunu net söyleyelim: bu bir yamadır, çözüm değildir. Bu satırlar dosyada durduğu sürece Ayarlar → Genel ekranındaki iki kutu gri görünür ve "Bu ayar wp-config.php dosyasında tanımlandığı için değiştirilemez" davranışı sergiler. Çoğu Türkçe kaynak burada duruyor; oysa asıl mesele, veritabanındaki bozuk değerin hâlâ orada oturuyor olması. Bir gün alan adınızı değiştirdiğinizde, siteyi başka sunucuya taşıdığınızda ya da bu satırları temizlediğinizde eski bozuk değer geri döner ve aynı krizi ikinci kez yaşarsınız.

Kalıcı Çözüm: Veritabanında siteurl ve home Değerlerini Düzeltme#

Kalıcı düzeltme wp_options tablosundaki iki satırı doğrudan değiştirmekten geçer. phpMyAdmin, hemen her hosting panelinde hazır gelir; kullanımına hiç aşina değilseniz phpMyAdmin kullanımı yazısı arayüzü ayrıntılı anlatıyor.

Adımlar:

1. Hosting panelinizde phpMyAdmin'i açın.
2. Doğru veritabanını seçin. Hangisi olduğundan emin değilseniz wp-config.php içindeki DB_NAME satırına bakın.
3. Sol menüden wp_options tablosuna tıklayın. Tablo öneki farklı olabilir — güvenlik için wp_ yerine wpxk_ gibi rastgele bir önek kullanılmış olabilir. wp-config.php içindeki $table_prefix değeri hangisiyse tablo o öneki taşır.
4. Üstteki SQL sekmesine geçin ve önce mevcut değerleri okuyun:

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

Çıktı şuna benzer görünür:

+-----------+-------------+--------------------------+
| option_id | option_name | option_value             |
+-----------+-------------+--------------------------+
|         1 | siteurl     | https://ornek.comm       |
|         2 | home        | https://ornek.comm       |
+-----------+-------------+--------------------------+

Hatayı gözünüzle görün — bu adım atlanmamalı. Değerin sonunda boşluk olup olmadığını anlamak için şunu da çalıştırabilirsiniz:

SELECT option_name, CONCAT('[', option_value, ']') AS gorunur
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Köşeli parantezler arasında fazladan boşluk görünüyorsa sorununuz yazım hatası değil, kopyalama artığıdır.

5. Şimdi düzeltin:

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

6. wp-config.php dosyasına eklediğiniz WP_HOME / WP_SITEURL satırlarını silin. Silmezseniz veritabanındaki düzeltmenin çalışıp çalışmadığını asla test edemezsiniz, çünkü sabitler her zaman kazanır. Silin, sayfayı yenileyin; site hâlâ açılıyorsa düzeltme tutmuş demektir. Açılmıyorsa satırları geri koyup SQL adımını yeniden gözden geçirin.

7. Panele girin, Ayarlar → Genel ekranını açın. İki kutu artık düzenlenebilir olmalı ve doğru adresi göstermeli. Kutular hâlâ griyse wp-config.php'de bir yerde o sabitler duruyordur; dosyada arama yapın, bazı tema veya güvenlik eklentileri de bu satırları ekleyebiliyor.

Veritabanı bilgilerini bulamıyorsanız#

phpMyAdmin'e girerken kullanıcı adı/parola isteniyorsa bunlar wp-config.php içindeki DB_USER ve DB_PASSWORD değerleridir. Çoğu paylaşımlı hosting panelinde phpMyAdmin bağlantısı zaten oturum açmış olarak gelir, ayrıca bilgi girmeniz gerekmez.

WP-CLI ile Tek Komutta Düzeltme#

Sunucunuzda SSH erişimi ve WP-CLI varsa iş iki satıra iner. VDS ya da sunucu erişimi olanlar için en temiz yol budur; WP-CLI kullanımı yazısında kurulumu anlatılıyor.

cd /home/kullanici/public_html
wp option get siteurl
wp option get home

Yanlış değerleri gördükten sonra:

wp option update siteurl 'https://ornek.com'
wp option update home 'https://ornek.com'
wp cache flush

WP-CLI'nin güzel yanı, --skip-plugins --skip-themes bayraklarıyla bozuk bir eklentinin araya girmesini de engelleyebilmenizdir:

wp option update siteurl 'https://ornek.com' --skip-plugins --skip-themes

Komut Success: Updated 'siteurl' option. çıktısı veriyorsa iş tamamdır. Error: Error establishing a database connection alıyorsanız sorununuz adres değil veritabanı bağlantısıdır; o ayrı bir konudur.

Gövde İçindeki Eski Adresleri Temizleme#

siteurl ve home düzeldi ama sitede hâlâ kırık görseller, çalışmayan iç bağlantılar görüyorsanız sebebi şudur: yazı gövdelerine, menülere, widget'lara ve eklenti ayarlarına gömülü eski adresler wp_options düzeltilince kendiliğinden değişmez.

Burada çok kritik bir tuzak var. Aklınıza gelen ilk çözüm muhtemelen şudur:

UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://eski.com', 'https://ornek.com');

Bu komut wp_posts tablosunda genelde sorunsuz çalışır. Ama aynı mantığı wp_options veya wp_postmeta tablolarına uygularsanız siteyi bozarsınız. Sebep: bu tablolarda veriler PHP'nin serialize() biçiminde saklanır ve o biçim her metnin uzunluğunu da içinde tutar:

a:1:{s:9:"site_logo";s:31:"https://eski.com/logo.png";}

Buradaki s:31 "31 karakterlik dizge" demektir. Adresi kısaltan veya uzatan bir REPLACE uzunluk sayısını güncellemez, veri bozulur ve o ayar sessizce kaybolur. Doğru yöntem serileştirmeyi anlayan bir araç kullanmaktır:

wp search-replace 'https://eski.com' 'https://ornek.com' --all-tables --dry-run

--dry-run ile önce kaç satırın etkileneceğini görün, doğruysa bayrağı kaldırıp tekrar çalıştırın. WP-CLI'niz yoksa aynı işi yapan "Better Search Replace" türü eklentiler de serileştirmeyi doğru işler — ama panele girebiliyor olmanız gerekir, ki bu noktada girebiliyor olmalısınız.

Alan adının tamamen değiştiği daha geniş senaryo için WordPress alan adı değiştirme yazısı adım adım süreci ele alıyor.

Düzelttikten Sonra Kalan Artıklar#

Adres düzeldikten sonra sık karşılaşılan üç yan etki var ve üçü de birkaç dakikada çözülür.

Bağlantılar 404 veriyor. Ana sayfa açılıyor ama alt sayfalar "bulunamadı" diyorsa kalıcı bağlantı kuralları eskiyi işaret ediyordur. Ayarlar → Kalıcı Bağlantılar ekranını açıp hiçbir şey değiştirmeden Değişiklikleri Kaydet'e basmak .htaccess kurallarını yeniden yazar. Ayrıntı için WordPress kalıcı bağlantı ayarları.

Karışık içerik uyarısı. Adres http iken https yaptıysanız tarayıcı konsolunda "Mixed Content" uyarıları görürsünüz; kilit simgesi görünmez. Görsellerin adresi hâlâ http:// ile başlıyordur. Yukarıdaki search-replace işlemini http://ornek.com → https://ornek.com olarak bir kez daha çalıştırmak yeter. Zorlama kurallarını da eklemek isterseniz HTTPS yönlendirme yazısına bakın.

Yönlendirme döngüsü. home www'suz, siteurl www'lu (ya da tersi) kaldıysa tarayıcı iki adres arasında sonsuz gidip gelir. İkisini de birebir aynı yazın; www tercihi ayrı bir konudur ve sunucu tarafındaki tek bir yönlendirme kuralıyla halledilir.

Sık Yapılan Hatalar ve Kaçınma Yolları#

• Sonuna eğik çizgi koymak. https://ornek.com/ değil https://ornek.com yazın. Çizgi çift eğik çizgili bağlantılara yol açar.
• Sertifika yokken https yazmak. Sertifika kurulu değilse tarayıcı sayfayı açmadan engeller. Önce sertifikayı kurun, sonra adresi güncelleyin.
• Yalnızca birini değiştirmek. home ile siteurl arasındaki uyumsuzluk döngüye sebep olur; ikisi de aynı anda güncellenmeli.
• Yedek almadan SQL çalıştırmak. UPDATE komutunun geri alma tuşu yoktur. phpMyAdmin'de tabloyu Dışa Aktar ile bir .sql dosyasına almak on saniye sürer.
• Yamayı kalıcı sanmak. wp-config.php satırları geçici köprüdür; veritabanını düzeltmeden bırakmak sorunu geleceğe ertelemektir.

Bu tür kazaların bir daha aynı paniği yaşatmaması için düzenli otomatik yedek çok işe yarar; kurulum mantığı için WordPress yedekleme yazısına göz atın. Panelinize giriş adresini gizleyerek yanlışlıkla yapılan değişiklikleri de sınırlayabilirsiniz — WordPress giriş URL gizleme bunun için.

Sıkça Sorulan Sorular#

Site adresini yanlış yazdım, yedeğim yok, verilerim gitti mi#

Hayır, verileriniz yerinde duruyor. Yanlış adres yalnızca wp_options tablosundaki iki metin satırını değiştirir; yazılarınız, sayfalarınız, medya dosyalarınız ve kullanıcı hesaplarınız hiç etkilenmez. Site erişilemez görünse bile dosyalar sunucuda, kayıtlar veritabanında olduğu gibi durur. Bu yüzden bu sorun veri kaybı değil, yalnızca yönlendirme sorunudur ve doğru değeri geri yazdığınız an her şey eski haline döner.

wp-config.php'ye eklediğim WP_HOME satırlarını silmek zorunda mıyım#

Kalıcı ve temiz bir kurulum istiyorsanız evet. O satırlar dururken WordPress veritabanındaki değeri hiç okumaz, yani gerçek sorun düzeltilmemiş halde kalır ve Ayarlar → Genel ekranındaki iki alan gri görünür. Sunucu değişikliği, alan adı taşıması ya da bir eklentinin bu dosyayı yeniden yazması gibi durumlarda eski bozuk değer aniden geri döner. Doğru sıra şudur: satırlarla erişimi aç, veritabanını düzelt, sonra satırları sil ve sitenin hâlâ çalıştığını doğrula.

phpMyAdmin'de wp_options tablosunu göremiyorum#

Tablo öneki varsayılan wp_ olmayabilir. WordPress kurulumu sırasında güvenlik için wpab3_ gibi rastgele bir önek seçilmiş olabilir ve o zaman tablonun adı wpab3_options olur. Doğru öneki wp-config.php dosyasındaki $table_prefix satırından okuyabilirsiniz. Ayrıca sunucuda birden fazla WordPress kurulu olabilir; soldaki listede birden çok veritabanı görüyorsanız wp-config.php içindeki DB_NAME değeriyle eşleşeni seçtiğinizden emin olun.

Adresi düzelttim ama site hâlâ eski adrese yönlendiriyor#

Büyük ihtimalle üç kaynaktan biri devrede: tarayıcı önbelleği, bir önbellek eklentisinin ürettiği statik dosyalar ya da .htaccess içinde kalmış eski bir yönlendirme kuralı. Önce tarayıcıyı gizli sekmede deneyin; orada düzgün açılıyorsa sorun önbellektir. Değilse .htaccess dosyasını açıp WordPress'in kendi blok'u dışındaki Redirect veya RewriteRule satırlarını kontrol edin. Bazı güvenlik ve önbellek eklentileri de kendi yönlendirmesini yazar; erişebiliyorsanız eklentileri geçici olarak kapatıp tekrar deneyin.

SQL komutu çalıştırmadan bu işi yapmanın yolu var mı#

Var, phpMyAdmin'de tabloyu tarayıcı arayüzünden düzenleyebilirsiniz. wp_options tablosunu açın, üstteki arama kutusuna siteurl yazıp aratın, çıkan satırın solundaki Düzenle bağlantısına tıklayın ve option_value alanını elle düzeltip Git'e basın. Aynı işlemi home satırı için tekrarlayın. SQL yazmaktan daha güvenlidir çünkü yanlışlıkla tüm tabloyu güncelleme riski yoktur; yalnızca daha yavaştır.

Yerelden canlıya taşıdım, adres localhost kaldı, aynı yöntem geçerli mi#

Evet, siteurl ve home düzeltmesi aynen geçerlidir; ancak yerelden taşımada bu iki satır tek başına yetmez. Yazı gövdelerinde, menü öğelerinde, eklenti ayarlarında ve medya kayıtlarında http://localhost/proje gibi yüzlerce gömülü adres kalmıştır. Bunları temizlemek için serileştirmeyi anlayan bir arama-değiştirme aracı kullanmak zorundasınız, düz SQL REPLACE komutu wp_options ve wp_postmeta tablolarında veriyi bozar. WP-CLI'nin search-replace komutu ya da eşdeğer bir eklenti bu iş için doğru araçtır.

Panelde alanlar gri görünüyor ve tıklayamıyorum, neden#

Bu, wp-config.php dosyasında WP_HOME ve WP_SITEURL sabitlerinin tanımlı olduğunun kesin işaretidir. WordPress bu sabitler varken alanları salt okunur gösterir, çünkü panelden yapılacak bir değişikliğin hiçbir etkisi olmayacaktır. Dosyayı açıp o iki satırı silin ve sayfayı yenileyin; alanlar tekrar düzenlenebilir hale gelir. Silmeden önce veritabanındaki değerlerin doğru olduğundan emin olun, aksi halde satırları sildiğiniz an site yeniden erişilemez olur.

Kapanış#

Yanlış yazılmış bir site adresi, verdiği panik hissiyle kıyaslandığında şaşırtıcı derecede basit bir sorundur: iki satırlık bir metin alanının içeriği bozulmuştur, o kadar. Kurtarmanın mantığı da hep aynı sıradadır — önce wp-config.php sabitleriyle kapıyı arala, sonra wp_options tablosundaki siteurl ve home değerlerini gerçekten düzelt, en sonunda geçici sabitleri kaldırıp permalink ile karışık içerik artıklarını temizle. Bu üç adımı atlamadan uygularsanız hem site geri gelir hem de aynı hata gelecekte ikinci kez patlamaz.

Bu tür kazaları tek başınıza göğüslemek istemiyorsanız, WordPress'in çalıştığı zemin de işin bir parçasıdır. Günlük otomatik yedek, tek tıkla geri dönüş ve phpMyAdmin'in hazır geldiği bir ortam için WordPress hosting paketleri bu senaryoları düşünerek kurgulanmıştır; güncelleme, yedek ve kurtarma işlerini bir uzmanın üstlenmesini isterseniz WordPress bakım hizmeti tam olarak bunu yapar. Sitenizi başka bir sunucuya taşırken adres kaynaklı bu sorunlarla uğraşmamak için site taşıma hizmetine bakabilir, düzenli yedek altyapısını ayrı bir katman olarak kurmak isterseniz yedekleme çözümlerini inceleyebilirsiniz.