cPanel’den DirectAdmin veya Plesk’e Geçiş Rehberi

cPanel’den DirectAdmin veya Plesk’e Geçerken Gerçek Risk Ne?

Kontrol paneli değiştirmek kağıt üzerinde basit görünür: cPanel’den backup al, DirectAdmin veya Plesk’e yükle, DNS’i güncelle ve yoluna devam et. Fakat canlı bir projede durum bu kadar kolay değil. SEO tarafında organik trafiği, e‑posta tarafında ise işinizin kalbini riske atıyorsunuz. Özellikle kurumsal siteler, e‑ticaret projeleri veya onlarca müşterisi olan ajanslar için 1–2 saatlik kesinti bile satış ve itibar kaybı anlamına gelebilir.

Bu yazıda, cPanel’den DirectAdmin veya Plesk’e geçişte SEO kaybı ve e‑posta kesintisi riskini azaltmak için adım adım bir plan sunuyoruz. DNS TTL planlamasından IMAP senkronizasyonuna, 301 yönlendirmelerden SPF/DKIM/DMARC doğrulamasına kadar hazırlık, geçiş ve izleme adımlarını ele alıyoruz. Amaç kesinti ve veri kaybı riskini azaltmaktır; sıfır kesinti veya sıralamaların değişmeyeceği garantisi değildir.

Dosya yolları, cron ve web sunucusu örnekleri Linux hedef ortamını esas alır. Plesk Windows/IIS hedefi ayrı bir uyarlama senaryosudur; aşağıdaki Linux adımları doğrudan uygulanmaz. Otomatik taşıma aracı kullanacaksanız kaynak-hedef panel sürümleri ve işletim sistemleri için desteğini ve aktarım kapsamını başlamadan önce doğrulayın.

cPanel’den Neden DirectAdmin veya Plesk’e Geçilir?

Önce motivasyonu netleştirelim. Neden yıllardır kullandığınız cPanel’i bırakıp DirectAdmin veya Plesk’e geçmek isteyebilirsiniz?

• Lisans ve maliyet: Panel lisans maliyetlerinde artış, özellikle çok hesaplı reseller veya VPS yapılarında toplam maliyeti yukarı çekebilir.
• Teknik tercih: Panelin kaynak gereksinimleri ve hedef işletim sistemiyle uyumu seçim kriterleriniz olabilir.
• Özellik seti: Git entegrasyonu, Node.js/Python desteği, gelişmiş yedekleme veya staging özellikleri gibi spesifik beklentileriniz olabilir.
• Altyapı standardizasyonu: Ajans veya SaaS tarafında, tüm sunucularda aynı panel tipine standartlaşmak operasyonu kolaylaştırır.

Gerekçeniz ne olursa olsun, değişmeyen bir şey var: SEO görünürlüğünüz ve e‑posta teslim edilebilirliğiniz bozulmamalı. Diğer uyumluluk ve operasyon gereksinimleri de geçiş öncesinde değerlendirilmelidir.

SEO Açısından Panel Değiştirmenin Gerçek Riskleri

Kontrol paneliniz doğrudan SEO faktörü değildir; Google “cPanel mi Plesk mi?” diye bakmaz. Ancak panel değişikliği sırasında yanlış alınan kararlar SEO’yu vurabilir. Dikkat edilmesi gereken ana başlıklar şöyle:

1. Uptime, TTFB ve sayfa hızındaki dalgalanmalar

Geçiş sırasında uzun süreli kesinti, Google bot’ların 5xx hataları görmesine neden olabilir. Kesintinin süresine ve kapsamına bağlı olarak tarama ve sıralama etkileri görülebilir. Ayrıca yeni sunucudaki PHP, veritabanı veya web sunucusu ayarları kötü yapılırsa TTFB yükselir, Core Web Vitals değerleriniz bozulabilir. Bu konuyu daha detaylı anlamak isterseniz Core Web Vitals ve hosting altyapısı rehberimize göz atabilirsiniz.

