Çok Dilli Web Sitesi Yaptırırken Hangi Maliyetler Çıkar?

Bir web sitesine ikinci bir dil eklemek ilk bakışta oldukça basit görünebilir:

“Mevcut sayfaları İngilizceye çeviririz, menüye dil seçeneği ekleriz.”

Fakat gerçek bir çok dilli web sitesi projesinin maliyeti yalnız metinlerin çeviri ücretinden oluşmaz.

Projeye göre ayrıca:

• Dil ve ülke mimarisi
• Yeni URL’ler
• CMS geliştirmeleri
• Çeviri veya lokalizasyon
• Yeni görseller
• Formlar
• SEO ayarları
• Hreflang
• QA
• Bakım

gibi ek iş kalemleri ortaya çıkabilir.

Bu nedenle çok dilli web sitesi bütçesini:

WEB SİTESİ MALİYETİ + ÇEVİRİ

şeklinde hesaplamak çoğu projede eksik kalır.

Daha gerçekçi model:

BASE WEBSITE → LANGUAGE ARCHITECTURE → LOCALIZATION → IMPLEMENTATION → SEO → QA → CONTINUOUS MAINTENANCE

şeklindedir.

DigitalPlus’ta Web Sitesi Geliştirme projelerinde çok dilli yapı gerekiyorsa bunu yalnız dil seçici eklemek olarak değil, sitenin içerik, teknik altyapı ve gelecekteki yönetim modelinin bir parçası olarak değerlendiriyoruz.

Çok Dilli Web Sitesi Normal Bir Web Sitesinden Neden Daha Pahalıdır?

Çünkü aynı web sitesinin yalnız metinlerini değil, kullanıcı deneyiminin belirli bölümlerini birden fazla dilde yönetmeye başlarsınız.

Örneğin 20 sayfalık kurumsal siteniz olduğunu düşünün.

Türkçe dışında İngilizce ve Almanca da yayınlanacaksa teorik olarak artık:

• 20 Türkçe sayfa
• 20 İngilizce sayfa
• 20 Almanca sayfa

yönetirsiniz.

Fakat maliyet otomatik olarak üç katına çıkmak zorunda değildir.

Aynı:

• Tasarım sistemi
• Component’ler
• CMS altyapısı
• Hosting
• Temel kod

diller arasında tekrar kullanılabilir.

Ek maliyet daha çok her yeni dil için tekrar yapılması gereken işlerden doğar.

Çok Dilli Web Sitesi Maliyet Formülü Nasıl Düşünülmeli?

Pratik bir proje modeli şöyle kurulabilir:

TOPLAM MALİYET = ANA WEB SİTESİ + ÇOK DİLLİ ALTYAPI + İÇERİK LOKALİZASYONU + DİL BAZLI QA + SEO + BAKIM

Bu kalemlerin büyüklüğü proje kapsamına göre değişir.

Örneğin:

• 5 sayfalık iki dilli kurumsal site

ile:

• 150 hizmet sayfası
• 4 ülke
• 3 dil
• Her ülkeye farklı teklif ve içerik

yöneten site aynı bütçeyle geliştirilmez.

1. İkinci Dil İçin Teknik Altyapı Maliyeti

İlk maliyet kalemi sitenin birden fazla dil sürümünü yönetebilmesidir.

CMS veya mevcut altyapıya göre:

• Dil yönetim sistemi
• Dil seçici
• URL üretimi
• Navigation
• Language relationships
• Translation workflow

kurulması gerekebilir.

WordPress kullanılan projelerde çok dilli yapı mevcut plugin veya özel geliştirmelerle yönetilebilir.

Özel yazılımda ise dil desteğinin uygulamanın veri modeli ve yönetim paneli içerisinde ayrıca geliştirilmesi gerekebilir.

WordPress Çok Dilli Siteyi Daha Ucuza mı Getirir?

Standart kurumsal projelerde mevcut çok dilli CMS çözümleri geliştirme süresini azaltabilir.

Ancak WordPress kullanılması çok dilli sitenin otomatik olarak ucuz olacağı anlamına gelmez.

Çünkü asıl maliyetin önemli bölümü yine:

• İçerik
• Lokalizasyon
• SEO
• Test
• Yönetim

tarafında oluşabilir.

2. Çeviri Maliyeti

En görünür maliyetlerden biri içeriklerin diğer dillere çevrilmesidir.

Çevrilmesi gereken alan yalnız ana sayfa metni değildir.

Projeye göre:

• Ana sayfa
• Hizmet sayfaları
• Hakkımızda
• Referanslar
• Blog içerikleri
• Form alanları
• Butonlar
• Menüler
• Footer
• FAQ
• SEO title
• Meta description

gibi birçok alanın dil bazında hazırlanması gerekir.

Bu yüzden sayfa sayısı arttıkça translation workload da büyür.

Kelime Sayısı mı, Sayfa Sayısı mı Maliyeti Belirler?

İkisi de etkileyebilir.

Uzun teknik içeriklerin bulunduğu 15 sayfalık B2B sitesi, kısa metinlerden oluşan 40 sayfalık başka bir siteden daha fazla çeviri işi gerektirebilir.

Bu nedenle yalnız:

“Kaç sayfa var?”

sorusuyla teklif çıkarmak yeterli değildir.

İçerik envanteri çıkarılarak:

• Sayfa sayısı
• İçerik uzunluğu
• Tekrar kullanılabilecek metinler
• Teknik terminoloji

birlikte değerlendirilmelidir.

3. Çeviri ile Lokalizasyon Aynı Şey Değildir

Çok dilli web sitesi için yalnız kelimelerin başka dile çevrilmesi her zaman yeterli değildir.

Örneğin Türkçe sayfada:

“Türkiye’nin her yerine hizmet veriyoruz.”

yazan metnin Almanca sürümünü kelimesi kelimesine çevirmek, Almanya’daki kullanıcıya anlamlı bir teklif oluşturmayabilir.

Lokalizasyon sırasında:

• Hizmet kapsamı
• Para birimi
• Tarih formatları
• Telefon numaraları
• Adresler
• Ticari ifadeler
• Ölçü birimleri
• Yerel terminoloji

değişebilir.

Dolayısıyla:

TRANSLATION = Dil dönüşümü

iken:

LOCALIZATION = İçeriği hedef pazara uyarlama

olarak düşünülebilir.

Lokalizasyon Neden Daha Pahalı Olabilir?

Çünkü çevirmenin yalnız metni çevirmesi değil, içeriğin hedef kullanıcı için doğru olup olmadığının da değerlendirilmesi gerekir.

Özellikle:

• Sağlık
• Hukuk
• Finans
• Teknik B2B
• Turizm

gibi alanlarda yerel uzman veya native reviewer gerekebilir.

4. Yeni Dil İçin İçerik Yeniden Yazılması Gerekebilir

Her sayfa birebir çevrilmek zorunda değildir.

Örneğin Türkiye’de önemli olan bir hizmet Almanya pazarında hiç sunulmuyor olabilir.

Veya İngilizce kullanıcıların karar verirken sorduğu sorular Türkçe kullanıcılardan farklı olabilir.

Bu durumda yeni dil sürümünde:

• Bazı sayfalar kaldırılabilir
• Bazı sayfalar birleştirilebilir
• Yeni landing page’ler açılabilir
• İçerik tamamen yeniden yazılabilir

Bu çalışma yalnız translation değil content production haline gelir.

Yeni pazara özel sayfa metinlerinin sıfırdan hazırlanması gerekiyorsa Web İçeriği Üretimi ayrı bir proje kalemi haline gelebilir.

5. Çok Dilli SEO Maliyeti

Web sitesinin ikinci dilde yayınlanması o dilde Google görünürlüğünün otomatik oluşacağı anlamına gelmez.

SEO hedefleniyorsa her pazar için ayrıca:

• Search demand
• Keyword research
• Search intent
• Landing page yapısı
• Metadata
• Internal linking

değerlendirilmelidir.

Örneğin Türkçede kullanılan anahtar kelimenin doğrudan İngilizce çevirisi kullanıcıların gerçekte yaptığı arama olmayabilir.

Bu nedenle:

TÜRKÇE KEYWORD → İNGİLİZCE ÇEVİRİ

yaklaşımı uluslararası SEO stratejisi değildir.

Her Dil İçin Ayrı Keyword Research Gerekir mi?

Organik Search hedefleniyorsa genellikle evet.

Çünkü kullanıcıların:

• Terminolojisi
• Arama biçimi
• Ürün isimleri
• Karar kriterleri

pazara göre değişebilir.

Örneğin aynı hizmet farklı ülkelerde farklı commercial modifiers ile aranabilir.

Dolayısıyla yeni dil eklemek aynı zamanda yeni Search market araştırması anlamına gelebilir.

6. URL Yapısı Planlama Maliyeti

Çok dilli sitelerde her dil için ayrı ve kalıcı URL yapısı oluşturulmalıdır.

