Teknoloji

Ayrı cPanel Hesabı mı Addon Domain mi? Güvenlik, E‑Posta ve SEO Açısından Doğru Seçim

İçindekiler

Neden “Ayrı cPanel Hesabı mı Addon Domain mi?” Sorusu Bu Kadar Kritik?

Bir hosting paketinde birden fazla site barındırmak, özellikle ajanslar, freelancer’lar ve çok markalı işletmeler için son derece cazip. Tek fatura, tek panel, daha az yönetim yükü… Ancak işin mutfağına indiğimizde kritik sorular ortaya çıkıyor: Tüm siteleri tek cPanel hesabında addon domain olarak mı tutmalıyım, yoksa her alan adı için ayrı cPanel hesabı mı açmalıyım? Bu seçim doğrudan güvenlik izolasyonunu, e‑posta itibarını, SEO sağlığını ve yedekleme/taşıma operasyonlarını etkiliyor.

DCHost tarafında onlarca ajans ve çoklu site sahibi müşteriyle çalışırken, en fazla tartıştığımız konulardan biri tam olarak bu. Bir WordPress eklentisinin açtığı güvenlik zaafı nedeniyle aynı hesabın altındaki tüm sitelerin etkilenmesi, tek bir domainin spam’e girmesi yüzünden aynı IP’yi ve hesabı paylaşan diğer sitelerin de e‑posta sorunları yaşaması gibi senaryolar, maalesef sahada sık gördüğümüz örnekler.

Bu yazıda, cPanel’de ayrı hesap ile addon domain kullanımını güvenlik, e‑posta ve SEO açısından parça parça analiz edeceğiz. Son bölümde de pratik bir karar matrisi ve DCHost altyapısında bu mimarileri nasıl kurabileceğinize dair somut öneriler bulacaksınız. Daha teknik detaya inmek isteyenler için, yeri geldikçe DCHost blogundaki ilgili rehberlere de bağlantı vereceğim.

Temel Kavramlar: cPanel Hesabı, Addon Domain ve Park Alan Adı

Önce terimleri netleştirelim ki aynı şeyi konuşalım.

cPanel hesabı nedir?

cPanel hesabı, sunucu üzerinde size ayrılmış izole bir kullanıcı alanıdır. Bu hesabın:

  • Kendi home dizini vardır (örneğin /home/kullaniciadi).
  • Kendi FTP/SFTP kullanıcıları, veritabanları, e‑posta hesapları ve DNS bölgesi (zone) bulunur.
  • Paylaşımlı hostingde CloudLinux benzeri teknolojilerle CPU, RAM, IO, Entry Processes limitleri hesap bazında uygulanır.

Yani her cPanel hesabı, güvenlik ve kaynak kullanımı açısından kendi başına bir “kiracı” gibidir. Reseller paketlerinde de aslında yaptığınız şey, alt müşteriler için yeni cPanel hesapları oluşturmak ve bunları paketlerle sınırlamaktır. Bu mimariyi daha detaylı anlamak için paylaşımlı ve reseller hosting’de çoklu web sitesi yönetimi rehberine de göz atabilirsiniz.

Addon domain nedir?

Addon domain, mevcut bir cPanel hesabı içinde ek bir alan adını tamamen farklı bir site gibi barındırmanızı sağlayan özelliktir. Teknik olarak:

  • Her addon domain için ayrı bir dosya klasörü oluşur (örneğin public_html/marka2).
  • İsterseniz ayrı veritabanı ve alt FTP kullanıcıları tanımlayabilirsiniz.
  • Aynı cPanel hesabının limitlerini (CPU, RAM, IO vb.) paylaşırlar.

Yani dışarıdan bakıldığında her addon domain, tamamen farklı bir site gibi görünür; ama perde arkasında hepsi tek bir cPanel kullanıcısının altında toplanmıştır.

Park alan adı (parked/alias) nedir?

Park alan adı, aynı siteyi birden fazla alan adıyla açmak istediğinizde kullanılır. Örneğin:

  • ornek.com ana siteniz,
  • ornek.net ise aynı içeriği açan park alan adınız olabilir.

Bunlar genellikle ayrı site değil, marka koruma veya farklı uzantıları tek siteye yönlendirme amaçlı kullanılır. Park alan adı mimarileri ve SEO etkileri için park alan adları için uygulanabilir stratejiler rehberini incelemeniz çok faydalı olur.

