Çok Dilli Kurumsal Sitelerde Domain ve Hosting

Çok dilli kurumsal sitelerde doğru mimariyi seçmek

Çok ülkeye açılan şirketlerin web tarafındaki en kritik tartışmalarından biri, “Bu işi domain ve hosting tarafında nasıl mimariyle çözeceğiz?” sorusu oluyor. Pazarlama ekibi güçlü bir marka ve yerel SEO isterken, IT ekibi yönetilebilirlik, güvenlik ve performans odaklı düşünüyor; finans tarafı ise uzun vadeli maliyetleri hesaplıyor. Yanlış seçilmiş bir domain veya hosting mimarisi, yıllar içinde SEO’yu sınırlayan, güvenlik risklerini artıran ve her küçük değişikliği zahmete dönüştüren bir teknik borca dönüşebiliyor.

Çok dilli kurumsal siteler için “tek doğru model” yok; her modelin güçlü ve zayıf yanları var. Önemli olan, .com, ülke alan adları (ccTLD), subdomain ve alt dizin seçeneklerini; SEO, operasyon, hukuk, güvenlik ve performans boyutlarıyla birlikte değerlendirip, şirketinizin yapısına uygun bir mimari planlamak.

Bu rehber .com, ccTLD, subdomain ve alt dizin modellerini kurumsal ekipler, içerik ve hosting gereksinimleriyle karşılaştırır. Alan adı yapısı, fiziksel sunucu sayısını tek başına belirlemez. DNS, sertifika, e-posta ve taşıma sorumluluklarını birlikte planlayarak DCHost veya başka bir sağlayıcının uygun hizmet seçeneklerini değerlendirebilirsiniz.

Alan adı tarafı: .com, ccTLD, subdomain ve alt dizin seçenekleri

Önce terminolojiyi netleştirelim. Alan adı uzantısı ile dil veya ülke sürümlerinin URL yapısı, birlikte planlanan farklı seçimlerdir:

Global gTLD (.com, .net, .org vb.)

gTLD (generic Top Level Domain), ülkeye bağlı olmayan genel uzantılardır. En yaygını .com’dur. Kurumsal şirketler için .com, “global çatı” domain olarak yaygın bir seçenektir. Markanız için merkezi bir global marka alan adı belirlemek istiyorsanız, bu genelde .com olur.

Marka ve TLD tarafını daha derin düşünmek isterseniz, “.com, .io, .ai arasında doğru isim nasıl bulunur?” sorusuna detaylı yaklaşan SEO ve marka için alan adı ve TLD seçimi rehberine mutlaka göz atın.

Ülke kodlu ccTLD (.tr, .de, .fr vb.)

ccTLD (country code TLD), ülke veya bölge koduna dayanan üst düzey alan adı uzantısıdır: .tr, .de, .fr, .uk gibi. Bu örnekler Google için coğrafi hedefleme sinyali verir ve kullanıcıda yerellik algısını destekleyebilir. Ancak Google’ın .io gibi genel uzantı olarak değerlendirdiği ccTLD’ler de vardır.

• Artıları: Ülke hedeflemesi için güçlü sinyal; yerel kullanıcıda güven algısını destekleme potansiyeli. ccTLD kullanımı tek başına hukuki veya regülasyonel uyum sağlamaz.
• Eksileri: Her ülke için ayrı domain kaydı, yenileme maliyetleri, her domainin SEO’sunu ve otoritesini tek tek inşa etme gerekliliği.

Bu dengeyi daha stratejik tartışmak için, “ccTLD mi gTLD mi, uluslararası SEO’da hangi yol ne zaman doğru?” sorusunu detaylı inceleyen alan adı stratejisi rehberini de yanınızda tutmanız iyi olur.

Subdomain (alt alan adı): fr.ornek.com, en.ornek.com

Subdomain, ana domainin önüne gelen ve teknik olarak ayrı bir site/host gibi davranabilen alt alanlardır: fr.ornek.com, en.ornek.com gibi.

