Site Taşıma Yaparken Dikkat Edilmesi Gerekenler

Site Taşıma Yaparken Dikkat Edilmesi Gerekenler

Site taşıma işi “dosyayı kopyala bitti” değildir. WordPress’te dosya + veritabanı + alan adı/DNS + SSL + e-posta + cache katmanları birlikte çalışır. Birini eksik taşırsan ya site açılmaz ya da görünürde açılır ama giriş/medya/formlar/kalıcı bağlantılar bozulur. Bu yazıda işi doğru sırayla, manuel taşıma ve eklenti ile taşıma olarak ikiye ayıracağım. Ayrıca farklı alan adına taşıma senaryosunu da ayrı ele alacağım.

Net konuşayım: Taşıma sırasında en çok hata yapılan iki nokta var. Birincisi, veritabanı içindeki URL’ler doğru güncellenmeden canlıya alınması. İkincisi, taşıma sonrası cache ve optimizasyonun yanlış çalışması. Taşıma tamamlandıktan sonra doğru Web Site Hızlandırma ile siteyi toparlamak önemlidir; ama önce stabil çalışacak, sonra Web Site Hızlandırma gelir. Hız uğruna taşıma bütünlüğünü bozan, aynı gün tekrar taşır.

Taşıma öncesi kısa kontrol: 10 dakikalık hazırlık

Hedefi netleştir

1) Aynı alan adında yeni hostinge mi geçiyorsun?

2) Alan adı da değişiyor mu? (farklı domain)

3) HTTPS/SSL zorunlu mu? (çoğu projede evet)

4) Yeni hostingin PHP sürümü ve limitleri yeterli mi?

Taşıma penceresi (downtime) planı

Taşıma sırasında sipariş alan, form toplayan veya üyelik çalışan sitelerde “veri kaybı” riski vardır. Ya bakım moduna alırsın ya da en azından taşımaya yakın saatte yeni içerik/sipariş alınmasını kontrol edersin. E-ticarette “gece taşırız” yaklaşımı hâlâ en güvenli yaklaşımdır.

Staging yaklaşımı

En sağlıklı yöntem: önce staging (geçici alan adı veya hosts dosyasıyla) test, sonra canlıya geçiş. Bu, yıllardır değişmeyen sağlam yöntemdir.

Web Sitesini Manuel Taşıma

Adım 1: Dosyalarınızı yedekleyin

WordPress dosyalarının ana gövdesi şuradadır: wp-content (tema, eklenti, uploads). Çekirdek dosyalar da taşınır ama kritik olan genelde wp-content’tir. Dosya yedeğini FTP ile alabilirsin; SSH varsa daha hızlı ve temiz alınır.

SSH ile sık kullanılan yedekleme örneği:

cd /path/to/public_html
tar -czf site-files-backup.tar.gz wp-content wp-config.php .htaccess

Not: Bazı sitelerde özel dosyalar wp-content dışında olabilir (custom scripts, özel upload klasörleri). Sende varsa onları da dahil et.

Adım 2: Sitenizin veritabanını yedekleyin

Veritabanı yedeği olmadan taşıma yapılmaz. “Dosyalar duruyor, veritabanını sonra alırım” dersen, en kritik veriyi kaçırırsın. phpMyAdmin ile export alınabilir; WP-CLI varsa daha hızlıdır.

WP-CLI ile veritabanı yedeği:

wp db export site-db-backup.sql

phpMyAdmin ile alacaksan Export formatı genelde SQL, sıkıştırma da (gzip) kullanırsan dosya daha küçük olur.

Adım 3: Yedeklediğiniz dosyaları yeni hostinge yükleyin

Yeni hostingde hedef klasörü net belirle (public_html, httpdocs, www). Dosyaları yükledikten sonra izin/sahiplik (permissions/owner) kontrolünü yap. Özellikle wp-content/uploads yazılabilir olmalı.

Tipik izinler: klasör 755, dosya 644. uploads yazılamıyorsa medya yükleme patlar. Taşıma sonrası “resim yüklenmiyor” çıkarsa ilk bakacağın yer burasıdır.

Adım 4: Yeni veritabanı oluşturun

Yeni hosting panelinden yeni bir veritabanı ve kullanıcı oluştur. Kullanıcıya tüm yetkileri ver (SELECT/INSERT/UPDATE/DELETE/CREATE/ALTER/INDEX vb.). Sonra yedek aldığın SQL’i içeri aktar.

WP-CLI ile içeri aktarma:

wp db import site-db-backup.sql

phpMyAdmin ile import yapacaksan, dosya boyutu büyükse “upload limiti” yüzünden import yarıda kalabilir. O durumda SSH veya panelin “remote import” araçları daha sağlamdır.

Adım 5: “wp-config.php” dosyasını düzenleyin

Bu adım taşımada en kritik 5 dakikadır. Yeni DB adı, kullanıcı adı, şifre ve host bilgileri wp-config.php içine doğru girilmelidir.

