cPanel Addon Domain ve Ayrı Hesap Karşılaştırması

cPanel kullanan hemen herkesin bir noktada sorduğu kritik bir soru var: Yeni alan adını addon domain olarak mı eklemeliyim, yoksa tamamen ayrı bir cPanel hesabı mı açmalıyım? Bu karar ilk bakışta basit bir kullanım tercihi gibi görünse de, arka planda güvenlik, performans, yedekleme ve ileride taşıma (migrasyon) süreçlerini doğrudan etkileyen bir mimari karardır. Çok sayıda siteyi aynı hesapta toplamak, ortak erişim yetkileri ve kaynak limitleri nedeniyle güvenlik ve taşıma süreçlerini karmaşıklaştırabilir. Bu yazıda, addon domain ve ayrı hesap seçeneklerini güvenlik, performans, yönetilebilirlik ve taşıma kolaylığı açısından adım adım karşılaştıracağız. Farklı trafik seviyeleri, ajans/freelancer senaryoları, e‑ticaret ve kurumsal siteler gibi pratik örnekler üzerinden, kendi projeleriniz için hangi yaklaşımın daha mantıklı olacağını netleştirmenize yardımcı olacağız.

cPanel’de Addon Domain ve Ayrı Hesap Tam Olarak Ne Demek?

Bağımsız bir ek web sitesini mevcut hesabın addon domain’i olarak veya ayrı bir cPanel hesabında yönetebilirsiniz. Aynı içeriği başka adla göstermek ise domain alias/parked domain konusudur; ziyaretçiyi başka URL’ye gönderen 301 yönlendirmesiyle aynı işlem değildir.

• Addon domain: Ek alan adı mevcut cPanel hesabına ve onun yönettiği dosya/ağ hizmetlerine bağlıdır. Bağımsız içerik için ayrı document root seçilir; hesap sahibi bütün siteleri yönetebilir.
• Ayrı cPanel hesabı: WHM’de gerekli yetkiye sahip yönetici veya reseller ayrı kullanıcı ve hesap oluşturur. Standart cPanel kullanıcısı bu yetkiye otomatik sahip değildir; sağlayıcıdan ayrı hosting hesabı da alınabilir. Kaynak kotaları, işlem sınırları ve izolasyonun kapsamı kurulum ve plana bağlıdır.

Aşağıdaki klasörler örnektir; gerçek document root’u Domains ekranından doğrulayın. Güncel cPanel arayüzünde bağımsız site için ana sitenin document root’unu paylaşma seçeneği kullanılmaz. İzin verilen kök konumlarını sürüm ve sağlayıcı ayarları belirler; güncel Create a New Domain belgesi bu arayüzde public_html dışına çıkılamayacağını belirtir. Bir klasörü başka adrese bağlamak, dosyaları taşımak veya güvenlik sınırı oluşturmak değildir.

• public_html/ — ana domaininiz
• public_html/yeni-site/ — addon domain için klasör

Ayrı hesapta her kullanıcının kendi ev dizini ve hesap yapılandırması olur. public_html, tmp ve logs gibi yolların tam yerini kurulumda kontrol edin. Ayrı hesabın içinde de birden fazla site bulunabilir; “bir proje, bir hesap” bilinçli bir yerleşim tercihidir. Paylaşımlı hosting, reseller ve VPS/dedicated seçiminde hesap sayısı, lisans, yönetim yetkisi ve uygulanan limitleri birlikte değerlendirin.

Güvenlik Açısından: Addon Domain mi, Ayrı Hesap mı?

Asıl fark, uygulamaların hangi kullanıcı ve servis yetkileriyle çalıştığıdır. Aynı hesaptaki ayrı klasörler, o hesap yetkisini ele geçiren bir uygulamaya karşı bağımsız güvenlik sınırı sağlamaz. Ayrı hesaplar da ortak sunucu, servis veya hatalı izin riskini kendiliğinden kaldırmaz.

Dosya Sistemi ve Kullanıcı İzolasyonu

Addon domain senaryosunda aynı cPanel hesabı altındaki tüm siteler aynı Linux kullanıcı hesabını paylaşır. Bu ne demek?