Güvenlik Perspektifi: İzolasyon Olmadan Çoklu Site Barındırmak Ne Kadar Riskli?

DCHost’ta sahada en sık gördüğümüz kritik hatalardan biri, farklı projeleri tek cPanel hesabı altında addon domain olarak yığmak. İlk etapta pratik ve ucuz görünse de, iş güvenliğe geldiğinde tablo değişiyor.

Dosya sistemi ve yetki seviyeleri

cPanel hesabı, Linux tarafında tek bir kullanıcı (user) olarak çalışır. Bu şu anlama gelir:

  • Hesaptaki tüm sitelerin PHP süreçleri aynı kullanıcıyla çalışır.
  • WordPress, Laravel veya özel yazılım fark etmeksizin, aynı hesabın altındaki tüm dosyalara okuma (ve çoğu zaman yazma) yetkisi vardır.
  • Bir sitedeki güvenlik açığı (örneğin insecure upload, eski bir eklenti) istismar edildiğinde, saldırgan çoğu zaman aynı hesaptaki diğer addon domain sitelerin dosyalarına da erişebilir.

Bu yüzden farklı müşterilere ait siteleri aynı cPanel hesabında addon domain olarak tutmak, güvenlik açısından ciddi risk. Dosya izinlerinin önemini daha teknik açıdan görmek isterseniz, Linux dosya izinleri ve güvenli ayarlar rehberini mutlaka okuyun.

Bir site hacklenirse ne olur?

Pratik bir senaryoyla anlatalım. Diyelim ki tek cPanel hesabında üç siteniz var:

  • ajans-siteniz.com – kendi kurumsal siteniz
  • musteri1.com – WordPress kurumsal site
  • musteri2.com – WooCommerce mağaza

musteri1.com üzerinde güncellenmeyen bir tema üzerinden zararlı bir yükleme yapılıyor ve saldırgan hesap içine PHP backdoor yerleştiriyor. Bu noktadan sonra:

  • Backdoor aynı kullanıcı altında çalışan diğer sitelerin klasörlerini tarayabilir.
  • musteri2.com üzerinde kredi kartı formu veya ödeme sayfasına zararlı JS enjekte edilebilir.
  • ajans-siteniz.com SEO açısından spam outbound link veya pharma hack ile kirlenebilir.

Bizim sahada en uğraştırıcı bulduğumuz işler, tam olarak bu tip “tek hesaptan tüm sitelere bulaşmış” hack vakaları. Temizlerken, sadece kodu düzeltmek yetmez; aynı zamanda dosya izinlerini, eklentileri, temaları ve yedekleri tek tek kontrol etmek gerekir. Bu süreçle ilgili daha detaylı bir bakış için hacklenmiş PHP sitelerini temizleme rehberini inceleyebilirsiniz.

Güvenlik açısından ne zaman ayrı cPanel hesabı zorunlu?

Aşağıdaki durumlarda addon domain yerine mutlaka ayrı cPanel hesabı öneriyoruz:

  • Farklı müşterilere ait siteler (ajans, freelancer, yazılım evi senaryoları).
  • Hassas veri işleyen projeler: e‑ticaret, ödeme formu, hasta/müşteri verisi saklayan uygulamalar.
  • Farklı ekiplerin eriştiği, farklı geliştiricilerin kodladığı projeler.
  • Denetim gerektiren (KVKK/GDPR, PCI DSS gibi) sistemler.

Ayrı cPanel hesabı oluşturduğunuzda:

  • Her sitenin kendi kullanıcı alanı olur, dosya seviyesinde izolasyon sağlanır.
  • cPanel güvenliğini ayrıca sertleştirebilir, her hesap için ayrı 2FA, IP kısıtlama gibi önlemler uygulayabilirsiniz. Bunun için cPanel hesap güvenliği sertleştirme rehberinde anlattığımız adımlar birebir geçerlidir.
  • Bir hesabın hacklenmesi durumunda, diğer sitelerin etkilenme ihtimali büyük ölçüde düşer.

Ne zaman addon domain ile yaşanabilir?