Örneğin:

• /tr/
• /en/
• /de/

gibi subdirectory modeli kullanılabilir.

Bunun dışında:

• Subdomain
• Ayrı country domain

gibi modeller de bulunabilir.

Doğru yapı:

• Mevcut domain
• Hedef ülkeler
• Teknik altyapı
• Operasyon modeli
• SEO stratejisi

üzerinden belirlenmelidir.

Her Ülke İçin Ayrı Domain Gerekir mi?

Hayır.

Örneğin:

• example.com/tr/
• example.com/de/

gibi tek domain altında farklı dil veya ülke sürümleri yönetilebilir.

Bazı işletmeler ise stratejik nedenlerle ülke domainleri kullanabilir.

Burada hosting, domain, SEO ve içerik operasyonu birlikte düşünülmelidir.

7. Hreflang Uygulaması Maliyet Çıkarır mı?

Çok dilli veya çok bölgeli sitelerde arama motorlarının doğru dil veya bölge URL’sini anlamasına yardımcı olmak için hreflang kullanılabilir.

Bu uygulamanın maliyeti özellikle büyük sitelerde artabilir.

Çünkü her ilgili URL grubunun karşılıklı ilişkileri doğru kurulmalıdır.

Örneğin yüzlerce sayfalık ve dört dil kullanan yapıda:

• Eksik hreflang
• Yanlış URL
• Karşılıksız annotation
• Canonical çakışması

gibi hatalar sistematik QA gerektirir.

Dolayısıyla hreflang yalnız template’e birkaç satır eklemekten ibaret değildir.

Hreflang Kurulmazsa Site Çalışmaz mı?

Hayır.

Hreflang sitenin teknik olarak çalışması için zorunlu değildir.

Ancak çok dilli ve özellikle aynı dile ait farklı bölgesel sayfaların bulunduğu yapılarda Google’ın doğru localized URL’yi kullanıcıya göstermesine yardımcı olabilir.

Bu nedenle uluslararası SEO hedefi bulunan projelerde teknik planın parçası olarak değerlendirilmelidir.

8. Canonical Yapısının Kontrol Edilmesi Gerekir

Çok dilli sitelerde yanlış canonical uygulaması önemli SEO sorunlarına yol açabilir.

Örneğin İngilizce sayfanın canonical’ı yanlışlıkla Türkçe sayfaya verilirse farklı dil sürümleri arasındaki ilişki yanlış ifade edilmiş olabilir.

Her language page’in:

• Canonical
• Hreflang
• Indexability

ilişkisi birlikte kontrol edilmelidir.

9. Menü ve Navigation Maliyeti

Dil seçici eklemek kolay görünür.

Ama kullanıcı:

Türkçe hizmet sayfasındayken İngilizceye geçtiğinde nereye gitmeli?

sorusu cevaplanmalıdır.

İdeal durumda doğrudan ilgili sayfanın diğer dil sürümüne geçer.

Ana sayfaya dönmek zorunda kalmaz.

Bunun için CMS içerisinde farklı language versions birbirleriyle ilişkilendirilmelidir.

Her Sayfanın Diğer Dilde Karşılığı Olmak Zorunda mı?

Hayır.

Örneğin bazı:

• Kampanyalar
• Yerel haberler
• Hizmetler

yalnız belirli pazara ait olabilir.

Bu durumda sistem olmayan bir çeviriye kullanıcıyı yönlendirmemelidir.

Language switcher davranışı bu senaryoya göre tasarlanmalıdır.

10. Tasarım Yeni Dillerde Tekrar Kontrol Edilmelidir

Aynı tasarım tüm dillerde kullanılabilir.

Ancak metin uzunlukları değişebilir.

Türkçede tek satır olan başlık Almancada üç satıra çıkabilir.

Bu durum:

• Butonlar
• Menüler
• Cards
• Hero alanları
• Tablolar

üzerinde layout problemleri oluşturabilir.

Bu nedenle tasarım bir kez hazırlanmış olsa bile her dil sürümünde responsive QA gerekebilir.

11. Sağdan Sola Yazılan Diller Ek Maliyet Oluşturabilir mi?

Evet.

Arapça gibi sağdan sola yazılan dillerde yalnız metni çevirmek yeterli değildir.

Arayüzün:

• Metin yönü
• Navigation
• Icon yerleşimi
• Form yapısı
• Component hizalamaları

da uygun biçimde çalışması gerekir.

Bu nedenle RTL desteği tasarım ve frontend tarafında ek geliştirme gerektirebilir.