2. IP adresi ve sunucu lokasyonu değişimi

Panel geçişi genelde yeni bir VPS veya dedicated sunucuya alınarak yapılır. Bu da çoğu zaman IP adresinin ve bazen de veri merkezi lokasyonunun değişmesi anlamına gelir. Sunucu lokasyonu değiştiğinde, özellikle hedef kitlenizden uzak bir bölgeye geçiyorsanız gecikme artar, sayfa açılış süresi uzayabilir. Sunucu lokasyonunun SEO’ya etkisini anlattığımız rehberde doğru bölge seçimi konusunda detaylı öneriler bulabilirsiniz.

3. URL yapısı, 301 yönlendirmeler ve SSL

Panel değişimi sırasında PHP/Apache/Nginx yapılandırması farklı olabilir. Mevcut .htaccess veya Nginx rewrite kuralları hedef web sunucusuna uygun biçimde aktarılıp doğrulanmazsa:

• Eski URL’ler 404 verebilir,
• HTTP → HTTPS yönlendirmesi bozulabilir,
• www / non-www varyantları karışabilir.

Bu sorunlar tarama hatalarına ve zamanla organik trafik kaybına yol açabilir. Daha önce HTTP’den HTTPS’e geçiş rehberinde anlattığımız gibi, SSL ve 301 kuralları her zaman ilk kontrol edilmesi gereken noktalar.

4. robots.txt, sitemap.xml ve canonical etiketleri

Yeni panelde sitenizi farklı bir dizine, alt alan adına veya test domainine taşıyorsanız robots.txt ve sitemap.xml dosyalarının güncel kaldığından emin olmalısınız. Örneğin, test ortamındaki “Disallow: /” satırının yanlışlıkla canlı domain için kalmadığını kontrol edin. Sitemap URL’leri ve canonical etiketleri de test adreslerini değil, amaçlanan canlı URL’leri göstermelidir. robots.txt ve sitemap.xml rehberimiz, taşıma sonrası bu ayarları hızlıca doğrulamanıza yardımcı olacaktır.

DNS ve TTL Planlaması ile Kesintiyi Azaltma

SEO ve e‑posta tarafında en kritik alan DNS geçişi. IP adresini değiştirdiğiniz gün, DNS’inizi de güncelliyorsunuz. Geçiş planlı olsa bile DNS önbellekleri nedeniyle bir süre bazı ziyaretçiler eski, bazıları yeni sunucuya gidebilir. Bu yüzden geçiş boyunca her iki sunucunun erişim ve hata kayıtlarını izleyin.

1. TTL’i önceden düşürmek

Geçişten 24–48 saat önce, değişecek A/AAAA ve MX kayıtlarının TTL (Time To Live) değerlerini örneğin 3600 saniyeden 300 saniyeye (5 dakikaya) düşürün; eski TTL daha uzunsa hazırlığa daha erken başlayın. MX hedefinin IP’si değişecekse onun A/AAAA kayıtlarını da kapsayın. Düşük TTL’nin etkili olması için önceden önbelleğe alınmış kayıtların eski TTL süresinin dolması gerekir. Bu, önbellek yenilenmesini hızlandırabilir; ancak tüm istemcilerin birkaç dakika içinde yeni sunucuya geçeceğini garanti etmez. Bu konuda daha detaylı teknik akış görmek isterseniz Zero‑Downtime taşıma için TTL stratejileri yazımıza mutlaka göz atın.

2. DNS kayıtlarını envanterlemek

Geçişe başlamadan önce mevcut DNS kayıtlarınızın eksiksiz bir listesini çıkartın:

• A / AAAA kayıtları (web, panel, API vb.)
• CNAME kayıtları (www, CDN alt alanları, e‑posta servisleri)
• MX kayıtları (e‑posta yönlendirmesi)
• TXT kayıtları (SPF, DKIM, DMARC, doğrulama kayıtları)
• SRV, CAA vb. özel kayıtlar