Addon domain’i tamamen çöpe atmak gerekmiyor. Bazı durumlarda mantıklı:

  • Aynı markanın çok düşük trafikli mikrositeleri (kampanya, lansman, tek sayfalık landing’ler).
  • Sadece çalışan içi erişimi olan basit bilgilendirme siteleri.
  • Geliştirme/test aşamasındaki geçici projeler (yine de staging için subdomain veya ayrı hesap çoğu zaman daha sağlıklı).

Burada kritik nokta: risk iştahınızı bilerek hareket etmek. Kurumsal ana sitenizle aynı hesaba, güvenliği belirsiz deneme projeleri yığmak, uzun vadede baş ağrısı yaratır.

E‑Posta Perspektifi: Aynı Hesap Altındaki Siteler Birbirini Nasıl Etkiler?

Güvenlikten sonra en hassas konu e‑posta. Çünkü e‑posta tarafında yaşanan itibar sorunları, sadece tek bir domaini değil, bazen aynı IP’yi paylaşan tüm domainleri etkileyebiliyor.

Aynı cPanel hesabında e‑posta nasıl çalışır?

cPanel tarafında:

  • Hesaptaki her alan adı için ayrı e‑posta adresleri tanımlanabilir ([email protected], [email protected] gibi).
  • Ancak bu e‑postalar genellikle aynı mail sunucusu IP’si üzerinden gönderilir.
  • SPF, DKIM, DMARC gibi kayıtlar alan adı bazında yönetilir, ama IP itibarını paylaşırsınız.

Eğer tek bir cPanel hesabı altında onlarca domain varsa ve bunlardan biri aşırı pazarlama maili atıyorsa veya bir form hacklenip spam kampanyası başlatırsa, aynı IP’yi ve altyapıyı paylaşan diğer alan adları da spam klasörüne düşme riski ile karşılaşabilir.

Spam ve kara liste riskleri

Şu senaryoyu düşünün:

  • kampanya-domaini.com adresinden günlük binlerce soğuk e‑posta gönderiliyor.
  • Geri dönüş oranı düşük, unsubscribe linkleri eksik, şikayet oranı yüksek.
  • Bir noktadan sonra IP, bazı RBL (Real-time Blackhole List) kara listelerine giriyor.

Aynı IP ve hosting hesabını kullanan kurumsal-ana-site.com için de e‑posta teslim edilebilirliği bozuluyor. Müşterilere attığınız teklif mailleri, tedarikçilere giden sipariş onayları spam’e düşmeye başlıyor. Bu durumu e‑postalar neden spam klasörüne düşüyor rehberinde detaylı biçimde anlattık.

E‑posta açısından ne zaman ayrı cPanel hesabı mantıklı?

Aşağıdaki durumlarda e‑posta tarafı için de izolasyon önemli hale geliyor:

  • Kritik iş süreçlerinde kullanılan (CRM bildirimleri, fatura, sözleşme vb.) transactional e‑postalar.
  • Marka itibarı açısından çok hassas kurumsal adresler (yönetim kurulu, hukuk, finans vb.).
  • Yoğun pazarlama iletişimi yapan, bülten gönderen domainlerle aynı altyapıyı paylaşan sakin kurumsal domainler.

Bu durumlarda, ya kritik domaini ayrı bir cPanel hesabına ve hatta gerekirse ayrı IP’ye almak, ya da pazarlama ve transactional e‑postaları ayrı alan adlarına bölmek (örneğin mail.ornek.com veya ornekmail.com) iyi bir stratejidir. Bu konuda ayrı gönderim alan adı kullanma stratejisi makalemizi mutlaka okumanızı öneririm.

Addon domain kullanırken e‑posta tarafında dikkat edilmesi gerekenler

Eğer addon domain mimarisinden vazgeçemiyorsanız, en azından şu tedbirleri alın:

  • Her alan adı için doğru SPF, DKIM ve DMARC kayıtlarını kurun. Bunun için SPF, DKIM ve DMARC rehberi işinizi kolaylaştıracaktır.
  • Form spam’ine dikkat edin, reCAPTCHA/honeypot kullanın, outbound e‑posta trafiğini izleyin.
  • Yüksek hacimli bülten veya kampanya maillerini, mümkün olduğunca ayrı bir gönderim alan adı üzerinden çalıştırın.

SEO Perspektifi: Aynı Hesapta Birden Fazla Site, Google’ı Nasıl Etkiler?