• PHP süreçlerinin etkili kullanıcısını, FTP/SSH yetkilerini ve uygulama erişimlerini ayrı inceleyin; bunların hepsi aynı kapsamda olmak zorunda değildir.
• Aynı sistem kullanıcısıyla çalışan sitelerde klasör ayırmak yeterli değildir. Saldırganın kod çalıştırabildiği kullanıcı, izin verilen diğer site dosyalarını okuyabilir veya değiştirebilir.
• Her uygulama zafiyeti sistem kullanıcısı düzeyinde kod yürütme sağlamaz; gerçek etkiyi zafiyet ve erişim yetkileri belirler.

Her siteyi ayrı bir cPanel hesabına yerleştirdiğinizde, her hesabın ayrı bir sistem kullanıcısı olur. Kullanıcı sınırı alan adı değil, hesaptır. Bu sayede:

• Dosya izinleri ve kullanıcı izolasyonu doğru yapılandırıldığında, bir sitedeki zafiyet üzerinden diğer sitelerin dizinlerine doğrudan erişme riski azalır.
• SSH/SFTP erişimlerini site bazında kısıtlamak ve loglamak çok daha sağlıklı olur.
• Yetki yönetimini (örneğin ajans, geliştirici, içerikçi erişimi) daha ince ayarlı kurabilirsiniz.

Bu konuyu daha derinlemesine ele aldığımız cPanel güvenlik sertleştirme kontrol listemize de mutlaka göz atmanızı öneririz.

Web Uygulaması Zafiyetleri ve Zincirleme Etki

Varsayımsal bir senaryo üzerinden gidelim: Aynı cPanel hesabında üç siteniz var; biri kişisel blog, biri küçük bir e‑ticaret sitesi, diğeri de basit bir tanıtım sayfası. Blogda kullanılan eski bir eklentide dosya yükleme zafiyeti bulunduğunu ve bunun saldırgana sunucuda kod çalıştırma olanağı verdiğini varsayalım. SQL injection gibi zafiyetlerin etkisi ise erişilebilen veritabanı yetkilerine bağlıdır; her zafiyet dosya sistemine erişim sağlamaz.

• Addon domain senaryosunda saldırgan, aynı kullanıcı altında çalışan diğer sitelerin dizinlerine, configuration.php, wp-config.php gibi kritik dosyalara ulaşmaya çalışır.
• Veritabanı şifreleri, SMTP bilgileri veya API anahtarları ele geçirilirse, saldırgan bunların sağladığı yetkilerle diğer sitelere ve hizmetlere de zarar verebilir.
• Ayrı hesap senaryosunda ayrı kullanıcılar ve doğru yapılandırılmış erişim izinleri, saldırının diğer hesaplara yayılmasını zorlaştırır. Ancak ayrı hesaplar mutlak izolasyon sağlamaz; ortak kimlik bilgileri, hatalı izinler veya sunucu düzeyindeki zafiyetler bu sınırı aşmaya yol açabilir.

Müşteri, ödeme veya hassas veri taşıyan bağımsız projelerde ayrı hesap güçlü bir başlangıç tercihidir; gereken izolasyon için ayrıca servis izinleri, sır yönetimi ve kimi iş yüklerinde ayrı sunucu/ortam gerekebilir. Düşük trafik tek başına güvenlik ölçütü değildir. Ortak hesap ancak aynı sahibin paylaşılmış erişim ve arıza etkisini kabul ettiği projelerde değerlendirilmelidir.

E-posta, SPF/DKIM ve Kara Liste Riskleri

Aynı cPanel hesabında birden fazla domainin e‑posta hizmetini çalıştırıyorsanız, bir alan adınızın spam için kötüye kullanılması diğer alan adlarınızı da etkileyebilir.

• Bir alan adından spam çıkışı olursa IP’niz veya sunucunuz RBL listelerine girebilir.
• Aynı çıkış IP’sini kullanan diğer alan adlarının teslim edilebilirliği de düşebilir; bu risk ayrı cPanel hesaplarında barındırılan alan adları için de geçerlidir.
• Ayrı hesapta ise en azından log yönetimi, kota, parola politikaları ve şüpheli hareket tespiti site bazında daha net gözlenebilir.

