WordPress Sitesinin Alan Adı Nasıl Değiştirilir

Marka değiştirdiniz, .com.tr uzantısına geçtiniz ya da deneme amaçlı aldığınız adresten gerçek alan adına taşınıyorsunuz. WordPress alan adı değiştirme işlemi ilk bakışta iki alanı düzenlemekten ibaret görünür: Ayarlar > Genel altındaki "WordPress Adresi" ve "Site Adresi". Gerçekte ise eski alan adınız veritabanının onlarca farklı yerine gömülüdür — görsel yollarında, iç bağlantılarda, menü kayıtlarında, sayfa oluşturucuların serileştirilmiş verilerinde, eklenti ayarlarında. O iki alanı değiştirip işi bitmiş sanan herkesin karşılaştığı manzara aynıdır: yazılar açılıyor ama tüm görseller kırık, sayfa oluşturucuyla yapılan sayfalar bomboş.

Bu yazıda alan adı değişimini baştan sona, doğru sırayla anlatacağım. Veritabanındaki eski adresleri neden basit bir SQL REPLACE ile değiştiremeyeceğinizi — serileştirilmiş veriyi bozduğu için — somut örnekle göstereceğim, doğru araçları ve komutlarını vereceğim, eski alan adından yeni alan adına 301 yönlendirmeyi hem Apache hem Nginx tarafında kuracağız ve arama motoru değerinizi korumak için sonrasında yapılması gerekenleri listeleyeceğiz. Bu işlemin geri dönüşü yedekten dönmekten ibarettir; o yüzden ilk bölümü atlamayın.

Başlamadan Önce: Yedek, DNS ve SSL Hazırlığı#

Alan adı değişimi tek adımlık bir işlem değil, üç ayrı katmanı ilgilendiren bir geçiştir: alan adı (DNS), sunucu yapılandırması (sanal host, SSL) ve WordPress (veritabanı + dosyalar). Sıralamayı bozarsanız site bir süre erişilemez kalır.

Başlamadan önce şunları tamamlayın:

1. Tam yedek alın. Dosyalar ve veritabanı ayrı ayrı. Veritabanı yedeğini komut satırından almak en güvenlisidir:

mysqldump -u kullanici -p --single-transaction --default-character-set=utf8mb4 \
  veritabani_adi > /home/kullanici/yedek-$(date +%F).sql

Yedek alma yöntemlerinin ayrıntısı için mysqldump-ile-veritabani-yedekleme yazısına bakabilirsiniz. Panelden alıyorsanız cPanel > Yedekleme ekranındaki "Ev Dizini" ve "MySQL Veritabanları" indirmelerinin ikisini birden alın.

2. Yeni alan adını sunucuya tanıtın. Paylaşımlı hostingde bu, yeni alan adını ana alan adı yapmak ya da park/addon olarak eklemek demektir; cPanel tarafındaki ayrımı addon-parked-domain-cpanel yazısında anlattık.

3. DNS kayıtlarını hazırlayın. Yeni alan adının A kaydı sunucunuzun IP adresine bakmalı. Değişikliğin yayılması zaman alır; propagasyon-suresi-dns yazısındaki TTL mantığını bilerek planlayın. Geçişten bir gün önce TTL değerini düşürmek, dönüş gerekirse elinizi rahatlatır.

4. SSL sertifikasını yeni alan adı için hazırlayın. Eski sertifika yeni alan adını kapsamaz; adres değiştiği anda tarayıcı güvenlik uyarısı verir. Otomatik sertifika kullanıyorsanız DNS doğru yönlendikten sonra kendiliğinden düzenlenir ama bu birkaç dakika sürebilir.

Sadece Ayarlar Ekranından Değiştirirseniz Ne Olur#

WordPress Ayarlar > Genel ekranındaki iki alan yalnızca wp_options tablosundaki siteurl ve home satırlarını günceller. Bu iki satır sitenin "ben neredeyim" bilgisidir; içeriğin kendisine dokunmaz.

Değişiklik sonrası yerinde kalan eski adresler şunlardır:

Tablodaki "serileştirilmiş" ibaresi olan satırlar, işin asıl zor kısmıdır. Bir sonraki bölüm tam olarak bunu açıklıyor.

Serileştirilmiş Veri Neden Basit SQL REPLACE'i Bozar#

Doğrudan UPDATE ... REPLACE() sorgusu çalıştırmayın; serileştirilmiş verinin uzunluk bilgisini bozar ve o veri kalıcı olarak okunamaz hale gelir.