Bu listeye kayıtlar arasındaki bağımlılıkları da ekleyin: MX hangi adı hedefliyor, bu adın A/AAAA kayıtları nerede yönetiliyor ve web ile aynı ad veya IP kullanılıyor mu? MX hedefi web ile aynı adsa o adın IP değişikliği posta teslimatını da etkiler. Yalnızca IP’nin ortak olması ise ayrı DNS adlarının birlikte güncellenmesini gerektirmez; eski IP’de hangi hizmetlerin açık kalacağını ayrıca planlayın. Genel DNS kavramlarına hâkim değilseniz DNS kayıtları A’dan Z’ye rehberimiz sağlam bir temel sunuyor.

Bu plan mevcut yetkili DNS hizmetini koruyarak kayıt değiştirmeyi esas alır. Yetkili DNS eski cPanel sunucusunda çalışıyorsa web ve posta taşındıktan sonra da DNS hizmetini ve bağlı olduğu sunucu/aboneliği açık tutun. Nameserver da değişecekse bölge aktarımı ve doğrulaması, delegasyon, gerekiyorsa glue kayıtları, varsa DNSSEC/DS geçişi ve eski-yeni DNS hizmetlerinin birlikte çalışacağı dönem için ayrıca plan hazırlayın. Bu ayrı geçiş tamamlanmadan eski yetkili DNS hizmetini kapatmayın. Harici e‑posta hizmeti aynı kalıyorsa posta kayıtlarını panel değişti diye değiştirmeyin.

3. Site bazında aşamalı geçiş

İmkânınız varsa yeni sunucudaki siteyi ayrı bir test alt alan adı altında (örneğin new.example.com) hazırlayın. Test ortamına genel erişimi kısıtlayın ve indekslenmesini önleyin; canlıya geçerken yalnızca önizleme için konan kısıtlamaları canlı siteden kaldırın. Test kopyasında üretim cron/kuyruk işlerini ve gerçek kullanıcılara bildirimleri kapalı tutun; posta testlerinde kontrollü alıcılar kullanın. Dosya ve veritabanlarını aktardıktan sonra, gerçek domaini de yeni sunucuda yapılandırıp hosts dosyanızda yeni IP’ye eşleyerek test edin; yalnızca test alt alanını denemek gerçek domainin yönlendirme ve sertifika davranışını doğrulamaz. Her şey yolunda ise DNS kayıtlarını site bazında sırayla güncelleyebilirsiniz: önce staging domainler, sonra az trafikli siteler, en son ana site. Bu yöntem tek bir domainin ziyaretçilerini kontrollü trafik gruplarına bölmek değildir.

Adım Adım cPanel → DirectAdmin / Plesk Taşıma Planı

1. Envanter ve ön analiz

İlk adımda sadece “kaç site var?” diye bakmak yetmez. Şu soruların hepsine net cevap vermek gerekiyor:

• Kaç adet domain ve alt domain yayınlanıyor?
• Hangi siteler WordPress, hangileri özel PHP/Laravel, hangileri statik?
• Kaç adet e‑posta hesabı var, günlük ortalama e‑posta hacmi nedir?
• Harici servislerle (ödeme sağlayıcısı, ERP, CRM, webhook vb.) entegrasyonlar neler?
• Özel cron job’lar, queue worker’lar, import/export script’leri var mı?

Bu listeyi çıkardıktan sonra kritik siteleri ve e‑posta kutularını işaretleyin. Bağımsız, düşük riskli bir siteyle pilot geçiş yapabilirsiniz; ancak taşıma sırasını yalnızca trafik miktarına göre değil, ortak DNS adları, veritabanları ve posta hizmetleri gibi bağımlılıklara göre belirleyin. Kritik varlıkları en sona bırakmak tek başına riski azaltmaz.