E‑posta tarafını daha detaylı ele aldığımız SPF, DKIM ve DMARC rehberimizi de bu bağlamda inceleyebilirsiniz.

Performans ve Hesap Bazındaki Kaynak Sınırları

Performans tarafında addon domain ile ayrı hesap arasındaki fark, çoğu zaman “ilk bakışta” görünmez. Ama hosting ortamınızda hangi kaynak limitlerinin hesap bazında uygulandığını anladığınızda tablo netleşir.

cPanel Kaynak Limitleri ve Addon Domain

cPanel bir yönetim panelidir; CPU, fiziksel bellek ve disk I/O sınırları CloudLinux LVE gibi kurulu mekanizmalarla uygulanabilir. CloudLinux’ta EP, LVE’ye eşzamanlı girişleri sınırlar; toplam süreç sayısı değildir. NPROC, LVE içindeki süreç ve thread toplamını sınırlar. Apache’de dinamik istekler EP ile ilişkiliyken LiteSpeed uygulaması farklıdır; EP’yi her kurulumda aktif ziyaretçi sayısına eşitlemeyin.

• Aynı LVE kullanıcı bağlamında çalışan addon siteler uygulanan hesap limitlerini paylaşır; hangi işleri sınıra dahil ettiğini ve paket değerlerini sağlayıcıdan doğrulayın.
• Bir site bu bütçeyi tüketirse aynı hesaptaki diğer işler de etkilenebilir.
• CPU veya I/O sınırı gecikme yaratabilir; Apache EP aşımı 508, bellek/NPROC sorunları 500/503 gibi yanıtlarla görülebilir. Hata kodunu tek başına teşhis saymayın; LVE fault sayaçlarını ve servis loglarını birlikte inceleyin.

Bu konuyu teknik detaylarıyla anlattığımız cPanel’de kaynak limitleri ve Resource Limit Reached hatası rehberinde ayrıca ele alıyoruz.

Ayrı hesap açtığınızda ise her site için ayrı limitler tanımlanabilir. Böylece:

• Yoğun trafik alan e‑ticaret siteniz için daha geniş CPU/RAM tanımlarken, basit tanıtım sitenizde daha düşük limitler kullanabilirsiniz.
• Hesap bazlı limitler, bir sitedeki ani trafik dalgalanmasının diğerlerini etkilemesini azaltabilir; ortak sunucu kaynakları tükendiğinde ayrı hesaplar da etkilenebilir.
• Hangi sitenin kaynağı tükettiğini izlemek ve optimize etmek çok daha kolay hale gelir.

Düşük Trafikli Blog vs. Yüksek Trafikli Kampanya Sitesi

İki senaryo düşünelim:

• Senaryo 1: Aynı kişisel cPanel hesabınız altında 3 küçük blog ve 1 küçük portföy sitesi var. Trafik düşük, değişiklikler seyrek. Bu durumda hepsini addon domain olarak yönetmek pratik olabilir; ancak düşük trafik tek başına güvenlik göstergesi değildir. Ortak hesapta bir ihlalin tüm siteleri etkileyebilmesi kabul edilebilir olmalıdır.
• Senaryo 2: Bir kurumsal site, bir WooCommerce mağaza, bir de yoğun kampanya dönemlerinde trafik yiyen landing page çalıştırıyorsunuz. Burada addon domain kullanmak, ortak kaynak limitleri aşıldığında diğer sitelerin de yavaşlaması veya cevap veremez hale gelmesi riskini artırır.

Özellikle kampanya trafiği, reklam, indirim dönemleri gibi durumlarda yoğun trafikli kampanyalar için hosting ölçeklendirme rehberimizde de anlattığımız gibi, siteleri ayrı hesaplar ve hatta gerekirse ayrı VPS’ler üzerinde dağıtmak çok daha sağlıklı bir yaklaşımdır.

Veritabanı ve Disk IO Yükü

Addon domain senaryosunda genellikle tek cPanel hesabı altında birden fazla MySQL/MariaDB veritabanı oluşturulur. Bu yapıda şu noktalar önemlidir:

