Site Taşırken Hangi Dosyalar Taşınır? Eksiksiz Taşıma Listesi

Site taşırken hangi dosyalar taşınır sorusunun kısa cevabı "dosyalar ve veritabanı" değildir — o cevap yüzünden yılda binlerce taşıma yarım kalır. Site açılır, ana sayfa görünür, herkes rahatlar; üç gün sonra iletişim formundan mail gelmediği, bir hafta sonra otomatik yedeklerin çalışmadığı, iki hafta sonra ödeme bildirimlerinin ulaşmadığı fark edilir. Çünkü taşınan şey bir klasör değil, birbirine bağlı bir sistemdir: dosyalar, veritabanı, e-posta kutuları, zamanlanmış görevler, sertifikalar, DNS'teki doğrulama kayıtları ve sunucu seviyesindeki ayarlar.

Bu yazıda taşımanın tam envanterini çıkarıyorum. Her başlıkta ne taşınacağını, nerede durduğunu, hangi komutla alınacağını ve karşı tarafa nasıl konacağını yazdım. Özellikle Türkçe kaynaklarda hiç geçmeyen kalemlere yer verdim: nokta ile başlayan gizli dosyalar, cron listesi, e-posta kutularının içeriği, SSL özel anahtarı, DNS'te yaşayan SPF/DKIM/doğrulama TXT kayıtları ve dosya izinleri. Sonunda da taşıma bitince tek tek işaretleyebileceğiniz bir kontrol listesi var.

Taşınacak Şeyler Beş Katmanda Toplanır#

Taşımayı kalem kalem düşünmek yerine katman katman düşünmek daha az şey unutturur. Beş katman şudur:

İlk ikisi herkesin bildiği kısımdır. Taşımaların bozulduğu yer neredeyse her zaman son üç katmandır. Aşağıda hepsini ayrı ayrı ele alıyorum.

1. Katman: Site Dosyaları ve Gizli Dosyalar#

Site dosyaları public_html dizininde durur ama taşınması gereken tek dizin o değildir.

public_html içinde ne var:

• Tema, eklenti, kod, index.php gibi uygulama dosyaları
• wp-content/uploads ya da image/catalog gibi medya klasörleri
• Alt alan adı klasörleri (bazı yapılandırmalarda public_html/blog gibi)

Nokta ile başlayan gizli dosyalar — en çok unutulan kalem. FTP istemcileri bu dosyaları varsayılan olarak göstermez. FileZilla'da Sunucu → Gizli Dosyaları Göstermeyi Zorla seçeneğini işaretlemezseniz aşağıdaki dosyaların hiçbirini indirmezsiniz ve site karşı tarafta çalışmaz:

Bu yüzden dosya taşımasını FTP yerine arşivleyerek yapmak çok daha güvenlidir. cPanel Dosya Yöneticisi'nde public_html üzerine sağ tıklayıp Compress demek ya da SSH'ta:

cd ~
tar -czf site-yedek.tar.gz public_html

tar gizli dosyaları içerir; FTP'nin filtresi diye bir şey tanımaz. SSH erişiminiz varsa iki sunucu arasında doğrudan aktarım en hızlısıdır:

rsync -avz --progress -e ssh ~/public_html/ [email protected]:~/public_html/

-a izinleri ve zaman damgalarını korur, -z sıkıştırır. Aktarım yarıda kesilirse aynı komutu tekrar çalıştırmanız yeterlidir; kalan yerden devam eder.

Ev dizinindeki public_html dışı içerik: Birçok kurulumda public_html dışında da veri vardır — özel yedek klasörleri, logs, Composer'ın vendor dizininin dışarı alınmış hâli, SSH anahtarları (~/.ssh). Ev dizinini bir kez listeleyip gözden geçirin:

ls -la ~
du -sh ~/* | sort -h

İkinci komut hangi klasörün ne kadar yer kapladığını gösterir; beklenmedik büyüklükte bir klasör görürseniz mutlaka bakın.

2. Katman: Veritabanı ve Veritabanı Kullanıcıları#

Veritabanı FTP ile inmez. Bunu bilmeyen çok kişi public_html klasörünü indirip "yedeğim var" sanıyor; oysa WordPress'in yazıları, OpenCart'ın ürünleri, tüm siparişler veritabanındadır.

Dışa aktarma — SSH varsa:

mysqldump -u kullanici -p --single-transaction --default-character-set=utf8mb4 veritabani_adi > veritabani.sql
gzip veritabani.sql

--single-transaction InnoDB tablolarında siteyi kilitlemeden tutarlı bir kopya alır. --default-character-set=utf8mb4 yazmazsanız Türkçe karakterler bozulabilir — taşıma sonrası "ÅŸ" gibi karakterler görüyorsanız sebebi budur.

SSH yoksa phpMyAdmin: Dışa Aktar → Özel → Sıkıştırma "gzip" → Karakter kümesi utf-8. Büyük veritabanlarında tarayıcı zaman aşımına uğrarsa tabloları gruplar hâlinde dışa aktarın ya da cPanel'in yedekleme aracını kullanın.

Unutulan kısım: veritabanı kullanıcısı ve yetkileri. SQL dosyası yalnızca veriyi taşır; kullanıcı adı, şifre ve yetkiler yeni sunucuda yoktur. Yeni sunucuda kullanıcıyı elle oluşturup veritabanına bağlamanız gerekir. cPanel'de bu MySQL Veritabanları ekranında "Veritabanına Kullanıcı Ekle" bölümüdür ve ALL PRIVILEGES işaretlenmelidir. SSH'ta:

CREATE DATABASE yenidb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'yeniuser'@'localhost' IDENTIFIED BY 'guclu-sifre';
GRANT ALL PRIVILEGES ON yenidb.* TO 'yeniuser'@'localhost';
FLUSH PRIVILEGES;

⚠️ cPanel'de veritabanı ve kullanıcı adları hesap adıyla öneklenir (hesapadi_wp gibi) ve hesap adı değiştiği için isimler yeni sunucuda farklı olur. Bu yüzden wp-config.php, configuration.php ya da .env içindeki bağlantı bilgilerini elle güncellemeniz gerekir. Taşıma sonrası "veritabanı bağlantı hatası" almanın bir numaralı sebebi budur.

Birden fazla veritabanı olabilir. Sitede forum, ikinci bir uygulama ya da eski bir kurulum varsa listeyi kontrol edin:

mysql -u kullanici -p -e "SHOW DATABASES;"

3. Katman: E-posta Kutuları ve Ayarları#

Bu, taşımanın en çok atlanan ve en pahalıya patlayan katmanıdır. E-posta hesapları veritabanında değildir, public_html içinde değildir; sunucunun posta dizininde durur.

Taşınması gereken beş ayrı şey var:

1. Hesap listesi ve şifreler. Yeni sunucuda aynı adreslerin aynı şifrelerle açılması gerekir, yoksa kullanıcıların Outlook/telefon ayarları çalışmaz.
2. Kutuların içeriği. Gelen kutusu, Gönderilenler, arşiv klasörleri — yıllara yayılan yazışma. cPanel'de /home/kullanici/mail/alanadi.com/kullanici yolunda Maildir biçiminde durur.
3. Yönlendirmeler (forwarder). info@ adresinin Gmail'e gitmesi gibi kurallar panel ayarıdır, dosya değildir.
4. Otomatik yanıtlayıcılar ve filtreler. Tatil mesajları, spam kuralları.
5. Kotalar. Hangi kutunun kaç GB olduğu.

Kutu içeriğini taşıma yolları:

• En kolay: IMAP üzerinden. Thunderbird gibi bir istemciye hem eski hem yeni hesabı IMAP olarak ekleyip klasörleri sürükleyerek kopyalarsınız. Küçük kutular için pratiktir, on binlerce mailde çok yavaştır.
• En sağlıklı: cPanel-to-cPanel tam hesap transferi. Bu yöntem posta kutularını, şifreleri, yönlendirmeleri ve filtreleri birlikte taşır.
• SSH varsa: Maildir dizinini doğrudan kopyalamak:

rsync -avz ~/mail/ [email protected]:~/mail/

Bu yöntem sonrası yeni sunucuda hesapların panelde de tanımlı olması gerekir; sadece dosya kopyalamak yetmez, çünkü şifre bilgisi ayrı bir yerde tutulur.

Kritik zamanlama uyarısı: E-posta taşımasında sıra önemlidir. MX kaydı hâlâ eski sunucuyu gösterirken gelen yeni mailler eski kutuya düşer. Doğru sıra: kutuları kopyala → MX kaydını değiştir → propagasyon süresince gelen birkaç maili ikinci bir kopyalamayla al. Bu ikinci geçişi yapmazsanız geçiş penceresinde gelen mailler eski sunucuda kalır ve kimse fark etmez.

4. Katman: Cron Görevleri ve Arka Plan Süreçleri#

Cron görevleri hiçbir dosya yedeğinde yer almaz. Kimse taşımaz, kimse sormaz ve site "çalışıyor" göründüğü için sorun aylarca fark edilmez.

Cron'da tipik olarak ne vardır: yedek alma betikleri, XML ürün besleme güncellemeleri, e-posta kuyruğu işleyicileri, önbellek temizleme, WordPress'in gerçek wp-cron alternatifi, ödeme mutabakat betikleri.

Listeyi almak için cPanel'de Cron İşleri ekranındaki tabloyu ekran görüntüsüyle kaydedin. SSH varsa:

crontab -l > cron-yedek.txt
cat cron-yedek.txt

Yeni sunucuda geri yüklemek:

crontab cron-yedek.txt
crontab -l   # dogrulama

⚠️ Cron satırlarındaki yollar yeni sunucuda değişir. /home/eskihesap/public_html/betik.php yolu yeni sunucuda /home/yenihesap/public_html/betik.php olur. Satırları olduğu gibi yapıştırırsanız görevler sessizce başarısız olur — cron hata verdiğinde ekrana bir şey yazmaz, çıktıyı e-postayla gönderir ve o e-posta da genelde okunmaz. Yeni sunucuda her satırı elle gözden geçirin ve PHP yolunun da doğru olduğundan emin olun:

which php
/usr/local/bin/php -v

Cron dışında arka planda çalışan başka şeyler de olabilir: supervisor ile yönetilen kuyruk işçileri, systemd servisleri, Node.js uygulamaları için PM2 süreçleri. VDS taşıyorsanız bunları da listeleyin:

systemctl list-units --type=service --state=running
pm2 list

Ayrıca deploy akışınız cPanel Git sürüm kontrolü üzerinden çalışıyorsa depo bağlantısı ve dağıtım ayarları yeni sunucuda yeniden kurulmalıdır; .git dizinini kopyalamak tek başına deploy akışını geri getirmez.

5. Katman: SSL, DNS Kayıtları ve Alan Adı Bağları#

Bu katman "sunucuda dosya" olmadığı için envanterden düşer, sonra da taşımadan sonraki güvenlik uyarılarının ve kaybolan maillerin sebebi olur.

SSL sertifikası. Üç parçadan oluşur: sertifika (cert.pem / .crt), özel anahtar (privkey.pem / .key) ve ara sertifika zinciri (chain.pem / CA bundle). cPanel'de SSL/TLS → Sertifikaları Yönet ekranından üçünü de kopyalayabilirsiniz. Özel anahtar bir daha üretilemez; kaybederseniz sertifikayı yeniden almanız gerekir.

Let's Encrypt kullanıyorsanız pratikte kopyalamaya gerek yoktur — yeni sunucuda DNS geçişinden sonra otomatik yeniden alınır. Ama ücretli/OV/EV sertifika kullanıyorsanız anahtar ve sertifikayı mutlaka alın. VDS'te dosya yolları:

ls -l /etc/letsencrypt/live/orneksite.com/
# cert.pem  chain.pem  fullchain.pem  privkey.pem

Ayrıca CSR dosyanız duruyorsa saklayın; sertifika yenilemede yeniden üretmek yerine kullanılabilir.

DNS'te yaşayan ama sunucuda görünmeyen kayıtlar. Alan adının DNS bölgesinde, hiçbir dosya yedeğinde bulunmayan kritik kayıtlar vardır:

Nameserver değiştiriyorsanız bunların hiçbiri kendiliğinden gelmez. Mevcut bölgeyi geçiş öncesi kaydedin:

dig orneksite.com ANY +noall +answer
dig TXT orneksite.com +short
dig TXT default._domainkey.orneksite.com +short
dig MX orneksite.com +short

ANY sorgusu birçok sunucuda artık tam liste vermez; bu yüzden kayıt tiplerini tek tek sorgulamak daha güvenilirdir. En temiz yol, eski DNS panelinden bölge dosyasını dışa aktarmaktır — cPanel'de bu WHM tarafında, kayıt kaydınız varsa DNS yönetim panelinizde "Zone Export" olarak geçer.

Alan adı bağları: Ek alan adları (addon domain), park edilmiş alan adları ve alt alan adı tanımları yeni hesapta yeniden oluşturulmalıdır. Her birinin hangi klasöre baktığını not edin; addon domain'lerin belge kökü genelde public_html/ikincisite.com gibi bir alt klasördür ve yanlış eşleştirilirse iki site birbirinin içeriğini gösterir.

Dosya İzinleri, Sahiplik ve PHP Sürümü#

Dosyalar taşındı, veritabanı yerinde, ama site "500 Internal Server Error" veriyorsa bu bölüme bakın.

İzinler. ZIP/tar ile taşırken çoğu zaman korunur, FTP ile taşırken korunmaz — FTP izin bilgisini taşımaz ve dosyalar sunucunun varsayılan izinleriyle oluşur. Doğru değerler:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 ~/public_html/wp-config.php

Klasörler 755, dosyalar 644, hassas yapılandırma dosyaları 600. 777 asla kullanmayın; paylaşımlı sunucularda 777 izinli bir dosya diğer hesaplardan yazılabilir hâle gelebilir ve birçok sunucu bu dosyaları çalıştırmayı reddeder.

Sahiplik (VDS'te). Dosyaları root olarak açtıysanız sahiplik root'ta kalır ve web sunucusu okuyamaz:

chown -R www-data:www-data /var/www/orneksite.com   # Debian/Ubuntu + Nginx/Apache
chown -R apache:apache /var/www/orneksite.com        # AlmaLinux/Rocky

PHP sürümü ve eklentileri. Yeni sunucudaki PHP sürümü eskisinden farklıysa site bozulabilir. Eski sunucuda çalışan sürümü öğrenin ve yeni sunucuda eşitleyin:

php -v
php -m   # yuklu eklentiler

Sitenin ihtiyaç duyduğu ama yeni sunucuda eksik olan bir eklenti (imagick, soap, intl, zip, mbstring) varsa uygulama beyaz ekran verir. cPanel'de PHP eklentileri Select PHP Version ekranından işaretlenir. Sürüm farkı büyükse geçişten önce test ortamında denemek gerekir.

PHP limitleri. memory_limit, upload_max_filesize, post_max_size, max_execution_time değerleri sunucudan sunucuya değişir. Eski değerleri not alın:

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

Taşıma Sonrası Kontrol Listesi#

Aşağıdaki listeyi taşımanın son adımı olarak tek tek işaretleyin. Her satır, gerçek bir taşımada gerçekten atlanmış bir kalemdir.

Dosya ve veri

1. public_html tamamı taşındı, gizli dosyalar dahil (.htaccess, .env, .user.ini, .well-known)
2. Ev dizinindeki public_html dışı klasörler gözden geçirildi
3. Tüm veritabanları dışa aktarıldı ve içe alındı, satır sayıları karşılaştırıldı
4. Veritabanı kullanıcısı oluşturuldu, yetkiler verildi, bağlantı dosyası güncellendi
5. Türkçe karakterler doğru görünüyor (utf8mb4 kontrolü)

E-posta

6. Tüm hesaplar aynı adres ve şifreyle yeniden oluşturuldu
7. Kutu içerikleri kopyalandı
8. Yönlendirmeler, otomatik yanıtlar ve filtreler yeniden tanımlandı
9. MX geçişinden sonra ikinci kopyalama yapıldı

Otomasyon

10. Cron listesi alındı, yollar güncellenerek yeni sunucuya kuruldu
11. Arka plan servisleri (supervisor, PM2, systemd) yeniden kuruldu

Kimlik ve ağ

12. SSL sertifikası, özel anahtar ve zincir taşındı ya da yeniden alındı
13. SPF, DKIM, DMARC ve doğrulama TXT kayıtları yeni DNS bölgesine eklendi
14. Addon/park/alt alan adları yeniden tanımlandı, belge kökleri doğrulandı

Sunucu ortamı

15. PHP sürümü ve eklentileri eşitlendi
16. Dosya izinleri 755/644'e getirildi, sahiplik düzeltildi
17. .htaccess ya da Nginx yapılandırması test edildi, iç sayfalar açılıyor

Son doğrulama

18. Site hosts dosyasıyla yeni sunucuda test edildi (DNS'e dokunmadan)
19. Formlar, ödeme akışı ve mail gönderimi denendi
20. Eski sunucu en az bir hafta açık tutuluyor

Son madde tartışmasızdır. Taşıma bittiği gün eski hesabı kapattırmayın; propagasyon süresince bazı ziyaretçiler hâlâ eski sunucuya gider ve orada üretilen veriyi (form kaydı, sipariş, mail) kaybedersiniz. Taşıma sırasında kesinti olup olmayacağı konusundaki asıl kural budur: kesinti, iki sunucu bir süre birlikte çalıştığında ortadan kalkar.

Sıkça Sorulan Sorular#

Site taşırken sadece public_html klasörünü almak yeterli mi#

Hayır, tek başına asla yeterli değildir. public_html yalnızca kod ve medya dosyalarını içerir; sitenin yazıları, ürünleri, siparişleri, kullanıcıları veritabanındadır ve o ayrı bir dışa aktarma işlemidir. Ayrıca e-posta kutuları, cron görevleri, SSL sertifikası ve DNS kayıtları da public_html içinde bulunmaz. Yalnızca klasörü taşıyarak site açılabilir ama içi boş görünür veya doğrudan veritabanı bağlantı hatası verir.

FTP ile indirdiğimde .htaccess dosyası neden görünmüyor#

Çünkü FTP istemcileri nokta ile başlayan dosyaları varsayılan olarak gizler. FileZilla'da Sunucu menüsündeki "Gizli Dosyaları Göstermeyi Zorla" seçeneğini işaretlemeniz gerekir; benzer bir ayar diğer istemcilerde de bulunur. Bu ayarı yapmadan indirdiğiniz yedekte .htaccess, .env, .user.ini ve .well-known klasörü eksik kalır. Bu dosyaları kaçırmamanın en güvenli yolu, sunucuda tar ya da panelin sıkıştırma aracıyla arşiv oluşturup arşivi indirmektir.

Veritabanı FTP ile taşınabilir mi#

Hayır, veritabanı FTP ile taşınamaz çünkü dosya sistemi üzerinde erişilebilir bir yerde durmaz; MySQL sunucusunun kendi veri dizinindedir ve paylaşımlı hostingde o dizine erişiminiz yoktur. Veritabanını taşımak için phpMyAdmin'den dışa aktarma, cPanel yedekleme aracı ya da SSH varsa mysqldump komutu kullanılır. Elde ettiğiniz .sql dosyasını yeni sunucuda oluşturduğunuz boş veritabanına içe aktarırsınız. İçe aktarmadan önce hedef veritabanının karakter kümesinin utf8mb4 olduğundan emin olun.

E-posta kutularındaki eski mailler taşınır mı#

Otomatik olarak taşınmaz, ayrıca kopyalanması gerekir. Panelde e-posta hesabını yeniden oluşturmak yalnızca boş bir kutu açar; içindeki yıllara yayılan yazışma eski sunucunun posta dizininde kalır. İçerik taşımanın üç yolu vardır: IMAP üzerinden bir e-posta istemcisiyle sürükleyerek kopyalamak, panelin hesap transferi özelliğini kullanmak ya da SSH ile mail dizinini rsync ile aktarmak. MX kaydını değiştirdikten sonra da geçiş penceresinde eski sunucuya düşen mailler için ikinci bir kopyalama yapmalısınız.

Cron görevleri kendiliğinden yeni sunucuya geçer mi#

Hayır, cron görevleri hiçbir dosya ya da veritabanı yedeğinin içinde yer almaz ve elle taşınması gerekir. Eski sunucuda cPanel'in Cron İşleri ekranındaki listeyi kaydedin ya da SSH'ta crontab -l komutuyla dışa aktarın. Yeni sunucuda satırları eklerken dosya yollarını mutlaka güncelleyin, çünkü hesap adı değiştiği için /home/eskihesap/... yolu artık geçersizdir. Cron başarısız olduğunda ekrana hata vermez, çıktıyı e-postayla gönderir; bu yüzden taşımadan sonra görevlerin çalıştığını log dosyasından doğrulayın.

SSL sertifikası yeni sunucuya taşınabilir mi#

Evet, sertifika ve özel anahtar dosyalarını kopyalayarak taşıyabilirsiniz; ücretli sertifikalarda yapılması gereken de budur. Sertifikanın üç parçasını da almanız gerekir: sertifikanın kendisi, özel anahtar ve ara sertifika zinciri. Özel anahtarı kaybederseniz sertifika kullanılamaz hâle gelir ve yeniden düzenletmek zorunda kalırsınız. Let's Encrypt kullanıyorsanız kopyalamaya gerek yoktur; DNS geçişi tamamlandıktan sonra yeni sunucuda ücretsiz sertifika otomatik olarak yeniden alınır.

Taşımadan sonra site açılıyor ama iç sayfalar 404 veriyor#

Bu neredeyse her zaman .htaccess dosyasının taşınmamasından kaynaklanır. Ana sayfa index.php üzerinden doğrudan açıldığı için çalışır, ancak iç sayfaların çalışması yeniden yazma kurallarına bağlıdır ve o kurallar .htaccess içindedir. Dosya gerçekten yerindeyse ikinci ihtimal, yeni sunucuda Apache'nin mod_rewrite modülünün etkin olmaması ya da AllowOverride ayarının kapalı olmasıdır. WordPress'te hızlı bir kontrol olarak Ayarlar → Kalıcı Bağlantılar ekranında hiçbir şey değiştirmeden Kaydet'e basmak .htaccess dosyasını yeniden üretir.

Eski hosting hesabını ne zaman kapatabilirim#

Taşıma bittikten sonra en az bir hafta, mümkünse iki hafta bekleyin. DNS değişikliği anında yayılmaz; bazı ağların çözümleyicileri eski kaydı TTL süresi boyunca ve bazen daha uzun süre önbellekte tutar, bu sürede o ziyaretçiler eski sunucuya gider. Hesabı erken kapatırsanız bu ziyaretçiler için site tamamen erişilemez olur ve o dönemde eski sunucuya düşen form kayıtları, siparişler ve mailler kaybolur. Kapatmadan hemen önce eski sunucudan tam bir yedek daha alıp yerelinizde saklamak da iyi bir alışkanlıktır.

Kapanış#

Site taşıma, bir klasörü kopyalama işi değil, beş katmanlı bir envanterin eksiksiz aktarılmasıdır: dosyalar (gizli olanlar dahil), veritabanı ve kullanıcı yetkileri, e-posta kutuları ve kuralları, cron görevleriyle arka plan süreçleri, son olarak SSL ile DNS'te yaşayan doğrulama kayıtları. Taşımaların çoğu ilk iki katmanda başarılı olur ve son üçünde sessizce yarım kalır — site açık göründüğü için de sorun haftalar sonra, form maili gelmediğinde ya da otomatik yedek çalışmadığında fark edilir. Yukarıdaki 20 maddelik listeyi taşımanın sonunda tek tek işaretlemek, bu sessiz kayıpların hemen hepsini önler.

Bu envanteri kendiniz çıkarmak istemiyorsanız site taşıma hizmeti dosyaları, veritabanını, posta kutularını ve DNS geçişini birlikte yürütür; siz yalnızca kontrol edersiniz. Yeni bir paket seçme aşamasındaysanız paylaşımlı hosting paketleri tipik kurumsal ve WordPress siteleri için, VDS sunucular ise PHP sürümü, cron ve servis yönetimini kendiniz kontrol etmek istediğiniz projeler için uygundur. Taşıma sırasında ve sonrasında güvenlik ağı olarak yedekleme hizmeti, e-posta tarafını ayrı bir altyapıya almak isterseniz kurumsal e-posta çözümleri süreci belirgin biçimde kolaylaştırır.