2. Yeni sunucuda DirectAdmin veya Plesk hazırlığı

Yeni sunucuda, önce panel kurulumunu ve temel sertleştirme adımlarını tamamlayın. Ardından:

• Hedef panel ve işletim sisteminde desteklenen PHP sürümleri ve handler’lar (php-fpm, lsphp vb.) yapılandırılır.
• Gerekirse çoklu PHP sürümü desteği açılır, her site için uygun sürüm planlanır. Bu konuda cPanel ve DirectAdmin’de çoklu PHP sürümü yönetimi yazımız size iyi bir rehber olur.
• Linux hedefte seçilen ve desteklenen web sunucusuna (Apache/Nginx/LiteSpeed) göre temel ayarlar yapılır.
• Kullanılan veritabanı sisteminin (MySQL/MariaDB veya PostgreSQL) sürüm uyumluluğu, karakter kümesi ve karşılaştırma düzeni (collation) kontrol edilir.
• Panel içi yedekleme ve loglama politikaları belirlenir.

Bu aşamada henüz DNS’i taşımıyoruz. Amaç, yeni paneli “gölge” ortamda üretime hazır hale getirmek.

3. Dosya ve veritabanı taşıma

Taşıma için tam hesap yedeğini kullanmak zorunda değilsiniz; manuel taşıma da bir seçenektir. Yöntemden bağımsız olarak, başlamadan önce dosyaları, veritabanlarını, e‑postaları ve gerekli ayarları kapsayan geri yüklenebilir yedekleri ayrı bir yerde saklayın.

Geri dönüş planını da bu aşamada yazın. Kabul edilebilir hata oranını, ödeme veya giriş gibi kritik akışların başarısızlık ölçütlerini ve müdahale süresini belirleyin; geçişi durdurma ya da geri dönme kararını verecek kişiyi atayın. Son eşitlemeye kadar eski ortam, doğrulama sonrasında yeni ortam yazmaya yetkili olsun; iki ayrı veri kopyasında eşzamanlı yazmaya izin vermeyin.

Geri dönüş gerekirse yazmaları, cron ve kuyruk işlerini kontrollü durdurun; iki ortamın güncel kopyalarını koruyun. Yeni ortamda oluşan siparişleri, dosyaları ve diğer değişiklikleri uygulamaya uygun yöntemle eski ortama uzlaştırıp doğrulamadan eski ortamda yazmayı açmayın. Çift sipariş veya ödeme işlemeyi önleyecek kontrolleri belirleyin. E‑postada yeni kutulara ulaşan mesajları da geri dönüş hedefiyle eşitleyin ve DNS önbellekleri nedeniyle iki tarafa gelen iletileri izleyin. Yalnızca DNS’i geri almak veya eski yedeği yüklemek yeni verileri korumaz; uzlaştırma doğrulanamıyorsa bakım durumunu sürdürün.

1. cPanel’den home dizini yedeği (public_html vb.) alın.
2. MySQL/MariaDB veritabanlarını mysqldump ile export edin; diğer veritabanı sistemleri için uygun dışa aktarma aracını kullanın.
3. DirectAdmin veya Plesk’te ilgili domainleri oluşturun.
4. Dosyaları yeni panele SFTP/rsync ile aktarın.
5. Veritabanlarını yeni sunucuya import edin, bağlantı yapılandırmalarını (DB host, user, şifre) güncelleyin. Bu ilk kopyadan sonra eski sunucuda oluşan değişiklikler de aktarılmalıdır. Canlıya geçmeden önce yazmaları ve arka plan işlerini kontrollü biçimde durdurup son dosya/veritabanı senkronizasyonunu tamamlayın; eski sunucuya gelen isteklerin ayrı bir veri kopyasına yazmasını önleyin.