• Tek DB kullanıcısı tüm veritabanlarına erişmek için kullanılırsa, bu kullanıcının bilgilerinin ele geçirilmesi erişebildiği tüm veritabanlarını riske atar.
• Aynı veritabanı sunucusundaki veritabanları ortak kaynakları paylaşır; ayrı cPanel hesapları bunu tek başına değiştirmez. Veritabanı yüküne hangi hesap bazlı IO limitlerinin uygulandığı yapılandırmaya bağlıdır.
• Log analizi ve yavaş sorgu takibinde (slow query), veritabanı ve kullanıcı adlarının hangi siteye ait olduğu kayıtlı değilse sorunlu siteyi ayrıştırmak zorlaşır.

Her siteye ayrı veritabanı ve yalnız gereken izinlere sahip DB kullanıcısı vermek her iki modelde de mümkündür. Ayrı hesap, sahipliği ve yetki devrini düzenlemeyi kolaylaştırabilir; veritabanı sunucusu yine ortak olabilir. Cache anahtarlarını site bazında ayırmak çakışmayı azaltır, fakat Redis veya başka cache servisinde erişim kontrolünün yerini tutmaz. WordPress sunucu optimizasyon rehberindeki önerileri gerçek PHP, veritabanı ve cache yapılandırmanızla birlikte uygulayın.

Yedekleme ve Taşıma Kapsamını Belirleme

Bir siteyi hesabın geri kalanından ayırırken dosya, veritabanı, posta ve zamanlanmış işlerin hangisine ait olduğunu bilmek gerekir. Aynı sunucuda addon domain’i hesaba dönüştürmek ile başka sunucuya kopyalamak farklı işlemlerdir. cPanel’in desteklediği dönüştürme aracı bazı adımları otomatikleştirir; kurulum şartlarını ve kapsam dışı verileri yine denetlemelisiniz.

Aynı Sunucuda Dönüştürme ve Başka Sunucuya Taşıma

Aynı sunucuda alan adı hâlâ eski hesabın addon domain’i iken ikinci bir normal cPanel hesabına aynı adla atanamaz. Yetkili yönetici WHM → Transfers → Convert Addon Domain to Account akışını kullanmalıdır; araç eski eşlemeyi işleyip yeni hesabı oluşturur. Gerekli rearrange-accts yetkisini, kurulu sürümü ve disk alanını kontrol edin. Resmi belge yeni alan adının gerektirdiği alanın yaklaşık üç katını önerir; kaynak verinin önemli kısmı işlem sonrası da kalır.

• Önce envanter ve geri dönüş: Asıl hesabın geri yüklenebilir yedeğini, addon document root’unu, ortak dosya/DB bağımlılıklarını, posta, cron, PHP ve .htaccess ayarlarını belirleyin. Canlı yazımları ve görevleri tutarlı aktarım için planlayın.
• Dönüştürme önkoşulları: Resmi belge kaynak hesaba atanmış IPv6 varken işlemin başarısız olacağını ve addon domain’in alt alanlarının önce kaldırılması gerektiğini belirtir. Bunlar diğer hizmetleri etkileyebilir; yedekleme, adres/DNS etkisi ve alt alanları yeni hesapta yeniden kurma planını yöneticiyle tamamlayın.
• Seçimleri doğrulayın: Araç document root, özel VirtualHost include, kurulu SSL sertifikası, özel DNS ve seçilen posta/FTP/Web Disk verilerini aktarabilir. Her türün gerçekten seçildiğini ve sürümdeki kapsamı denetleyin; posta her durumda sıfırdan kurulmak, sertifika her durumda yeniden çıkarılmak zorunda değildir.
• DB Copy veya Move: Veritabanı seçimi varsayılan olarak boş olabilir. Copy ayrı isimle kopya oluşturur; Move sahiplik/yetkiyi değiştirir ve eski hesap erişimini kaybeder. Paylaşılan DB veya kullanıcıları ayırmadan taşımayın; yeni bağlantı adlarını ve izinleri uygulamada doğrulayın.
• Kapsam dışını tamamlayın: MultiPHP ayarları, uygulama kurulum/integrasyon bilgileri, alt alanlar ve listelenmeyen cron/özel ayarlar otomatik aktarılmış kabul edilmemelidir. Kopyalanan uygulama dosyası, çalışan uygulama yapılandırmasıyla aynı şey değildir.
• Başka sunucuya taşıma: Hedefte alan adı başka hesaba ait değilse yeni hesap hazırlanabilir; eski sunucu doğrulama ve geçiş tamamlanana kadar tutulabilir. Alternatif olarak önce kaynakta desteklenen dönüşümü yapıp bağımsız hesabı hesap aktarım aracıyla taşıyın. Hedefle ortak DNS kümesi veya posta yönlendirmesini ayrıca planlayın.
• Kesim ve doğrulama: Gerçek hostname/HTTPS, dosya sahipliği, DB, posta ve cron’u test edin; son dosya/DB/posta değişikliklerini eşgüdümleyin. Alan adı veya URL değişmiyorsa WordPress URL değişimi ya da yeni 301 gerekmez. Gereken URL değişikliklerinde serialize veriyi anlayan araçlar kullanın; bütün DB’ye körlemesine metin değiştirme uygulamayın.

