WordPress Sitesini Baska Alan Adina Klonlama

Bir WordPress sitesini "klonlamak", o sitenin birebir bir kopyasını farklı bir alan adında ya da alt alan adında (subdomain) yeniden ayağa kaldırmak demektir. Amaç, aynı temayı, aynı eklentileri, aynı içeriği ve aynı veritabanını yeni bir adreste, sıfırdan kurmadan çalışır hale getirmektir. Bir müşterinin sitesini kendi sunucunuzda demo olarak açmak, canlı siteden bağımsız bir test ortamı hazırlamak, aynı tasarımı yeni bir marka için başlangıç noktası yapmak ya da bir siteyi kademeli olarak yeni bir domaine geçirmek — bunların hepsi klonlamanın günlük hayattaki karşılığıdır.

Buradaki en kritik ayrım şudur: klonlama, taşımanın (migration) aksine kaynak siteyi olduğu gibi bırakır. Taşımada eski site kapanır, DNS yeni sunucuya çevrilir ve tek bir "canlı" kopya kalır; klonlamada ise iki ayrı, birbirinden bağımsız site oluşur. Bu yazıda klonlama ile taşımanın farkını, Duplicator ve All-in-One WP Migration gibi eklentilerle klonlamayı, dosya ve veritabanını elle kopyalayarak manuel klon almayı, WP-CLI search-replace veya Better Search Replace ile URL güncellemeyi ve serileştirilmiş (serialized) veriyi bozmadan koruma yöntemini kıdemli bir sistem yöneticisi gözüyle anlatacağım. Son bölümde ise klondan sonra en çok atlanan adımı — arama motorlarının kopyayı indekslemesini engellemeyi — ele alacağız.

Klonlama ile Taşıma Arasındaki Fark#

İki kavram sık sık karıştırılır ama sonuçları tamamen farklıdır. Taşıma tek bir siteyi bir yerden bir yere götürür; işlem bittiğinde kaynak genellikle kapatılır. Klonlama ise kaynağı yerinde tutarak ikinci bir örnek üretir. Bu ayrım hem teknik adımları hem de sonrasında yönetmeniz gereken riskleri değiştirir.

En büyük risk, iki sitenin aynı içeriğe sahip olmasıdır. Arama motorları aynı metni iki farklı adreste görürse bunu "yinelenen içerik" (duplicate content) olarak değerlendirebilir; bu da SEO açısından istenmeyen bir durumdur. Bu yüzden bir klonun neredeyse her zaman ya arama motorlarına kapatılması ya da kalıcı olacaksa canonical etiketlerle yönetilmesi gerekir. Taşımada böyle bir sorun yoktur çünkü ortada tek bir yayın vardır.

Aşağıdaki tablo iki yaklaşımı özetliyor:

Eğer amacınız siteyi tümden yeni bir hosting'e götürmekse, klonlama değil taşıma yapmanız gerekir; bunun kesintisiz yolunu web sitesi taşıma rehberinde ayrıntılı anlattık. Bu yazıda odağımız, kaynağı koruyarak ikinci bir kopya üretmektir.

Klonlamanın Yaygın Kullanım Senaryoları#

Klonlamayı ne zaman tercih edeceğinizi bilmek, yöntem seçimini de kolaylaştırır. Pratikte en çok karşılaştığım senaryolar şunlardır:

• Müşteri demosu. Bir ajansın canlı sitesini kendi sunucunuzda demo.siteniz.com gibi bir subdomainde çoğaltıp müşteriye "işte önerdiğimiz değişiklikler" diye göstermek.
• Riskli değişiklik denemesi. Büyük bir tema veya WooCommerce güncellemesini canlıda denemeden önce bir kopyada test etmek. Bu iş için kalıcı bir çözüm istiyorsanız WordPress yedekleme alışkanlığıyla birlikte bir staging kurgusu düşünmelisiniz.
• Şablon çoğaltma. Zincir bir işletmenin her şubesi için aynı tasarımı temel alıp içerikleri değiştirmek. Klon, sıfırdan kurmaktan çok daha hızlıdır.
• Alan adı değiştirme. Markanız eskiad.com'dan yeniad.com'a geçiyorsa, önce yeni domainde birebir kopya kurar, test eder, sonra eski adresten 301 yönlendirme yaparsınız.