12. Görseller de Lokalize Edilmeli mi?

Görselin içerisinde metin varsa evet.

Örneğin:

• Banner
• Infographic
• Ürün görseli üzerindeki açıklamalar
• Promotional graphics

farklı dil sürümleri gerektirebilir.

Bu durumda translation yanında tasarım üretim maliyeti de oluşur.

13. Video İçerikleri Yeni Dil Maliyetini Artırır mı?

Evet.

Video kullanılıyorsa projeye göre:

• Subtitle
• Voice-over
• Yeni grafikler
• Transcript

gerekebilir.

Dolayısıyla çok dilli website bütçesi yalnız website development ekibiyle sınırlı olmayabilir.

14. Formlar Her Dil İçin Yeniden Hazırlanmalı mı?

Form yapısı tekrar kullanılabilir.

Ancak:

• Label’lar
• Placeholder’lar
• Validation mesajları
• Success message
• Privacy açıklamaları

yerelleştirilmelidir.

Ayrıca farklı ülkelerden gelen lead’lerin farklı satış ekiplerine gönderilmesi isteniyorsa routing logic gerekebilir.

15. CRM Entegrasyonu Çok Dilli Yapıda Ek Maliyet Çıkarabilir mi?

Evet.

Örneğin form üzerinden gelen lead’in:

• Dili
• Ülkesi
• İlgilendiği hizmet

CRM’e ayrıca gönderilebilir.

Ardından:

Türkiye → Türk satış ekibi

Almanya → Almanca satış ekibi

gibi otomatik yönlendirmeler yapılabilir.

Bu artık yalnız çeviri değil integration ve automation kapsamına girer.

16. Para Birimi Ek Maliyet Oluşturur mu?

Sitenin yalnız kurumsal tanıtım amacı varsa farklı para birimi gerekmeyebilir.

Ama fiyat gösteriliyorsa:

• TRY
• EUR
• USD

gibi farklı currency ihtiyaçları oluşabilir.

Kur manuel mi güncellenecek?

Ülkeye göre sabit fiyat mı kullanılacak?

Vergi dahil fiyat değişecek mi?

Bu sorular özellikle e-ticaret ve rezervasyon sistemlerinde development scope’u artırabilir.

17. E-Ticaret Sitesinde Çok Dilli Yapı Neden Daha Pahalıdır?

E-ticarette dil sayısı arttığında yalnız kurumsal sayfalar çoğalmaz.

Aynı zamanda:

• Ürün adları
• Ürün açıklamaları
• Kategoriler
• Filtreler
• Attribute’lar
• Checkout
• Transactional e-postalar

da lokalize edilebilir.

10.000 ürün bulunan mağazada bunun içerik ve veri operasyonu kurumsal siteden çok daha büyük olabilir.

18. Blog İçerikleri de Çevrilmeli mi?

Hepsinin çevrilmesi şart değildir.

Önce hedef pazardaki gerçek information demand değerlendirilmelidir.

Türkçe blogda iyi performans gösteren her konunun Almanca veya İngilizce pazarda aynı talebe sahip olduğu varsayılmamalıdır.

Bu nedenle içerik migration’ında üç karar verilebilir:

• TRANSLATE
• LOCALIZE / REWRITE
• DO NOT CREATE

Bu yaklaşım gereksiz çeviri maliyetini de azaltabilir.

19. Mevcut Siteye Sonradan Dil Eklemek Daha mı Pahalıdır?

Altyapının nasıl geliştirildiğine bağlıdır.

Site baştan multilingual düşünülerek oluşturulduysa yeni dil eklemek nispeten kolay olabilir.

Ancak mevcut:

• URL yapısı
• CMS
• Component’ler
• Hard-coded metinler

tek dil varsayımıyla geliştirilmişse refactoring gerekebilir.

Bu nedenle gelecekte uluslararası büyüme ihtimali varsa altyapının baştan genişleyebilir tasarlanması uzun vadeli maliyeti azaltabilir.

20. Mevcut URL’ler Değişecekse Migration Maliyeti Çıkabilir

Mevcut Türkçe site örneğin:

/hizmetler/

yapısından:

/tr/hizmetler/

yapısına taşınacaksa mevcut URL’ler değişmiş olur.

Bu durumda:

• URL inventory
• 301 redirect mapping
• Internal link update
• Canonical
• Sitemap
• Search Console monitoring

gibi migration çalışmaları gerekebilir.

Organik trafik alan mevcut bir sitede bu değişiklik yalnız web development kararı olarak yapılmamalıdır.

