WordPress’te Site Taşıma Sonrası Karşılaşılan Hatalar

WordPress site taşıma, doğru hazırlıkla yapıldığında 15 dakika süren bir işlemdir. Ancak taşıma sonrasında URL yapısı bozulması, veritabanı bağlantı hatası, tema ve eklenti çakışmaları gibi üç temel sorun ortaya çıkar; bunların her biri sitede erişilemezliğe, hatalı sayfa gösterimine veya SEO kaybına yol açar. Bu rehberde her hatayı gerçek bir senaryo üzerinden anlatıyor, kök nedenini açıklıyor ve uygulanabilir çözüm adımlarını veriyorum.

Site taşıma sonrası en sık karşılaşılan 3 hata — sırasıyla — şunlardır:

1. URL yapısı değişikliği ve 404 hataları
2. Veritabanı bağlantı hatası
3. Tema ve eklenti çakışmaları

WordPress site taşıma: URL Yapısı Değişikliği ve 404 Hataları

Taşıma sonrasının en yaygın belirtisi, daha önce indekslenen sayfaların 404 Not Found dönmesidir. Ziyaretçiler eski URL’leri tıkladığında “Sayfa bulunamadı” sayfasıyla karşılaşır, arama motorları bu URL’leri geçersiz sayar ve sıralama kaybı başlar. Kök neden hemen her zaman wp_options tablosundaki siteurl ve home alanlarının eski domain’i tutmasıdır.

Bu iki alan, WordPress’in mutlak URL ürettiği her yerde referans noktasıdır. Yeni domain’i yansıtmadığı sürece site kendi içinde bile çalışmaz: medya yolları, kalıcı bağlantılar, yönlendirmeler — hepsi eski adrese sabitlenir. Sorunu üç adımda çözersiniz:

1. wp-config.php’ye geçici tanımlar ekleyin. Veritabanına dokunmadan, eski URL’leri geçersiz kılmak için wp-config.php dosyasına şu iki satırı ekleyin:
   define('WP_HOME', 'https://yeni-domain.com');
define('WP_SITEURL', 'https://yeni-domain.com');
2. Veritabanını gerçek kayıtla eşitleyin. wp_options tablosunda option_name = 'siteurl' ve option_name = 'home' satırlarını bulup option_value sütununu yeni domain ile güncelleyin. Bu adımdan sonra wp-config’teki tanımları silebilirsiniz.
3. Kalıcı bağlantıları yenileyin. wp-admin → Ayarlar → Kalıcı Bağlantılar sayfasına girip hiçbir şeyi değiştirmeden “Değişiklikleri Kaydet” butonuna tıklayın. Bu işlem .htaccess dosyasını yeniden yazar ve 404 hatalarını büyük ölçüde temizler.

Eğer eski URL’leri de yeniden yönlendirmek istiyorsanız, WordPress’in Redirection eklentisini kurup search/replace aracıyla veritabanındaki tüm eski domain kalıntılarını toplu şekilde değiştirebilirsiniz. Bu adım SEO sürekliliği için kritiktir; aksi halde tüm backlink değeri kaybedilir.

Veritabanı Bağlantı Hatası

Taşıma sonrası sitenin tamamen beyaz bir sayfada “Error establishing a database connection” mesajıyla açılması, neredeyse her zaman wp-config.php dosyasındaki veritabanı bilgilerinin güncellenmemesinden kaynaklanır. WordPress yeni sunucuda eski sunucunun IP’sini, portunu veya kullanıcı adını arar, bulamaz ve bağlantıyı reddeder.

Çözüm için wp-config.php dosyasını açın ve şu dört sabitin yeni sunucu bilgileriyle eşleştiğinden emin olun:

define('DB_NAME',     'yeni_veritabani_adi');
define('DB_USER',     'yeni_kullanici');
define('DB_PASSWORD', 'yeni_sifre');
define('DB_HOST',     'localhost');   // paylaşımlı hosting ise genelde 'localhost', managed DB ise uzak host

Bu bilgileri yeni sunucunun kontrol panelinden alırsınız (cPanel, Plesk, DirectAdmin veya yönetilen bir panel). Veritabanı sunucusunun localhost dışında bir adresle çalıştığı durumlarda (Amazon RDS, DigitalOcean Managed DB, Cloud SQL gibi) DB_HOST değerine uzak sunucunun IP veya host adı yazılır; güvenlik duvarı kurallarının da yeni sunucudan gelen bağlantılara izin verdiğinden emin olun.

Bilgiler doğru ama hâlâ aynı mesaj geliyorsa, sırayla şu kontrolleri yapın:

• Veritabanı sunucusu çalışıyor mu? SSH veya konsol üzerinden mysql -u KULLANICI -p ile bağlanmayı deneyin.
• Veritabanı kullanıcısının SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER yetkileri var mı?
• Veritabanı kullanıcısı, hedef veritabanı ile eşleştirilmiş mi? cPanel’de “MySQL Databases” bölümünde kullanıcıyı veritabanına eklemek ayrı bir adımdır.
• Disk kotası veya inodes sınırı aşıldı mı? Bazı paylaşımlı hostinglerde disk dolduğunda DB yazma işlemi sessizce kesilir.

Taşıma sonrası ilk 24 saatte bu hata bir kez daha ortaya çıkabilir; bunun nedeni DNS önbelleklerinin eski sunucuya yönlendirmesi değil, MySQL’in henüz yeni sunucuda tam olarak hazır olmamasıdır. SHOW PROCESSLIST; komutuyla aktif sorgu sayısını ve bağlantı durumunu gözlemleyebilirsiniz.

Tema ve Eklenti Çakışmaları

Veritabanı bağlantısı kurulduktan sonra sitenin açılıp “Beyaz Ekran Ölümü” (White Screen of Death, WSOD) vermesi, tema veya eklenti uyumsuzluğuna işaret eder. Yeni sunucunun PHP sürümü, MySQL sürümü veya bellek limitleri eski sunucudan farklıysa, kodda eski sürüm varsayımlarına dayanan bileşenler aniden hata vermeye başlar. En sık tetikleyiciler şunlardır:

• PHP 7.4’te sorunsuz çalışan bir tema, PHP 8.0+ sürümünde create_function(), magic_quotes gibi kaldırılmış fonksiyonlar yüzünden hata verir.
• Bir eklenti, register_post_type() veya add_shortcode() çağrılarını init hook’undan önce çalıştırarak fatal error tetikler.
• Sunucu memory_limit değeri 128M’ın altında, tema veya eklenti 256M istiyor; PHP bellek tükeniyor ve süreç ölüyor.
• SSL sertifikası yüklenmemiş; https:// bekleyen kaynaklar mixed-content uyarısı veriyor, bazı JS kütüphaneleri yüklenmiyor.

Sorunu daraltmak için sıralı bir izolasyon protokolü uygulayın:

1. WP_DEBUG açın. wp-config.php içinde define('WP_DEBUG', true); ve define('WP_DEBUG_LOG', true); satırlarını ekleyin. Hata mesajları wp-content/debug.log dosyasına yazılır ve gerçek kök neden görünür.
2. Tüm eklentileri devre dışı bırakın. FTP/SFTP ile wp-content/plugins klasörünün adını plugins-off olarak değiştirin. Site bu halde açılıyorsa, sorun bir eklentidedir; klasörü eski adına döndürün ve eklentileri tek tek aktifleştirerek suçluyu bulun.
3. Temayı varsayılan temaya geçirin. wp-content/themes/aktif-tema klasörünü geçici olarak yeniden adlandırın. WordPress otomatik olarak twentytwentyfour gibi bir varsayılan temaya düşer. Site açılıyorsa, sorun temadadır; functions.php dosyasını ve tema sürüm notlarını kontrol edin.
4. PHP sürümünü doğrulayın. phpinfo() çıktısı veya wp-admin → Site Sağlığı → Bilgi paneli aktif sürümü gösterir. Temanız veya eklentileriniz “PHP 7.4+” gibi eski bir sürümde test edildiyse, sunucuyu geriye dönük uyumlu moda almak için hosting sağlayıcınızın “MultiPHP Manager” veya “PHP Selector” aracından uygun sürümü seçin.
5. PHP sürümünü doğrulayın. phpinfo() çıktısı veya wp-admin → Site Sağlığı → Bilgi paneli aktif sürümü gösterir. Temanız veya eklentileriniz “PHP 7.4+” gibi eski bir sürümde test edildiyse, sunucuyu geriye dönük uyumlu moda almak için hosting sağlayıcınızın “MultiPHP Manager” veya “PHP Selector” aracından uygun sürümü seçin.

Site Taşıma Öncesi Kontrol Listesi

Yukarıdaki hatalarla karşılaşmamak için taşıma öncesinde 5 dakikalık bir hazırlık rutini uygulamak büyük fark yaratır. Bu kontrol listesi, gerçek taşıma adımına geçmeden önce tamamlanması gereken adımları içerir:

1. Tam yedek alın. Hem dosyaları (FTP üzerinden wp-content klasörü) hem de veritabanını (phpMyAdmin veya mysqldump) ayrı ayrı yedekleyin. Yedekleme eklentileri (UpdraftPlus, BlogVault) işi kolaylaştırır ancak sunucu tarafı yedek her zaman ek bir güvence katmanıdır.
2. Yeni sunucu gereksinimlerini doğrulayın. WordPress’in önerdiği minimum sürümler PHP 7.4+ ve MySQL 5.7+ (veya MariaDB 10.3+) şeklindedir. Yeni sunucu bu sürümlerin altındaysa, taşıma sonrası hemen uyumsuzluk hataları başlar.
3. DNS yayılma süresini planlayın. Domain yöneticisinde TTL (Time To Live) değerini taşımadan 24 saat önce 300 saniyeye düşürün. Bu sayede yeni IP’ye geçiş daha hızlı yayılır; eski sunucu ziyaretçilerin yükünü 24-48 saat taşımaya devam edebilir.
4. SSL sertifikasını önceden hazırlayın. Let’s Encrypt otomatik yenileme yapan bir sertifika sağlayıcıdır; yeni sunucuda sertifika henüz kurulmamışsa, site https:// üzerinden ulaşılamaz hale gelir ve tüm bağlantılar mixed-content hatasına düşer.
5. Test domaini üzerinde doğrulayın. Gerçek domain’i yayına almadan önce, wp-config.php içinde WP_HOME ve WP_SITEURL sabitlerini geçici bir test domaini ile değiştirin. Tüm sayfaları, medyayı ve formları bu test domaininde gözden geçirin; hata yoksa gerçek domain’e dönün.

WordPress site taşıma için pratik kontrol listesi

WordPress site taşıma konusunda uygulamaya geçmeden önce mevcut yedeği doğrulayın, değişikliği küçük adımlarla test edin ve sonucu canlı sitede tekrar kontrol edin. Benzer konular için WordPress beyaz sayfa hatası ve WordPress admin paneli yavaşlığı rehberlerine de bakabilirsiniz. Resmi kaynak olarak WordPress taşıma dokümantasyonu sayfasını incelemek faydalı olur.

Sonuç

WordPress site taşıma, üç ana hata kategorisinin (URL yapısı, veritabanı bağlantısı, tema/eklenti çakışması) bilinmesiyle büyük ölçüde risksiz hale gelir. wp-config.php ve wp_options tablosunun yeni ortamla eşleşmesi, kalıcı bağlantıların yenilenmesi, eski URL’lerin yönlendirilmesi ve WP_DEBUG loglarının sistematik okunması, taşıma sonrası sorunların %90’ını ilk bir saat içinde çözer.

Bu adımları üretim ortamına geçmeden önce mutlaka staging (kopyalama) ortamında sınayın. Sitenin tam yedeğini (dosyalar + veritabanı) taşımadan önce alın; bu sayede bir adım ters gittiğinde geri dönmek dakikalar içinde mümkün olur. Özel bir taşıma senaryosu veya hata mesajı için başlık altındaki iletişim kanallarından bana ulaşabilirsiniz.

WordPress Site Taşıma İçin Pratik Özet Tablosu

Aşağıdaki tablo, WordPress’te Site Taşıma Sonrası Karşılaşılan Hatalar konusunda hızlı karar vermeniz için temel kontrolleri özetler. Önce belirtiyi bulun, ardından önerilen aksiyonu uygulayın.

SSS: WordPress’te Site Taşıma Sonrası Karşılaşılan Hatalar

WordPress’te Site Taşıma Sonrası Karşılaşılan Hatalar için ilk kontrol ne olmalı?
Önce sorunun kapsamını belirleyin. Sadece tek sayfada mı, tüm sitede mi, yoksa belirli kullanıcı veya cihazlarda mı göründüğünü kontrol edin.

Bu işlem SEO performansını etkiler mi?
Evet, teknik sorunlar kullanıcı deneyimini ve tarama kalitesini etkileyebilir. Bu nedenle değişiklikten sonra Search Console verilerini takip etmek gerekir.

Canlı sitede işlem yapmadan önce yedek almak gerekir mi?
Kesinlikle gerekir. Dosya ve veritabanı yedeği olmadan yapılan canlı değişiklikler, küçük bir hatada geri dönüşü zorlaştırabilir.

Değişiklikten sonra cache temizlemek şart mı?
Çoğu durumda evet. WordPress cache eklentisi, CDN ve tarayıcı cache’i eski çıktıyı göstermeye devam edebilir.

Sorun devam ederse nasıl ilerlemeliyim?
Son yapılan değişikliği geri alın, hata loglarını kontrol edin ve eklenti/tema çakışmasını izole edin. Gerekirse küçük adımlarla yeniden test edin.