Bu senaryoların ortak noktası, hedef adresin kaynaktan farklı olmasıdır. İşte bu "farklı adres" meselesi klonlamanın en teknik kısmını doğurur: WordPress, site adresini veritabanına gömülü şekilde binlerce yerde saklar. Kopyayı alıp bırakmak yetmez; tüm bu adresleri yeni domaine göre güncellemeniz gerekir. Buna gelmeden önce klondan önce yapılması gereken hazırlığa bakalım.

Klonlamadan Önce Hazırlık#

Aceleyle alınan klon, en çok "yarı çalışan" bir kopya üretir: ana sayfa açılır ama görseller kırıktır, yönetici paneline girilemez ya da form gönderimleri eski adrese gider. Bunları önlemenin yolu, başlamadan önce eksiksiz bir envanter çıkarmaktır.

İlk olarak kaynak sitenin tam bir yedeğini alın — hem dosyalar hem veritabanı. Klon işlemi kaynağa dokunmasa da, bir eklentinin dışa aktarma sırasında hata vermesi ihtimaline karşı elinizde güncel bir yedek bulunması şarttır. İkinci olarak PHP ve veritabanı sürümlerini not edin: hedef sunucudaki PHP sürümü kaynaktan çok eskiyse klon "beyaz ekran" verebilir. Üçüncü olarak siteye özel sabit kodlanmış (hardcoded) URL'ler var mı diye düşünün — bazı temalar ya da özel kodlar alan adını doğrudan dosyaların içine yazmış olabilir.

Manuel yöntem kullanacaksanız komut satırında hangi bilgilere ihtiyaç duyacağınızı önceden toplayın:

# Kaynak sitenin wp-config.php dosyasindan alacaklariniz
# DB_NAME     -> veritabani adi
# DB_USER     -> veritabani kullanicisi
# DB_PASSWORD -> veritabani parolasi
# DB_HOST     -> genellikle localhost
# $table_prefix -> tablo oneki (ornegin wp_ ya da wp_a1b2_)

Tablo önekini ($table_prefix) mutlaka not edin; birçok güvenlik eklentisi bunu wp_ yerine rastgele bir değere çevirir ve manuel klonda bu ayrıntı gözden kaçarsa hiçbir tablo tanınmaz. Envanteriniz hazırsa artık yöntem seçebiliriz. Önce en kolay yol olan eklentiyle klonlamaya bakalım.

Yontem 1 - Eklentiyle Klonlama#

Teknik olmayan kullanıcılar ve orta ölçekli siteler için en pratik yol, bu iş için tasarlanmış bir eklenti kullanmaktır. İki popüler seçenek Duplicator ve All-in-One WP Migration'dır; ikisi de klonlamayı "paketle ve aç" mantığıyla iki adıma indirger.

Duplicator çalışma mantığı olarak siteyi tek bir arşive ve küçük bir installer.php dosyasına paketler. Adımlar şöyledir: kaynak sitede Duplicator ile bir paket oluşturursunuz, üretilen arşiv ile installer.php dosyasını hedef alan adının kök dizinine yüklersiniz, sonra tarayıcıdan https://yeniad.com/installer.php adresini açarsınız. Kurulum sihirbazı sizden hedef veritabanı bilgilerini ister ve en güzel yanı, kurulum sırasında eski URL'yi yeni URL ile değiştirmeyi kendisi teklif eder:

Eski URL:  https://eskiad.com
Yeni URL:  https://yeniad.com
Eski yol:  /home/eskikullanici/public_html
Yeni yol:  /home/yenikullanici/public_html

Bu ekranda değerleri doğru girerseniz, Duplicator veritabanındaki tüm adresleri serileştirilmiş veriyi bozmadan güncellemeyi üstlenir — bu, manuel yöntemin en riskli kısmını sizin yerinize halleder.

