Webflow yayın anında düz HTML basar. Locale sayfası yayına çıktığında hreflang, canonical ve dil metni kaynak kodda zaten durur; Googlebot'un JavaScript kuyruğuna girmesini bekleyen bir kabuk yoktur. Bu, Wix veya Squarespace tarafında custom code'un DOM'a sonradan enjekte edildiği kurulumlardan köklü biçimde ayrılır.
Kod yazmadan ikinci, üçüncü, onuncu dili açma vaadi bu statik modele yaslanır. Localization eklentisi her sayfayı kaynak dilin kopyası olarak çoğaltır, editör çeviriyi kopyanın üzerine yazar. Teknik SEO kararlarının büyük kısmı yine platformun varsayılanına devredilir. Statik HTML, hreflang setinin her koşulda doğru kurulduğu anlamına gelmez; asıl kırılma, çevirisi bitmemiş bir locale'in "yayında" sayılıp kümeye alınması ve CMS alanlarının locale'e duyarlı işaretlenmemesidir.
Hreflang otomasyonu yayında olan locale'ler arasında karşılıklı referansı büyük ölçüde kapatır. CMS koleksiyonunda hangi alanın çevrildiği platform tarafından izlenmez. Custom code head'e statik etiket basabilir; site genelinde hreflang altyapısını bunun üzerine kurmak denetimi kaybettirir.
Webflow Localization mimarisi: primary locale, secondary locale ve alt dizin yapısı
Webflow'da bir "primary locale" ve bunun altında sınırsız sayıda "secondary locale" tanımlanıyor. Kaynak dil, sitenin kök URL'sinde kalırken ikincil diller alt dizin olarak yayınlanıyor: /de/, /ja/, /tr/ gibi. Sayfa ağacı, navigasyon ve şablon yapısı tamamen primary locale'den türetiliyor; bir secondary locale kendi başına farklı bir sayfa hiyerarşisi kuramıyor, sadece mevcut ağacın içeriğini değiştirebiliyor.
Bu, bazı çok dilli senaryolarda avantaj. Yapısal tutarlılık garanti altında; bir dil versiyonunda var olan sayfa diğerlerinde eksik kalmıyor, çünkü sayfa var olma kararı primary locale'de veriliyor. Ancak bir pazar için özel bir sayfa açmak, örneğin sadece bir ülkeye özgü bir kampanya sayfası, bu mimaride doğal bir karşılığı yok; o sayfa önce primary locale'de var olmak zorunda, sonra diğer dillere "boş" veya "gereksiz" olarak yayılıyor.
Her locale, ayrı ayrı yayına alınıyor. Bir secondary locale eklenip içerik girilse bile, o locale yayınlanmadan hiçbir URL üretilmiyor ve dolayısıyla hreflang setine dahil olmuyor. Bu adım basit görünse de, büyük ekiplerde çeviri tamamlanmadan yanlışlıkla yayına alınan veya çeviri tamamlandığı halde yayınlanması unutulan locale'ler sık görülen bir operasyonel kayıp noktası.
Hreflang etiketleri otomatik üretiliyor, ama hangi koşulda tutarlı kalıyor?
Bir locale yayına alındığında Webflow, o sayfanın tüm yayında olan diğer locale karşılıklarını otomatik olarak hreflang etiketleriyle işaretliyor. Karşılıklı referans eksikliği, manuel kurulumun en sık rastlanan hatası, bu otomasyon sayesinde büyük ölçüde ortadan kalkıyor; bir sayfa yayınlandığı sürece diğer tüm sürümler birbirini görüyor.
Sorun, "yayında" ile "çevrilmiş" arasındaki farkta başlıyor. Bir secondary locale yayınlandığında, henüz dokunulmamış alanlar kaynak dildeki içeriği aynen gösteriyor; sayfa teknik olarak yayında ve hreflang setine dahil, ama gösterdiği içerik hâlâ birebir kaynak dil. Google bu sayfayı bağımsız bir dil sürümü olarak değerlendirirken karşısında ince veya kopya içerik buluyor. Hreflang doğru kurulu görünüyor, ama arkasındaki sayfa kümesi vaat ettiği çeşitliliği taşımıyor.
Yayın anında bir senkron gecikmesi de bildiriliyor: yeni bir locale ilk kez yayınlandığında veya bir sayfa güncellendiğinde, hreflang setinin tüm sayfalara aynı anda yansıması bazı durumlarda birkaç saatlik bir gecikmeyle gerçekleşiyor. Bu pencerede Search Console'da geçici "no return tag" uyarıları görülebiliyor; genellikle kendiliğinden düzeliyor, ama sistematik olarak tekrar ediyorsa yayın sırasının kendisi sorgulanmalı, tek bir sayfa değil.
x-default değeri, sorgusuz sualsiz primary locale'e atanıyor ve arayüzde bunu değiştirme seçeneği yok. Kaynak dil pazarlama açısından ideal karşılama noktası olmayabilir; örneğin Türkçe kaynak dilden başlayıp asıl büyümenin İngilizce pazarında gerçekleştiği bir markada, x-default'un hangi versiyona gitmesi gerektiği konusunda platform tercih hakkı bırakmıyor. X-default'un doğru konumlandırılması gereken bu tür senaryolarda platformun bu kısıtı, Webflow'u tek başına yeterli bırakmıyor.
CMS Collection içeriğinin locale bazlı çevirisi nerede kırılıyor?
Statik sayfalar için localization süreci nispeten doğrudan: her metin bloğu ayrı bir çeviri alanı olarak açılıyor, editör üzerine yazıyor, bitiyor. CMS koleksiyonlarında (blog yazıları, ürünler, kategori girdileri gibi tekrarlayan içerik türlerinde) tablo değişiyor; her alanın locale bazında ayrı ayrı etkinleştirilmesi gerekiyor ve bu etkinleştirme adımı kolayca unutulan bir ayar.
Alan tipi de bir sınır getiriyor. Zengin metin alanları, referans alanları (bir koleksiyon öğesinin başka bir koleksiyona bağlandığı durumlar) ve bazı üçüncü parti entegrasyon alanları, locale bazlı çeviriyi her zaman aynı temizlikte taşımıyor. Bir ürün sayfası kendi açıklamasını çevirmiş olsa bile, o sayfanın referans verdiği kategori adı hâlâ kaynak dilde kalabiliyor; sonuç, aynı sayfada iki dilin karıştığı bir görünüm.
Slug alanı ayrı bir gözden kaçan nokta. Birçok kurulumda CMS öğesinin slug'ı primary locale'e bağlı kalıyor; alt dizin öneki dil değiştirse de (/tr/urun-adi yerine /de/urun-adi), slug'ın kendisi çoğu zaman kaynak dilde donuyor. URL yapısının okunabilirlik ve ölçek dengesini önemseyen pazarlarda bu, tam yerelleştirilmiş bir URL bekleyen kullanıcı deneyimini zayıflatıyor; hreflang veya canonical mantığını bozmuyor ama SERP'te görünen URL'nin yerel hissi taşımamasına yol açıyor.
Editör tarafında en sık yapılan hata, bir koleksiyon öğesinin bazı alanlarını çevirip bazılarını atlamak. Webflow bu eksik alanları görsel olarak ayrı bir statüyle işaretlemiyor; sayfa listesinde "çevrildi" veya "çevrilmedi" gibi bir gösterge yok. Büyük bir katalogda onlarca öğe için bu kontrol manuel bir sürece dönüşüyor ve genellikle atlanıyor.
Bunu önlemenin pratik yolu, her koleksiyon öğesini yayına almadan önce aynı alan listesini kontrol eden harici bir belge tutmaktır: hangi alanın locale'e duyarlı olarak işaretlendiği, editörün hangi alanı atladığı, hangi alanın hâlâ kaynak dilde kaldığı. Bu kontrol listesi Webflow arayüzünden değil, proje ekibinin kendi iş akışından beslenmelidir. Locale sayısı ikiden fazlaysa öğeleri gruplandırarak toplu kontrol döngüsü kurmak, her öğeyi ayrı ayrı incelemekten daha sürdürülebilir; katalog büyüdüğünde tek tek kontrol, kaçınılmaz olarak seyrelerek anlamlılığını yitirir.
Statik sayfalar ile CMS şablonlarının localization davranışı neden ayrışıyor?
Statik bir sayfa çevrildiğinde eşleştirme birebir: bir kaynak sayfa, bir hedef sayfa, aralarında tek bir hreflang bağı. CMS şablonlarında (Collection Page Template) durum farklı işliyor; tek bir şablon, koleksiyondaki her öğe için tekrar kullanılıyor ve localization bu şablonun kendisine değil, öğe verisine uygulanıyor.
Bu ayrım, şablon seviyesinde tanımlanan SEO alanlarında (meta başlık deseni, meta açıklama deseni) bir boşluk açabiliyor. Meta başlık, dinamik bir CMS alanına bağlıysa ve o alan locale bazında çevrilmemişse, tüm dil versiyonlarında aynı kaynak dildeki meta başlık SERP'te görünüyor. Sayfa içeriği tamamen çevrilmiş olsa bile, arama sonucundaki başlık ve açıklama hâlâ kaynak dilde kalabiliyor; kullanıcı tıkladığında dil beklentisiyle gördüğü sayfa arasında bir tutarsızlık oluşuyor.
Bu, özellikle şablon tabanlı içerik yönetiminde headless mimarilerin karşılaştığı soruna benziyor; headless CMS'te SEO kararlarının kodun içinde nerede gizlendiğini ele alan mantık burada da geçerli, sadece kod yerine Webflow'un görsel alan eşleştirmesi devreye giriyor. Fark eden bir şey yok görünüyor, ama kontrol edilmesi gereken katman aynı: şablon SEO alanının hangi veri kaynağına bağlı olduğu, her locale için tek tek doğrulanmalı.
Canonical ve x-default davranışı: platformun bıraktığı karar alanı
Varsayılan canonical davranışı isabetli: her locale sayfası kendi URL'sine self-referencing canonical veriyor, ekstra ayar gerekmiyor. Çok dilli yapıda varsayılan kararın self-canonical olması ilkesi burada platform tarafından zaten uygulanıyor; manuel müdahale gereksiz, hatta risk taşıyor.
Asıl karar alanı x-default ve öncelik sıralamasında kapanıyor. Primary locale değiştirilebiliyor ama bu, mevcut yayında olan yüzlerce sayfanın URL yapısını da değiştiren büyük bir operasyon; küçük bir düzeltme olarak yapılabilecek bir ayar değil. Bir markanın hedef pazarı zamanla değişip kaynak dil artık en doğru karşılama noktası olmadığında, Webflow bu değişikliği "sayfa taşıma" seviyesinde bir projeye dönüştürüyor.
CMS öğesi bazında özel canonical tanımlamak da doğrudan desteklenmiyor; bir öğe için farklı bir canonical URL istenirse, bunu özel bir alan üzerinden custom code ile enjekte etmek gerekiyor. Tekil sayfalarda kabul edilebilir bir çözüm, ama kataloğun büyük kısmında sistematik bir ihtiyaçsa bu, platformun sınırlarını zorlamaya başladığının işareti.
Custom code ile açılan boşluklar ne kadar güvenilir?
Webflow'un site veya sayfa düzeyinde custom code alanı, head bölümüne ek etiket enjekte etmeye izin veriyor. Burada önemli bir fark var: Webflow, yayın anında statik HTML üretiyor, yani head koduna eklenen bir etiket, tarayıcı çalışmadan önce kaynak kodda zaten mevcut oluyor. İstemci tarafı render bekleyen platformlarda hreflang'ı JavaScript ile enjekte etmenin taşıdığı risk, DOM'da görünüp kaynak kodda görünmemesi, burada büyük ölçüde ortadan kalkıyor.
Ama bu avantaj sınırsız değil. Custom code alanı locale'e duyarlı koşullu mantık kurmayı kolaylaştırmıyor; her locale için ayrı bir enjeksiyon yazmak, kodu locale sayısı kadar çoğaltmak anlamına gelebiliyor. Birden fazla locale için dinamik bir link seti üretmek istendiğinde, bu veriyi bir CMS koleksiyonundan çekip döngüyle basmak gerekiyor; bu da temel bir CMS yapısı kurmayı ve custom code'un bu yapıyla senkron kalmasını gerektiriyor.
Bir başka risk, Webflow'un kendi ürettiği hreflang veya meta etiketleriyle özel kodun çakışması. İkisi aynı anda aynı locale için farklı bir değer üretiyorsa, hangisinin öncelikli sayılacağı garanti edilmiyor; tarayıcı ve arama motoru bu iki kaynağı her zaman aynı şekilde çözmüyor. Sessiz bir uyumsuzluk. Search Console hreflang setini doğru raporlayabilir, ama kaynak kodda iki çakışan değer aynı anda var görünüyorsa hangi tag'ın fiilen işlendiğini yalnızca URL İnceleme aracıyla canlı sayfayı çekerek teyit edebilirsiniz; panel görünümü tek başına yeterli değildir. Bu yüzden custom code çözümleri, platformun otomasyonunu tamamlayan nokta atışı düzeltmeler olarak kalmalı; site genelinde bir hreflang altyapısını custom code üzerine inşa etmek, denetimi kaybetmenin en hızlı yolu.
Webflow ne zaman yetersiz kalıyor: ölçek eşiği
Az sayıda statik sayfa ve iki üç locale ile çalışan bir kurumsal site için Webflow Localization, manuel hreflang kurulumunun getirdiği hataları büyük ölçüde önlüyor. Statik yayın modeli, JavaScript render kaynaklı riskleri baştan eliyor ve bu, platformun gerçek bir avantajı.
Eşik, CMS kataloğu büyüdüğünde ve locale sayısı arttığında belirginleşiyor. Onlarca koleksiyon öğesinde alan bazlı çeviri disiplinini elle takip etmek, beş locale'i geçtiğinde pratik olarak sürdürülemez hale geliyor; hangi öğenin hangi alanının çevrildiğini gösteren bir panel olmadığı için kontrol tamamen manuel kalıyor. Hreflang hatalarının sistematik tespiti için önerilen düzenli denetim rutini, burada eksik alan takibiyle birlikte yürütülmeli; aksi halde hata sayısı fark edilmeden birikiyor. Beş locale üzerindeki kurulumlar için denetim sıklığı içerik güncelleme döngüsüyle eşgüdümlü çalışmalı: her içerik yayın turunda hreflang setinin tüm sürümlerde tutarlı kaldığı teyit edilmeli, ayda bir yapılan genel tarama ise katalog büyüklüğüyle orantılı bir örnekleme kapsamında planlanmalı.
Pazar bazlı canonical veya x-default ince ayarı gerektiren markalarda da sınır erken geliyor. Karar basit bir soruya indirgeniyor: ekibin platformun varsayılanının dışına çıkması gereken bir hreflang veya canonical ihtiyacı düzenli olarak doğuyor mu? Cevap hayırsa Webflow'un otomasyonu zaman kazandırıyor. Cevap evetse, custom code ile nokta atışı yamalar üretmek yerine, büyüme planının bu esnekliği zaten kurulu sunan bir mimariye (örneğin Next.js tabanlı bir i18n kurulumuna) taşınmayı içerip içermediği değerlendirilmeli.
Webflow'un statik yayın mimarisi, çok dilli SEO'nun en sık karşılaşılan risk kategorisini, render gecikmesini, büyük ölçüde ortadan kaldırıyor. Ama bu, editoryal disiplinin yerini almıyor; alan bazlı çeviri tamamlanmadan yayına alınan bir locale, teknik olarak kusursuz bir hreflang setinin arkasında ince içerik taşıyabiliyor.
Katalog büyüdükçe asıl kontrol noktası, hreflang'ın var olup olmadığı değil, hreflang'ın işaret ettiği her sayfanın gerçekten bağımsız ve tamamlanmış bir dil sürümü olup olmadığı. Bu kontrolü platformun kendisi otomatikleştirmiyor; düzenli bir denetim ritmi kurulmadığında eksik çeviriler, yayında göründükleri için fark edilmeden aylarca kalabiliyor.