Teknik olarak Google, aynı IP veya aynı hosting hesabı altındaki siteleri tek tek değerlendirir; yani “aynı cPanel’de host ediliyor” diye otomatik bir ceza vermez. Ancak pratikte, addon domain kullanımı bazı yapısal SEO hatalarına zemin hazırlayabiliyor.

Canonical, 301 ve çoklu domain mimarisi

Birçok kullanıcı, addon domain ile farklı domainleri aynı siteye yönlendirme konusunu karıştırıyor. Şunları ayıralım:

  • Ayrı site: site1.com ve site2.com tamamen farklı içerik.
  • Aynı site, farklı domain: site1.com ana domain, site2.com ise 301 veya canonical ile ana domain’e yönlendirilen alternatif.

İkinci senaryoda addon domain yerine genellikle park domain + 301 + doğru canonical mimarisi tercih edilir. Bu konuda birden fazla alan adını aynı siteye yönlendirmek rehberimizde net bir yol haritası paylaştık.

Subdomain, alt dizin ve addon domain karışıklığı

Addon domain kullandığınızda, pratikte çoğu zaman siteniz şu şekilde yapılandırılır:

  • DocumentRoot: /home/kullanici/public_html/site2
  • Alan adı: site2.com

Yani dosya yapısı olarak bir alt klasör, ama Google için bağımsız bir alan adı. Buna ek olarak, sıkça şu karışıklıklar yaşanıyor:

  • blog.site1.com gibi subdomain’ler hem site1.com/blog hem de blog.site1.com üzerinden açılabiliyor.
  • www ve çıplak alan adı (non‑www) ayarları doğru yapılmadığında, site farklı URL’ler üzerinden kopya içerik gibi görünebiliyor.

Bu konuda blog, mağaza ve landing page için subdomain mi klasör mü rehberimiz ile www mi çıplak alan adı mı makalemizi birlikte okumanız, doğru SEO mimarisi kurarken çok işinize yarar.

Addon domain SEO açısından ne zaman sorun yaratır?

Addon domain’in SEO tarafında doğrudan cezaya sebep olması söz konusu değil. Sorun genellikle şu durumlarda ortaya çıkıyor:

  • Tek cPanel hesabında, aynı veya çok benzer içerikli siteler tutuluyor (doorway sites, PBN denemeleri vb.).
  • Canonical, hreflang, 301 yönlendirmeleri yanlış yapılandırılıyor ve kopya içerik sinyalleri güçleniyor.
  • Bir addon domain, hack veya spam yüzünden black‑hat outbound link çiftliğine dönüşüyor ve aynı hesabın altındaki diğer siteler de algoritmik olarak şüpheli görünebiliyor.

Dolayısıyla SEO açısından kritik noktalar şunlar:

  • Farklı hedef kitlelere ve dillere hitap eden siteler arasında doğru hreflang ve canonical kullanımı.
  • Ek domainleri aynı siteye yönlendirirken 301 ve canonical hiyerarşisini net belirlemek.
  • Hack ve spam’e karşı güvenliği sıkı tutarak, sitelerinizi link çiftliği haline gelmekten korumak.

Yönetim, Kaynaklar ve Yedekleme: Operasyonel Yükü Nasıl Etkiliyor?

Güvenlik ve SEO kadar önemli bir diğer başlık da operasyon. 10–20 siteyi yönetirken addon domain ile ayrı cPanel hesabı arasında günlük iş yükü açısından ciddi fark oluşabiliyor.

Kaynak limitleri: CPU, RAM, IO ve EP

Paylaşımlı hosting veya reseller paketlerinde en önemli konulardan biri, her hesabın CPU, RAM, IO ve Entry Processes (EP) limitleridir. Bunu detaylıca cPanel kaynak limitleri rehberimizde anlattık.

Aynı cPanel hesabına eklediğiniz her addon domain:

  • Aynı CPU ve RAM havuzunu paylaşır.
  • Aynı anda gelen ziyaretçi sayısı arttıkça, EP limitine daha çabuk ulaşırsınız.
  • Bir sitenin ani trafik artışı, aynı hesapta duran diğer siteleri de yavaşlatabilir veya Resource Limit Reached hatasına sürükleyebilir.