PHP, dizi ve nesneleri veritabanında saklarken serileştirir. Serileştirilmiş bir metin, her dizenin uzunluğunu kendi içinde yazar:

// theme_mods_tema içindeki bir kayıt
a:1:{s:4:"logo";s:34:"https://eskisite.com/logo.png";}

Buradaki s:34: ifadesi, "sonraki dize 34 karakterdir" demektir. Şimdi klasik yanlış sorguyu çalıştıralım:

-- ⚠️ BU SORGUYU ÇALIŞTIRMAYIN
UPDATE wp_options
SET option_value = REPLACE(option_value, 'eskisite.com', 'yenisite.com.tr');

Sonuç şu olur:

a:1:{s:4:"logo";s:34:"https://yenisite.com.tr/logo.png";}

Dizenin gerçek uzunluğu artık 37, ama başında hâlâ s:34: yazıyor. PHP bu veriyi unserialize() ile okumaya çalıştığında uyuşmazlık nedeniyle false döner ve WordPress o ayarın hiç var olmadığını varsayar. Belirtisi şudur: logonuz kaybolur, tema özelleştirmeleri sıfırlanır, sayfa oluşturucu ile yapılmış sayfa bomboş açılır, widget alanları boşalır. Üstelik hata mesajı görmezsiniz — veri sessizce yok sayılır.

Aynı tuzak yalnızca uzunluğu değişen değişimlerde patlar. eskisite.com yerine tam aynı karakter sayısında bir adres yazarsanız sorun çıkmaz; ama pratikte bu neredeyse hiç olmaz. Bu yüzden alan adı değişiminde serileştirmeyi anlayan bir araç kullanmak zorunludur: araç veriyi açar, içindeki dizeleri değiştirir, uzunlukları yeniden hesaplar ve tekrar serileştirir.

Doğru Yöntem: WP-CLI ile search-replace#

Sunucuya SSH erişiminiz varsa en temiz yol WP-CLI'dır. Serileştirilmiş veriyi doğru işler, çalıştırmadan önce kuru prova imkânı verir.

Önce kuru prova yapın — hiçbir şeyi değiştirmez, sadece kaç satırın etkileneceğini gösterir:

cd /home/kullanici/public_html

wp search-replace 'https://eskisite.com' 'https://yenisite.com.tr' \
  --all-tables-with-prefix --dry-run --report-changed-only

Çıktı, tablo tablo kaç değişiklik yapılacağını listeler. Sayılar makul görünüyorsa --dry-run parametresini kaldırıp gerçek işlemi çalıştırın:

wp search-replace 'https://eskisite.com' 'https://yenisite.com.tr' \
  --all-tables-with-prefix --report-changed-only

# www'lu ve protokolsüz kalıntılar için ikinci ve üçüncü tur
wp search-replace 'https://www.eskisite.com' 'https://yenisite.com.tr' --all-tables-with-prefix
wp search-replace '//eskisite.com' '//yenisite.com.tr' --all-tables-with-prefix

Üç ayrı tur çalıştırmanın nedeni şudur: eski adres içerikte https://, https://www. ve protokolsüz // biçimlerinde geçmiş olabilir. Tek bir arama hepsini yakalamaz.

Birkaç önemli ayrıntı:

• --all-tables-with-prefix, eklentilerin kendi oluşturduğu tabloları da kapsar. Sadece --all-tables kullanmak, aynı veritabanında başka bir kurulum varsa ona da dokunur; ön ekli sürüm daha güvenlidir.
• Çok siteli kurulumda --network ve --url parametreleri gerekir; tek site yapısına göre farklı çalışır.
• İşlem bittiğinde kalıcı bağlantı kurallarını yenileyin:

wp rewrite flush --hard
wp cache flush

WP-CLI Yoksa: Eklenti veya Betikle Değiştirme#

SSH erişimi olmayan paylaşımlı hosting kullanıcıları için iki seçenek var.

Seçenek 1 — Arama/değiştirme eklentisi. WordPress deposundaki arama-değiştirme eklentileri de serileştirmeyi doğru işler. Kullanım sırası:

1. Eklentiyi kurup etkinleştirin.
2. Önce "kuru çalıştırma" seçeneğiyle deneyin, etkilenen satır sayısını görün.
3. Tabloları seçerken hepsini işaretleyin, GUID sütununu değiştirmeyin (aşağıya bakın).
4. Gerçek işlemi çalıştırın.
5. Eklentiyi silin. Bu tür araçlar sitede sürekli durmamalı; yanlış elde tüm veritabanını yeniden yazabilir.