<?php
define('DB_NAME', 'yeni_veritabani_adi');
define('DB_USER', 'yeni_kullanici');
define('DB_PASSWORD', 'yeni_sifre');
define('DB_HOST', 'localhost');

DB_HOST bazı hostlarda localhost değildir (örnek: 127.0.0.1 veya ayrı bir host adı). Hosting panelinin verdiği bilgiyi kullan.

Ek olarak taşıma sırasında debug açmak işe yarar (ekrana basmadan):

<?php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Taşıma bitince debug’u kapatman daha doğrudur. Canlıda açık bırakmak profesyonel değildir.

Manuel taşıma sonrası en kritik kontrol

1) Admin giriş yapılıyor mu?

2) Kalıcı bağlantılar çalışıyor mu? (404 var mı?)

3) Medya dosyaları yükleniyor mu ve görüntüleniyor mu?

4) Formlar e-posta gönderiyor mu?

5) SSL düzgün mü, karışık içerik (mixed content) var mı?

Kalıcı bağlantılar bozulduysa çoğu zaman “Ayarlar > Kalıcı Bağlantılar” sayfasına girip “Kaydet” demek bile .htaccess’i yeniler. Apache kullanıyorsan işe yarar. Nginx’te kural sunucu tarafındadır.

Eklenti ile WordPress Site Taşıma

Eklenti ile taşıma, özellikle küçük/orta sitelerde hızlıdır. Ama “her eklenti her hostta kusursuz” değildir. Büyük sitelerde yedek boyutu, timeout ve bellek limitleri can yakar. Yine de doğru kullanılırsa çok pratiktir.

Eklenti ile WordPress sitenizin yedeğini alın

Taşıma eklentileri genelde tek bir paket üretir: dosya + veritabanı. Burada dikkat edeceğin şey; yedeğin eksiksiz oluşturulması ve yarıda kesilmemesidir. Yedek alırken sunucu kaynakları yetmiyorsa PHP limitlerini geçici yükseltmek gerekebilir.

Taşıma eklentisi ne kullanırsan kullan, şu disiplin değişmez: yedek dosyası oluştu mu, boyutu mantıklı mı, hata logu var mı?

Yedeği yeni hostinge yükleyin

Yeni hostta temiz bir WordPress kurup eklentiyi kurarak import yapmak genelde daha stabil sonuç verir. Bazı kişiler “boş klasöre import” dener; bazı eklentilerde bu sıkıntı çıkarır. Temiz kurulum + import yaklaşımı, eskiden beri daha garantidir.

Eklenti ile taşıma sonrası kontroller

Taşıma eklentileri URL değişimini bazen otomatik yapar, bazen yapmaz. Eğer aynı domain ile taşındıysan genelde sorun olmaz. Alan adı değiştiyse, aşağıdaki “Farklı alan adına taşıma” bölümündeki URL düzeltmeleri şarttır.

Taşıma sonrası cache/optimizasyon eklentilerini hemen agresif açma. Önce stabil çalışsın, sonra Web Site Hızlandırma ayarlarını kontrollü geri getir. Çünkü taşıma sonrası “CSS/JS kırıldı” gibi sorunları çoğu zaman cache katmanı büyütür.

WordPress Sitenizi Farklı Alan Adına Taşıma

Alan adı değişimi, klasik taşımanın üstüne bir katman daha ekler: veritabanı içindeki eski URL’lerin yeni URL ile değiştirilmesi. Burada “bul-değiştir” yaparken dikkat etmezsen siteyi tamamen dağıtabilirsin. Çünkü WordPress veritabanında bazı alanlar “serialize” formatında tutulur; yanlış replace, veri uzunluğunu bozup kırar.

Manuel farklı alan adına taşıma: doğru yöntem

En sağlam yöntem WP-CLI ile search-replace yapmaktır. Çünkü serialized verileri doğru işler.

Örnek WP-CLI komutu (önce dry-run ile kontrol):

wp search-replace "http://eskidomain.com" "https://yenidomain.com" --all-tables --dry-run

Dry-run temiz görünüyorsa gerçek işlemi uygula:

wp search-replace "http://eskidomain.com" "https://yenidomain.com" --all-tables

www değişimi varsa onu da ayrıca yapman gerekebilir. Eski site www’li, yeni site www’siz ise iki farklı replace gerekebilir. Bu işi yarım yamalak yaparsan karışık içerik ve yönlendirme problemleri çıkar.

wp-config.php içinde geçici siteurl/home tanımı (krizde kurtarıcı)

Bazen veritabanı URL’leri bozuk olduğu için admin bile açılmaz. Bu durumda geçici olarak wp-config.php içine siteurl ve home tanımlayıp paneli açarsın, sonra düzenlersin.

<?php
define('WP_HOME', 'https://yenidomain.com');
define('WP_SITEURL', 'https://yenidomain.com');

Bu kalıcı çözüm değildir. İş bitince kaldırmak daha doğrudur; çünkü yönetimi zorlaştırır.