Taşıma sonrası siteleri test etmek için gerçek domaini değiştirmek zorunda değilsiniz. Hosts dosyanıza yeni IP ve domain eşleşmesini ekleyerek tarayıcınızdan doğrudan yeni sunucuya bağlanabilirsiniz. Böylece geçişten önce kritik akışları (sepet adımları, ödeme, form gönderimi, admin girişi vb.) yeni sunucuda test edebilirsiniz. Ödeme testlerinde test modunu kullanın. Hosts eşleşmesi yalnızca kendi cihazınızı etkilediğinden, ödeme sağlayıcısının geri çağrıları gibi dış sistemlerden gelen istekleri ayrıca doğrulayın.

4. E‑posta taşıma stratejisi

E‑posta taşımada amaç yalnızca eski mesajları kopyalamak değil, geçiş sırasında gelen mesajların da yeni kutulara ulaşmasını sağlamaktır. Web ve e‑posta kesintilerinin etkisi işletmenin iş akışına göre değişir.

E‑posta tarafında temel adımlar:

• Önce yeni panelde tüm e‑posta hesaplarını IMAP kutularıyla birlikte oluşturun; kotaları, erişim bilgilerini, alias ve yönlendirmeleri, filtreleri ve otomatik yanıtları envanterle karşılaştırın. IMAP mesaj aktarımı bu ayarların taşındığını göstermez.
• Eski cPanel sunucusuyla yeni DirectAdmin/Plesk sunucusu arasında IMAP senkronizasyonu yapın; klasörleri ve mesajların aktarımını doğrulayın. Yalnızca kullanıcı cihazlarında saklanan postaları ayrıca envantere alın; sunucular arası IMAP aktarımı bunları kapsamaz. Eşitleme işlemi için iki sunucuya da yetkili erişim sağlayın.
• Postayı etkileyen MX veya hedef A/AAAA değişikliklerinden önce yeni sunucuda alım-gönderim testlerini ve kimlik doğrulama kontrollerini tamamlayın. Kullanıcıların bağlanacağı posta adlarıyla eşleşen güvenilir TLS sertifikalarını ve girişleri doğrulayın; gerekli erişim bilgilerini güvenli biçimde iletip istemci geçişini planlayın. MX hedefi web ile aynı adı kullanıyorsa bu hazırlık web DNS değişikliğinden de önce bitmelidir.

IMAP senkronizasyonu ve DNS geçişi hakkında ayrıntılar için cPanel e‑posta hesaplarını yeni sunucuya taşımak rehberimize mutlaka bakın. Daha genel bir perspektif için de e‑posta altyapısını taşırken kesinti yaşamamak yazımız iyi bir özet sunuyor.

5. SPF, DKIM, DMARC ve PTR kayıtlarını unutmamak

Yeni IP ve yeni panel demek, çoğu zaman SPF, DKIM, DMARC ve PTR kayıtlarını yeniden ele almak demektir. Bu kontroller atlanırsa taşıma sonrasında teslimat hataları veya spam klasörüne düşme riski artabilir.

• SPF: Yeni sunucu doğrudan e‑posta gönderecekse yeni gönderim IP’sini mevcut SPF politikasına ekleyin; eski IP’yi ancak eski sunucudan gönderim sona erdiğinde kaldırın.
• DKIM: Yeni sunucuda DKIM imzalamayı yapılandırın; yalnızca açık anahtarı ilgili selector._domainkey adı altında DNS’e TXT kaydı olarak yayımlayın. Anahtar değişiyorsa farklı bir selector kullanın. Test mesajında imzanın doğrulandığını kontrol edin; eski imzalı mesajların doğrulanması gerekebileceği sürece eski selector kaydını koruyun.
• DMARC: Panel geçişi nedeniyle mevcut politikayı otomatik olarak p=none’a indirmeyin; yeni gönderim yolunda SPF veya DKIM doğrulamasının görünür From alanıyla hizalı olduğunu test edin. Yeni kurulumda p=none ve raporlarla gözlem yapıp, meşru gönderim akışlarına göre quarantine veya reject politikasını değerlendirin.
• PTR (rDNS): Gönderim IP’sinin PTR kaydını posta sunucusunun tam alan adına yönlendirin; bu adın A/AAAA kaydı da aynı gönderim IP’sine dönmelidir. PTR değişikliğini IP’yi yöneten sağlayıcı üzerinden planlayın.