Ayrı cPanel hesabı açtığınızda ise, her siteyi ayrı limitle tanımlamak ve yükü daha dengeli dağıtmak mümkün hale gelir. Özellikle DCHost reseller veya çok siteli hosting mimarilerinde, her projeye birkaç vCPU ve belirli RAM limiti atayıp, sorun üreten siteyi kolayca izole etmek büyük konfor sağlar.

Yedekleme ve geri yükleme

Addon domain ile ayrı hesap arasındaki en belirgin operasyonel farklardan biri de yedekleme tarafında ortaya çıkar:

  • Tek cPanel hesabında 10 site varsa, tam yedek aldığınızda hepsi tek paket halinde gelir.
  • Geri yükleme yaptığınızda, genellikle hesabın tamamını dönmeniz gerekir; bu da diğer sitelerdeki güncel değişiklikleri ezme riski taşır.
  • Ayrı cPanel hesabında ise, site bazında yedek ve geri yükleme yapmak çok daha temizdir.

Bu fark, özellikle site taşıma ve felaket kurtarma senaryolarında çok net hissedilir. Yedek süreçlerini sağlam kurmak için, önce cPanel’de tüm siteyi yedekleme ve geri yükleme rehberimizi, sonra da 3‑2‑1 yedekleme stratejisini incelemenizi öneririm.

Erişim yönetimi ve yetkilendirme

Ayrı cPanel hesabı kullanmanın güzel yanlarından biri de yetki yönetimini sadeleştirmesidir:

  • Her müşteri veya proje için ayrı cPanel kullanıcı adı/şifresi tanımlarsınız.
  • Geliştiricilere, yalnızca ilgili hesaba veya alt FTP hesabına erişim verirsiniz.
  • Bir müşteriyle yollar ayrıldığında, sadece o hesabın erişimlerini kapatarak temiz bir ayrılık sağlayabilirsiniz.

Addon domain’de ise, tek hesabın bilgilerini paylaşmak zorunda kalırsınız; bu da hem güvenlik hem de operasyonel takip açısından karmaşa yaratır.

Karar Matrisi: Hangi Durumda Ayrı cPanel Hesabı, Hangi Durumda Addon Domain?

Şimdiye kadar parçaları tek tek inceledik. Hepsini bir araya getirip pratik bir karar matrisi çıkaralım.

Genel soru seti

Her yeni alan adı eklerken kendinize şu soruları sorun:

  1. Bu site farklı bir müşteriye mi ait, yoksa aynı markanın alt projesi mi?
  2. Bu sitede hassas veri işleniyor mu (ödeme, kişisel veri, login vb.)?
  3. Bu siteden gönderilecek e‑postalar, marka itibarı açısından ne kadar kritik?
  4. Sitenin trafiği ve kaynak kullanımı diğerlerine göre ne kadar yoğun olacak?
  5. İlerde bu siteyi ayrı sunucuya veya altyapıya taşımak isteyebilir miyim?

Net öneriler

Aşağıdaki senaryolarda tercihleri şu şekilde özetleyebiliriz:

  • Farklı müşterilere ait, üretimde çalışan siteler
    KESİN ayrı cPanel hesabı.
  • E‑ticaret, ödeme alan siteler, muhasebe/CRM panelleri
    → Ayrı cPanel hesabı, mümkünse ayrı IP ve güçlendirilmiş güvenlik.
  • Aynı markanın düşük trafikli mikrositeleri (kampanya, etkinlik landing’i)
    → Trafik düşük, veri hassas değilse addon domain kabul edilebilir; yine de staging ve test için ayrı subdomain veya hesap düşünün.
  • Blog, mağaza, landing page gibi alt bölümler (aynı domain altında kalacaksa)
    → Genelde addon domain yerine subdomain veya alt dizin mimarisi daha anlamlı; SEO tarafı için ilgili rehberlere mutlaka bakın.
  • Kısa süreli PoC (Proof of Concept) ve test projeleri
    → Kaynaklarınız sınırlıysa geçici addon domain kullanılabilir, ama kalıcı hale gelen projeleri zamanla ayrı hesaba taşıyın.

Hem addon domain hem de ayrı hesap kullanılan hibrit mimari

