cPanel’den DirectAdmin veya Plesk’e Geçişte SEO ve E‑Postayı Korumak

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 DCHost ekibi olarak, cPanel’den DirectAdmin veya Plesk’e geçişi SEO ve e‑posta kesintisi yaşamadan nasıl planladığımızı, sahada kullandığımız adım adım stratejiyi anlatacağım. DNS TTL planlamasından, IMAP senkronizasyonuna; 301 yönlendirmelerden SPF/DKIM/DMARC doğrulamasına kadar net ve uygulanabilir bir yol haritası hedefliyoruz. Amacımız şu: Panel değişikliğini, Google ve e‑posta servis sağlayıcıları için neredeyse “görünmez” hale getirmek.

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: Bazı ekipler DirectAdmin’in hafifliğini, bazıları ise Plesk’in Windows ve Linux dünyasını bir arada yönetebilmesini seviyor.
• Ö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ı. Kalan her şey, doğru planlamayla çözülebilir.

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. Bu da özellikle sık taranan sitelerde kısa vadede sıralama oynamaları yaratır. 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ı olduğundan, .htaccess veya Nginx rewrite kuralları birebir taşınmazsa:

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

Bu da kısa sürede tarama hataları ve organik trafikte düşüş anlamına gelir. 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. Yanlışlıkla canlı domain için “Disallow: /” satırı bırakan çok proje gördük. 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 Sıfıra Yakın Kesinti

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. Bunu plansız yaparsanız bazı ziyaretçiler eski sunucuya, bazıları yeni sunucuya gider; siz de hangi tarafta ne olduğunu takip edemezsiniz.

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

Geçişten 24–48 saat önce, A/AAAA ve MX kayıtlarınızın TTL (Time To Live) değerlerini örneğin 3600 saniyeden 300 saniyeye (5 dakikaya) düşürün. Böylece DNS yayılımı hızlanır, cutover anında en fazla birkaç dakikalık gecikmeler yaşarsınız. 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 listeyi manuel tutmak yerine, bir kez düzgün hazırlayıp saklamak ileride yaşayabileceğiniz pek çok sorunu daha başlamadan çözer. Genel DNS kavramlarına hâkim değilseniz DNS kayıtları A’dan Z’ye rehberimiz sağlam bir temel sunuyor.

3. Aşamalı geçiş (blue/green yaklaşımı)

İmkânınız varsa yeni paneli aynı domain için ayrı bir alt alan adı altında (örneğin new.example.com) ayağa kaldırın. Tüm dosya ve veritabanlarını taşıdıktan sonra, hosts dosyanızı kullanarak sadece kendi bilgisayarınızdan bu alt alanı test edin. Her şey yolunda ise DNS’i bir anda değil, belirli trafik gruplarını taşıyarak (örneğin önce staging domainler, sonra az trafikli siteler, en son ana site) güncelleyebilirsiniz.

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. Taşıma sırasında bu kritik varlıkları en son taşıyarak riskinizi azaltabilirsiniz.

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

DCHost üzerinde alacağınız yeni VPS veya dedicated sunucuda, önce panel kurulumunu ve temel sertleştirme adımlarını tamamlıyoruz. Ardından:

• 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.
• Web sunucusu (Apache/Nginx/LiteSpeed) tercihine göre temel optimizasyonlar yapılır.
• MySQL/MariaDB veya PostgreSQL sürümü ve charset/colation ayarları 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

cPanel tarafında her bir hesap için full backup almak zorunda değilsiniz; özellikle panel tipleri farklıysa manuel taşıma çoğu zaman daha temiz olur.

1. cPanel’den home dizini yedeği (public_html vb.) alın.
2. Veritabanlarını mysqldump ile export edin.
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.

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 bütün kritik akışları (sepet adımları, ödeme, form gönderimi, admin girişi vb.) test etmiş olursunuz.

4. E‑posta taşıma stratejisi

Panel değişimlerinde en çok korkulan kısım e‑postadır. Çünkü web sitesinde 10 dakikalık kesinti tolere edilebilir; ama o sırada gelen bir iş teklifi e‑postası kaybolursa telafisi yok.

E‑posta tarafında yaklaşımımız net:

• Önce yeni panelde tüm e‑posta hesaplarını IMAP kutularıyla birlikte oluşturun.
• Eski cPanel sunucusuyla yeni DirectAdmin/Plesk sunucusu arasında IMAP senkronizasyonu yapın.
• MX kayıtlarını en son dakikada, planlanan bakım penceresinde değiştirin.

Bu konuyu pratikte nasıl yaptığımızı, adım adım ekran görüntüleriyle görmek isterseniz 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. Aksi halde taşıma sonrası ilk fark edeceğiniz şey “E‑postalarım spam’e düşmeye başladı.” cümlesi olur.

• SPF: Yeni IP’yi SPF kaydınıza ekleyin, eskiyi gereksizse kaldırın.
• DKIM: DirectAdmin veya Plesk üzerinde DKIM anahtarını oluşturup DNS’e TXT kaydı olarak ekleyin.
• DMARC: Geçiş döneminde politikayı p=none’da tutup raporları analiz ettikten sonra quarantine veya reject’e çekmek çoğu zaman daha güvenlidir.
• PTR (rDNS): IP’nizin reverse DNS kaydını, gönderim yaptığınız ana domain ile eşleştirin.

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ı