Bu yapıların tümünü adım adım ve pratik örneklerle görmek için SPF, DKIM, DMARC ve rDNS ile e‑posta teslim edilebilirliğini artırma rehberimizi inceleyebilirsiniz.

6. DNS cutover: Canlıya geçiş anı

Testler tamamlandıysa DNS envanterindeki bağımlılıklara göre canlıya geçin. Aşağıdaki web‑sonra‑posta sırası yalnızca kayıtlar ve hizmetler bağımsızsa uygulanır. Ortak ad kullanılıyorsa web IP değişikliğini aynı zamanda posta geçişi olarak planlayın; her iki hizmet de önceden hazır olmalıdır.

1. Yazmaları ve arka plan işlerini kontrollü durdurup son dosya/veritabanı eşitlemesini doğrulayın. Web A/AAAA kayıtlarını planlanan yeni adreslere yönlendirin; eski sunucuya gelen isteklerin eski veri kopyasına yazmasını engellemeyi sürdürün. Düşük TTL’ye rağmen önceki kayıtların önbellekte kalabileceğini hesaba katın.
2. Yeni ortamda kritik akışları ve 4xx/5xx hatalarını kontrol edin; doğrulama sonrası yalnızca yeni veri kopyasında yazmayı açın. Önceden belirlenen başarısızlık eşiğine ulaşılırsa atanan sorumlu geri dönüş planını başlatsın; DNS’i tek başına geri çevirmeyin.
3. Bağımsız posta geçişinde, hedef adı değişiyorsa MX kayıtlarını yeni posta sunucusunun adına yönlendirin ve bu adın A/AAAA kayıtlarını doğrulayın. MX hedef adı aynı kalıp IP’si değişiyorsa MX yerine ilgili A/AAAA kayıtlarını güncelleyin. Ortak web–MX hedef adı varsa bu IP değişikliği ilk adımda postayı da taşır; ayrı bir MX değişikliği beklemeyin.
4. Eski sunucuda SMTP alımını ve IMAP erişimini sürdürün; gecikmeli mesajları tekrarlanan IMAP senkronizasyonuyla yeni kutulara aktarın. İstemcilerin yeni gönderim ve erişim yolunu kullandığını da doğrulayın. Eski sunucuya teslimatlar sona ermeden, son eşitleme ve istemci geçişi doğrulanmadan eski posta hizmetini kapatmayın.

Cutover sürecini yoğun trafik saatleri dışında, mümkünse gece/geç saat veya hafta sonu (sizin hedef kitleniz için trafiğin en düşük olduğu an neyse) yapmak riski azaltır. Zamanlama konusunda kararsızsanız, yeni site yayına alma kontrol listemizdeki zamanlama önerileri işinize yarayacaktır.

cPanel → DirectAdmin Geçişinde Özel Dikkat Noktaları

DirectAdmin’e geçerken kaynak ihtiyacını ve yönetim kolaylığını hedef yapılandırmanız üzerinden değerlendirin. Ancak cPanel’den gelirken bazı farklara dikkat etmek gerekir:

• Hesap ve kullanıcı yapısı: cPanel’deki account yapısı ile DirectAdmin’deki kullanıcı/reseller yapısı birebir aynı değildir. Ajans veya reseller iseniz, hangi domainin hangi kullanıcıda açılacağına önceden karar verin.
• PHP selector ve handler farkları: Mevcut cPanel ortamınızdaki PHP sürümü seçimini, handler’ları ve varsa CloudLinux yapılandırmasını envantere alın; hedef DirectAdmin kurulumunda bunların karşılığını doğrulayın. WordPress, WooCommerce, Laravel gibi uygulamalarınız için uygun PHP sürümünü ve handler’ı taşıma öncesinde planlayın.
• Yedekleme formatı: Hedef DirectAdmin sürümündeki taşıma aracının cPanel full backup kapsamını doğrulayın. Karmaşık yapılarda dosya, veritabanı ve e‑posta için manuel taşıma da bir seçenektir; iki yöntemde de taşınan öğeleri envanterle karşılaştırın.
• Cron job yönetimi: cPanel’de tanımlı crontab girdilerini tek tek kontrol ederek DirectAdmin tarafında yeniden oluşturun. Zamanlama, PHP binary yolu ve dizin path’leri değişmiş olabilir.

cPanel → Plesk Geçişinde Özel Dikkat Noktaları

Plesk geçişinde önce hedef işletim sistemini netleştirin. Bu rehberin uygulama adımları Linux hedefini esas alır. Windows/IIS hedefi için uygulama ve taşıma yöntemi uyumluluğunu ayrı değerlendirin; staging testi, aracın desteklemediği bir kaynak-hedef eşleşmesini desteklenir hale getirmez.

• Windows/IIS uyarlaması: Seçilen aracın ilgili kaynak ve hedef sürümler ile işletim sistemlerini desteklediğini doğrulamadan otomatik aktarıma başlamayın. Windows hedefinde IIS site ve uygulama havuzlarını, PHP çalışma biçimini, dosya izinlerini, yolları, zamanlanmış görevleri ve bağımlılıkları ayrıca planlayın. Linux home/public_html yolları, cron girdileri ve Apache/Nginx kuralları doğrudan uygulanmaz. ASP.NET gereksinimi varsa onu da ayrı değerlendirin; kapsamlı staging testi yapın.
• Linux hedefte Apache/Nginx yapılandırması: Hangi web sunucusunun hangi istekleri işlediğini belirleyin ve mevcut .htaccess yönlendirmelerini test edin. Tüm rewrite kurallarını otomatik olarak Nginx’e taşımak yerine, yalnızca hedef mimaride gerekli olduğu doğrulanan uyarlamaları yapın.
• Git entegrasyonu ve deployment: Otomatik deploy kullanacaksanız hedef Plesk kurulumundaki Git desteğini ve iş akışınıza uygunluğunu doğrulayın. Git ile otomatik deploy rehberimizdeki akışı değerlendirebilirsiniz. Yeni otomasyonu taşıma ile aynı anda zorunlu kılmak yerine ayrı test edip aşamalı devreye alın.
• Mail sunucusu türü: Hedef Plesk sürümü ve işletim sisteminde desteklenen MTA seçeneklerini doğrulayın. MTA ve spam filtresi seçimini uyumluluk ve işletim gereksinimlerine göre yapın; teslim edilebilirliği yalnızca MTA seçimine bağlamayın.

SEO ve E‑Posta İçin Taşıma Sonrası Kontrol Listesi

Geçiş bittiğinde iş bitmiş sayılmaz. İlk 24–72 saat hem SEO hem e‑posta tarafında yakın takip için başlangıç penceresidir; DNS önbellekleri, posta kuyrukları ve arama raporlarındaki gecikmeler nedeniyle izlemeyi gerekirse uzatın. Trafik ve indeksleme eğilimlerini sonraki haftalarda da takip edin. Aşağıdaki kontrol listesi bu takip için kullanılabilir.

SEO kontrol listesi

• Site genelinde 4xx/5xx hata oranı: Web sunucu loglarını ve gerekiyorsa uygulama loglarını kontrol edin.
• HTTP → HTTPS, www ↔ non‑www yönlendirmeleri: Tarayıcı ve curl -I ile test edin.
• robots.txt içeriği: Canlı domain için istenmeyen “Disallow” kuralları kalmadığından emin olun.
• sitemap.xml erişimi: Arama motorlarına gönderilen sitemap URL’lerinin doğru domaini ve yolu gösterdiğini kontrol edin.
• Google Search Console: Tarama hataları, sunucu hataları ve indeks kapsamı raporlarını geçişten sonra özellikle sık takip edin.