DCHost müşterilerinde sık gördüğümüz sağlıklı bir model de şu:

  • Her müşteri veya marka için en az bir ana cPanel hesabı açmak.
  • Aynı markaya ait ufak, düşük riskli mikrositeleri bu hesabın altında addon domain olarak toplamak.
  • Yükü artan veya iş kritik hale gelen mikrositeleri, zamanla ayrı cPanel hesaplarına taşımak.

Böylece hem faturaları sade tutuyor, hem de güvenlik ve yönetilebilirlik dengesini korumuş oluyorsunuz.

DCHost Üzerinde Pratik Yaklaşımlar: Hangi Hizmette Nasıl Kurulur?

Kararı verdikten sonra, bunu DCHost altyapısında nasıl kurabileceğinizi netleştirelim. Burada birkaç tipik senaryo üzerinden gidelim.

Senaryo 1: 5–10 kurumsal site yöneten ajans

Bu tip ajanslarda genellikle:

  • Her müşteri için ayrı cPanel hesabı açılmasını,
  • Gerekirse aynı müşterinin ufak mikrositelerini addon domain ile yönetmesini,
  • cPanel hesaplarının tamamında 2FA, güçlü şifre, IP kısıtlama gibi güvenlik sertleştirmelerini uygulamasını

öneriyoruz. Ajansların çoklu müşteri altyapılarını kurgularken nelere dikkat etmesi gerektiğini, ajanslar için hosting paneli erişim yönetimi rehberinde daha detaylı anlattık.

Senaryo 2: Tek markası olan ama çok sayıda mikrosite kullanan işletme

Örneğin ana domaininiz marka.com olsun. Buna ek olarak:

  • kampanya2025.com
  • etkinlik.marka.com
  • partner.marka.com

gibi yapılarınız var. Burada genellikle:

  • marka.com için ana cPanel hesabı,
  • Kısa ömürlü, düşük trafikli kampanya siteleri için addon domain,
  • Uzun ömürlü, SEO açısından değerli blog veya mağaza gibi yapılar için ise subdomain/alt dizin tercih ediyoruz.

Bu tür SEO odaklı alt yapı kararları için, subdomain mi alt dizin mi rehberimizi de mutlaka okumanızı tavsiye ederim.

Senaryo 3: Büyüyen projeyi paylaşımlı hostingten VPS’e taşıma

Başlangıçta tek cPanel hesabında birkaç addon domain ile idare ettiğiniz bir yapı, zamanla trafik ve iş kritikliği açısından büyüyebilir. Bu noktada tipik yol haritası şöyle oluyor:

  1. Kritik siteleri ayrı cPanel hesaplarına bölmek.
  2. Gerekirse DCHost üzerinde yönetilen VPS veya dedicated sunucuya geçip, cPanel/WHM ile bu hesapları merkezi yönetmek.
  3. Kaynak planlamasını (CPU, RAM, disk, IO) site bazında yaparak, büyüyen projelere özel optimizasyon uygulamak.

Bu geçişi planlarken, paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberimiz, pratik adımlar ve kontrol listeleri ile ciddi zaman kazandırır.

Özet ve Yol Haritası: Kısa Vadede Kolay, Uzun Vadede Sağlam Olan Seçim

Addon domain kullanmak, özellikle ilk etapta çok cazip: Tek hesap, tek panel, hızlı kurulum… Ama iş büyüdükçe, güvenlik, e‑posta itibarı, SEO ve yedek/taşıma gibi konularda gizli maliyetler birikmeye başlıyor. DCHost tarafında gördüğümüz örneklerde, en sorunsuz yapıların ortak noktası, farklı projeleri ve müşterileri erken aşamada ayrı cPanel hesaplarına bölmüş olmaları.

Eğer şu an tek cPanel hesabında birden fazla site çalıştırıyorsanız, panik yapmaya gerek yok. Önceliği belirleyip, kritik siteleri yavaş yavaş ayrı cPanel hesaplarına taşıyarak başlayabilirsiniz. Bu sırada:

  • cPanel güvenliğini sıkılaştırın (2FA, IP kısıtlaması, güçlü şifre politikası).
  • Her domain için SPF, DKIM, DMARC yapılandırmasını kontrol edin.
  • www/non‑www, 301 ve canonical ayarlarını sadeleştirerek SEO tarafını sağlamlaştırın.
  • Düzenli ve test edilmiş bir yedekleme stratejisi kurun.

