Puan
18
Çözümler
0
- Katılım
- 3 Kas 2025
- Mesajlar
- 99
- Tepkime puanı
- 0
WordPress Site Taşıma: Adım Adım Hosting Değiştirme Rehberi 2027
WordPress sitenizi başka bir hosting hesabına taşımak, yalnızca dosyaları yeni sunucuya yüklemekten ibaret değildir. İçeriklerinizin, kullanıcı bilgilerinizin, tema ayarlarınızın ve eklenti verilerinizin bulunduğu veritabanını da aktarmanız gerekir.İşlemin başarıyla tamamlanması için yeni sunucudaki kopyanın çalışması, alan adının doğru yere yönlenmesi ve taşıma sırasında oluşan yeni kayıtların korunması önemlidir. Özellikle sipariş alan veya üyelik sistemi bulunan sitelerde bu son nokta belirleyicidir.
Bu rehberde hazırlık aşamasını, eklentiyle ve manuel taşıma yöntemlerini, güvenli URL değişimini ve geçiş sonrası kontrolleri bulabilirsiniz.
Önce Taşımanın Kapsamını Belirleyin
İlk olarak şu soruyu yanıtlayın: Yalnızca hosting mi değişiyor, yoksa sitenin adresi de değişecek mi?| Taşıma türü | Yapılacak işlem |
|---|---|
| Alan adı ve adres yapısı aynı | Dosyalar ve veritabanı aktarılır, yeni sunucu yapılandırılır |
| Alan adı değişiyor | Aktarıma ek olarak URL değişimi ve yönlendirme planı gerekir |
| Alt dizin değişiyor | Yeni dosya konumu ve ilgili adresler düzenlenir |
| HTTP’den HTTPS’e geçiliyor | Sertifika, adresler ve kaynak bağlantıları kontrol edilir |
Alan adı, protokol ve dizin aynı kalıyorsa sırf sunucu değişti diye veritabanındaki bütün URL’leri değiştirmeniz gerekmez. Yeni veritabanı bağlantı bilgilerinin düzenlenmesi yeterli olabilir.
Taşıma ile birlikte tema değişikliği, eklenti temizliği ve kapsamlı tasarım yenilemesi yapmak ise sorun araştırmayı zorlaştırır. Önce mevcut siteyi çalışır durumda taşıyın; diğer değişiklikleri ayrı aşamalarda uygulayın.
Taşımadan Önce Hazırlık Listesi
Dosyaları ve veritabanını birlikte yedekleyin
Yedeğinizin yalnızca görsellerden veyawp-content klasöründen oluşmadığını doğrulayın. Taşıma için yapılandırma dosyaları, kullanılan özel dosyalar ve veritabanı da önemlidir.Dosya ve veritabanı kopyalarının aynı çalışma durumunu temsil etmesi gerekir. Yedekleme sırasında içerik değişmeye devam ediyorsa aralarında tutarsızlık oluşabilir. Yedeği eski hosting hesabından bağımsız bir yerde saklayın.
Yeni hosting ortamını kontrol edin
Şu bilgileri karşılaştırın:- PHP sürümü ve gerekli PHP uzantıları.
- MySQL veya MariaDB sürümü.
- Disk alanı ve dosya sayısı sınırı.
- Bellek ve işlem kaynakları.
- Dosya yükleme ve işlem süresi sınırları.
- SSL, e-posta ve zamanlanmış görev desteği.
Site dışındaki hizmetleri unutmayın
WordPress taşıma paketi, hosting hesabındaki bütün hizmetleri kapsamayabilir. E-posta kutuları, DNS kayıtları, sunucu cron görevleri, özel yönlendirmeler ve harici depolamadaki dosyalar ayrıca değerlendirilmelidir.Ödeme servisleri, SMTP hizmeti veya IP adresi kısıtlaması kullanan API bağlantıları varsa yeni sunucu için gerekli değişiklikleri önceden belirleyin.
DNS TTL Değeri Nasıl Hazırlanmalı?
TTL, DNS kaydının önbellekte ne kadar süre tutulacağını belirler. Taşımadan önce ilgili kayıtların TTL değerini düşürmek, geçiş sırasında eski yanıtların daha kısa süre saklanmasına yardımcı olabilir.Sağlayıcınız izin veriyorsa geçici olarak 300 saniye gibi düşük bir değer kullanılabilir. Ancak bunu geçişten hemen önce yapmak, önceden önbelleğe alınmış kayıtların süresini geriye dönük değiştirmez.
TTL değerinin 300 olması, bütün ziyaretçilerin beş dakika içinde yeni sunucuya ulaşacağını garanti etmez. Yerel önbellekler ve DNS hizmetinin davranışı da etkili olabilir. Cloudflare’ın proxied kayıtlarında TTL ayrıca otomatik olarak yönetilir.
Nameserver değiştirmek zorunda değilsiniz. Mevcut DNS hizmetinizi koruyup yalnızca web sitesini yeni sunucuya yönlendirebilirsiniz. Nameserver değiştiriyorsanız e-posta ve doğrulama kayıtlarının yeni DNS bölgesinde bulunduğunu da kontrol edin.
WordPress Taşıma Yöntemleri
Eklentiyle taşıma
All-in-One WP Migration ve Duplicator gibi araçlar, dosya ve veritabanı aktarımını kolaylaştırır. Ancak yöntem seçimini yalnızca site boyutuna göre yapmak yeterli değildir.| Durum | Değerlendirilebilecek yöntem |
|---|---|
| Standart blog veya kurumsal site | Taşıma eklentisi |
| Büyük arşiv ve sınırlı sunucu kaynakları | Sunucu üzerinden aktarım veya manuel yöntem |
| Sürekli sipariş alan mağaza | Son veri eşitlemesi planlanan taşıma |
| Multisite veya özel yapılandırma | Bu yapıyı destekleyen araç ve teknik çalışma |
| Teknik erişim veya deneyim sınırlı | Sağlayıcı desteği |
All-in-One WP Migration, dışa aktardığı
.wpress paketini hedef WordPress kurulumuna içe aktararak taşımayı gerçekleştirir. URL değişimini ve serileştirilmiş verileri de işleyebilir.Her kurulum için geçerli sabit bir “512 MB sınırı” varsaymayın. İçe aktarma ekranındaki limit, PHP yapılandırmasına bağlı olabilir. Web sunucusu, güvenlik katmanı veya CDN de yüklemeyi ayrıca sınırlandırabilir; yalnızca PHP limitini artırmak bütün engelleri çözmez.
Duplicator’ın klasik yönteminde arşiv ve kurulum dosyası hedefe yüklenir. Hedef klasörün ve kullanılacak veritabanının doğru seçilmesi önemlidir. İşlem tamamlandıktan sonra kurulum ve arşiv dosyaları sunucudan kaldırılmalıdır.
Sağlayıcı desteğiyle taşıma
Hosting firmasının taşıma hizmeti sunması işi kolaylaştırabilir. Hizmetin kapsamını öğrenin: dosyalar, veritabanı, e-posta, DNS ve son veri eşitlemesi aynı hizmete dâhil olmayabilir.Taşımanın ücretsiz olması veya ekip tarafından yapılması, tek başına kesinti ve veri kaybı yaşanmayacağı anlamına gelmez.
Manuel WordPress Taşıma Adımları
1. Dosyaları kopyalayın
WordPress’in bulunduğu klasörü SFTP veya sağlayıcınızın güvenli aktarım yöntemiyle kopyalayın..htaccess gibi gizli dosyaların atlanmadığını kontrol edin.Dosyaları taşırken eski sunucudan silmeyin. Önce yeni ortamda çalışan bir kopya oluşturun.
2. Doğru veritabanını dışa aktarın
wp-config.php içindeki DB_NAME değerinden kullanılan veritabanını doğrulayın. phpMyAdmin üzerinden dışa aktarabilir veya SSH erişiminiz varsa WP-CLI kullanabilirsiniz.Büyük veritabanlarında tarayıcı üzerinden çalışan aktarım zaman aşımına uğrayabilir. WP-CLI’nin
wp db export ve wp db import komutları alternatif sunar. Dışa aktarma varsayılan olarak ilgili veritabanındaki bütün tabloları kapsadığından, başka uygulamalarla paylaşılan veritabanlarında kapsamı ayrıca kontrol edin.SQL yedeğini web üzerinden indirilebilen açık bir klasörde bırakmayın.
3. Yeni veritabanını oluşturun
Hedef hosting hesabında ayrı bir veritabanı ve kullanıcı oluşturun. Kullanıcıya bu veritabanında gerekli yetkileri verin.cPanel kullanıyorsanız Database Wizard / Veritabanı Sihirbazı üzerinden işlem yapabilirsiniz. Panelin eklediği hesap önekleri dâhil tam veritabanı ve kullanıcı adlarını kaydedin.
SQL dosyasını hedef veritabanına aktarın. İçe aktarma hata verirse bunu giderip işlemin tamamlandığını doğrulayın; yarım kalmış aktarımı başarılı kabul etmeyin.
4. Dosyaları doğru belge köküne yükleyin
Hedef klasör her zamanpublic_html değildir. Ek alan adları farklı dizinlere bağlı olabilir.cPanel’de Domains / Alan Adları ekranındaki Document Root / Belge Kökü bilgisini kontrol ederek dosyaları ilgili konuma yerleştirin.
5. Yapılandırmayı düzenleyin
Yeni kopyanınwp-config.php dosyasında şu değerleri güncelleyin:DB_NAMEDB_USERDB_PASSWORDDB_HOST
DB_HOST çoğu ortamda localhost olabilir; sağlayıcınızın verdiği değeri esas alın. Dosyadaki tablo önekinin aktardığınız tablolarla eşleştiğini ve varsa sabit adres tanımlarının doğru olduğunu kontrol edin.Test kopyasının eski canlı veritabanına bağlı kalmadığından emin olun. Aksi hâlde test sırasında yaptığınız değişiklikler canlı verileri etkileyebilir.
Alan Adı Değişiyorsa URL’ler Nasıl Güncellenir?
WordPress ve eklentileri bazı ayarları serileştirilmiş veri olarak saklar. Bu yapı, metinlerin uzunluk bilgisini de içerir.Veritabanının tamamında gelişigüzel SQL
REPLACE işlemi yapmak, uzunluk bilgilerini bozabilir. URL değişiminde bu yapıyı anlayan bir araç kullanın.WP-CLI ile önce prova yapın
Aşağıdaki örnek, ayrı veritabanına bağlanan yeni kopya ve standart tek site kurulumu içindir. Dizin ve adresleri kendi bilgilerinizle değiştirin:
Kod:
wp --path=/YENI_WORDPRESS_DIZINI search-replace \
'https://eski.example' 'https://yeni.example' \
--all-tables-with-prefix \
--skip-columns=guid \
--dry-run
--dry-run, değişiklikleri kaydetmeden rapor üretir. Tablo kapsamını ve eşleşmeleri kontrol ettikten, yeni veritabanının yedeğini aldıktan sonra bu seçeneği kaldırarak işlemi uygulayabilirsiniz.--all-tables-with-prefix, mevcut önekle başlayan eklenti tablolarını da kapsar. Multisite veya paylaşılan veritabanında kapsamı ayrıca değerlendirin.WP-CLI serileştirilmiş veriyi zaten işler.
--precise bu desteği açmak için zorunlu değildir; daha kapsamlı fakat daha yavaş PHP yöntemini zorlar.Mevcut içeriklerin GUID değerlerini koruyun. URL gibi görünseler de içerik kimliği olarak kullanılırlar; değiştirilmesi bazı akış okuyucularında eski içeriklerin yeniden gösterilmesine yol açabilir.
SSH yoksa Better Search Replace kullanın
Yeni kopyada eklentiyi açın, eski ve yeni adresi yazın, yalnızca ilgili tabloları seçin ve önce Dry Run çalıştırın.Eklenti serileştirilmiş veriyi destekler; ayrıca hayalî bir “serileştirmeyi aç” ayarı aramanız gerekmez. GUID değiştirme seçeneğini kapalı tutun.
DNS Değişmeden Önce Yeni Siteyi Test Edin
Alan adı aynı kalacaksa bilgisayarınızın hosts dosyasıyla bu adı geçici olarak yeni IP’ye eşleyebilirsiniz. Böylece ziyaretçiler eski sunucuyu kullanırken siz yeni kopyayı gerçek alan adıyla test edersiniz. İşiniz bitince yerel eşlemeyi kaldırın.Geçici test adresi de kullanılabilir; ancak bu durumda adres değişikliklerinin yayına geçişte geri düzenlenmesi gerekir.
Test kopyasını erişim korumasıyla sınırlandırın. Gerçek e-posta gönderimini, ödeme işlemlerini ve dış sistemleri etkileyen görevleri kontrol altına alın.
noindex kullanmak erişim korumasının yerini tutmaz.WooCommerce ve Üyelik Sitelerinde Son Eşitleme
İlk kopyayı aldıktan sonra eski sitede yeni siparişler veya kullanıcı kayıtları oluşabilir. Test ettiğiniz kopya bu kayıtları içermez.Bu nedenle geçiş planında:
- Yeni ortamı önceden hazırlayıp test edin.
- Son aktarım sırasında yeni kayıt oluşmasını kontrollü biçimde durdurun.
- Son veritabanı ve dosya değişikliklerini aktarın.
- İşlemleri doğrulayıp trafiği yeni ortama geçirin.
- Eski sunucuda yeni kayıt alınmasını engelleyin.
Kesintisiz yazma gerekiyorsa son farkların güvenli aktarımı için daha kapsamlı bir eşitleme planı gerekir.
Geçiş Sonrası Kontrol Listesi
| Kontrol | Bakılacak noktalar |
|---|---|
| Sayfalar | Ana sayfa, yazılar, kategoriler ve önemli açılış sayfaları |
| Medya | Görseller, PDF dosyaları ve indirmeler |
| Hesaplar | Giriş, kayıt ve parola sıfırlama |
| Formlar | Gönderim, kayıt ve e-posta teslimi |
| E-ticaret | Sepet, ödeme, sipariş ve bildirimler |
| HTTPS | Sertifika, yönlendirme ve karışık içerik |
| SEO | Canonical, robots, noindex ve site haritası |
| Arka plan | Cron görevleri, kuyruklar ve harici bağlantılar |
Yeni ortamda önbellekleri temizleyin; eski sunucuya ait ayarları gözden geçirin. Test amacıyla eklediğiniz erişim ve indeksleme kısıtlamalarını yayına geçerken uygun şekilde kaldırın.
Eski hosting hesabını yalnızca belirli bir süre geçti diye silmeyin. Yeni siteyi doğrulayın, eski sunucuya gelen trafiği izleyin ve geri dönüş ihtiyacını değerlendirin. Google da eski altyapının kapatılmasını trafik geçişi doğrulandıktan sonra önerir.
Taşıma SEO’yu Etkiler mi?
Adresler aynı kaldığında URL yönlendirmesi gerekmez. Ancak sunucu hataları, yavaş yanıtlar veya yanlışlıkla bırakılmışnoindex ayarları görünürlüğü etkileyebilir. Hosting değişiminden sonra tarama hızında geçici değişiklikler de görülebilir.Alan adı değişiyorsa eski sayfaları ilgili yeni sayfalara kalıcı yönlendirmeyle eşleyin. Bütün adresleri yeni ana sayfaya göndermeyin. Canonical adreslerini ve site haritasını güncelleyin; uygun alan adı değişimlerinde Search Console’un adres değişikliği aracını kullanın.
Google, yönlendirmelerin genel olarak en az bir yıl korunmasını önerir. Taşınma sırasında arama görünürlüğünde geçici dalgalanmalar yaşanabilir.
Sıkça Sorulan Sorular
WordPress taşımak için yeniden kurulum gerekir mi?
Manuel taşımada mevcut dosyalar ve veritabanı kullanılabilir. Bazı eklenti yöntemleri ise hedefte önce boş bir WordPress kurulumu ister.Site taşınırken kapanır mı?
Geçiş doğru hazırlanırsa kesinti azaltılabilir. Sipariş ve üyelik verilerini korumak için kontrollü bir bakım aralığı gerekebilir.Görseller görünmüyorsa neyi kontrol etmeliyim?
Dosyaların aktarılıp aktarılmadığını, izinleri, görsel URL’lerini, HTTPS bağlantısını ve varsa harici depolama ayarlarını inceleyin.Sayfalar 404 veriyorsa ne yapmalıyım?
Kalıcı bağlantı ayarlarını yeniden kaydedin. Sorun devam ederse web sunucusunun yeniden yazma kurallarını kontrol ettirin. Nginx yapılandırması.htaccess üzerinden yönetilmez.