• Artıları: Farklı altyapılara yönlendirmesi kolay; her subdomain’i ayrı sunucuda, ayrı panelde, hatta ayrı teknolojide barındırabilirsiniz. Bazı kurumlarda ülke ekiplerine neredeyse bağımsız operasyon imkânı sağlar.
• Eksileri: Ayrı altyapılar kullanıldığında her subdomain’in içerik, bağlantı ve teknik SEO yönetimini koordine etmek gerekir. Subdomain seçimi tek başına alt dizine göre daha düşük SEO performansı anlamına gelmez. Analitik, güvenlik ve bakım tarafında karmaşıklık artabilir.

Alt dizin: ornek.com/fr/, ornek.com/de/

Alt dizin, aynı domain altında farklı dil veya ülke sürümlerini dizin yapısıyla ayırma yöntemidir: ornek.com/tr/, ornek.com/en/ gibi.

• Artıları: İçerik ve bağlantı yönetimi tek domain altında toplanır; bu yapı tek başına daha hızlı SEO kazanımı garanti etmez. Ortak hosting, SSL ve teknik altyapı kullanımı yönetimi kolaylaştırabilir.
• Eksileri: Tüm trafik tek altyapıda karşılanıyorsa, yanlış kapasite planlaması performans ve ölçeklenebilirlik sorunlarına yol açabilir. Alt dizin yapısı tek fiziksel sunucu gerektirmez. Bazı hukuk/regülasyon senaryolarında ülke bazlı veri ve altyapı ayrımı için ek tasarım gerekebilir.

Alt dizin ve subdomain tercihini, sadece çok dilli değil; blog, mağaza ve mikro siteler için de tartıştık. Daha spesifik bir karar vermek isterseniz, subdomain mi alt dizin mi rehberindeki SEO ve hosting karşılaştırmasını da mutlaka okuyun.

Dört ana mimari model ve ne zaman hangisi?

Kurumsal çok dilli siteler için dört temel domain mimarisini ele alalım. DCHost ile bunlardan birini planlarken gerekli hosting ve DNS özelliklerinin seçilen hizmet kapsamında desteklendiğini doğrulayın.

Model 1: Tek .com + alt dizinlerde diller (ornek.com/tr, ornek.com/en)

Merkezi pazarlama ve IT yönetimi olan, farklı dillerde kurumsal içerik ve satış talebi formları sunan bir B2B şirketi için başlangıç seçeneği olabilir. Dil sayısını tek başına kapasite ölçütü saymayın.

• SEO: Tüm diller tek domain altında toplanır; bu, içerik ve iç bağlantı yönetimini kolaylaştırabilir ancak otomatik sıralama avantajı sağlamaz. hreflang etiketleri doğru ve karşılıklı kurgulandığında, Google’ın uygun dil veya bölge sürümünü belirlemesine yardımcı olur.
• Hosting: Tek güçlü VPS veya dedicated sunucu, gerekirse önünde CDN ile, trafik ve uygulamanın kaynak ihtiyacına bağlı olarak yeterli olabilir. Trafiğiniz büyüdükçe veritabanı/sunum katmanını ayırarak ölçekleyebilirsiniz.
• Operasyon: Ortak uygulama kullanıldığında tek panel, tek deploy hattı ve ortak SSL yönetimiyle DevOps karmaşıklığı azaltılabilir.

Önbelleğe alınmayan işlemler uzak kullanıcılarda yavaşsa önce ağ, uygulama ve veritabanı sürelerini ayırın. Uygun CDN önbelleği yardımcı olabilir; kullanıcıya özel, oturumlu veya hassas yanıtları ortak önbelleğe almayın. Ek bölgeyi ölçülen ihtiyaç, maliyet ve işletim kapasitesine göre değerlendirin.

Model 2: Tek .com + dil/ülke bazlı subdomain’ler (fr.ornek.com, de.ornek.com)

Kime uygun? Ülke ekipleri teknik ve içerik tarafında daha bağımsız olsun isteyen, farklı teknoloji stack’leriyle çalışmak isteyen kurumlar için mantıklı bir tercih.