Dönüştürme durumunu ve ayrıntı loglarını kontrol edin; “Done” uygulama testinin yerine geçmez. Yeni posta teslimi yeni hesapta devam ederken kaynakta kalan posta kopyası güncellenmez. Kaynak dosyaları ancak yeni hesap, geri dönüş noktası ve eski hesabın diğer siteleri doğrulandıktan sonra seçerek temizleyin; bütün eski hesabı silmek veya tam eski yedeği düşünmeden geri yüklemek diğer siteleri ya da yeni yazımları bozabilir.

Yedekleme ve Geri Yükleme Kolaylığı

cPanel yedekleme sistemini düşündüğümüzde:

• Tam hesap yedeği addon siteleri aynı hesap kapsamına alabilir; her yedekleme aracı tek büyük dosya üretmek veya yalnız tam hesap restore etmek zorunda değildir.
• cPanel Backup Wizard tam ve kısmi yedek seçenekleri sunar. Tam yedeğin otomatik geri yüklenmesi WHM/sağlayıcı yetkisi gerektirir; kısmi dosya/DB geri yükleme seçeneklerinin kapsamını kontrol edin.
• Tek projeyi geri döndürürken diğer sitelerin dosya, DB ve postasını ezmeyin. Proje başına ayrı hesap sınırı bunu kolaylaştırabilir; zamanlama, saklama, erişim ve restore testi yine ayrıca gerekir.

Kritik projelerde hesap ayrımını doğrulanmış kurtarma noktalarıyla tamamlayın. Hesap başına yedek olması, güncel veya geri yüklenebilir olduğu anlamına gelmez; kaynak dışı kopya ve uygulama doğrulaması planlayın. 3‑2‑1 yedekleme stratejisi rehberi bu planı genişletir.

Sunucular Arası Taşıma ve Kesintiyi Azaltma

Bir noktada sitelerinizi farklı bir sunucuya, farklı bir veri merkezine veya paylaşımlı hosting’den VPS/dedicated ortama taşımak isteyebilirsiniz. Bu durumda:

• WHM Transfer Tool gibi hesap farkındalığı olan araçlar uygun yetki ve uyumlulukla hesabı aktarım birimi yapar. rsync ile dosya kopyalamak tek başına DB, posta ayarı veya hesap yapılandırmasını taşımaz.
• Addon siteyi tek başına çıkarırken paylaşılan veriyi ayırın veya önce desteklenen hesap dönüşümünü planlayın. Tüm ana hesabı taşımak, addon’u bağımsız bir hesaba dönüştürmez.
• İstemci/DNS cache’i, aktif yazımlar, kuyruklar ve posta nedeniyle sıfır kesinti taahhüdü verilemez. Son eşitleme ve geri dönüşü uygulamaya göre test edin.

cPanel’den cPanel’e taşıma rehberi ve taşımalarda TTL planlaması uygulama ayrıntılarını ele alır. TTL’yi düşürmek önceki cache süresini geriye dönük kısaltmaz; eski değerlerin dolmasını bekleyin. Aynı sunucuda IP ve hostname değişmiyorsa DNS geçişi zorunlu değildir. Uzak taşıma sonunda eski eşlemeyi kaldırırken ortak DNS kümesindeki yeni kayıtları da kaldırmadığınızı doğrulayın.