All-in-One WP Migration ise daha da basittir: kaynak sitede "Export" ile tek bir .wpress dosyası indirirsiniz, hedef sitede boş bir WordPress kurup aynı eklentiyle "Import" edersiniz. İçe aktarma bittiğinde eklenti URL değişikliğini otomatik yapar. Tek dezavantajı, ücretsiz sürümde içe aktarma boyut sınırıdır; büyük sitelerde bu sınır için ya premium uzantı ya da başka bir yöntem gerekir.

Eklenti yöntemi için pratik ipuçları:

• Hedef alan adında boş ama çalışan bir WordPress kurulumu hazır olsun (import yöntemi bunu gerektirir).
• Paket/arşiv boyutu büyükse hosting'in upload_max_filesize ve max_execution_time değerlerini geçici olarak yükseltin.
• Klon bittikten sonra kalıcı bağlantıları (Ayarlar > Kalıcı Bağlantılar) tek tıkla yeniden kaydedin; bu, .htaccess kurallarını yeni siteye göre tazeler.

Eklenti yöntemi çoğu durumda yeter. Ancak siteniz çok büyükse, hosting kaynaklarınız kısıtlıysa ya da tam kontrol istiyorsanız manuel klonlama daha güvenilirdir.

Yontem 2 - Manuel Klonlama (Dosya ve Veritabani)#

Manuel klon üç parçadan oluşur: dosyaları kopyalamak, veritabanını kopyalamak ve yeni sitenin wp-config.php dosyasını yeni veritabanına bağlamak. URL güncellemesini ise ayrı bir adımda yapacağız (bir sonraki bölüm).

1. Dosyaları kopyalayın. Aynı sunucuda subdomain klonu alıyorsanız SSH ile rsync en temiz yoldur:

# Kaynak dizinden hedef dizine tum WordPress dosyalarini kopyala
rsync -av --exclude 'wp-content/cache' \
  /home/kullanici/public_html/ \
  /home/kullanici/demo.siteniz.com/

Farklı sunuculara kopyalıyorsanız kaynak dizini tar ile paketleyip aktarın:

# Kaynakta arsivle
tar -czf site.tar.gz -C /home/kullanici/public_html .
# Hedefte ac
tar -xzf site.tar.gz -C /home/yeni/public_html

2. Veritabanını dışa/içe aktarın. mysqldump ile kaynak veritabanını alıp hedefte oluşturduğunuz boş veritabanına yükleyin:

# Kaynak veritabanini disa aktar
mysqldump -u eskikullanici -p eski_db > site.sql

# Hedefte yeni bos bir veritabanina yukle
mysql -u yenikullanici -p yeni_db < site.sql

3. wp-config.php dosyasını düzenleyin. Yeni site kök dizinindeki wp-config.php içinde veritabanı bilgilerini yeni değerlere çevirin:

define( 'DB_NAME', 'yeni_db' );
define( 'DB_USER', 'yenikullanici' );
define( 'DB_PASSWORD', 'yeni_guclu_parola' );
define( 'DB_HOST', 'localhost' );

$table_prefix = 'wp_';  // kaynaktakiyle AYNI olmali

Bu üç adımdan sonra klon "teknik olarak" ayağa kalkar ama henüz kullanılamaz: veritabanının içindeki bütün adresler hâlâ eskiad.com'u işaret eder. Yönetici paneline girmeye çalışırsanız muhtemelen sizi eski siteye yönlendirir. İşte bu yüzden bir sonraki adım — URL güncelleme — manuel klonun kalbidir.

URL'leri Guncelleme - Search-Replace ve Serialize Veri#

WordPress site adresini onlarca tabloda saklar: wp_options içindeki siteurl ve home, yazı ve sayfa içeriklerindeki görsel/link URL'leri, eklenti ayarları, menü öğeleri ve daha fazlası. Bunların hepsini elle değiştiremezsiniz. Ama bir kritik tuzak var: WordPress bazı verileri serileştirilmiş (serialized) PHP dizileri olarak saklar ve bu dizilerde her metnin uzunluğu bilgisi de gömülüdür. Basit bir "bul ve değiştir" SQL sorgusu (UPDATE ... REPLACE(...)) bu uzunluk bilgisini güncellemez; sonuç bozuk bir seri dizisi ve çalışmayan bir eklenti olur.