URL veya altyapı değişikliği söz konusuysa Site Taşıma SEO kapsamında mevcut organik görünürlüğün korunması ayrıca planlanmalıdır.

21. Domain Maliyeti Artabilir mi?

Tek domain altında subdirectory kullanılıyorsa yeni domain gerekmeyebilir.

Ama işletme:

• .de
• .co.uk
• .fr

gibi ayrı country domain’leri kullanacaksa:

• Domain kaydı
• Yenileme
• DNS
• SSL

maliyetleri ayrı oluşabilir.

22. Hosting Maliyeti Artar mı?

Her yeni dil için otomatik olarak ayrı sunucu gerekmez.

Ancak daha fazla:

• Sayfa
• Medya
• Trafik
• Cache varyasyonu

altyapı ihtiyacını artırabilir.

Uluslararası ziyaretçiler için CDN veya farklı hosting architecture’ı da değerlendirilebilir.

Bu nedenle hosting maliyeti dil sayısından çok gerçek traffic ve infrastructure ihtiyacına bağlıdır.

23. Çok Dilli Sitede Analytics Ayrı Kurulmalı mı?

Aynı analytics altyapısı kullanılabilir.

Ancak performansı dil veya ülke bazında ayırabilmek için measurement planı buna göre hazırlanmalıdır.

Örneğin raporda:

• Türkçe landing pages
• İngilizce landing pages
• Almanca landing pages

ayrı incelenebilir.

Bu sayede hangi pazarın gerçekten:

• Traffic
• Lead
• Revenue

ürettiği görülebilir.

24. Cookie ve Privacy Gereksinimleri Ülkeye Göre Değişebilir

Birden fazla ülkede hizmet verildiğinde yalnız dili değil, veri işleme süreçlerini de değerlendirmek gerekebilir.

Örneğin:

• Cookie consent
• Privacy policy
• Form consent
• Marketing permission

gereksinimleri hedef pazara göre farklılaşabilir.

Hukuki gereksinimler işletmenin faaliyet gösterdiği bölge ve veri işleme modeline göre uygun hukuk veya uyum uzmanıyla değerlendirilmelidir.

25. Hukuki Metinlerin Çevirisi Ayrı Maliyet midir?

Olabilir.

Örneğin:

• Gizlilik politikası
• Çerez politikası
• Kullanım koşulları
• Mesafeli satış metinleri

yalnız normal pazarlama çevirisi olarak ele alınmayabilir.

Hedef ülkenin hukuki gereksinimlerine göre ayrıca düzenlenmesi gerekebilir.

26. QA Maliyeti Neden Dil Sayısıyla Artar?

Site teknik olarak bir kez geliştirilse bile her dil sürümünün ayrı kontrol edilmesi gerekir.

Örneğin İngilizce sürümde çalışan form Almanca sürümde yanlış endpoint’e bağlı olabilir.

Her dil için en azından:

• Navigation
• Broken links
• Forms
• Language switcher
• Responsive design
• Metadata
• Canonical
• Hreflang

kontrol edilebilir.

Bu nedenle QA workload yeni dil ekledikçe artar.

27. Çeviri QA’sı ile Teknik QA Aynı Şey mi?

Hayır.

Translation QA:

• Dil
• Terminoloji
• Anlam
• Marka tonu

üzerine odaklanır.

Technical QA ise:

• Link
• Form
• URL
• Layout
• SEO elementleri

üzerine odaklanır.

İyi çok dilli projede bu iki kontrol birbirinin yerine geçmez.

28. Native Speaker Kontrolü Gerekli mi?

Projenin önemine göre değerlendirilebilir.

Özellikle satış odaklı:

• Homepage
• Service pages
• Product pages
• Advertising landing pages

için native veya hedef pazarı iyi bilen reviewer, makine veya doğrudan çeviri sırasında oluşabilecek doğal olmayan dili yakalayabilir.

29. AI ile Çeviri Maliyeti Düşürülebilir mi?

Evet, belirli workflow’larda yapay zeka veya machine translation ilk taslağın üretim maliyetini azaltabilir.

Ancak:

AI çıktı verdi → otomatik yayın

modeli özellikle ticari ve teknik sayfalarda kalite riski oluşturabilir.

Daha sağlıklı süreç:

SOURCE CONTENT → MACHINE / AI DRAFT → HUMAN REVIEW → LOCALIZATION → QA → PUBLISH

şeklinde kurulabilir.

İnsan kontrolünün yoğunluğu içerik riskine göre değişebilir.