• SEO: Her subdomain’in içerik, iç bağlantı ve teknik SEO düzeni planlanmalıdır. Alt dizine göre kaçınılmaz bir otorite kaybı varsayılmamalıdır; tutarlı iç bağlantılar ve global navigasyon, sürümler arasındaki ilişkiyi kullanıcılar ve arama motorları için netleştirir.
• Hosting: Her subdomain’i DCHost üzerinde ayrı bir hosting hesabına, hatta ayrı VPS veya dedicated sunucuya yönlendirebilirsiniz. Örneğin varsayımsal bir kurulumda fr.ornek.com WordPress, tr.ornek.com ise headless bir yapı ile çalışabilir; subdomain bu ayrımı kolaylaştırır.
• Operasyon: Güzel yanı, ülke IT ekiplerine “kısmi bağımsızlık” tanıması. Ancak SSL, DNS, güvenlik politikaları gibi çatı kararların koordineli yürütülmesi şart.

Dezavantajlar: Yönetim maliyeti artar. Her subdomain’in SSL, yedekleme, izleme ve güvenlik ayarlarını net prosedürlerle yönetmeniz gerekir; yoksa operasyonel aksama riski artar.

Model 3: Sadece ccTLD’ler (ornek.com.tr, ornek.de, ornek.fr)

Yerel ürün, fiyat, kampanya ve içerik yönetimini ayırmak isteyen bir şirket için ccTLD modeli değerlendirilebilir. Alan adı uzantısı yerel tüzel kişilik, fiziksel ofis veya hukuki uyum kanıtı değildir; kayıt uygunluğunu ve veri işleme yükümlülüklerini ayrıca inceleyin.

• SEO: Her ülke için ccTLD, yerel SEO’da kuvvetli bir işaret. Doğru içerik ve backlink stratejisiyle birlikte kullanıldığında, “tamamen yerel” algısını güçlendirir.
• Hosting: Her domain için ayrı altyapı planlayabilir, DCHost ile hedef pazara uygun lokasyon seçeneklerini değerlendirebilirsiniz. Kullanıcıya yakın sunucu lokasyonu ağ gecikmesini azaltabilir; hız ve Core Web Vitals sonuçları uygulama, içerik ve önbellekleme gibi etkenlere de bağlıdır.
• Operasyon: Tam bağımsız ülke siteleri kurabilirsiniz; ccTLD kullanımı bunu zorunlu kılmaz. Her ülke kendi kampanyalarını, ödeme sistemlerini, hukuki metinlerini yönetebilir.

Dezavantajlar: SEO ve bağlantı çalışmaları farklı domain’lere bölünür. 10 ülke için ayrı domain kullanıyorsanız, 10 sitenin SEO’sunu koordine etmeniz gerekir. Ortak kurumsal içerik (hakkımızda, sürdürülebilirlik raporları vb.) ilgili sitelerde tutarlı ve güncel tutulmalı; bu da süreç gerektirir.

Model 4: Hibrit model (global .com + stratejik ccTLD’ler)

Global bir kurumsal adresi korurken belirli pazarlarda bağımsız yerelleştirme isteyen şirketler hibrit modeli değerlendirebilir. Esnekliğin karşılığında birden fazla siteyi, URL envanterini ve içerik sorumlularını koordine etmek gerekir.

Örnek bir kurgu:

• Global site: ornek.com; kurumsal, yatırımcı ilişkileri, kariyer ve ürün özetleri.
• Stratejik pazarlar: ornek.com.tr veya ornek.de gibi ccTLD’lerde ilgili yerel içerik ve kampanyalar.
• Diğer pazarlar: ornek.com/en/ veya ornek.com/ar/ gibi içerik dilini düzenleyen alt dizinler. Yol adları kendi başına hreflang değildir; en-EU geçerli bir hreflang bölge etiketi olarak kullanılmamalıdır.

Artıları: Global marka iletişimini .com üzerinde toplayabilir, iş hacmi yüksek ülkelerde ccTLD ile yerelleşebilirsiniz. Ancak ayrı alan adlarının SEO sinyalleri otomatik olarak .com üzerinde birleşmez.

Eksileri: Mimari doğru planlanmazsa, kullanıcılar ve arama motorları için karmaşaya dönüşebilir. Hangi içerik nerede “kanonik”? Hangi domain kimin ana adresi? Bunlar net tanımlanmalı.

SEO perspektifi: hreflang, canonical ve bölgesel hedefleme

Domain mimarisini seçtikten sonra, uluslararası SEO’nun bel kemiği olan birkaç mekanizmayı doğru kurmanız gerekiyor:

• Hreflang: Eşdeğer dil/bölge sayfalarını tam URL’lerle ilişkilendirin; sürümler kendilerini ve karşılıklı alternatiflerini göstermelidir. Dil kodu ve isteğe bağlı geçerli ülke kodunu içerikle uyumlu seçin.
• Canonical: Yinelenen veya çok benzer sayfalarda tercih edilen URL’yi belirtir. Çeviri sayfalarını yalnızca aynı konuyu işledikleri için başka dildeki canonical altında birleştirmeyin. Aynı dildeki benzer bölgesel sayfalarda canonical ve hreflang kararlarını birlikte değerlendirin.
• Güncel ülke hedefleme: Search Console’un International Targeting raporu ve ülke hedefleme ayarı kullanımdan kaldırıldı. Ülke seçimi adımı yerine erişilebilir bölgesel URL’leri, uygun hreflang ve görünür içeriği kullanın; kullanıcıya dil/bölge değiştirme bağlantıları sunun.

Hreflang kurulum rehberi ccTLD, alt alan ve alt dizin örneklerini açıklar. Klasör adları tek başına sayfanın dilini veya hedef ülkesini belirlemez; Google dili görünür içerikten anlar. Otomatik IP/dil yönlendirmeleri bütün sürümlerin erişimini engellememelidir.

Bir diğer kritik nokta da sunucu lokasyonu. Kullanıcı ile sunucu arasındaki ağ gecikmesi, ilk bayt süresini (TTFB) ve kullanıcı deneyimini etkileyebilir. CDN, önbellekten sunduğu içerikte bu etkiyi azaltabilir; kaynak sunucuya ulaşması gereken isteklerde ise sunucunun konumu önemini korur. Bu konuyu teknik ve SEO perspektifinden irdelediğimiz sunucu lokasyonu SEO’yu etkiler mi rehberi, özellikle global kullanıcı kitleniz varsa elinizin altında olmalı.

Hosting mimarisi: tek altyapı mı, bölgesel sunucular mı?

Domain ve hosting mimarileri birlikte planlanmalıdır; ancak alan adı yapısı tek başına sunucuların sayısını veya konumunu belirlemez. Değerlendirilebilecek tipik desenler şöyle:

Senaryo A: Tek güçlü altyapı + CDN

Tek .com ve alt dizinler için ortak uygulama altyapısı bir başlangıç seçeneğidir. Seçilen VPS veya dedicated hizmetin kapasitesini ve yönetim kapsamını doğrulayın; uygun statik ve herkese açık içerikleri CDN’den, önbelleğe alınmayan işlemleri origin’den sunmayı değerlendirin. Alt dizin kullanımı birden fazla uygulama sunucusuna veya bölgeye engel değildir.

• Avantaj: Dağıtım, güvenlik duvarı kuralları ve yedekleme yönetimi tek merkezde toplanabilir. Ölçeklenebilirlik, sunucu kapasitesine ve uygulamanın yüküne bağlıdır.
• Dezavantaj: Kaynak sunucuya uzak kullanıcıların dinamik isteklerinde gecikme yüksek olabilir. Bölgesel uygulama sunucuları veya veritabanı kopyaları eklemeden önce gecikmenin ağdan, uygulamadan mı yoksa veritabanından mı kaynaklandığını belirlemek gerekir.

Senaryo B: Bölgesel sunucular + merkezi veritabanı veya replikasyon

Örnek bir çok bölgeli tasarımda, hedef pazarlara uygun lokasyonlarda ayrı VPS veya dedicated sunucular kullanılabilir; önlerine akıllı DNS yönlendirmesi ve/veya CDN konabilir. Veritabanı tek merkezde tutulabilir veya merkezi yazma düğümü ve bölgesel salt okunur replikalarla dağıtılabilir. Multi-master ise yazma çakışmaları ve tutarlılık gereksinimleri ayrıca değerlendirilerek seçilmelidir.