SEO, Loglama ve Yönetilebilirlik: Her Şeyin Takibi Ayrı Olsun

Tek panel yönetimi pratik olabilir; site envanteri ve doğru log eşlemesi yine gerekir. cPanel hesap sınırını tek başına SEO kazancı veya kaybı olarak değerlendirmeyin. Arama motorunun erişebildiği içerik, URL, yanıt ve performans davranışı değişmedikçe bir hesap açmış olmak başlı başına optimizasyon sonucu değildir.

Log Ayrıştırma ve Sorun Giderme

Addon domain için de alan adına göre erişim logları bulunabilir: cPanel Raw Access, hesaptaki domain’leri ayrı indirme bağlantılarıyla listeler. Arşivlerin aynı logs dizininde durması kayıtların zorunlu olarak karıştığı anlamına gelmez. PHP/uygulama hata logları ve merkezi sistemlerdeki site eşlemesini ayrıca doğrulayın:

• Her log kaynağını domain, uygulama ve hesapla eşleyin; paylaşılan logta uygun site alanı kullanın.
• Merkezi izleme ve analitikte filtrelerin gerçek hostname/site bilgisine dayandığını kontrol edin.
• Yetki, saklama ve kişisel veri içeriğini belirleyin; ayrı hesap bu politikaları kendiliğinden kurmaz.

Proje başına ayrı hesap, kaynak grafikleri ve yetki sınırını proje ile eşlemeyi kolaylaştırabilir. Domain bazında log ve izleme her iki düzende de mümkündür; hangi dosyanın hangi işlemleri kapsadığını bilmek gerekir.

SEO Perspektifi: Domain Stratejisi ve Yönlendirmeler

Addon veya ayrı hesap seçimini sıralama vaadiyle yapmayın. Site hızı, HTTPS, canonical ve yönlendirme sorunlarını iki modelde de gerçek HTTP davranışı üzerinden kontrol edin. Ayrı hesap yönetim yetkisini bölmeyi kolaylaştırabilir; şu ayarlar addon domain’lerde de kuruluma göre yönetilebilir:

• Domain’in SSL sertifikası, HTTPS yönlendirmesi, HTTP başlıkları ve cache davranışı. HSTS’yi alt alan ve geri dönüş etkisini değerlendirmeden genişletmeyin.
• Gerçekten aynı içeriğin farklı URL’leri için doğru canonical sinyali; kalıcı adres değişiminde eşdeğer hedefe 301.
• Ayrı dil/bölge içeriklerini koruyan URL ve hreflang düzeni. Farklı dil sayfalarını sırf bir hesapta diye tek URL’ye birleştirmeyin.

Bu konuyu daha kapsamlı tartıştığımız birden fazla alan adını aynı siteye yönlendirme ve SEO stratejileri yazımız, domain yapınızı planlarken size ciddi yol gösterecektir.

Hangi Senaryoda Addon Domain, Hangi Senaryoda Ayrı Hesap Mantıklı?

Teoriyi bir kenara bırakalım ve doğrudan karar vermenizi kolaylaştıracak pratik bir çerçeve çıkaralım.

Addon Domain Kullanmanın Mantıklı Olduğu Durumlar

• Aynı sahibin ortak hesap erişimi ve olay etkisini kabul ettiği küçük kişisel veya düşük etkili projeler.
• Güncelleme, yedekleme ve erişim takibi düzenli yapılan siteler; düşük trafik veya “demo” etiketi güvenlik kanıtı değildir.
• Bağımsız içerik gerekiyorsa addon domain; aynı içeriğin ek adı için alias, başka URL’ye geçiş için yönlendirme. Bu seçenekleri birbirinin yerine kullanmayın.

Bu durumda addon domain size:

• Daha az ana hesap ve giriş bilgisi yönetimi.
• Hesapta bu özellik ve domain kotası açıksa ek site kurabilme.
• Plan ve lisans koşullarına göre maliyet avantajı olasılığı; alan adı sayısı, kaynak bütçesi ve güvenlik ihtiyacını birlikte değerlendirme.

Ayrı Hesabın Güçlü Bir Tercih Olduğu Durumlar