E‑posta kontrol listesi

• MX kayıtlarının doğru hedefe işaret ettiğini doğrulayın.
• SPF, DKIM ve DMARC kayıtlarını online test araçları veya komut satırı ile test edin.
• PTR kaydının posta sunucusunun tam alan adını gösterdiğini ve bu adın A/AAAA kaydının gönderim IP’sine döndüğünü kontrol edin.
• Farklı sağlayıcılarla (Gmail, Outlook vb.) iki yönlü deneme e‑postaları gönderip alın; her iki tarafta teslimatı ve spam klasörünü kontrol edin.
• Kullanıcıların Outlook/Thunderbird/Mobile cihazlarında sunucu ismi, port ve TLS ayarlarını güncelleyip güncellemediğini takip edin.

Panel Geçişi İçin Örnek İş Planı

Panel geçişini yalnızca “backup al‑yükle” işlemi olarak değil, DNS, SEO, e‑posta ve uygulama mimarisi bir arada düşünülerek planlamak gerekir.

Örnek bir projede görevler şöyle sıralanabilir:

• Mevcut cPanel hesabının ve DNS kayıtlarının envanterini çıkarın.
• Yeni DirectAdmin veya Plesk ortamını ihtiyaçlara uygun kaynaklarla hazırlayın. VPS, dedicated veya colocation seçeneklerini değerlendirirken panel lisansı, işletim sistemi uyumluluğu ve yönetim sorumluluğunu belirleyin.
• Önce staging/test ortamına taşıma yapıp uygulama sorumlularıyla fonksiyonel testleri tamamlayın.
• E‑posta kaybı ve uzun kesinti riskini azaltmak için IMAP senkronizasyonunu, DNS TTL planını ve eski sunucunun kapatılma koşullarını birlikte belirleyin.
• Cutover sonrası SEO ve e‑posta metriklerini izleyin; tespit edilen sorunlara göre yapılandırmayı düzeltin.

Eğer panel değişikliği sizin için kritik bir adım ama nereden başlayacağınızı bilemiyorsanız, daha önce paylaştığımız cPanel’den cPanel’e canlı taşıma senaryosu, Plesk ↔ cPanel kesintisiz geçiş planı ve bu yazıda özetlediğimiz adımlar iyi bir başlangıç noktası olabilir.

Sonuç: Panel Geçişini Kontrollü Yönetin

cPanel’den DirectAdmin veya Plesk’e geçmek, doğru planlanmazsa SEO ve e‑posta tarafında ciddi sorunlara yol açabilir. Ama DNS TTL stratejisini önceden kurgulayıp, dosya ve veritabanı aktarımından sonra sitenin yeni sunucudaki çalışmasını hosts dosyası üzerinden test ederek, e‑postaları IMAP senkronizasyonu ve doğru SPF/DKIM/DMARC/PTR ayarlarıyla birlikte ele aldığınızda, geçişin kullanıcılar ve arama motorları üzerindeki olumsuz etkilerini azaltabilirsiniz.

Panel geçişinde hedef, hazırlık ve uygun otomasyonla kesintiyi ve hata riskini azaltmak olmalıdır. Eğer siz de cPanel’den DirectAdmin veya Plesk’e geçmeyi düşünüyorsanız, önce bu yazıdaki kontrol listesini kendi projenize uygulayın; dışarıdan destek alacaksanız taşıma kapsamını ve sorumlulukları önceden netleştirin. Amaç, panel değişikliği sırasında mevcut SEO performansını ve e‑posta itibarını korumaktır; panel değiştirmek tek başına bunları iyileştirmez.