Bu yüzden asla düz SQL REPLACE çalıştırmayın. Doğru araçlar serileştirilmiş veriyi ayrıştırıp, metni değiştirip, uzunluğu yeniden hesaplayıp geri paketler. En güvenilir iki yöntem şunlardır.

WP-CLI ile search-replace (önerilen). SSH erişiminiz varsa bu, en hızlı ve en güvenli yoldur. --dry-run ile önce sadece kaç değişiklik yapılacağını görürsünüz, emin olunca gerçek çalıştırırsınız:

# Once deneme (hicbir sey yazilmaz, kac eslesme oldugunu gosterir)
wp search-replace 'https://eskiad.com' 'https://yeniad.com' --dry-run

# Gercek degistirme (serialize veriyi guvenle korur)
wp search-replace 'https://eskiad.com' 'https://yeniad.com' \
  --all-tables --skip-columns=guid

Burada iki bayrak önemlidir. --skip-columns=guid, yazıların guid alanına dokunmamayı sağlar; guid bir kalıcı tanımlayıcıdır ve değiştirilirse RSS okuyucuları içeriği "yeni" sanabilir, resmi WordPress önerisi de bu alanı değiştirmemek yönündedir. --all-tables ise eklentilerin kendi tablolarını da kapsamaya yarar.

Better Search Replace eklentisi (SSH yoksa). Komut satırına erişiminiz yoksa bu ücretsiz eklenti aynı işi yönetici panelinden yapar. Eklentiyi kurar, "Search" alanına https://eskiad.com, "Replace" alanına https://yeniad.com yazar, değiştirilecek tabloları seçer ve mutlaka önce "Run as dry run" kutusu işaretliyken çalıştırırsınız. Kaç satırın etkileneceğini görüp emin olduktan sonra işareti kaldırıp gerçek değişimi yaparsınız. Bu eklenti de serileştirilmiş veriyi doğru işler.

URL değişiminde dikkat edeceğiniz noktalar:

• http ve https farkına dikkat edin; kaynak http ile çalışıyorsa ve yeni sitede SSL kullanacaksanız https://eskiad.com yerine http://eskiad.com aramanız gerekebilir. Yeni sitede SSL için ücretsiz Let's Encrypt SSL seçeneklerini değerlendirin.
• www olan ve olmayan varyantları ayrı ayrı çalıştırmanız gerekebilir.
• Değişimden sonra kalıcı bağlantıları yeniden kaydedin ve varsa önbellek eklentisinin önbelleğini temizleyin.

Bu adımdan sonra klon artık yeni adresinde kendi başına çalışan bağımsız bir sitedir. Geriye, en çok atlanan ama en önemli iş kalıyor: kopyanın arama motorlarına yansımasını engellemek.

Klon Sonrasi Indeksleme Onlemleri ve Kontroller#

Klonunuz bir demo, test ya da geçici kopyaysa, arama motorlarının onu indekslemesini kesinlikle istemezsiniz. Aksi halde demo.siteniz.com ile asıl siteniz Google'da yan yana çıkar, yinelenen içerik yüzünden ikisi de zarar görür. Önlem birkaç katmanlıdır.

İlk ve en kolay katman, WordPress'in kendi ayarıdır: kopyanın yönetici panelinde Ayarlar > Okuma > "Arama motorlarının siteyi dizine eklemesini engelle" kutusunu işaretleyin. Bu, robots meta etiketini noindex yapar. Ancak bu tek başına yeterince güçlü bir garanti değildir; sunucu düzeyinde de destekleyin.

İkinci katman, robots.txt ile taramayı engellemektir. Kopyanın kök dizinine şu içerikte bir robots.txt koyabilirsiniz:

User-agent: *
Disallow: /

Daha kesin bir yöntem, klonu bir subdomainde tutuyorsanız web sunucusu seviyesinde noindex başlığı göndermektir. Nginx için:

# demo.siteniz.com icin tum yanitlara noindex ekle
location / {
    add_header X-Robots-Tag "noindex, nofollow" always;
    try_files $uri $uri/ /index.php?$args;
}

En sağlam yol ise klonu tamamen dış dünyaya kapatmaktır — örneğin HTTP temel kimlik doğrulaması (basic auth) ile parola arkasına almak. Böylece hem arama motorları hem yetkisiz ziyaretçiler dışarıda kalır. Sunucu tarafı korumaları için bir WAF katmanı da düşünebilirsiniz.

Eğer klon kalıcı olacak ve gerçekten yayında kalacaksa (örneğin marka değişikliği), o zaman noindex yerine farklı bir strateji izlersiniz: eski adresten yeni adrese 301 kalıcı yönlendirme kurar ve yeni sitede doğru canonical etiketlerin çalıştığından emin olursunuz. Bu, arama motoruna "asıl adres burası" mesajını verir. Marka geçişinin SEO tarafını SEO hizmetleri sayfamızdaki uzmanlarla planlamak, sıralama kaybını en aza indirir.

Son olarak klonun sağlığını kontrol edin:

• Görseller ve CSS düzgün yükleniyor mu? Kırık görsel genelde URL değişiminin eksik yapıldığının işaretidir.
• Yönetici paneline girebiliyor musunuz? Giremiyorsanız siteurl/home değerleri hâlâ eski adresi gösteriyor olabilir.
• İç bağlantılar ve formlar yeni adrese mi gidiyor? Kırık iç bağlantıları bulmak için bir tarama aracı ya da eklenti kullanın.
• E-posta gönderen eklentiler (iletişim formu, WooCommerce) klonda gerçek müşterilere mail atmasın diye devre dışı bırakıldı mı?

Bu kontrolleri geçen klon, kaynağınızı hiç etkilemeden yanında güvenle yaşar.

Sikca Yapilan Hatalar#

Yıllar içinde onlarca klon işleminde tekrar tekrar aynı hataların yapıldığını gördüm. Bunları önceden bilmek çoğu sorunu ortaya çıkmadan önler.

En sık hata, veritabanında düz SQL REPLACE çalıştırıp serileştirilmiş veriyi bozmaktır; sonuç, ayarları kaybolmuş eklentiler ve çalışmayan sayfa oluşturuculardır. Çözüm, her zaman WP-CLI search-replace ya da Better Search Replace kullanmaktır. İkinci sık hata, tablo önekini ($table_prefix) gözden kaçırmaktır — güvenlik eklentisi öneki değiştirmişse ve wp-config.php'de eski öneki bırakırsanız site "veritabanı bağlantı hatası" verir.

Üçüncüsü, klonu indekslemeye açık unutmaktır; haftalar sonra Google'da demo sitenin çıktığını fark etmek can sıkıcıdır. Dördüncüsü, aktif eklentileri klonda kapatmadan bırakıp gerçek müşterilere test e-postaları göndermektir. Beşincisi ise klon alırken kaynak sitenin yedeğini almamaktır; klon kaynağa dokunmaz ama Murphy yasası her zaman iş başındadır. Bu hataların ortak çözümü, işe düzenli bir yedekleme disiplini ve bir kontrol listesiyle başlamaktır.

Sıkça Sorulan Sorular#

Klonlama kaynak siteme zarar verir mi?#

Hayır, doğru yapıldığında kaynak site hiç etkilenmez. Klonlama yalnızca dosya ve veritabanının bir kopyasını okur; kaynağa yazma yapmaz. Yine de bir eklentinin dışa aktarma sırasında beklenmedik biçimde davranma ihtimaline karşı, klon almadan önce kaynağın tam bir yedeğini almak en doğru alışkanlıktır. Böylece en kötü senaryoda bile geri dönüşünüz hazır olur.

Aynı içerik iki sitede olunca Google beni cezalandırır mı?#