• Avantaj: Kullanıcıya yakın sunucular ağ gecikmesini azaltabilir. Düşük TTFB, uygulama ve veritabanı erişimine de bağlıdır; yüksek erişilebilirlik için yedeklilik ve arıza durumunda devralma ayrıca tasarlanmalıdır.
• Dezavantaj: Mimarinin tasarımı ve bakımı daha uzmanlık gerektiriyor. Deploy, veritabanı replikasyonu, sağlık kontrolleri ve felaket senaryoları iyi planlanmalı.

Çok bölge ihtiyacını şirket türünden değil, ölçülen gecikme, kapasite ve kurtarma hedeflerinden çıkarın. DCHost’un VPS, dedicated veya colocation seçeneklerini karşılaştırırken ilgili lokasyonların, ağ bağlantılarının ve yönetim hizmetlerinin güncel kapsamını doğrulayın.

Senaryo C: Ülke bazlı tamamen bağımsız altyapılar

Her ccTLD’nin (ornek.com.tr, ornek.de vb.) kendi sunucusu, kendi veritabanı ve hatta zaman zaman kendi teknoloji stack’i olduğu yapı. Global içerikler (örneğin kurumsal haberler, sürdürülebilirlik raporları) genellikle API ile veya içerik senkronizasyon süreçleriyle paylaşılır.

• Avantaj: Her ülke/iş birimi tamamen bağımsız hareket edebilir. Yerel entegrasyonlar (ödeme, ERP, lojistik sistemleri) daha esnek kurgulanır.
• Dezavantaj: Teknik borç yönetimi zordur. Bir ülkede yapılan iyi bir güvenlik veya performans iyileştirmesini diğerlerine taşımak zaman alır; versiyonlar hızla dağılır.

Gerçekçi senaryolar: 3 farklı şirket tipi üzerinden düşünmek

Senaryo 1: 5 ülkeye açılan B2B üretici

Türkiye merkezli bir makine üreticisi düşünün. Ana pazar Türkiye ve Almanya; yanında birkaç Avrupa ülkesi daha var. Satışlar ağırlıklı bayiler ve distribütörler üzerinden yürüyor; asıl hedef lead toplamak ve marka bilinirliğini artırmak.

Bu varsayımsal profil için aşağıdaki başlangıç düzeni değerlendirilebilir:

• Global domain: ornek.com; marka ana adresi.
• Diller: ornek.com/tr/, ornek.com/en/, ornek.com/de/ ve ornek.com/fr/ gibi alt dizinler.
• Hosting: Ölçülen kaynak ihtiyacına uygun VPS veya dedicated hizmet; güvenle önbelleğe alınan içerik için CDN. NVMe gibi bir özellik tek başına uygulama performansını belirlemez.

Bu sayede:

• SEO çalışmaları tek domain altında toplanır; güçlü sıralamalar yalnızca bu mimariyi seçmekle garanti edilmez.
• Lead formları, CRM entegrasyonları, döküman indirmeler tek altyapıda toplanır.
• Ülke ekipleri çeviri ve lokal içeriklerle farklılaşırken, ortak altyapı IT ekibinin ayrı sistemleri yönetme yükünü azaltabilir.

Senaryo 2: 20+ ülkede faaliyet gösteren B2C perakendeci

Burada iş değişiyor. Bir moda perakendecisi hayal edin: Her ülkede ayrı fiyatlandırma, kampanyalar, ödeme yöntemleri, lojistik iş ortakları ve hatta ürün gamı var. Kullanıcıya yerellik hissi vermek kritik.

Bu durumda genelde hibrit veya ccTLD odaklı mimari ağır basıyor:

• Global çatı: ornek.com; kurumsal ve yatırımcı içerikleri.
• Büyük pazarlar: ornek.com.tr, ornek.de ve ornek.fr gibi yerelleştirilmiş ccTLD siteleri.
• Diğer pazarlar: ornek.com/en/ gibi alt dizinler; ülkeye özgü sürümler gerekiyorsa URL, içerik ve hreflang birlikte planlanır.

Hosting tarafında ise, yüksek trafik ve kampanya yoğunluğu nedeniyle bölgesel VPS/dedicated kümeleri değerlendirilebilir. DCHost üzerinde böyle bir tasarım planlanırken uygun sunucu lokasyonlarının mevcut olması gerekir; CDN içerik dağıtımını, WAF (Web Application Firewall) ise uygulama katmanındaki korumayı destekleyebilir.