Her şey test edildiyse sıra A/AAAA ve MX kayıtlarını yeni IP ve mail sunucusuna yönlendirmeye geliyor.

1. Önce web için A/AAAA kayıtlarını güncelleyin. TTL düşük olduğu için birkaç dakika içinde çoğu kullanıcı yeni sunucuya gitmeye başlayacaktır.
2. Sunucu loglarını izleyerek 4xx/5xx hatalarını takip edin. Her şey yolundaysa sıradaki adım e‑posta.
3. Daha sonra MX kayıtlarını yeni mail sunucusuna yönlendirin. Eski sunucuda kısa süre daha IMAP erişimini açık tutarak, gecikmeli gelen mailleri de yakalayı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 genellikle daha hafif ve sade bir yapı sunar. Ancak cPanel’den gelirken bazı farklara dikkat etmek gerekir:

• Hesap/hane 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ı: cPanel’de CloudLinux + MultiPHP ile alışkın olduğunuz yapı, DirectAdmin’de farklı modüllerle sağlanır. WordPress, WooCommerce, Laravel gibi uygulamalarınız için uygun PHP sürümünü ve handler’ı taşıma öncesinde planlayın.
• Yedekleme formatı: cPanel full backup dosyalarını DirectAdmin’e doğrudan import eden script’ler olsa da, karmaşık yapılarda manuel taşıma (dosya + DB + mail) çoğu zaman daha kontrollü sonuç verir.
• 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 özellikle Windows ve Linux sunucuları birlikte yöneten ekipler için cazip. Yine de cPanel’den geçerken dikkat etmeniz gereken bazı başlıklar var:

• Windows vs Linux farkı: cPanel’den Plesk Windows’a geçiyorsanız, PHP/ASP.NET uygulama havuzları, dosya izinleri ve path yapısında ciddi farklar vardır. Bu durumda önce staging ortamında kapsamlı test yapmak şart.
• Apache + Nginx reverse proxy mimarisi: Plesk, varsayılan olarak Apache önünde Nginx kullanan bir yapı sunabilir. Bu, .htaccess kurallarınızın çalışma şeklini etkileyebilir; gerekli rewrite’ları Nginx tarafına taşımayı unutmayın.
• Git entegrasyonu ve deployment: Plesk’in Git entegrasyonu, otomatik deploy için oldukça pratiktir. Daha önce Git ile otomatik deploy rehberimizde Plesk tarafındaki akışı detaylı anlatmıştık. Panel geçişi yaparken bu otomasyonu da aynı anda kurmayı düşünebilirsiniz.
• Mail sunucusu türü: Plesk’te Postfix, qmail gibi farklı MTA seçenekleri bulunur. E‑posta teslim edilebilirliği tarafında hedeflediğiniz seviyeye göre uygun MTA’yı ve spam filtresi yapısını seçin.

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ından takip etmeniz gereken bir dönemdir. DCHost’ta taşıma projelerinde kullandığımız pratik kontrol listesini paylaşalım.

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 doğru domaini gösterdiğini kontrol edin.
• Farklı sağlayıcılardan (Gmail, Outlook vb.) deneme e‑postaları alıp spam klasörüne düşüp düşmediğini test edin.
• Kullanıcıların Outlook/Thunderbird/Mobile cihazlarında sunucu ismi, port ve TLS ayarlarını güncelleyip güncellemediğini takip edin.

DCHost ile Panel Geçişini Nasıl Kurguluyoruz?

DCHost tarafında cPanel, DirectAdmin ve Plesk’in tamamı ile çalışan altyapılar yönetiyoruz. Bu yüzden panel geçişlerini sadece “backup al‑yükle” mantığıyla değil, DNS, SEO, e‑posta ve uygulama mimarisi bir arada düşünülerek planlıyoruz.

Tipik bir projede şu adımları beraber yürütüyoruz:

• Mevcut cPanel hesabınızın ve DNS kayıtlarınızın envanterini çıkarıyoruz.
• Yeni DirectAdmin veya Plesk ortamınızı, ihtiyaçlarınıza uygun kaynaklarla (VPS, dedicated veya colocation üzerinde) hazırlıyoruz.
• Önce staging/test ortamına taşıma yapıp sizinle beraber fonksiyonel testler gerçekleştiriyoruz.
• IMAP senkronizasyonu ve DNS TTL planlaması ile, e‑posta kaybı ve uzun kesinti riskini en aza indiriyoruz.
• Cutover sonrası SEO ve e‑posta metriklerini birlikte izleyip, gerekiyorsa ince ayarları hızlıca yapıyoruz.

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ç: Paneli Değiştirin, Arka Planda Kalsın

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ı taşımayı hosts dosyası üzerinden test ederek, e‑postaları IMAP senkronizasyonu ve doğru SPF/DKIM/DMARC/PTR ayarlarıyla birlikte ele aldığınızda; bu geçiş kullanıcılarınız ve Google için neredeyse “görünmez” hale gelir.

DCHost olarak biz, panel değişikliğini bir yazılım güncellemesi kadar sıradanlaştırmayı hedefliyoruz: Arka planda ciddi hazırlık ve otomasyon, ön tarafta ise minimum kesinti ve risksiz bir deneyim. 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; ardından bizimle iletişime geçerek projenizi birlikte planlayalım. Böylece panel değişikliğini, SEO skorlarınızı ve e‑posta itibarınızı yükseltecek bir fırsata dönüştürebilirsiniz.