Hreflang etiketleri doğru, canonical yapısı temiz, her dil versiyonu kendi URL'sinde duruyor. Buna karşılık Google Search Console'da bir dil versiyonu haftalarca indekslenmiyor, ya da arama sonucunda kullanıcının bulunduğu ülkeye yanlış dil sürümü çıkıyor. Teknik denetim listesinin tamamı yeşil göründüğünde bu tablo kafa karıştırıyor, çünkü sorun etiketlerde değil, o etiketlerin Googlebot'a ne zaman ve nasıl ulaştığında.
Bir sayfanın HTML kaynağında yazılı olan ile tarayıcıda (veya Googlebot'un render motorunda) gerçekten oluşan içerik farklı iki katmandır. hreflang, canonical ve lang attribute'u JavaScript tarafından enjekte ediliyorsa, bu katmanlar arasındaki gecikme çok dilli bir site için çok daha ağır bir bedele dönüşür: tek dilli bir sitede bir sayfa gecikirken, çok dilli bir sitede o gecikme dil sayısı kadar çarpılır.
Aşağıda bu gecikmenin kaynağı, CSR, SSR ve SSG mimarilerinin bu sinyalleri nasıl farklı şekilde taşıdığı ve hangi mimarinin hangi site profiline uyduğu ele alınıyor.
Googlebot çok dilli bir sayfayı render kuyruğuna aldığında ne olur?
Googlebot bir URL'yi ziyaret ettiğinde iki aşamalı bir işlem çalışır. İlk aşamada ham HTML taranır ve linkler, temel meta veri, statik olarak yazılmış her şey bu anda okunur. İkinci aşamada sayfa bir render kuyruğuna girer; burada Chromium tabanlı bir motor JavaScript'i çalıştırır ve sayfanın son haline ulaşır. Bu iki aşama arasındaki süre saniyeler değil, sitenin crawl bütçesine ve sunucu yanıt hızına göre saatlerden günlere kadar uzayabilir.
Tek dilli bir sitede bu gecikme tek bir URL için geçerlidir. Çok dilli bir sitede aynı içerik /tr/, /en/, /de/ gibi ayrı URL'lerde durur ve her biri render kuyruğuna kendi başına girer. Google bu URL'leri aynı öncelikle işlemez; genellikle kaynak dil (ya da en çok bağlantı alan sürüm) daha hızlı render edilir, diğer dil sürümleri kuyrukta daha geride kalır.
Bu davranışı somut olarak görmek isterseniz Googlebot'un gerçek ziyaret sıklığını ve render arasındaki farkı log analizi ile Googlebot davranışını inceleyen rehberde anlatılan yöntemle sunucu loglarından çıkarabilirsiniz. Log kayıtları, hangi dil versiyonunun ilk taramadan render aşamasına kaç gün içinde geçtiğini gösterir ve bu veri, mimari kararın gerçek dünya kanıtı haline gelir.
Render kuyruğunun uzunluğu sabit değildir; Google'ın o site için ayırdığı crawl bütçesine, sunucunun yanıt hızına ve kuyrukta o anda bekleyen toplam URL sayısına göre değişir. Crawl bütçesi düşük bir sitede, örneğin yeni açılmış veya otorite skoru henüz oluşmamış bir çok dilli projede, ilk tarama ile render arasındaki mesafe birkaç günden birkaç haftaya kadar uzayabilir. Bu bekleme süresinde dil sürümleri arasında da bir sıralama oluşur: iç linklerle en çok desteklenen, sitemap'te en üstte yer alan veya en hızlı yanıt veren sunucu bölgesine bağlı dil sürümü kuyrukta öne geçer.
Crawl (tarama) ile render (işleme) aynı olay değildir, ve indeksleme kararı genellikle render tamamlandıktan sonra verilir. Bir dil sürümü taranmış ama henüz render edilmemişse, Search Console'da "Discovered - currently not indexed" ile "Crawled - currently not indexed" arasında bir geçiş görülür; bu iki durumun hangisinde kaldığı, sorunun tarama önceliğinde mi yoksa render kapasitesinde mi olduğunu ayırt etmenin ilk ipucudur.
CSR (İstemci Taraflı Render) hangi çok dilli sinyalleri geciktiriyor?
CSR mimarisinde tarayıcıya (ve Googlebot'un ilk taramasına) gönderilen HTML genellikle boş bir kabuktur; gerçek içerik, dil metinleri, hreflang etiketleri ve lang attribute'u tamamen JavaScript çalıştıktan sonra DOM'a eklenir. İlk tarama aşamasında bu sinyaller mevcut değildir, render kuyruğuna girene kadar Google onların varlığından habersizdir.
Bu durum üç ayrı riski birden büyütür. Birincisi, hreflang etiketleri render öncesinde görünmediği için Google alternate URL ilişkisini kurmadan önce sayfayı tek dilli bir sayfa gibi değerlendirebilir. İkincisi, dil seçici bileşeni genellikle JavaScript ile çalıştığından, render tamamlanmadan önce Googlebot hangi dil sürümlerinin var olduğunu bilemez. Üçüncüsü, çeviri metinleri bir API çağrısıyla asenkron yükleniyorsa, render motoru zaman aşımına uğradığında sayfa içeriksiz kalabilir.
Bu üç risk özellikle ürün kataloğu büyük, dil sayısı yüksek sitelerde birikir. Yüzlerce ürün sayfasının her biri kendi dil sürümüyle render kuyruğuna girdiğinde, kuyruk uzar ve toplam indeksleme süresi haftalar sürebilir. Headless mimarilerde bu sorunun nasıl yönetildiğini headless CMS ile çok dilli SEO yönetimini ele alan yazıda daha ayrıntılı bulabilirsiniz; oradaki ayrım, içerik API'sinin build zamanında mı yoksa istek anında mı çağrıldığına dayanıyor.
CSR'nin en sinsi belirtisi, sorunun tek bir dilde değil birden fazla dilde aynı anda ama farklı yoğunlukta ortaya çıkmasıdır. Örneğin ana dil sürümü zaten yüksek trafik ve çok sayıda geri bağlantı aldığından Google onu daha sık ziyaret eder, render kuyruğunda öne alır; ikincil diller ise aynı JavaScript yükünü taşımasına rağmen daha az öncelik görür. Böylece aynı CSR mimarisi, ana dilde görünür bir sorun yaratmazken ikincil dillerde ciddi bir indeksleme açığı bırakabilir. Bu asimetri, sorunu ilk fark eden kişinin genellikle "sitede bir teknik problem yok, sadece bir dil geride" diye yanlış bir teşhis koymasına neden olur; oysa kök neden tüm dillerde aynıdır, sadece etkisi trafiğe göre farklı hızda görünür hale gelir.
SSR render süresini kısaltıyor, ama hangi çok dilli riskler kalıyor?
SSR (Sunucu Taraflı Render) mimarisinde HTML, kullanıcıya (ve Googlebot'a) gönderilmeden önce sunucuda üretilir. hreflang, canonical ve dil metinleri ilk yanıtın içinde hazır bulunur; bu, CSR'ye kıyasla render kuyruğu bağımlılığını büyük ölçüde azaltır. Google artık ilk taramada zaten tam HTML'i görür.
Ancak SSR çok dilli sinyalleri otomatik olarak doğru üretmez, sadece doğru üretilenleri erken teslim eder. Locale tespiti sunucu tarafında Accept-Language başlığına veya URL öntakısına göre yapılıyorsa, bu tespitin her istek için doğru çalışıp çalışmadığı ayrı bir denetim gerektirir; yanlış locale eşlemesi, tüm dil sürümlerinde aynı hreflang hatasının tekrarlanmasına yol açar.
İkinci risk hydration aşamasında ortaya çıkar. Sunucu tam HTML'i gönderdikten sonra tarayıcı JavaScript'i yükler ve React veya Vue gibi çerçeveler DOM'u "hydrate" eder; bu geçiş anında bazı meta etiketleri kısa süreliğine kaybolabilir veya çift render nedeniyle yanlış dil değerine geçebilir. Next.js gibi çerçevelerde bu geçişin nasıl yönetildiğine Next.js i18n SEO rehberinde değinilmiş; Nuxt tarafında benzer bir hydration mantığı Nuxt ile çok dilli SEO kurulumunu anlatan yazıda ele alınıyor. İki çerçevede de ilke aynıdır: sunucudan gelen ilk HTML ile hydration sonrası DOM'un aynı dil sinyalini taşıması gerekir.
Üçüncü bir risk, önbellekleme katmanında ortaya çıkar. SSR mimarilerinde performans için sunucu tarafında (ya da bir CDN'de) sayfa çıktısı önbelleğe alınır; bu önbellek anahtarı locale'i doğru ayırt etmiyorsa, bir kullanıcının aldığı Türkçe render başka bir kullanıcıya İngilizce istekte de dönebilir. Bu tür bir önbellek karışması genellikle trafik arttığında, yani en kritik anda fark edilir, çünkü düşük trafikte önbellek isabet oranı düşük kaldığından sorun gizli kalır. Önbellek anahtarına Accept-Language başlığını veya URL öntakısını dahil etmek, bu riski büyük ölçüde ortadan kaldırır.
SSG ile üretilen statik HTML çok dilli SEO'da neyi garantiliyor, neyi garanti etmiyor?
SSG (Statik Site Üretimi) mimarisinde her dil sürümü build aşamasında tam bir HTML dosyası olarak üretilir. Googlebot bu dosyayı ilk taramada okuduğunda hreflang, canonical, lang attribute'u ve tüm çeviri metni zaten yerindedir; render kuyruğuna bağımlılık pratikte sıfırlanır, çünkü render edilecek bir şey kalmamıştır.
Bu güvence içeriğin build anındaki durumunu kapsar, sonradan yapılan değişikliği kapsamaz. Bir çeviri metni build sonrasında bir yönetim panelinden veya bir üçüncü taraf çeviri widget'ından JavaScript ile güncelleniyorsa, bu güncelleme statik HTML'in avantajını devre dışı bırakır ve site CSR'nin taşıdığı riski küçük ölçekte yeniden üretir. Bu yüzden "SSG kullanıyoruz" ifadesi tek başına yeterli garanti değildir; asıl soru, dil içeriğinin build zamanında mı yoksa çalışma zamanında mı belirlendiğidir.
SSG'nin ikinci sınırı build süresidir. Dil sayısı ve sayfa sayısı arttığında build süresi de uzar; her yeni dil eklendiğinde toplam sayfa sayısı çarpımsal büyür ve dağıtım hattı buna göre ölçeklenmelidir. Bu, mimari seçiminde teknik bir kısıt olarak trafiğin ve dil sayısının birlikte değerlendirilmesi gerektiğini gösterir.
Bazı SSG çerçeveleri bu sınırı "artımlı statik yeniden üretim" (incremental static regeneration) gibi bir mekanizmayla yumuşatır: tüm sayfalar her build'de yeniden üretilmez, sadece değişen içerik güncellenir ve talep anında yeniden oluşturulur. Bu yaklaşım build süresini kısaltırken, ilk isteği alan kullanıcıya (veya Googlebot'a) eski bir statik sürüm sunulup arka planda güncelleme yapılmasına izin verir. Çok dilli bir site için bu, taze içeriğin her dilde eşit hızda yayılmadığı anlamına gelir; bir dil sürümü güncellenirken diğeri henüz tetiklenmemiş eski haliyle kalabilir. Bu gecikme render kuyruğu gecikmesinden farklıdır, ama sonuç aynıdır: dil sürümleri arasında içerik tazeliği tutarsızlığı.
Render gecikmesinin somut belirtileri: GSC'de ve canlı testte ne görünür?
Render kaynaklı bir gecikmeyi tahminle değil, üç ayrı kontrol noktasıyla doğrulayabilirsiniz. Birincisi Search Console'un Kapsam raporunda "Crawled - currently not indexed" durumudur; bu durum bir dil sürümünde yoğunlaşıyor ve diğer dillerde görünmüyorsa, sorun içerik kalitesinden değil o dilin render sırasından kaynaklanıyor olabilir.
İkincisi URL Denetimi aracındaki "Taranan sayfa" görünümüdür. Buradaki "Sayfa kaynağını görüntüle" çıktısı ile "Render edilmiş HTML" çıktısı karşılaştırıldığında, hreflang etiketinin veya çeviri metninin yalnızca render edilmiş sürümde bulunduğu görülürse, bu doğrudan CSR bağımlılığının kanıtıdır. Aynı karşılaştırmayı hreflang etiketlerinin sayfada gerçekten oluşup oluşmadığını doğrulamak için hreflang var ama Google doğru sayfayı göstermiyor başlıklı debug yazısında anlatılan adımlarla da tekrarlayabilirsiniz.
Üçüncüsü tarayıcı tarafında JavaScript devre dışı bırakılarak yapılan basit bir testtir. Tarayıcı geliştirici araçlarında JavaScript kapatılıp sayfa yeniden yüklendiğinde dil metni, dil seçici ve hreflang bağlantıları hâlâ görünüyorsa, sayfa render bağımlılığından büyük ölçüde arınmıştır. Görünmüyorsa, o sayfanın çok dilli sinyalleri tamamen render aşamasına bağlıdır ve gecikme riski yüksektir.
Dördüncü bir doğrulama noktası, Search Console'daki Sayfalar raporunun dil bazında filtrelenmesidir. Bir dizin yapısı (/tr/, /en/, /de/) kullanıyorsanız, her dizini ayrı ayrı filtreleyip indekslenen sayfa oranını karşılaştırabilirsiniz. Bir dilde indeksleme oranı diğerlerinden belirgin şekilde düşükse ve o dilin sayfa sayısı, iç link yapısı ve içerik kalitesi diğerleriyle aynıysa, geriye kalan açıklama render önceliğidir. Bu karşılaştırma, sorunun tek bir sayfaya özgü olmadığını, sistematik bir mimari zayıflığa işaret ettiğini kanıtlar.
Hangi mimari seçilmeli: dil sayısı, güncelleme sıklığı ve trafiğe göre karar çerçevesi
Üç mimari arasında evrensel bir kazanan yoktur; karar üç değişkenin kesişiminde şekillenir. Dil sayısı azsa ve içerik nadiren değişiyorsa (örneğin kurumsal bir tanıtım sitesi), SSG'nin build süresi maliyeti düşük kalır ve render bağımlılığı ortadan kalkar; bu profil için SSG açık tercih olur.
Dil sayısı yüksek, içerik sık güncelleniyor ve kullanıcı bazlı kişiselleştirme gerekiyorsa (örneğin fiyat veya stok bilgisi gösteren bir e-ticaret sitesi), tam statik üretim pratik olmaktan çıkar. Bu durumda SSR, çok dilli sinyalleri her istekte taze üreterek render kuyruğu bağımlılığını azaltan orta yol haline gelir; sunucu maliyeti artar, ama indeksleme öngörülebilirliği geri kazanılır.
CSR'nin tek başına çok dilli bir genel site için önerilebilir bir seçim olduğu senaryo azdır; genellikle bir dashboard veya oturum açmış kullanıcıya özel bir panel gibi, indekslenmesi gerekmeyen alanlarda mantıklıdır. Herkese açık, dil bazlı organik trafik beklenen sayfalarda CSR tercih edilecekse, en azından kritik meta veri ve ilk ekran içeriğinin sunucu tarafında ön render edilmesi (hibrit bir yaklaşım) gecikmeyi ölçülebilir şekilde azaltır.
Bu üç senaryonun hiçbiri mevcut teknoloji yığınından bağımsız seçilmez. Bir ekip zaten bir framework, bir CMS ve bir dağıtım hattı üzerinde çalışıyorsa, mimari değişikliğinin maliyeti render gecikmesinin maliyetiyle karşılaştırılmalıdır. Bazı durumda çözüm mimariyi değiştirmek değil, mevcut CSR yapısına sunucu taraflı bir ön render katmanı eklemektir; bazı durumda ise büyüyen bir çok dilli katalog için SSG'den SSR'ye geçiş kaçınılmaz hale gelir.
Render mimarisi kararı bir kez verilip unutulacak bir ayar değildir. Dil sayısı arttıkça, trafik büyüdükçe veya içerik güncelleme sıklığı değiştikçe aynı soruyu yeniden sormak gerekir: çok dilli sinyaller Googlebot'a ilk taramada mı ulaşıyor, yoksa render kuyruğunun insafına mı bırakılmış durumda.