Senaryo 3: Grup şirketi / holding yapısı

Holding seviyesinde bir kurumsal site (holding.com), altında onlarca farklı sektör ve markadan oluşan grup şirketleri düşünün. Her grup şirketinin kendi markası ve çoğu zaman kendi alan adı vardır.

Bu profilde strateji genelde şöyle şekilleniyor:

• Holding: holding.com (tek dil veya çok dilli, sade kurumsal yapı).
• Grup şirketleri: marka1.com, marka2.com.tr, marka3.de gibi bağımsız alan adları.
• Siteler arası bağlantılar: Holding ve grup şirketleri arasındaki ilişkiyi açıklayan, kullanıcıya yararlı bağlantılar; karşılıklı bağlantılar otomatik SEO otoritesi aktarımı sağlamaz.

Burada kritik nokta, holding ve markalar arasında net bir alan adı hiyerarşisi kurmak ve her domain’in amacını, sorumlusunu ve kullanım durumunu kaydetmektir. Marka koruması için tutulan her alan adında ayrı bir site yayımlamak gerekmez. Alan adı portföyü genişledikçe, yenileme, transfer ve güvenlik süreçleri için merkezi bir yönetim ihtiyacı doğar. Bu tip yapılarda DCHost tarafında alan adı yönetimi, DNS, hosting ve güvenliği bütüncül ele almak, sorumlulukların ve değişikliklerin takibini kolaylaştırabilir.

DNS, SSL, e-posta ve operasyonel detaylar

Domain ve hosting mimarisini kağıt üzerinde seçmek tek başına yetmez; aşağıdaki operasyonel başlıklar da en az mimari kadar kritiktir:

DNS mimarisi

• Domain, alt alan, yetkili DNS, kayıt türü, hedef ve sorumlu bilgisini güncel bir envanterde tutun.
• Yönetilen DNS veya kendi yetkili DNS altyapınız kullanılabilir; markalı özel nameserver ve glue kullanımı bu mimarinin genel önkoşulu değildir.
• Bir domain’i sabit bir bölgesel IP’ye yönlendirmek, ziyaretçinin konumuna göre seçim yapan geo-DNS ile aynı şey değildir. Coğrafi/ağırlıklı politikalar için sağlayıcı desteğini ve sağlık kontrollerini ayrıca doğrulayın.
• DNS önbellekleri yönlendirme değişikliğini geciktirebilir. Çok bölgede veri, oturum ve arıza sonrası devralma davranışını ayrıca test edin.

SSL mimarisi

• Ad kapsamı: TLS sertifikası URL yolunu değil hostname’i doğrular. ornek.com/tr/ ve ornek.com/de/ aynı hostname’i kullanır; yalnız bu alt dizinler için wildcard gerekmez. www.ornek.com ayrı addır ve ayrıca kapsanmalıdır.
• Wildcard: *.ornek.com, fr.ornek.com gibi tek sol etiketi eşleştirir; ornek.com apex’ini veya a.fr.ornek.com gibi daha derin adı tek başına kapsamaz. Gerekli adları sertifikada ayrıca belirtin.
• Çok domain: SAN alanında birden çok izin verilen DNS adı bulunan tek sertifika farklı ccTLD’leri de kapsayabilir; ayrı sertifikalar başka bir seçenektir. Reverse proxy kullanımı tek başına ad kapsamı sağlamaz. Sertifikayı TLS’in sonlandığı her noktada doğru hostname için yapılandırın.
• Yenileme ve güvenlik: Otomatik yenilemeyi, dağıtımı ve son kullanım uyarılarını izleyin. Let’s Encrypt wildcard doğrulaması DNS-01 gerektirir; DNS API erişimini en dar yetkiyle verin. DV/OV/EV doğrulama düzeyi ile wildcard/SAN ad kapsamı farklı kararlardır; daha geniş kapsam otomatik güvenlik artışı değildir.

E-posta adresleri ve marka bütünlüğü

Çok domain’li yapılarda, e-posta adreslerinin nasıl kurgulanacağı da baştan netleştirilmelidir:

• Kurumsal iletişim: İletişimde karışıklığı azaltmak için “ismi@ornek.com” gibi tek bir kurumsal e-posta domain’i kullanılabilir.
• Ülke/marka bazlı adresler: Bazı durumlarda “destek@ornek.de” gibi ülke domain’leri için de adresler tanımlanabilir; bu durumda MX kayıtlarınızı ve SPF/DKIM/DMARC yapılandırmalarınızı dikkatle tasarlamanız gerekir.

Doğru mimariyi seçerken hangi soruları sormalısınız?

Karar öncesinde pazarlama, IT, güvenlik ve ilgili hukuk/veri sorumlularıyla şu soruları değerlendirin:

• Önümüzdeki 3–5 yılda kaç dil ve kaç ülke hedefleniyor?
• Hangi ülkelerde lokal ofis, ekip veya hukuk/regülasyon gereksinimi var?
• Ürün ve fiyatlandırma her ülkede ne kadar farklılaşıyor?
• Merkezi pazarlama ve IT ekipleri mi baskın, yoksa ülke ekipleri mi?
• Kullanılacak teknolojiler (CMS, e-ticaret, özel yazılım) ülkeden ülkeye değişecek mi?
• SEO hedeflerinizde “global marka otoritesi” mi, “yerel görünürlük” mü daha önde?
• Performans hedefleri neler? (TTFB, LCP, Core Web Vitals metrikleri…)

Bu sorulara net cevaplar verdiğinizde, yukarıda anlattığımız dört modelden hangisinin size daha uygun olduğu büyük ölçüde ortaya çıkıyor. Sonrasında ise alan adı ve TLD tarafını stratejik olarak çerçeveleyen TLD seçimi rehberi ile, ccTLD/gTLD karışımınızı daha teknik temelde netleştirebilirsiniz.

DCHost ile adım adım yol haritası

Domain, hosting, DNS, TLS ve e-posta kararlarını aynı mimari envanterinde toplayın. Her dil veya ülke sürümünün amacı, sahibi, veri akışı ve bakım sorumluluğu belli olsun. DCHost ile hizmetleri görüşürken bu gereksinimlerle birlikte mevcut trafik ve kapasite ölçümlerini paylaşabilirsiniz.

Özetle:

• Merkezi kurumsal içerik için tek gTLD ve alt dizinleri başlangıç seçeneği olarak değerlendirin; SEO veya kapasite avantajını otomatik saymayın.
• Yerel içerik ve bağımsız ekip ihtiyacı için ccTLD veya subdomain seçeneklerini yönetim yüküyle karşılaştırın.
• Hibrit modelde aynı içeriğin nerede yayımlanacağını, canonical/hreflang ilişkilerini, e-posta ve sertifika kapsamını açıkça belirleyin.
• URL değişiyorsa eski–yeni sayfa eşlemesini ve ilgili 301 yönlendirmelerini hazırlayın. HTTPS eski adlarda da çalışmalı; ilgisiz sayfaları tek ana sayfaya göndermeyin.

Uluslararası SEO ile domain yapınızı uyumlu hale getirmek için, mutlaka hreflang rehberimizi ve ccTLD/gTLD dengesini tartıştığımız alan adı stratejisi yazımızı okumanızı öneririz. Sunucu tarafında ise, sunucu lokasyonu ve SEO ilişkisini ele aldığımız rehber, global mimarinizi performans açısından da rayına oturtmanıza yardımcı olacaktır.

DCHost’tan teklif alırken ürünün lokasyon, ağ, kapasite, yedekleme, yönetim ve destek kapsamını doğrulayın. Yönetilen hizmet, talep ettiğiniz her işi otomatik olarak içermez; DNS, sertifika, uygulama ve taşıma işlerinin sorumlusunu belirleyin. Mevcut URL değişiklikleri için yönlendirme, veri senkronizasyonu, doğrulama ve geri dönüş planı hazırlayın.

Seçtiğiniz mimariyi yeni ülke, marka veya iş yükü eklendiğinde yeniden değerlendirin. İlk kurulumun uzun vadede her birleşme veya büyümeyi sorunsuz karşılayacağını varsaymayın; içerik, URL, sertifika ve altyapı envanterini güncel tutmak değişiklikleri daha kontrollü yönetmenizi sağlar.