30. Her Yeni Dil Web Sitesi Maliyetini İki Katına mı Çıkarır?

Hayır.

Ana:

• Design system
• Frontend
• CMS
• Hosting

altyapısı çoğu zaman ortak kullanılabilir.

Dolayısıyla ikinci dil genellikle sıfırdan ikinci bir web sitesi geliştirmek anlamına gelmez.

Fakat:

• İçerik
• Lokalizasyon
• SEO
• QA
• Bakım

gibi maliyetler her dil için tekrar oluşabilir.

31. İki Dil ile Beş Dil Arasında Maliyet Nasıl Değişir?

İlk ek dilde multilingual altyapının kurulması gerekir.

Sonraki dillerde altyapının önemli bölümü tekrar kullanılabilir.

Ancak her yeni dil hâlâ:

• Content
• Translation
• Localization
• SEO research
• QA

ekler.

Bu nedenle maliyet doğrusal olmak zorunda değildir ama dil sayısı büyüdükçe operasyon yükü kesinlikle artar.

32. Her Dil Aynı Maliyete mi Sahiptir?

Hayır.

Örneğin maliyeti şu faktörler değiştirebilir:

• Çevirmen bulunabilirliği
• Teknik uzmanlık
• Native review
• RTL ihtiyacı
• İçerik uzunluğu
• Yerel regulatory kontroller

Dolayısıyla İngilizce ile daha niş bir dilin üretim maliyeti aynı olmayabilir.

33. Çok Dilli Siteyi Yayına Aldıktan Sonra Maliyet Biter mi?

Hayır.

Yeni Türkçe içerik yayınlandığında şu sorunun sürekli cevaplanması gerekir:

Bu içerik diğer dillere de aktarılacak mı?

Yeni:

• Hizmet
• Kampanya
• Blog
• Referans
• Ürün

eklendiğinde multilingual content workflow tekrar çalışır.

34. Çok Dilli Web Sitesinde Bakım Maliyeti Neden Artabilir?

Bakım yalnız plugin veya yazılım güncellemesi değildir.

Çok dilli yapıda ayrıca:

• Eksik translation
• Broken language relationships
• Hreflang
• Language navigation
• Localized forms

takip edilebilir.

Site sürekli güncelleniyorsa Web Sitesi Yönetimi kapsamında içerik, bakım, güvenlik ve performans operasyonunun kim tarafından sürdürüleceği baştan planlanmalıdır.

35. Çok Dilli Sitenin En Büyük Gizli Maliyeti Nedir?

Çoğu zaman ilk geliştirme değil sürekli content operation’dır.

Örneğin Türkçe ekip ayda:

• 4 blog
• 2 yeni hizmet sayfası
• 3 vaka çalışması

yayınlıyorsa dört dilde çalışan yapıda şu karar her içerik için tekrar ortaya çıkar:

• Hangi dillere çevrilecek?
• Kim çevirecek?
• Kim kontrol edecek?
• Ne zaman yayınlanacak?

Bu nedenle multilingual website kurarken yalnız launch budget değil ongoing budget da hesaplanmalıdır.

36. Bütün Siteyi Aynı Anda Çevirmek Gerekir mi?

Hayır.

Bütçe sınırlıysa fazlı rollout yapılabilir.

Örneğin ilk faz:

• Ana sayfa
• Ana hizmetler
• Hakkımızda
• İletişim

ile başlanabilir.

Daha sonra Search demand ve iş önceliğine göre diğer içerikler eklenebilir.

Bu yaklaşım düşük değerli yüzlerce sayfayı ilk günden çevirmek yerine yatırımı daha kontrollü yönetmeye yardımcı olur.

37. Hangi Sayfaların Önce Çevrileceğine Nasıl Karar Verilir?

Önceliklendirme şu faktörlere göre yapılabilir:

• Business value
• Search demand
• Sales relevance
• Traffic
• Müşteri ihtiyacı

Örneğin ihracat yapan B2B şirket için İngilizce:

• Ana ürün grupları
• Sektör sayfaları
• Teknik ürün sayfaları
• İletişim

ilk fazda blog arşivinden daha yüksek öncelikli olabilir.

38. Çok Dilli Website Teklifinde Nelerin Dahil Olduğunu Kontrol Edin

“3 dil dahil” ifadesi tek başına yeterli değildir.

Teklifte şu sorular cevaplanmalıdır:

1. Çevirileri kim hazırlayacak?
2. Native review dahil mi?
3. Lokalizasyon dahil mi?
4. Çeviri CMS’e kim tarafından girilecek?
5. Dil URL yapısı dahil mi?
6. Hreflang kurulacak mı?
7. SEO title ve description’lar çevrilecek mi?
8. Her dilde form QA yapılacak mı?
9. Yeni görseller dahil mi?
10. Sonraki içeriklerin çeviri maliyeti nasıl hesaplanacak?

39. Çeviri Hizmeti Dahil Değilse Fiyat Neden Daha Düşük Görünebilir?

İki web geliştirme teklifi aynı teknik kapsamı sunuyor olabilir.

Birinci teklif:

• Çeviri
• Content entry
• SEO localization
• QA

dahil ederken ikinci teklif yalnız multilingual CMS’i kuruyor olabilir.

Bu nedenle toplam fiyat karşılaştırılmadan önce scope karşılaştırılmalıdır.

40. Çok Dilli Web Sitesi İçin Fiyat Tek Sayıya Nasıl İndirgenir?

Sağlıklı teklif öncesinde en az şu bilgiler bilinmelidir:

Değişken	Maliyete Etkisi
Dil sayısı	Content ve QA hacmini artırır
Sayfa sayısı	Çeviri ve yayın yükünü artırır
Kelime hacmi	Translation maliyetini etkiler
Lokalizasyon ihtiyacı	Editoryal maliyeti artırabilir
Özel CMS	Development ihtiyacını artırabilir
SEO hedefi	Keyword research ve teknik SEO ekler
RTL dil	Frontend ve design QA artırabilir
E-ticaret	Ürün ve kategori hacmini büyütür
Ülkeye özel içerik	Yeni sayfa üretimi gerektirebilir
Migration	Redirect ve SEO QA gerektirebilir

41. Çok Dilli Web Sitesi İçin Sabit Paket Mantıklı mı?

Küçük ve standart projelerde paket model kullanılabilir.

Örneğin:

• 10 sayfa
• 2 dil
• Aynı tasarım
• Çeviri müşteri tarafından

gibi scope netse iş kolay fiyatlandırılabilir.

Ama:

• 4 ülke
• 3 dil
• Her ülkede farklı hizmetler
• SEO localization
• CRM routing

gibi ihtiyaçlar varsa proje özel kapsam gerektirir.

42. DigitalPlus Web Sitesi Paketlerinde Çok Dilli Yapı Nasıl Değerlendirilmeli?

Standart web sitesi paketleri bir başlangıç scope’u sağlayabilir.

Çok dilli yapı ise:

• Ek dil sayısı
• Sayfa hacmi
• Çeviri sorumluluğu
• SEO ihtiyacı
• Özel entegrasyon

nedeniyle ayrıca kapsamlandırılabilir.

Mevcut website paketlerini ve kapsam seviyelerini DigitalPlus Fiyatlandırma sayfasından inceleyebilirsiniz.

43. En Ucuz Çok Dilli Website Teklifi Mantıklı mı?

Scope doğruysa olabilir.

Düşük fiyat kendi başına problem değildir.

Ama teklif yalnız:

“Dil plugin’i kurulur.”

seviyesindeyse aşağıdaki maliyetlerin sonradan çıkıp çıkmayacağını kontrol edin:

• Çeviri
• Localization
• Content entry
• Hreflang
• SEO
• QA
• Bakım

44. Çok Dilli Site İçin Gereksiz Maliyeti Nasıl Azaltabilirsiniz?

1. Gerçekten ihtiyacınız olan dillerle başlayın.
2. Bütün eski blog arşivini otomatik çevirmeyin.
3. Commercial pages’i önceliklendirin.
4. Tek bir design system kullanın.
5. Translation glossary oluşturun.
6. Tekrarlanan metinleri merkezi yönetin.
7. AI veya translation memory kullanımını kontrollü değerlendirin.
8. İlk günden sürdürülebilir content workflow kurun.

45. Translation Glossary Neden Maliyeti Azaltabilir?

Özellikle teknik sektörlerde aynı terim sürekli farklı çevrilirse her içerikte yeniden edit gerektirir.

Örneğin şirket için onaylı:

• Ürün adları
• Teknik terimler
• Hizmet isimleri
• Marka ifadeleri

glossary içerisinde tutulabilir.

Bu hem tutarlılığı hem üretim hızını artırabilir.

46. İki Dilli Küçük Kurumsal Site İçin Hangi Kalemler Çıkar?

Örneğin Türkçe + İngilizce küçük kurumsal site için:

• Ana website tasarım ve geliştirme
• Multilingual CMS kurulumu
• İngilizce translation / localization
• İngilizce content entry
• Language navigation
• SEO metadata
• Hreflang ve teknik kontroller
• İngilizce QA

temel scope’u oluşturabilir.

47. Uluslararası B2B Sitesinde Hangi Ek Maliyetler Çıkar?

İhracat hedefleyen üretici için kapsam daha geniş olabilir:

• Her pazar için keyword research
• Product localization
• Technical terminology review
• Sector landing pages
• Country-specific contact flows
• CRM lead routing
• International SEO QA

Bu projede maliyeti yalnız toplam sayfa sayısı açıklamaz.

Uzmanlık ve lokalizasyon ihtiyacı da önemli iş kalemidir.

48. Turizm Sitesinde Çok Dilli Yapı Neden Önemlidir?

Otel ve turizm işletmelerinde farklı ülkelerden ziyaretçiler doğrudan web sitesine gelebilir.

Bu nedenle yalnız temel bilgilerin değil:

• Oda bilgileri
• Rezervasyon
• Hizmetler
• Politikalar
• Lokasyon

gibi karar alanlarının da kullanıcının dilinde doğru çalışması gerekebilir.

Bu tür projelerde dil yalnız içerik özelliği değil conversion journey’nin parçasıdır.

49. Çok Dilli Web Sitesi Maliyetini Hesaplamadan Önce Sorulacak 12 Soru

1. Kaç dil olacak?
2. Diller belirli ülkeleri de hedefliyor mu?
3. Toplam kaç sayfa çevrilecek?
4. Çevirileri kim hazırlayacak?
5. Localization gerekiyor mu?
6. Native review gerekiyor mu?
7. Yeni pazarlara özel sayfalar oluşturulacak mı?
8. SEO yapılacak mı?
9. Mevcut URL yapısı değişecek mi?
10. Form ve CRM routing değişecek mi?
11. Görsel veya video localization gerekiyor mu?
12. Yeni içerikler gelecekte nasıl çevrilecek?

50. Çok Dilli Web Sitesi İçin Gerçek Toplam Maliyeti Nasıl Düşünmelisiniz?

Yalnız launch maliyetine bakmayın.

İki ayrı bütçe düşünün:

INITIAL BUILD COST

ve:

ONGOING MULTILINGUAL OPERATIONS

İlk grup:

• Development
• Translation
• Localization
• SEO setup
• QA

içerebilir.

İkinci grup:

• Yeni içerik çevirileri
• Content updates
• Maintenance
• SEO
• Localization QA

içerebilir.

Çok Dilli Web Sitesi Yaptırırken Hangi Maliyetler Çıkar?

Kısa cevap:

Çok dilli web sitesi maliyeti yalnız çeviri ücretinden oluşmaz.

Gerçek maliyet modeli:

WEB DEVELOPMENT

↓

MULTILINGUAL CMS

↓

TRANSLATION + LOCALIZATION

↓

LANGUAGE / COUNTRY ARCHITECTURE

↓

SEO + HREFLANG

↓

CONTENT ENTRY

↓

LANGUAGE-SPECIFIC QA

↓

ONGOING MAINTENANCE

şeklinde düşünülmelidir.

Her yeni dil website geliştirme maliyetini sıfırdan tekrar oluşturmaz.

Aynı tasarım ve teknik altyapı tekrar kullanılabilir.

Ancak her yeni dil:

• İçerik
• Lokalizasyon
• SEO
• Test
• Bakım

operasyonunu büyütür.

Bu nedenle teklif alırken yalnız:

“İkinci dil kaç TL?”

diye sormayın.

Şunları netleştirin:

• Hangi sayfalar dahil?
• Çeviriyi kim yapıyor?
• Lokalizasyon var mı?
• SEO araştırması dahil mi?
• Hreflang ve URL mimarisi kuruluyor mu?
• CMS girişini kim yapıyor?
• QA kim tarafından yapılıyor?
• Yeni içeriklerin sonraki dil maliyeti nasıl hesaplanacak?

İşletmeniz için çok dilli yapının teknik kapsamını, sayfa sayısını ve geliştirme modelini belirlemek için Web Sitesi Geliştirme hizmetimizi inceleyebilirsiniz. İçeriklerin farklı pazarlara göre yeniden hazırlanması gerekiyorsa Web İçeriği Üretimi, yayın sonrası güncelleme ve bakım operasyonu için Web Sitesi Yönetimi hizmetlerini değerlendirebilirsiniz.