Doğrudan bir "ceza" nadirdir ama yinelenen içerik arama motorlarının hangi adresi göstereceğini şaşırtır ve ikisinin de sıralamasını zayıflatabilir. Bu yüzden bir demo veya test klonunu mutlaka noindex ile arama motorlarına kapatın. Klon kalıcı olacaksa, eski adresten yeni adrese 301 yönlendirme kurar ve tek bir asıl adresi canonical ile işaret edersiniz; böylece iki kopya arasında rekabet oluşmaz.

URL değiştirmek için neden düz SQL sorgusu kullanamıyorum?#

Çünkü WordPress bazı verileri serileştirilmiş PHP dizileri olarak saklar ve bu dizilerde her metnin karakter uzunluğu da kayıtlıdır. Basit bir SQL REPLACE metni değiştirir ama uzunluk bilgisini güncellemez; sonuçta dizinin yapısı bozulur ve o veriyi kullanan eklenti çalışmaz hale gelir. WP-CLI search-replace ve Better Search Replace gibi araçlar diziyi çözüp değiştirip yeniden paketlediği için uzunluk her zaman doğru kalır.

SSH erişimim yoksa klonlamayı nasıl yaparım?#

SSH olmadan da rahatça klonlayabilirsiniz. En kolay yol Duplicator veya All-in-One WP Migration gibi bir eklentiyle paketleyip hedef alan adında içe aktarmaktır; bu eklentiler URL değişimini de otomatik yapar. URL güncellemesini elle yapmanız gereken durumlarda ise Better Search Replace eklentisi, WP-CLI'ın yaptığı serileştirme-güvenli değişimi tamamen yönetici panelinden yapmanızı sağlar.

Klonu farklı bir hosting sağlayıcısında açabilir miyim?#

Evet. Manuel yöntemde dosyaları tar ile paketleyip yeni sunucuya taşır, veritabanını mysqldump ile alıp hedefte içe aktarır, wp-config.php'yi yeni veritabanına bağlar ve URL değişimini yaparsınız. Eklenti yöntemi de sağlayıcıdan bağımsız çalışır. Farklı sunucuda PHP ve MySQL sürümlerinin uyumlu olduğundan emin olmanız yeterlidir; uyumsuz sürümler klonun beyaz ekran vermesinin başlıca sebebidir.

Klonlama ile staging aynı şey mi?#

Yakın akrabalar ama aynı değiller. Staging, canlı sitenin değişiklikleri test etmek için tutulan ve sonra genelde canlıya geri "push" edilen özel bir kopyasıdır; genellikle hosting paneli bunu tek tuşla yönetir. Klonlama ise daha genel bir kavramdır — kopyayı test için de kullanabilir, tamamen bağımsız yeni bir site olarak da bırakabilirsiniz. Her staging bir tür klondur, ama her klon staging amacıyla alınmaz.

Kapanış#

WordPress klonlama, doğru sırayla yapıldığında karmaşık değildir: kaynağın yedeğini al, dosya ve veritabanını kopyala, wp-config.php'yi yeni veritabanına bağla, URL'leri serileştirme-güvenli bir araçla güncelle ve kopyayı arama motorlarından koru. Bu beş adımı içselleştirdiğinizde ister bir müşteri demosu, ister riskli bir güncelleme testi, isterse marka değişikliği olsun her senaryoyu güvenle yönetirsiniz. En büyük iki tuzağı — düz SQL REPLACE ile serileştirilmiş veriyi bozmak ve klonu indekslemeye açık unutmak — hatırladığınız sürece işlem sorunsuz ilerler.

Klonlarınızı hızlı çalışan, NVMe diskli ve ücretsiz SSL'li bir zeminde barındırmak isterseniz WordPress hosting paketlerimiz tam bu iş için hazırlandı; daha fazla kaynak gerektiren büyük siteler için sanal sunucu ve VDS çözümlerimize göz atabilirsiniz. Klonu kalıcı bir domaine taşıyacaksanız alan adı kaydı, düzenli kopyalar için yedekleme hizmeti ve sunucu tarafını bize bırakmak isterseniz sunucu yönetimi desteğimiz hep bir tık uzağınızda. Sorularınız için destek ekibimiz her zaman yanınızda.