• E‑ticaret, ödeme sistemiyle entegre uygulamalar, üye girişi olan SaaS projeleri.
• Kurumsal şirket siteleri, resmi kurumlar, hukuk/sağlık gibi hassas veri barındıran projeler.
• Ajans veya freelancer olarak müşterilere ait siteleri barındırıyorsanız.
• Geliştirici, tasarımcı, içerikçi gibi farklı rollere ayrı ayrı erişim vermeniz gerekiyorsa.
• Orta/uzun vadede siteyi farklı sunucuya, hatta farklı altyapıya taşıma ihtimaliniz yüksekse.

Bu senaryolarda ayrı hesap, yetki ve sorumluluk sınırı kurmaya yardımcı olur. Belirli bir mevzuat veya güvenlik standardına tek başına uyum sağlamaz; gereken izolasyon, erişim ve denetim kapsamını iş yüküne göre belirleyin. Reseller hosting rehberi müşteri bazında yönetim seçeneklerini açıklar.

DCHost Tarafında Pratik Yaklaşım Önerilerimiz

Seçimi proje sahipliği, erişim yetkileri, ölçülen kaynak ihtiyacı ve gelecekteki devir planına göre yapın. Aynı hesapta tutulacak projelerin ortak risk ve yönetim sınırını baştan belirleyin.

Paylaşımlı Hosting Kullananlar İçin

• Bağımsız müşteri veya hassas veri sınırı gerekip gerekmediğini belirleyin.
• Ayrı hesap gerekiyorsa sağlayıcının ayrı hosting veya yetkili reseller seçeneklerini, lisans ve yönetim kapsamını doğrulayın.
• Yalnız ek alan adıyla aynı içerik sunulacaksa alias; ziyaretçi başka URL’ye gidecekse uygun yönlendirme tasarlayın. HTTPS ve DNS gereksinimleri yine geçerlidir.

Yoğun WordPress iş yükünde hesap sınırı ile hosting kapasitesini ayrı değerlendirin. WordPress için hosting seçimi rehberini gerçek trafik, cache, DB ve PHP ölçümleriyle birlikte kullanın; ayrı hesap veya daha pahalı paket tek başına hız artışı garantilemez.

Reseller, VPS ve Dedicated Kullananlar İçin

• Reseller veya dedicated sunucu/VPS üzerinde cPanel/WHM lisansı ve hesap oluşturma yetkisini doğrulayın; sunucu sahibi olmak panelin veya yönetimin pakete dahil olduğunu göstermez.
• Müşteri ve bağımsız kritik proje başına ayrı hesap tercih edin; aynı sahipteki düşük etkili siteleri yalnız ortak risk kabul ediliyorsa gruplayın.
• Dosya, DB, posta ve cron envanterini güncel tutun; ileride bir hesabı aktarmak yine uyumluluk ve geçiş testi gerektirir.

Daha güçlü izolasyon gerekiyorsa ayrı VPS veya başka bir bağımsız çalışma ortamını değerlendirin. Fiziksel altyapı, ağ, yedekleme ve yönetim sorumluluklarının hangi noktada ortak kaldığını seçilen planla doğrulayın.

Kararı Hesap Sınırı ve İş Yüküne Göre Verin

Addon domain, aynı hesaptan yönetilen ek site için kolaylık sağlar. Ayrı hesap, bağımsız sahiplik, yetki devri, kaynak takibi ve kurtarma sınırını düzenlemeyi kolaylaştırır. Doğru seçim trafik sayısından veya gelecekte büyüme ihtimalinden tek başına çıkmaz; paylaşılabilecek risk, operasyon ve gerçek erişim ihtiyacı birlikte belirlenmelidir.

Mevcut addon siteleri ayıracaksanız aynı sunucuda desteklenen WHM dönüşümü ile başka sunucuya taşıma yolunu baştan ayırın. Veri ve uygulama kapsamını doğrulayın, yedek/geri dönüş hazırlayın, çalışmayı test edin ve ancak sonra eski veriyi seçerek temizleyin. Hesap, domain, DNS ve uygulama sınırlarını açık tutmak uzun vadeli bakımı kolaylaştırır.