DCHost olarak, ister paylaşımlı hosting, ister reseller, ister VPS/dedicated olsun, çoklu site barındırma mimarinizi başından itibaren doğru kurgulamanız için yanınızdayız. Mevcut yapınızı birlikte gözden geçirip, hangi sitenin addon domain, hangisinin ayrı cPanel hesabı olmasının daha mantıklı olduğunu, hem teknik hem maliyet tarafını dengeleyerek netleştirebiliriz. Böylece kısa vadede pratik, uzun vadede ise güvenli ve ölçeklenebilir bir altyapıya sahip olursunuz.

Sıkça Sorulan Sorular

Güvenlik açısından bakıldığında, ayrı cPanel hesabı her zaman addon domain’e göre daha güvenlidir. Çünkü her cPanel hesabı, Linux tarafında ayrı bir kullanıcıya sahiptir ve dosya sistemi seviyesinde izolasyon sağlar. Addon domain’lerde ise tüm siteler aynı kullanıcı altında çalıştığı için, bir sitedeki güvenlik açığı çoğu zaman aynı hesaptaki diğer sitelerin dosyalarına da erişim imkânı verir. Özellikle farklı müşterilere ait siteler, e‑ticaret projeleri veya hassas veri işleyen uygulamalar söz konusuysa, mutlaka ayrı cPanel hesabı kullanmanızı öneririz.

Addon domain tamamen yanlış değildir; sadece nerede kullanılacağını bilmek gerekir. Aynı markaya ait, düşük trafikli ve kısa ömürlü mikrositeler (kampanya sayfaları, etkinlik landing’leri gibi) addon domain olarak yönetilebilir. Ayrıca sadece çalışanların eriştiği basit bilgilendirme siteleri veya geçici test projeleri de addon domain ile barındırılabilir. Ancak bu siteler zamanla iş kritik hale geldiyse, trafik veya veri hassasiyeti arttıysa, orta vadede ayrı cPanel hesabına taşımak çok daha sağlıklı bir yaklaşımdır.

Tek başına “aynı cPanel hesabında host edilmek” SEO için bir ceza sebebi değildir. Google, siteleri alan adı ve içerik bazında değerlendirir. Ancak addon domain kullanırken yapılan yapısal hatalar SEO’ya zarar verebilir. Örneğin www/non‑www ayarlarının karışması, birden fazla domainin aynı içeriği sunup canonical ve 301 yönlendirmelerinin yanlış yapılandırılması, kopya içerik sinyallerini artırabilir. Ayrıca hack veya spam nedeniyle bir addon domainin link çiftliğine dönüşmesi, aynı hesap altındaki diğer siteleri de şüpheli gösterebilir. Doğru canonical, 301 ve güvenlik ayarlarıyla bu riskleri minimize etmek mümkündür.

Addon domain kullanırken asıl risk, aynı mail sunucusu IP’sini ve çoğu zaman aynı altyapıyı paylaşmanızdan kaynaklanır. Eğer addon domain’lerden biri yoğun pazarlama maili gönderiyor, form spam’i yüzünden habersizce toplu mail atılıyor veya yanlış yapılandırma nedeniyle spam şikayetleri artıyorsa, IP itibarı düşer. Bu durumda aynı hesabı kullanan diğer alan adlarının e‑postaları da spam klasörüne düşmeye başlayabilir. Kritik kurumsal e‑postalar için ya ayrı cPanel hesabı ve mümkünse ayrı IP kullanmak, ya da transactional ve pazarlama e‑postalarını ayrı alan adlarına bölmek çok daha sağlıklı bir stratejidir.

Evet, mümkündür ve çoğu zaman büyüyen projeler için önerdiğimiz yol budur. Önce yeni cPanel hesabını oluşturup, ilgili domaini bu hesaba tanımlamanız gerekir. Ardından addon domain altındaki dosyaları ve veritabanını yeni hesaba taşıyıp, yapılandırmaları (wp-config.php, .env, e‑posta hesapları, DNS kayıtları vb.) güncellersiniz. Son adımda DNS kesintisiz geçiş için TTL ayarlarını ve 301 yönlendirmelerini planlı şekilde uygularsınız. DCHost tarafında bu süreci adım adım doğru kurguladığınızda, hem kesinti süresini hem de SEO ve e‑posta tarafındaki riskleri minimumda tutabilirsiniz.