SSL ve yönlendirme (301) kuralı

Alan adı değişiminde SSL sertifikası mutlaka yeni domain için kurulmalıdır. Eski domainden yeni domaine 301 yönlendirme yapılır. WordPress seviyesinde değil, mümkünse sunucu seviyesinde yapılması daha temizdir.

Apache için basit 301 örneği (eski domainde .htaccess):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^eskidomain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.eskidomain\.com$
RewriteRule ^(.*)$ https://yenidomain.com/$1 [R=301,L]

Taşıma sonrası 301 yönlendirmeler düzgün olursa SEO kaybı azalır. Ayrıca eski linkler kırılmaz.

Eklenti ile Farklı Alan Adına Site Taşıma

Birçok taşıma eklentisi alan adı değişimini otomatik yönetir. Ama yine de kontrol şarttır. Çünkü bazı eklentiler sadece wp_options içindeki siteurl/home değerini değiştirir; içerik içindeki eski linkler kalır. Bu da karışık içerik (mixed content) ve eski domain referansları üretir.

Eklenti ile taşıdıktan sonra URL kontrolü

1) Anasayfa kaynak kodunda eski domain geçiyor mu?

2) Medya URL’leri eski domain mi?

3) Menü linkleri ve widget linkleri eski domain mi?

Eski domain kalmışsa WP-CLI search-replace ile temizlemek en güvenlisidir. Taşıma eklentisi yaptı diye güvenip geçme; kontrol etmeden canlıya alma.

Taşıma sonrası sık görülen problemler ve hızlı çözümler

Kalıcı bağlantılar (404) problemi

Çözüm: Kalıcı bağlantılara girip kaydet. Apache’de .htaccess yazılır. Nginx’te kuralları kontrol et.

Medya bozuk veya yükleme hatası

Çözüm: wp-content/uploads permissions/owner kontrol et. PHP limitleri (upload_max_filesize, post_max_size) yeterli mi bak. CDN/hotlink kuralı varsa uploads erişimini engelliyor mu kontrol et.

Limitleri görmek için hızlı kontrol (SSH):

php -i | grep -E "upload_max_filesize|post_max_size|memory_limit|max_execution_time"

Formlardan mail gitmiyor

Taşıma sonrası en sık unutulan şey: SMTP ayarları. Yeni hostta PHP mail kısıtlı olabilir. Çözüm: SMTP ile gönderim + domain DNS (SPF/DKIM) kontrolü.

Karışık içerik (mixed content)

HTTP’ten HTTPS’e geçişte içerik içindeki eski http linkleri kalırsa tarayıcı uyarı verir. Çözüm: doğru URL replace + cache temizliği.

Cache ve optimizasyon karmaşası

Taşıma sonrası “site bozuldu” şikâyetinin önemli kısmı cache yüzündendir. Cache eklentisi, CDN, sunucu cache eski dosyaları servis eder. Taşıma bitince tüm cache katmanlarını temizle, sonra Web Site Hızlandırma ayarlarını kontrollü geri aç. Yanlış sıra ile açarsan “CSS kırıldı” diye uğraşırsın.

Taşıma sonrası performans ve güvenlik: doğru sırayla Web Site Hızlandırma

Taşıma bitti, site stabil açılıyor. Şimdi sıra performans düzeninde. Burada da disiplin şart: önce temel sağlık, sonra Web Site Hızlandırma. Şunları yap:

1) Gereksiz eklentileri kaldır (hem risk düşer hem hız artar) -> bu da Web Site Hızlandırma demektir.

2) Cache istisnalarını doğru kur (sepet/ödeme/hesap sayfaları cache’lenmez) -> doğru Web Site Hızlandırma budur.

3) CDN kullanıyorsan statik dosyalarda düzgün çalıştır, admin ve dinamik alanlarda bypass et -> güvenli Web Site Hızlandırma.

4) Görsel optimizasyonunu kontrollü yap (WebP, lazyload), ama upload akışını bozma -> sürdürülebilir Web Site Hızlandırma.

Gördüğün gibi Web Site Hızlandırma taşımanın düşmanı değil; doğru sırayla yapılırsa taşıma sonrası kaliteyi yükseltir.

Tek sayfada uygulama sırası (özet plan)

1) Dosyaları yedekle

2) Veritabanını yedekle

3) Dosyaları yeni hostinge yükle

4) Yeni veritabanı oluştur ve import et

5) wp-config.php düzenle

6) Alan adı değişiyorsa WP-CLI search-replace ile URL’leri düzelt

7) SSL kur, yönlendirmeleri düzenle

8) Kalıcı bağlantılar, medya, mail, formlar test

9) Cache temizle, sonra kontrollü Web Site Hızlandırma uygula

Bu sırayla ilerlersen site taşıma işi temiz biter. Sıra bozulursa taşıma uzar, hata artar, sinir artar. WordPress’te taşımanın “klasik ve doğru” yolu budur.