Seçenek 2 — Bağımsız değiştirme betiği. Sunucuya tek dosyalık bir arama/değiştirme betiği yükleyip tarayıcıdan çalıştırırsınız. Bu yöntemde iki kural var: işlem bitince dosyayı mutlaka silin ve dosya adını tahmin edilemez yapın. Sunucuda unutulan böyle bir dosya, veritabanınızı isteyen herkese açık bırakır.

GUID sütununa dokunmayın. wp_posts.guid alanı bir adres gibi görünse de RSS okuyucular için benzersiz kimlik olarak kullanılır. Değiştirirseniz tüm yazılarınız abonelerin akışında yeniden "yeni" olarak görünür. WP-CLI bu sütunu varsayılan olarak atlar; eklenti kullanıyorsanız GUID kutusunu işaretlemeyin.

wp-config.php ile Geçici Zorlama#

Adres değişikliği sırasında panele giremez hale gelirseniz — özellikle eski adres artık çözülmüyorsa — wp-config.php üzerinden adresi zorlayabilirsiniz:

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

Bu iki tanım veritabanındaki değerleri geçersiz kılar ve panele girmenizi sağlar. Ancak kalıcı çözüm değildir: bu satırlar duruyorken Ayarlar > Genel ekranındaki alanlar gri görünür ve düzenlenemez. Veritabanı değişimini tamamladıktan sonra satırları kaldırın. Yanlış adres girip paneli tamamen kaybettiyseniz wordpress-site-adresi-yanlis-degistirildi yazısındaki kurtarma adımları bu durumu ayrıntılı ele alıyor.

Eski Alan Adından 301 Yönlendirme Kurma#

Bu adım SEO açısından en kritik olanıdır. Eski alan adına gelen ziyaretçiyi ve arama motoru botunu, aynı sayfanın yeni adresine kalıcı (301) olarak yönlendirmeniz gerekir. Herkesi ana sayfaya atmak yaygın bir hatadır ve derin sayfaların birikmiş değerini çöpe atar.

Eski alan adı hâlâ sizde ve aynı sunucuya bakıyorsa, Apache tarafında .htaccess dosyasının en üstüne şunu ekleyin:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?eskisite\.com$ [NC]
RewriteRule ^(.*)$ https://yenisite.com.tr/$1 [R=301,L]
</IfModule>

$1 yakalaması sayesinde eskisite.com/hizmetler/bakim adresi yenisite.com.tr/hizmetler/bakim adresine gider; yol korunur. Nginx kullanıyorsanız eski alan adı için ayrı bir sunucu bloğu açmak en temizidir:

server {
    listen 80;
    listen 443 ssl;
    server_name eskisite.com www.eskisite.com;

    ssl_certificate     /etc/letsencrypt/live/eskisite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/eskisite.com/privkey.pem;

    return 301 https://yenisite.com.tr$request_uri;
}

Dikkat edilecek üç nokta:

• Eski alan adının SSL sertifikası çalışmaya devam etmeli. https://eskisite.com adresine gelen bir ziyaretçi sertifika hatası görürse yönlendirme hiç çalışmaz; tarayıcı uyarı ekranında durur.
• Yönlendirme 301 olmalı, 302 değil. 302 geçici demektir ve arama motoru eski adresi indekste tutmaya devam eder.
• Eski alan adını en az bir yıl elinizde tutun. Yönlendirme, alan adı süresi dolduğu gün biter ve o güne kadar biriken bağlantı değeri kaybolur.

Yönlendirme kurallarının farklı biçimleri ve zincir yönlendirme tuzakları için htaccess-yonlendirme ve wordpress-301-yonlendirme yazılarına bakabilirsiniz.

Değişim Sonrası Kontrol Listesi#

Adres değişti, yönlendirme kuruldu. Şimdi tek tek doğrulayın:

1. Kalıcı bağlantıları yenileyin. Ayarlar > Kalıcı Bağlantılar ekranını açıp hiçbir şey değiştirmeden Kaydet'e basın. Bu, .htaccess kurallarını yeniden yazar. Yazılar 404 veriyorsa ilk bakılacak yer burasıdır; wordpress-permalink-ayarlari yazısı ayrıntısını veriyor.
2. Karışık içerik kontrolü yapın. Tarayıcı konsolunda Mixed Content uyarısı varsa bir yerde hâlâ eski adres veya http:// kalmıştır.
3. Sitemap dosyasını yenileyin. SEO eklentiniz sitemap'i yeniden üretmeli ve içindeki tüm adresler yeni alan adında olmalı; wordpress-xml-sitemap yazısı kontrol yöntemini anlatıyor.
4. Search Console'da yeni mülkü doğrulayın ve adres değiştirme aracını kullanın. Yeni mülkü henüz eklemediyseniz google-search-console-kurulumu yazısındaki adımları izleyin.
5. E-posta ve MX kayıtlarını unutmayın. Alan adı değişti ama e-posta hesaplarınız eski alan adındaysa, yeni alan adında hesapları açıp yönlendirme kurmanız gerekir.
6. Ödeme ve dış servis panellerini güncelleyin. Sanal POS, kargo entegrasyonu, e-posta pazarlama aracı ve reklam hesaplarındaki alan adı tanımlarını değiştirin; bunların çoğu alan adı doğrulaması yapar ve sessizce çalışmayı bırakır.
7. Türkçe karakter kontrolü. Veritabanı üzerinde toplu işlem yapıldıktan sonra karakter seti sorunları görünür hale gelebilir; belirtiler ve çözümü için wordpress-turkce-karakter-sorunu yazısına bakın.

Sık Yapılan Hatalar#

Bu işlemde en çok gördüğüm dört hata şunlar:

• Yedek almadan başlamak. Serileştirilmiş veri bozulduğunda geri dönüş yolu yalnızca yedektir; onarım gibi bir şansınız yoktur.
• Doğrudan phpMyAdmin'den SQL REPLACE çalıştırmak. Yukarıda anlattığımız uzunluk bozulmasının tek sebebi budur.
• Yönlendirmeyi ana sayfaya yapmak. eskisite.com/urun/x adresini yenisite.com.tr ana sayfasına atmak, o sayfanın arama sonucundaki yerini sıfırlar.
• Eski alan adını bırakmak. Yenileme yapılmayan alan adı başkasına geçebilir; hem yönlendirmeniz biter hem de eski bağlantılarınız başka bir siteye gider.

Bu işlemin tamamı yerine siteyi baştan yeni bir ortama taşımayı düşünüyorsanız, dosya ve veritabanını birlikte taşımayı anlatan wordpress-manuel-site-tasima yazısı sürecin diğer yarısını kapsıyor.

Sıkça Sorulan Sorular#

WordPress alan adı değiştirince SEO değerim kaybolur mu#

Doğru yapılırsa kayıp minimal olur, yanlış yapılırsa ciddi kayıp yaşarsınız. Değerin korunması için iki şart var: eski adresten yeni adrese sayfa bazlı 301 yönlendirme kurmak ve eski alan adını en az bir yıl elinizde tutmak. Arama motorları yeni adresi yeniden taramak ve sıralamayı aktarmak için zamana ihtiyaç duyar; bu süreçte trafikte geçici bir dalgalanma normaldir. Search Console'daki adres değiştirme aracını kullanmak bu süreci hızlandırır.

Sadece Ayarlar ekranındaki iki adresi değiştirmek yeterli mi#

Hayır, yeterli değildir ve tek başına yapılırsa sitenin görünümü bozulur. O iki alan yalnızca WordPress'in kendi adres bilgisini günceller; yazı içeriklerine, medya yollarına, menü bağlantılarına ve eklenti ayarlarına gömülü eski adresler olduğu gibi kalır. Sonuç genelde şudur: sayfalar açılır ama görseller kırık görünür ve sayfa oluşturucuyla yapılmış tasarımlar boş gelir. Veritabanı genelinde serileştirmeye uygun bir arama/değiştirme işlemi mutlaka yapılmalıdır.

phpMyAdmin üzerinden SQL REPLACE ile değiştirebilir miyim#

Hayır, bu yöntem serileştirilmiş verileri kalıcı olarak bozar. PHP serileştirmesi her dizenin karakter uzunluğunu verinin içinde saklar; adres uzunluğu değişince bu sayı yanlış kalır ve PHP o kaydı hiç okuyamaz. Belirtisi sessizdir: hata mesajı görmezsiniz, sadece logo, widget ve tema ayarları kaybolur. Serileştirmeyi anlayan bir araç kullanın — WP-CLI'ın search-replace komutu ya da aynı işi yapan bir eklenti.

WP-CLI erişimim yoksa ne yapmalıyım#

Paylaşımlı hostingde SSH yoksa arama/değiştirme eklentisi kullanabilirsiniz; bu eklentiler de serileştirilmiş veriyi doğru işler. Kullanım sırası önemlidir: önce yedek alın, sonra kuru çalıştırma seçeneğiyle kaç satırın değişeceğini görün, ardından gerçek işlemi yapın ve işlem biter bitmez eklentiyi silin. Bu araçlar veritabanının tamamını yeniden yazabildikleri için sitede sürekli durmamalıdır. Alternatif olarak hosting sağlayıcınızdan SSH erişimi talep edebilirsiniz.

