Headless CMS, içerik katmanını sunum katmanından ayırarak geliştiricilere önemli bir esneklik sağlıyor. Ancak bu ayrışma, çok dilli SEO açısından bazı köklü varsayımları ortadan kaldırıyor. Geleneksel bir CMS'de eklenti ya da yerleşik özellik olarak hazır gelen hreflang yönetimi, URL yapısı kararları ve dil sürümü eşleştirme mekanizmaları, headless yapıda doğrudan frontend uygulamasının sorumluluğuna geçiyor.
WordPress veya Drupal gibi geleneksel platformlarda bir eklenti, dil sürümlerini birbirine bağlayan hreflang etiketlerini otomatik olarak oluşturuyor. Headless mimaride ise bu etiketlerin üretilmesi için içerik modeli, API yanıtları ve frontend render mantığı üçlüsünün uyum içinde çalışması gerekiyor. Bu uyum kurulmadığında Google farklı dil sürümlerini birbirinden bağımsız sayfalar olarak değerlendiriyor — ve büyük ihtimalle yanlış sürümü sıralamaya koyuyor.
Sorun genellikle teknik bilgi eksikliğinden değil, sorumluluğun kimin omzunda olduğunun belirsizliğinden kaynaklanıyor. Frontend geliştirici "SEO bu bizim işimiz değil" diyor, SEO ekibi ise "kod tarafı bizi ilgilendirmez" diye düşünüyor. Headless mimaride bu iki tarafın ortak bir dil kurması, sıradan bir CMS projesine kıyasla çok daha belirleyici.
Headless yapıda içeriğin dil boyutu: CMS'den ayrışan frontend ne üretiyor?
Geleneksel CMS mimarisinde içerik oluşturma, URL üretme ve HTML render etme aynı sistem içinde gerçekleşiyor. Headless mimaride bu adımlar birbirinden koparılıyor: CMS içeriği depoluyor ve bir API aracılığıyla sunuyor; frontend uygulama (Next.js, Nuxt, SvelteKit veya başka bir framework) bu içeriği alıp HTML'e dönüştürüyor. Meta etiketler, canonical URL'ler, hreflang, sayfa başlıkları — bunların tümü frontend katmanında üretiliyor. CMS bunların hiçbirini otomatik olarak sağlamıyor.
Bu ayrışmanın pratik sonucu şu: hangi dil sürümünün hangi URL'de yayınlanacağını, locale kodlarının URL yapısında nasıl görüneceğini ve belirli bir locale için içerik yoksa ne olacağını geliştirici ekibin tasarım aşamasında kararlaştırması gerekiyor. Çoğu headless projede bu kararlar "teknik detay" olarak bırakılıyor; SEO ekibi devreye girdiğinde ise mimari çoktan yerleşmiş oluyor.
Contentful, Sanity ve Storyblok'un locale modellerine bakıldığında önemli bir fark görülüyor. Contentful alan bazlı çeviri kullanıyor: tek bir içerik girişi var, her alan farklı locale için farklı değer taşıyor. Sanity genellikle belge bazlı yaklaşımı tercih ediyor: her dil için ayrı bir belge oluşturuluyor ve bu belgeler birbirine referansla bağlanıyor. Storyblok her iki modeli de destekliyor. Bu mimari tercih, ilerleyen aşamalarda hreflang uygulamasını ve URL yönetimini doğrudan etkiliyor — özellikle belirli bir locale için içerik eksikse ne olacağı sorusu cevaplı olmak zorunda.
URL ve locale routing: SEO kararları kodun içinde nerede gizleniyor?
Next.js i18n routing, locale öneki kullanan bir URL yapısı sunuyor: /tr/, /en/, /de/ gibi. Bu, geleneksel alt dizin yapısına doğrudan karşılık geliyor ve çok dilli URL yapısı seçimi açısından en öngörülebilir seçenek. Ancak framework yapılandırmasında yapılan küçük bir hata zincirleme sorunlara dönüşebiliyor.
Sık karşılaşılan bir senaryo: varsayılan locale (örneğin Türkçe) URL öneki almıyor. Böylece Türkçe sayfalar /urunler/ adresinde, İngilizce sayfalar /en/products/ adresinde yayınlanıyor. Bu teknik olarak çalışsa da iki URL formatının tutarsızlığı hreflang setini karmaşıklaştırıyor. Türkçe canonical URL'in de bu yapıyla uyumlu olması gerekiyor; aksi durumda canonical çatışması kaçınılmaz.
Middleware katmanında locale tespiti ayrı bir risk noktası. Kullanıcı tarayıcısının Accept-Language başlığına bakarak otomatik yönlendirme yapmak Googlebot'u tek bir locale'e kilitleme riskini taşıyor. Googlebot yönlendirmeyi takip edecek mi, etmeyecek mi; etseydi hangi dil sürümünü indeksleyecekti? Headless projelerde bu middleware genellikle geliştirici kolaylığı için ekleniyor, SEO sonuçları düşünülmeden. Kullanıcı tercihini cookie veya oturum üzerinden yönetmek çoğu durumda daha temiz bir çözüm.
Domain bazlı routing — her dil için ayrı alan adı — headless projelerinde teknik olarak uygulanabilir ama içerik API entegrasyonu karmaşıklaşıyor. Her deployment'ın hangi locale'i sunduğunu tutmak, hreflang eşleştirmesinde ek bir koordinasyon katmanı gerektiriyor. Küçük ve orta ölçekli projeler için alt dizin yapısı genellikle daha yönetilebilir.
Hreflang headless mimaride nasıl üretilir?
Hreflang'ın üç uygulama yöntemi var: HTML head meta etiketi, HTTP response header ve XML sitemap. Headless mimaride bu üçünün uygulanabilirliği farklılaşıyor ve doğru yöntemi seçmek hem teknik hem de operasyonel bir karara dönüşüyor.
HTML head yöntemi, SSG ve SSR her ikisinde de çalışıyor. SSG'de build zamanında her sayfa için tüm dil varyantlarını içeren hreflang etiketleri üretiliyor. SSR'de ise her istek sırasında içerik API'sinden dil varyantı listesi çekilerek aynı etiketler dinamik olarak oluşturuluyor. Pratikte en güvenilir yaklaşım bu: her sayfanın meta üretim mantığı, içerik API'sinden o içeriğin tüm locale varyantlarını alıp hreflang olarak yazıyor. Hreflang karşılıklı referans kuralı burada da geçerli — Türkçe sayfa İngilizce varyantına işaret ediyorsa, İngilizce sayfa da Türkçe varyantına işaret etmek zorunda.
HTTP header yöntemi, Vercel veya Netlify gibi statik hosting platformlarında doğal olarak desteklenmiyor. Edge Function ya da Lambda kullanımı gerekiyor; bu gereksiz karmaşıklık yaratıyor ve çoğu headless proje bu yöntemden kaçınıyor. PDF gibi HTML olmayan kaynaklar söz konusu olmadıkça tercih edilmez.
XML sitemap yöntemi, headless projelerde güçlü bir tamamlayıcı. Sitemap genellikle build sürecinde programatik olarak üretiliyor; her URL için tüm dil varyantları xhtml:link elemanlarıyla ekleniyor. Bu yaklaşımın avantajı HTML'e dokunmadan dil sürümü güncellemelerini yönetebilmesi; dezavantajı ise büyük sitelerde sitemap boyutunun şişmesi. Detaylı planlama için çok dilli sitemap oluşturma sürecinin öncelikle netleştirilmesi gerekiyor.
ISR veya SSR'de şu senaryo ortaya çıkabiliyor: bir sayfanın Türkçe versiyonu revalidate olurken İngilizce versiyonu henüz eski içeriği sunuyor. Bu kısa dönem içinde iki varyant farklı hreflang setleri taşıyabiliyor. Statik HTML'e kıyasla daha kısa ömürlü bir tutarsızlık bu, fakat yoğun içerik güncellemelerinde birikimli bir etki yaratabiliyor.
SSG, SSR ve ISR: render tercihinin çok dilli SEO'ya yansıyan farkları
Render stratejisi kararı çoğunlukla performans ve geliştirici deneyimi açısından ele alınıyor. Ama çok dilli siteler için bu kararın doğrudan SEO boyutu var ve dil sayısı arttıkça bu boyut ağırlık kazanıyor.
SSG'de tüm dil sürümleri build zamanında üretiliyor. 5 dil ve 3.000 ürün sayfası varsa 15.000 sayfa build sürecinde oluşturuluyor. Bu başlangıçta yönetilebilir görünüyor; 10 dile çıkıldığında veya katalog büyüdüğünde build süresi 20–30 dakikayı geçebilir. İçerik güncellemelerinin hemen yayına girmesi yerine build sürecini beklemesi, editoryal ekipler için ciddi bir sürtüşme noktası yaratıyor. Ürün açıklaması değiştiğinde tüm dil varyantlarının yeniden build alması gerektiğini hesaba katmak gerekiyor.
SSR her istek için sunucu tarafında render üretiyor. İçerik her zaman güncel, ama sunucu yükü çok dilli yapıda çarpan etkisi yaratıyor. Aynı içerik sekiz farklı dil için sekiz farklı API çağrısı yapıyor olabilir. CDN önbellekleme ile bu yük yönetilebilir; fakat dil bazlı cache anahtarlaması doğru kurulmadığında Türkçe kullanıcıya İngilizce önbelleklenmiş sayfa dönebilir — hem kullanıcı deneyimi hem de indeksleme açısından sorunlu bir durum.
ISR, Next.js'in sunduğu hibrit yaklaşım. Sayfalar statik olarak üretiliyor ama belirli bir süre sonra arka planda yenileniyor. Çok dilli yapıda tutarsızlık penceresi gerçek bir risk: bir ürün sayfasının Türkçe versiyonu revalidate olurken İngilizce versiyonu eski içeriği sunuyor olabilir. Bu dönemde iki varyant arasında canonical bilgisi veya hreflang seti farklılaşabilir. Revalidate süresi 60 saniye gibi kısa bir değer seçilirse bu risk minimize ediliyor; çok uzun süreler ise içerik tazeliği sorununu geri getiriyor.
Seçim kriterleri çoğu zaman içerik hızına bağlı. Haber veya blog siteleri gibi sık güncellenen yapılar için SSR veya kısa revalidate süreli ISR, ürün değişiminin yavaş olduğu kataloglar için SSG daha uygun. Dil sayısı karar ağırlığını değiştiriyor: 3 dilde SSG sorunsuz çalışırken, 12 dilde aynı mimari operasyonel yük yaratabilir.
İçerik modeli tercihi SEO'yu neden etkiliyor?
Alan bazlı çeviri modeli — Contentful'un varsayılan yaklaşımı — tek bir içerik girişinde tüm locale değerlerini tutuyor. Bu modelin SEO açısından kritik bir kırılganlığı var: bir locale için belirli bir alan boşsa sistem varsayılan dile fallback yapabiliyor. Türkçe ürün sayfasının meta description alanı doldurulmamışsa, sayfa Türkçe URL'de yayına girebiliyor ama meta description İngilizce içerik taşıyabiliyor. Bu durum teknik SEO denetiminde sıklıkla karşılaşılan bir sessiz hata.
Belge bazlı çeviri modeli ise her dil için bağımsız bir içerik belgesi oluşturuyor. SEO açısından daha öngörülebilir: belge ya var ya yok, ara durum daha az. Ancak iki belge arasındaki ilişki — hreflang eşleştirmesi için zorunlu olan bu bağ — manuel olarak tanımlanmak zorunda. Sanity gibi sistemlerde bu ilişki genellikle bir referans alanıyla kuruluyor. Frontend uygulamanın bu referansı doğru okuyup hreflang setini tutarlı şekilde üretmesi gerekiyor.
Kısmi çeviriler her iki modelde de zor bir senaryo yaratıyor. Katalogunuzdaki ürünlerin yalnızca %60'ı Almanca çevrilmişse, Almanca versiyonu olmayan %40 için ne yapılacağı açıkça belirlenmeli. Seçenekler üçe indirgenebilir: 404 döndürmek, varsayılan dile yönlendirmek veya sayfayı noindex etiketiyle yayına almak. 404 genellikle en temiz çözüm — var olmayan bir sayfanın var olmayan dildeki versiyonunu bu şekilde işaretlemek Google'a net bir sinyal veriyor. Varsayılan dile yönlendirme ise dikkatli kurulmadığında aynı içeriğin birden fazla locale URL'sinde görünmesine yol açıyor. Çok dilli yapı kararları arasında kısmi çevirinin nasıl yönetileceği, mimari seçimden önce netleştirilmesi gereken bir konu.
Bir de içerik tipleri arası tutarsızlık var. Blog yazıları ve ürün sayfaları için farklı locale kapsamı tanımlamak mümkün — ve çoğu projede kaçınılmaz. Ürünlerin 10 dilde, blog yazılarının 3 dilde yayınlandığı bir yapıda her içerik tipi için ayrı fallback mantığı gerekiyor. Bu ayrım CMS içerik modelinde baştan planlanmadıkça sonradan eklenmesi maliyetli.
Bu kararların büyük çoğunluğunun frontend mimarisi seçilirken ve içerik modeli tasarlanırken yapılması gerekiyor. SEO ekibinin bu aşamada teknik ekiple aynı masada olması, sonradan "neden indexlenmedi" sorusunu sormaktan çok daha verimli. Headless geçişi planlarken mevcut dil sürümlerinin URL yapısının korunup korunmayacağı, hreflang etiketlerinin nasıl taşınacağı ve sitemapların nasıl yeniden üretileceği — bunlar teknik olmakla birlikte SEO çıktılarını doğrudan belirliyor. Geçiş süreci kendi başına bir planlama alanı; doğrudan 301 eşleştirme ve hreflang seti geçişini birlikte yönetmek gerekiyor.
Headless CMS'in sunduğu esneklik, dikkatli kurulmadığında çok dilli SEO için güçlü bir kırılma noktasına dönüşebilir. Fakat aynı esneklik, geleneksel CMS'lerde güç olan şeyleri — locale bazlı routing, edge caching, dinamik sitemap üretimi, kısmi revalidation — olması gereken biçimde inşa etmeyi de mümkün kılıyor. Fark, bu kararların kimin sorumluluğunda olduğunun baştan netleştirilip netleştirilmediğinde yatıyor. SEO ve frontend mimarisi arasındaki sınırın bilinçli çizildiği projelerde headless yapı gerçek bir avantaja dönüşüyor; sınır belirsiz kaldığında ise her iki taraf da karşı tarafın halledeceğini varsayıyor.