Nuxt, Vue ekosisteminin en olgun SSR/SSG framework'ü olarak çok dilli projeler için güçlü bir zemin sunuyor. @nuxtjs/i18n modülü bu zeminin üstüne oturuyor: locale yönetimi, URL yapısı, hreflang üretimi ve dil geçişleri için kapsamlı bir API sağlıyor. Bu entegrasyon Next.js'e kıyasla daha az manuel kurulum gerektiriyor; ancak "modül her şeyi hallediyor" yanılgısı, zaman içinde SEO sorunlarına zemin hazırlıyor.
Nuxt i18n modülünün temel avantajı, framework ile derin entegrasyonu. Hreflang etiketleri otomatik üretiliyor, locale URL'leri route sistemiyle birlikte yönetiliyor, dil değiştirme bileşeni kolayca ekleniyor. Dezavantajı ise bu otomasyonun varsayılan davranışlarının her projeye uymayabileceği: varsayılan locale'nin URL'de nasıl göründüğü, kısmi çevirilerin nasıl ele alındığı ve SEO'ya kritik bazı yapılandırmaların varsayılan değerleri, geliştirici beklentisiyle örtüşmeyebilir.
Nuxt ile çok dilli SEO kurulumu, Next.js'teki gibi sıfırdan yazılması gereken bir altyapıyı değil, doğru yapılandırılması gereken bir modülü kapsıyor. Bu fark her ikisini de cazip kılıyor — ama hataların kaynağını da farklılaştırıyor. Yapılandırma hataları genellikle sessizdir: sayfa yükleniyor, içerik görünüyor, ama hreflang seti yanlış URL'lere işaret ediyor ya da belirli locale'lerin meta etiketleri boş üretiliyor. Bunu fark etmek için Google Search Console'u veya kaynak kodu incelemek gerekir; sayfa yüzeyden sorunsuz göründüğünden hata uzun süre gözden kaçabilir.
@nuxtjs/i18n modülünün yapısı: hangi sorunları çözüyor, hangilerini devrediyor?
@nuxtjs/i18n modülü nuxt.config.ts içinde tanımlanıyor. Temel yapılandırma locale listesi, varsayılan locale, strateji seçimi ve mesaj dosyalarının konumundan oluşuyor. Strateji seçimi SEO açısından en kritik karar: prefix, prefix_except_default, prefix_and_default veya no_prefix seçenekleri URL yapısını doğrudan belirliyor.
prefix_except_default en yaygın kullanılan strateji. Varsayılan locale URL öneki almıyor: /urunler/ Türkçeye, /en/products/ İngilizceye karşılık geliyor. Bu yaklaşım temiz URL'ler üretiyor ama hreflang setinde dikkate alınması gereken bir asimetri yaratıyor: tr locale'inin URL'si /urunler/ iken x-default olarak işaret edilecek URL de aynı. İki işlev tek URL'de birleşiyor; bu sorunlu değil ama bilinçli olarak yönetilmesi gerekiyor. prefix stratejisi tüm locale'lere öneki zorunlu kılıyor; hreflang seti daha tutarlı ama varsayılan locale için ek bir yönlendirme katmanı planlanmalı. no_prefix stratejisi ise dil seçici ve yönlendirme hataları açısından en riskli seçenek — aynı URL farklı içerik sunuyor ve Googlebot hangi dil versiyonunu indekslediğini bilemez hale geliyor.
Locale listesi tanımlanırken iso alanı BCP 47 formatında olmalıdır: tr-TR, en-US, de-DE gibi. Bu değer yanlış girildiğinde modül hreflang etiketlerini sessizce hatalı üretiyor; örneğin de yerine de-DE kullanılması gereken yapıda Google bölge bazlı hedeflemeyi atlayarak yalnızca dil eşleştirmesi yapabilir. detectBrowserLanguage özelliği dikkatli kullanılmalıdır: Accept-Language başlığını okuyarak otomatik yönlendirme yapan bu özellik, Googlebot'un tüm locale versiyonlarına erişimini engeller. Özelliği tamamen kapatmak ya da yalnızca cookie tabanlı çalışacak biçimde kısıtlamak, crawl tutarlılığı açısından en güvenilir yaklaşımdır.
Uluslararası anahtar kelime araştırması sırasında hangi locale'lerin öncelikli hedef olduğu belirlendikten sonra locale listesi kararlı tutulmalı. Sonradan eklenen locale'ler mevcut hreflang setlerini bozacağından, her yeni dil eklemesi teknik taşıma planı gerektiriyor. Bu planlamanın içerik üretim takviminden önce yapılması, yayın sürecinde hreflang tutarsızlıklarının önüne geçiyor.
Hreflang otomasyonu: modül ne üretiyor, ne üretmiyor?
Nuxt i18n modülü, useHead veya useSeoMeta entegrasyonu aracılığıyla hreflang etiketlerini otomatik olarak üretiyor. Tek satır konfigürasyonla tüm locale'ler için hreflang etiketi oluşturuluyor. Ancak bu otomasyonun sınırlarını anlamak, üretim hatalarını önceden gidermek için şart.
Modülün varsayılan davranışı, konfigürasyonda tanımlanan tüm locale'ler için hreflang etiketi üretiyor. Bu davranış kısmi çeviriler söz konusu olduğunda sorun yaratıyor: bir ürün sayfasının Almanca versiyonu henüz çevrilmemişse bile modül Almanca için hreflang etiketi üretiyor ve var olmayan URL'ye işaret ediyor. Google bu URL'yi taradığında 404 bulursa o hreflang seti güvenilirliğini yitiriyor. Bunu önlemek için her sayfada mevcut locale'leri dinamik olarak belirleyip modülün üretimini bu veriye göre kısıtlamak gerekiyor.
Hreflang karşılıklı referans kuralı burada da geçerli. Modül genellikle her sayfanın kendi locale setini doğru üretiyor ama özel sayfa tipleri — özel route'lar, dinamik parametreli sayfalar, API güdümlü içerikler — modülün standart akışının dışına çıkabiliyor. Bu durumlarda hreflang etiketlerini manuel olarak oluşturmak ve modülün otomatik üretimiyle çakışmayacak biçimde yerleştirmek gerekiyor.
x-default değeri modülün güncel versiyonlarında destekleniyor ama yapılandırma gerektiriyor. x-default'un ne zaman gerekli olduğu ve hangi URL'ye işaret etmesi gerektiği, strateji seçimiyle doğrudan ilişkili. prefix_except_default kullanıldığında varsayılan locale URL'si x-default için doğal aday; prefix stratejisinde ise ayrı bir yönlendirme URL'si tanımlamak gerekiyor.
Dinamik içerikli sayfalarda hreflang setinin bütünlüğünü korumanın en güvenilir yolu, her slug için ilgili locale eşleşmelerini CMS tarafında açıkça saklamak. Örneğin bir blog yazısının Türkçe, İngilizce ve Almanca sürümleri ayrı slug değerleri taşıyorsa, bu üç slug arasındaki eşleşme ilişkisinin doğrudan içerik verisinde tutulması hreflang üretimini öngörülebilir kılıyor. Bu yapı kurulmadığında modül locale geçişlerinde yanlış URL'lere işaret ediyor; hreflang hata tespiti sırasında bu tutarsızlıklar ancak manuel kontrol ile fark ediliyor.
SSR, SSG ve Nuxt Content: render modunun çok dilli SEO'ya etkisi
Nuxt üç temel render modunu destekliyor: SSR (sunucu tarafı render), SSG (statik site üretimi) ve hibrit mod. Her modun çok dilli yapıda farklı SEO yansımaları var ve doğru tercih projenin içerik güncelleme sıklığına, sayfa sayısına ve tarama bütçesi önceliklerine göre şekilleniyor.
SSG'de tüm dil ve sayfa kombinasyonları build zamanında üretiliyor. nuxt generate komutu ile statik HTML dosyaları oluşturuluyor; bu dosyalar CDN'den sunulduğunda hem hız hem de crawl kolaylığı açısından avantaj sağlıyor. Dezavantajı, locale sayısı ve sayfa hacmi çarpıldığında build süresinin uzaması. Beş dil ve 10.000 sayfa için 50.000 statik dosya üretiliyor; büyük projelerde bu onlarca dakikaya varan build süreleri anlamına gelebiliyor. SSR'de her istek için sunucu tarafında render gerçekleşiyor; içerik her zaman güncel ama CDN önbellekleme yapılandırması kritik: locale bazlı cache anahtarlaması doğru kurulmadığında Fransızca içerik talep eden kullanıcıya Türkçe önbelleklenmiş sayfa dönebiliyor.
Nuxt 3'ün hibrit modunda routeRules ile sayfa bazında SSG, SSR veya ISR seçilebilir. Bu esneklik çok dilli yapıda içerik türüne göre farklı önbellekleme stratejileri uygulanmasına olanak tanır: sık güncellenmeyen bilgi sayfaları SSG ile sunulurken aktif katalog sayfaları ISR ile yönetilebilir. Uluslararası sitemap yapısı bu kararla doğrudan ilişkilidir; SSG sayfaları anında listelenebilirken ISR sayfaları için yenileme aralıklarının sitemap güncelleme sıklığıyla hizalanması indekslenmiş içeriğin güncelliğini korur.
Nuxt Content modülüyle çalışıldığında çok dilli yapı için dil bazlı dizin yapısı kullanılıyor: /content/tr/, /content/en/ gibi. Bu yapı SEO açısından temiz ama locale varlığının programatik olarak kontrol edilmesi hreflang üretimini doğrudan etkiliyor. Nuxt Content query API'si bu kontrolü destekliyor; ama hreflang mantığını bu API'ye bağlamak ekstra kod gerektiriyor. Harici headless CMS entegrasyonunda ise içerik runtime'da çekildiğinden ISR veya SSR zorunlu hale gelir; bu durum locale bazlı önbellekleme planlamasının her yeni dil eklendiğinde yeniden gözden geçirilmesini gerektirir.
Canonical URL yönetimi ve URL yapısı tutarlılığı
Nuxt i18n modülü canonical URL'leri otomatik olarak üretmiyor; bu hreflang'ın aksine, her sayfada manuel olarak yönetilmesi gereken bir alan. useHead veya useSeoMeta ile canonical etiketi sayfanın tam URL'sine göre dinamik olarak belirlenmeli. Bunu merkezi bir composable içinde tanımlamak — tüm sayfalarda çağrılan tek bir useCanonical fonksiyonu — canonical yönetimini tutarlı ve bakımı kolay bir yapıya taşır.
prefix_except_default stratejisinde canonical URL'lerin tutarsızlığı yaygın bir hata modu. Türkçe sayfa /urunler/ adresinde yayınlanıyor, canonical da bu URL'ye işaret ediyor. Ancak middleware veya uygulama kodunda bir yerde /tr/urunler/ URL'si de üretiliyorsa ve 301 ile /urunler/'a yönlendirilmiyorsa, iki URL aynı içeriği sunuyor demek. Çok dilli canonical yönetimindeki bu asimetri, baştan önleyen bir URL mimarisi kurmayı gerektiriyor.
Route alias kullanımı da dikkat gerektiriyor. Nuxt'ta belirli URL'ler alias olarak tanımlanabiliyor; bu özellikle eski URL'lerden yeni yapıya geçişte kullanılıyor. Bir sayfanın birden fazla URL'si varsa ve bunlar canonical ile hreflang setinde tutarlı biçimde tanımlanmamışsa Google farklı URL'leri farklı sayfalar olarak değerlendiriyor. Alias URL'lerin tümü ya 301 ile canonical URL'ye yönlendirilmeli ya da noindex etiketi taşımalı. Migration senaryolarında bu iki katmanı paralel tutmak, canonical'a tek başına güvenmekten daha sağlam bir yaklaşımdır.
Dil dosyaları ve lazy loading: SEO ile performans arasındaki denge
Nuxt i18n modülü çeviri mesajlarını iki şekilde yükleyebiliyor: tüm dilleri başlangıçta yüklemek veya lazy mod ile sadece aktif locale'i yüklemek. SEO açısından bu seçim SSR/SSG render sürecini etkiliyor ve proje ölçeğine bağlı olarak farklı optimizasyon noktaları yaratıyor.
Lazy loading SSG'de sorun çıkarmıyor — her sayfa build sırasında ilgili locale'in mesajlarıyla üretiliyor. SSR'de ise her istek için yalnızca talep edilen locale'in mesajları yükleniyor; bu sunucu belleği üzerindeki yükü azaltıyor. Ancak CDN katmanında locale bazlı cache anahtarlaması kurulmadığında lazy loading avantajı kaybolabiliyor: sunucu doğru locale mesajını yükliyor ama CDN yanlış locale içeriğini önbelleğe alabiliyor.
Çeviri dosyalarındaki eksik anahtarlar — belirli bir locale için bir mesajın tanımlanmamış olması — SSR'de runtime hatalarına ya da boş içeriğe yol açabiliyor. Bu sessiz bir hata türü: sayfa görünüşte yükleniyor ama belirli bir metin bloğu boş geliyor. Google bu içeriği taradığında boş alan görüyor. Teknik SEO denetiminde çeviri dosyalarının eksiksizliğini kontrol etmek, özellikle yeni locale eklendiğinde ihmal edilen adımlardan biri. CI sürecine locale key karşılaştırması eklemek bu sorunu otomatize eder: her deployment öncesi tüm locale dosyalarının aynı anahtarları içerip içermediği programatik olarak doğrulanabilir.
Çeviri dosyalarının içerik kalitesi meta etiket kalitesini doğrudan belirler. Title ve description değerleri makine çevirisinden kopyalanmışsa, her dil için salt dönüştürülmüş metinler arama sonuçlarına yansır. Yerelleştirme ile çeviri arasındaki fark meta etiketlerde özellikle belirginleşir; hedef pazarın arama davranışına göre yeniden kurulmuş başlıklar ile kelimesi kelimesine çevrilmiş başlıklar arasındaki tıklama oranı farkı ciddi olabilir. Çeviri dosyası yapısında meta title ve description için ayrı anahtarlar tanımlanmış ve sayfa içi içerikten bağımsız biçimde yönetilebiliyorsa, yerelleştirme sürecini içerik ekibine devretmek teknik bağımlılığı azaltır.
Canlıya geçiş öncesi test ve doğrulama süreci
Nuxt i18n kurulumunu tamamladıktan sonra canlıya geçmeden önce birkaç doğrulama adımı beklenmedik indeksleme sorunlarını önler. İlk kontrol noktası hreflang setinin kaynak kodda gerçekte ne ürettiği. Her locale için bir sayfa açıp view-source ile head içeriğini incelemek, modülün beklenen URL'leri mi yoksa farklı bir yapı mı ürettiğini ortaya koyar. Özellikle dinamik rotalar ve [slug] yapısına sahip sayfalar bu kontrolde öncelik taşır.
Canonical URL'lerin her sayfada doğru ayarlandığı da aynı adımda kontrol edilebilir. Dil değiştirme bileşeni üzerinden locale geçişi yapıldığında canonical etiketinin güncellenip güncellenmediği — Vue'nun reaktif meta yönetiminde zaman zaman görülen gecikmeli güncelleme sorununu tespit etmek için — kısa bir oturum simülasyonuyla anlaşılır. Hreflang test yöntemleri bu denetimin URL set bütünlüğü açısından nasıl yürütüleceğini adım adım ele alır.
Google Search Console'da yeni locale URL'leri canlıya geçtikten sonra URL İnceleme aracıyla birkaç örnek sayfa işlenmelidir. Bu adım modülün ürettiği hreflang'ın Google tarafından nasıl okunduğunu ve hangi locale'lerin tanındığını gösterir. Uluslararası hedefleme raporundaki uyarılar, kurulumun ilk günlerinde hreflang setinin tutarlı çalışıp çalışmadığını doğrulamak için değerli bir sinyal sunar.
Tarama bütçesi de kontrol edilmesi gereken bir alan. Nuxt uygulamalarında otomatik üretilen route'lar locale kombinasyonlarıyla çarpıldığında beklenmedik URL sayısı üretebilir. robots.txt ve sitemap doğrulaması yapıldığında taranmasını istemediğiniz URL'lerin açıkça dışlandığından, taranmasını istediğiniz locale sayfalarının ise sitemap'te eksiksiz listelendiğinden emin olmak gerekir. Bu adım ölçek büyüdükçe giderek daha belirleyici hale gelir.
Nuxt i18n modülü, çok dilli SEO kurulumunda geliştirici deneyimini önemli ölçüde iyileştiriyor. Hreflang üretimi, locale routing ve dil geçişleri gibi tekrarlayan görevler otomatikleşiyor. Bu otomasyonun sağladığı hızın yanı sıra, kısmi çeviri yönetimi, canonical URL tutarlılığı ve CDN önbellekleme yapılandırması gibi alanlar elle müdahale gerektirmeye devam ediyor. Modülün hangi kararları aldığı, hangilerini geliştirici sorumluluğuna bıraktığı net biçimde anlaşıldığında kurulum hem daha hızlı hem de daha az hata üretiyor.
Next.js ile kıyaslandığında Nuxt'un i18n entegrasyonu daha kapsayıcı ama daha az şeffaf. Next.js'de her SEO kararı açıkça kod yazılarak alınıyor; Nuxt'ta modül bu kararların büyük kısmını konfigürasyon üzerinden yönetiyor. Bu, hataların debug edilmesini bazen güçleştiriyor: konfigürasyonun bir satırındaki bir karar, sayfanın ürettiği hreflang setini sessizce yanlışlaştırabiliyor. Proje büyüdükçe — daha fazla locale, daha karmaşık rota yapısı, harici CMS entegrasyonu — bu sessiz hata riskini azaltmanın en güvenilir yolu, her locale kombinasyonunun gerçekte ne ürettiğini periyodik olarak doğrulamak ve konfigürasyon değişikliklerini küçük, izole adımlarla uygulamaktır.