Eski alan adını ne kadar süre tutmalıyım#

En az bir yıl, mümkünse iki yıl tutmanız önerilir. Yönlendirme yalnızca alan adı sizde olduğu ve DNS kaydı sunucunuza baktığı sürece çalışır; süre dolduğu gün eski bağlantılar ölür. Ayrıca eski alan adı serbest kaldığında başkası alabilir ve sizin eski bağlantılarınız üzerinden gelen ziyaretçiler bambaşka bir siteye düşer. Basılı materyalde, e-posta imzalarında ve dış sitelerdeki bağlantılarda eski adresin ne kadar yaygın olduğunu düşünerek karar verin.

Alan adı değişince e-posta hesaplarım ne olur#

Eski alan adındaki e-posta hesapları, o alan adının MX kaydı sunucunuza baktığı sürece çalışmaya devam eder. Ancak yeni alan adında aynı isimlerle hesap açmanız ve iletişimi oraya taşımanız gerekir. Doğru sıra şudur: yeni alan adında hesapları oluşturun, eski hesaplardan yenilerine yönlendirme kurun, dış servislerde kayıtlı adresleri güncelleyin ve eski hesapları en az birkaç ay açık tutun. Posta kutusundaki eski iletileri taşımak isterseniz IMAP üzerinden aktarım yapılabilir.

Yönlendirmeyi WordPress eklentisiyle mi sunucu tarafında mı kurmalıyım#

Sunucu tarafında kurmak açık ara daha iyidir. Eski alan adı için .htaccess veya Nginx bloğunda tanımlanan yönlendirme, PHP hiç çalışmadan devreye girer; hem daha hızlıdır hem de WordPress bozulsa bile çalışır. Eklenti tabanlı yönlendirme ise her istekte WordPress'in yüklenmesini gerektirir ve eski alan adında ayrı bir kurulum olmasını zorunlu kılar. Eklentileri site içi bağlantı düzeltmeleri için saklayın, alan adı düzeyindeki yönlendirmeyi sunucuda yapın.

Değişiklikten sonra yazılar 404 veriyor ne yapmalıyım#

İlk yapılacak şey Ayarlar > Kalıcı Bağlantılar ekranını açıp hiçbir şey değiştirmeden Kaydet'e basmaktır. Bu işlem yeniden yazma kurallarını sıfırlar ve .htaccess dosyasını günceller. Sorun devam ediyorsa .htaccess dosyasının yazılabilir olduğunu ve WordPress blok kurallarının içinde bulunduğunu kontrol edin. Nginx kullanıyorsanız .htaccess okunmaz; sanal host yapılandırmasındaki try_files satırının doğru olduğundan emin olun. Ana sayfa açılıp iç sayfaların 404 vermesi neredeyse her zaman bu yeniden yazma kuralı sorunudur.

Kapanış#

Alan adı değişimi, doğru sırayla yapıldığında bir saatlik bir iştir; yanlış sırayla yapıldığında ise günlerce süren bir onarım işine dönüşür. Kritik nokta şudur: adres bilgisi sitenizin iki alanında değil, veritabanının her yerinde yaşar ve bu verinin bir bölümü serileştirilmiş biçimdedir. Uzunluk bilgisini yeniden hesaplayan bir araç kullanın, GUID sütununa dokunmayın, eski adresten yeni adrese sayfa bazlı 301 yönlendirme kurun ve eski alan adını en az bir yıl elinizde tutun. Geçişten sonra kalıcı bağlantıları yenilemek, sitemap'i güncellemek ve Search Console'da adres değişikliğini bildirmek de listenin ayrılmaz parçasıdır.

Yeni alan adınızı almadıysanız veya uzantı seçiminde kararsızsanız alan adı sayfasından uygun uzantıyı sorgulayabilirsiniz; yeni alan adı için sertifikayı hazırlarken SSL sayfasındaki seçenekler işinizi görür. Siteyi aynı anda yeni bir ortama da taşıyacaksanız veritabanı ve dosya aktarımını üstlenen site taşıma hizmetimiz bu geçişi kesintisiz yapar. Değişim sonrası bakım, güncelleme ve yedek takibini birinin üstlenmesini istiyorsanız WordPress hosting paketleri ve WordPress bakım hizmeti bu sorumluluğu devralır.