Çok Dilli ve Çok Para Birimli WooCommerce Siteleri İçin CDN Cache‑Key Mimarisi

Çok dilli ve çok para birimli bir WooCommerce mağazası kurduğunuz anda, klasik “CDN aç, önbelleği bas” yaklaşımı bir anda yetersiz kalır. Aynı URL'yi ziyaret eden farklı kullanıcıların farklı dil, para birimi, vergi ve kargo seçenekleri görmesi gerekir. Yanlış tasarlanmış bir CDN cache‑key mimarisi ise tam tersini yapar: bir kullanıcının TL fiyatıyla oluşturduğu sayfa, başka bir kullanıcının EUR kurunda karşısına çıkabilir. Hem dönüşüm hem güven algısı zedelenir.

Bu yazıda DCHost ekibi olarak, pratikte sıkça karşılaştığımız çok dilli / çok para birimli WooCommerce senaryoları üzerinden, CDN cache‑key tasarımını baştan sona ele alacağız. Sadece “şu header'ı ekleyin” seviyesinde kalmayıp; dil ve para birimi nasıl belirleniyor, hangi cookie ve query parametreleri gerçekten gerekli, hangileri cache hit oranınızı gereksiz yere düşürüyor, bunları adım adım inceleyeceğiz.

Ayrıca CDN katmanını; tarayıcı önbelleği, tam sayfa (page cache) ve nesne önbelleği (Redis/Memcached) ile birlikte düşünerek, uçtan uca bir mimari çizeceğiz. Amacımız: yanlış dil/para birimi göstermeden, sepet ve ödeme sayfalarını bozmadan, istikrarlı bir şekilde yüksek cache hit oranına ulaşmak.

Çok Dilli / Çok Para Birimli WooCommerce Neden Özel Cache‑Key İster?

WooCommerce temelli basit tek dilli bir mağazada, CDN tarafında cache‑key genellikle şu kadardır:

• Şema (http/https)
• Host (www.example.com)
• Path (/kategori/urun-adi/)
• Seçili bazı query parametreler (örn. sayfalama)

Bu, çoğu içerik sitesi için yeterlidir. Ancak çok dilli ve çok para birimli yapı devreye girdiğinde, aynı path altında şu farklılıkların oluştuğunu görürüz:

• Farklı dilde ürün adı, açıklama, buton metinleri
• Farklı para birimi (TL, EUR, USD vb.)
• Farklı KDV oranları veya fiyat dahil/dahil değil gösterimi
• Lokasyona göre değişen kargo ve kampanya kuralları

Eğer cache‑key içinde dil ve para birimi boyutlarını doğru temsil etmezseniz şu problemlerle karşılaşırsınız:

• Yanlış para birimiyle fiyat gösterimi (özellikle reklam kampanyalarında büyük güven kaybı)
• TR ziyaretçinin Almanca içerik, DE ziyaretçinin Türkçe içerik görmesi
• Sepete eklenen ürünle vitrinde görülen fiyatın uyuşmaması
• KDV ve kargo hesaplarının gerçek tutarla eşleşmemesi

Özetle: Çok dilli / çok para birimli WooCommerce projelerinde performans ile doğruluk arasındaki dengeyi, cache‑key mimariniz belirler.

WooCommerce Trafiğini Katmanlara Ayırmak: Nerede Ne Önbelleklenir?

Sadece CDN tarafına odaklanmadan önce, WooCommerce'de tipik bir önbellekleme yığınına bakalım:

• Tarayıcı önbelleği: CSS, JS, görseller için uzun TTL; HTML için kısa veya hiç.
• CDN önbelleği: Statik dosyalar + mümkünse HTML için tam sayfa cache.
• Origin tam sayfa önbellek: Nginx FastCGI cache, LiteSpeed Cache, Varnish vb.
• Nesne önbelleği: Redis/Memcached ile veritabanı sorgularını hafifletme.

Bu katmanların birlikte nasıl çalıştığını daha genel açıdan görmek için, WordPress'te tam sayfa önbellekleme rehberimizi ve WooCommerce için Redis/Memcached nesne önbelleği yazımızı da incelemenizi öneririz.

Bu yazıda özellikle CDN cache‑key boyutuna odaklanacağız; ama unutmayın: CDN ne kadar akıllı olursa olsun, arka tarafta iyi tasarlanmamış bir origin cache stratejisi varsa, depremi sadece bir kat yukarı taşımış olursunuz.

Cache‑Key Nedir, CDN'ler Nasıl Oluşturur?

Cache‑key, kısaca “bu istek, önbellekte hangi kaydın karşılığı olsun?” sorusunun cevabıdır. Çoğu CDN için varsayılan cache‑key şu bileşenlerden oluşur:

• Şema: http / https
• Host: www.site.com
• Path: /urun/kirmizi-elbise/
• Query string: Tüm parametreler veya seçili olanlar
• Belirli header'lar (örn. Accept-Encoding, bazen User-Agent)

Gelişmiş senaryolarda cache‑key içine cookie değerleri ve özel header'lar da eklenir. İşte tam bu noktada çok dilli / çok para birimli WooCommerce devreye girer:

• Farklı dil için kullanılan query parametresi (lang, locale vb.)
• Para birimini taşıyan cookie veya query parametresi
• Ülke bilgisini taşıyan header (X-Country gibi) veya GeoIP sonucu

Amaç, sadece gerçekten içerik farkı yaratan boyutları cache‑key'e almak; diğer her şeyi ya yok saymak ya da normalize etmektir. Aksi hâlde her UTM parametresi, her A/B test ID'si için yeni bir cache girdisi oluşur ve hit oranınız dramatik şekilde düşer.

Çok Dilli WooCommerce İçin Cache‑Key Tasarımı

Dil mimarisi, cache‑key tasarımını doğrudan etkiler. WooCommerce projelerinde en sık gördüğümüz dil yapılarını tek tek inceleyelim.

1) Her Dil İçin Ayrı Alan Adı (ccTLD veya alt alan)

• tr.site.com → Türkçe
• en.site.com → İngilizce
• site.de → Almanca

Bu mimaride dil zaten host üzerinden ayrılmıştır. Yani:

• tr.site.com/urun/ayakkabi/ → Türkçe
• en.site.com/product/shoes/ → İngilizce

CDN cache‑key'inde ekstra bir dil boyutu eklemenize gerek yoktur; host zaten dil ayrımını yapar. Önemli nokta, kullanmak istediğiniz hreflang ve uluslararası SEO stratejisinin bu domain mimarisiyle uyumlu olmasıdır. Bu konuda daha geniş bir çerçeve için hreflang yapılandırma rehberimizi ve çok dilli web siteleri için hosting ve SEO mimarisi yazımızı inceleyebilirsiniz.

2) Dil İçin Alt Dizin Kullanımı (/tr/, /en/ vb.)

• site.com/tr/urun/ayakkabi/
• site.com/en/product/shoes/

Burada dil bilgisi path içinde taşınıyor. CDN cache‑key zaten path'i içerdiği için, yine ekstra bir dil parametresine ihtiyaç yok. Önemli olan:

• Rewrite kurallarıyla dil alt dizinlerinin tutarlı olması,
• 404 ve yönlendirmelerin dil bağımsız çılgınlıklar yapmaması.

Dil switcher butonlarınız da doğrudan bu alt dizinleri kullanıyorsa, CDN tarafında dil için ekstra vary tanımı gerekmeyebilir.

3) Dil Query Parametresi ile Belirleniyorsa (?lang=tr)

• site.com/urun/ayakkabi/?lang=tr
• site.com/urun/ayakkabi/?lang=en

Bu senaryoda kritik hata şudur: CDN varsayılan olarak query parametrelerini görmezden gelecek şekilde ayarlanırsa, ?lang=tr ve ?lang=en istekleri aynı cache girdisini paylaşır. Bu da dil karışıklığına neden olur.

Çözüm:

• Cache‑key içine sadece belirli query parametrelerini (örn. lang) dahil edin.
• UTM, kampanya, takip parametrelerini ise cache‑key dışına çıkarın.

Bunu yaparken, CDN ve tarayıcı önbelleğinde cache‑busting stratejileri yazımızda anlattığımız gibi, hangi parametrelerin gerçekten içerik değiştirdiğini, hangilerinin sadece analitik amaçlı olduğunu netleştirmek kritik.

4) Dil Cookie ile Belirleniyorsa

Bazı çok dilli eklentiler, URL’de dil belirtmek yerine language veya benzeri bir cookie kullanır. Eğer URL yapınızda dil görünmüyor, sadece cookie değişiyorsa, CDN için şu seçenekleriniz var:

• Ya cookie tabanlı vary tanımlayıp cache‑key'e language değerini eklersiniz,
• Ya da HTML seviyesinde tam sayfa cache'i devre dışı bırakıp sadece statik dosyalar için CDN kullanırsınız.

İlk seçenek mümkün ama risklidir: çok sayıda farklı cookie birleşimi (A/B testleri, sepet, oturum vb.) varsa, cache‑key explode olur, hit oranınız ciddi şekilde düşer. Genellikle dil bilgisini URL'ye taşımak (alt dizin veya alt alan adı) hem SEO hem cache‑key basitliği açısından daha sağlıklı bir çözümdür.

Çok Para Birimli WooCommerce İçin Cache‑Key Tasarımı

Para birimi boyutu, dil kadar hatta bazen daha kritik. Çünkü yanlış kur veya yanlış küsuratla fiyat göstermek, ziyaretçinin saniyeler içinde siteden ayrılmasına sebep olur. WooCommerce tarafında para birimi genellikle şu yollardan biriyle belirlenir:

• GeoIP ile ülkeye göre otomatik (örn. DE → EUR, TR → TRY)
• Kullanıcının seçtiği bir para birimi switcher'ı (header veya footer menüsünde)
• Alt alan / alt dizin ile ayrılmış vitrin (eu.site.com, site.com/eu/ vb.)
• Query parametresi (örn. ?currency=EUR)
• Cookie (örn. currency=EUR)

1) Para Birimi Alan Adı veya Alt Dizinle Ayrılıyorsa

Dilde olduğu gibi, eğer her para birimi için farklı host/path kullanıyorsanız:

• site.com/tr/ → TRY
• site.com/eu/ → EUR

Bu durumda para birimi zaten URL seviyesinde kodlanmış olduğundan, cache‑key için ekstra bir şey yapmanıza gerek yoktur. Yine de WooCommerce eklentilerinizin ekstra currency cookie'leri oluşturup oluşturmadığını kontrol etmeli, bunları gereksiz yere vary olarak eklememelisiniz.

2) Query Parametresi ile Para Birimi Seçimi

• site.com/urun/ayakkabi/?currency=EUR
• site.com/urun/ayakkabi/?currency=TRY

Bu, cache‑key açısından en temiz çözümlerden biridir. Yapmanız gereken:

• CDN üzerinde cache‑key içine sadece currency (ve gerekiyorsa lang) parametrelerini dahil etmek,
• Diğer tüm tracking parametrelerini cache‑key dışında bırakmak.

Böylece her dil/para birimi kombinasyonu için tek bir HTML kopyası saklar, gereksiz varyant üretmezsiniz.

3) Cookie ile Para Birimi Belirleniyorsa

Birçok WooCommerce çoklu para birimi eklentisi, kullanıcının seçimini cookie içine yazar; URL genellikle değişmez. Örneğin:

• Cookie: currency=EUR veya currency=TRY
• URL: site.com/urun/ayakkabi/

Bu durumda CDN, aynı URL için farklı HTML dönüşleri alacaktır. İki temel strateji vardır:

1. Cookie tabanlı vary: Cache‑key içine sadece currency cookie'sini eklersiniz. Diğer WooCommerce cookie'lerini (sepet, oturum vb.) cache‑key dışı bırakır ya da bu cookie'ler var olduğunda cache'i tamamen bypass edersiniz.
2. HTML için CDN cache'ini devre dışı bırakma: CDN sadece statik dosyaları cache'ler, HTML tamamen origin'den gelir. Basit ama performans potansiyelini sınırlayan bir çözüm.

Biz DCHost tarafında genellikle şu yaklaşımı tercih ediyoruz:

• Para birimi cookie'sini cache‑key içine dahil et.
• Sepet ve oturum cookie'leri (örn. woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_*) varsa, isteği bypass et.

Böylece hem vitrin sayfalarında güçlü bir HTML cache elde ediyor, hem de sepet/checkout akışında kişiselleşmiş içeriği koruyorsunuz.

Pratik Cache‑Key Tasarımı: Hangi Boyutlar Zorunlu, Hangileri Lüks?

Çok dilli ve çok para birimli bir WooCommerce için ideal cache‑key taslağı aşağıdaki gibi olabilir:

• Her zaman: Şema + host + path
• Opsiyonel: Sadece içerik farkı yaratan query parametreler (lang, currency, page gibi)
• Gerekliyse: Para birimi cookie'si (currency) veya dil cookie'si (language)
• Genellikle gerekmez: User-Agent, cihaz tipi (responsive tema kullanıyorsanız)
• Kesinlikle gerekmez: UTM, kampanya, fbclid, gclid ve diğer tracking parametreleri

CDN tarafında bu mantığı, CDN cache-control ve edge kuralları rehberimizde anlattığımız gibi, şu şekilde ifade edebilirsiniz (temsilî pseudo-konfigürasyon):

# Temsili mantık, gerçek sentaks CDN'e göre değişir
cache_key = scheme + host + path
include_query = ['lang', 'currency', 'paged']
include_cookies = ['currency']
ignore_query = ['utm_source', 'utm_medium', 'utm_campaign', 'fbclid', 'gclid']

Bu sayede:

• URL üzerindeki gerçek içerik değiştiriciler (dil, para birimi, sayfa numarası) cache‑key içinde yer alır.
• Takip parametreleri yüzünden aynı sayfanın onlarca kopyası tutulmaz.

WooCommerce'de Hangi Sayfalar CDN'de Tam Sayfa Cache Olmamalı?

CDN ve tam sayfa önbellekleme konuşurken en çok bozulan yerler, elbette WooCommerce'in dinamik akış sayfalarıdır. Genel prensip şu:

• Güvenle cache'lenebilir: Anasayfa, kategori arşivleri, ürün sayfaları (oturum açmamış kullanıcılar için), blog yazıları, statik kurumsal sayfalar.
• Cache edilmemesi gerekenler: Sepet, ödeme (checkout), hesap (my-account) sayfaları, kullanıcıya özel dashboard'lar.

Birçok CDN veya page cache eklentisi, URL pattern veya cookie varlığına göre kural yazmanıza izin verir. Örneğin:

• Path /sepet, /cart, /checkout, /my-account içeriyorsa cache bypass.
• woocommerce_cart_hash veya wp_woocommerce_session_* cookie'si varsa cache bypass.

Bu bölümde anlattıklarımızı, daha derin pratik örneklerle görmek isterseniz WooCommerce için CDN ve önbellek ayarları yazımızı mutlaka okumanızı tavsiye ederiz.

CDN + Origin Uyumlu Mimarisi: Vary, TTL ve stale-* Ayarları

CDN cache‑key tasarımınız, origin tarafındaki header ve cache kurallarıyla uyumlu olmalıdır. Aksi hâlde:

• Origin, Vary: Cookie gönderirken CDN sadece URL'yi cache‑key yapar ve tutarsız davranır.
• CDN, currency cookie'sine göre vary tanımlar; ama origin tarafındaki page cache bu cookie'yi dikkate almaz.

İdeal senaryoda:

• Origin tam sayfa cache, dil ve para birimi boyutlarını zaten biliyor olur.
• CDN ise bu boyutları cache‑key'e ekleyip, TTL ve stale-while-revalidate gibi gelişmiş direktifleri uygular.

Örneğin, origin'den aşağıdaki gibi bir header çıktısı almak isteyebilirsiniz:

Cache-Control: public, max-age=60, s-maxage=600, 
  stale-while-revalidate=30, stale-if-error=300
Vary: Accept-Encoding, Cookie

Burada Vary: Cookie çok geniştir; WooCommerce cookie'lerinin bir kısmını CDN tarafında yok sayarak sadece dil/para birimi cookie'lerini cache‑key'e dahil etmek önemlidir. stale-while-revalidate ve stale-if-error direktiflerini de doğru kurarak, kısa süreli origin kesintilerinde bile sitenizi ayakta tutabilirsiniz.

Örnek Senaryo: TR + AB Pazarı için Çok Dilli / Çok Para Birimli Mağaza

Diyelim ki WooCommerce mağazanız hem Türkiye hem de Avrupa Birliği müşterilerine hitap ediyor:

• Türkçe + TRY: site.com/tr/
• İngilizce + EUR: site.com/en/

Ek olarak, kullanıcı para birimini header'daki bir switcher ile TRY/EUR arasında değiştirebiliyor; seçimi currency cookie'si ile tutuluyor. Cache‑key mimarisini şöyle kurabilirsiniz:

1. Dil: Zaten alt dizinle ayrılmış (tr/en), dolayısıyla cache‑key için host + path yeterli.
2. Para birimi: currency cookie'sini cache‑key içine dahil edin.
3. Tracking parametreleri: UTM, fbclid, gclid vb. parametreleri cache‑key dışında bırakın.
4. Kritik sayfalar: /sepet, /checkout, /my-account gibi path'ler için CDN tam sayfa cache'ini kapatın.

Böylece:

• site.com/en/product/shoes/ + currency=EUR → ayrı cache girdisi
• site.com/en/product/shoes/ + currency=TRY → ayrı cache girdisi
• Aynı URL + farklı UTM parametreleri → aynı cache girdisini paylaşır

Bu mimariyi hem CDN hem de origin cache tarafında aynı mantıkla kurarsanız, dil/para birimi karışıklığını engellerken, cache hit oranınızı da yüksek tutarsınız.

DCHost Altyapısında Bu Mimarileri Nasıl Kuruyoruz?

DCHost tarafında yönettiğimiz WooCommerce projelerinde genellikle şu yolu izliyoruz:

• Önce dil ve domain mimarisini netleştiriyoruz (ccTLD, alt alan, alt dizin).
• Ardından seçilen çoklu para birimi eklentisinin dil/para birimi sinyallerini (cookie, query param, path) haritalıyoruz.
• Origin tarafında Nginx/LiteSpeed veya Varnish ile dil/para birimi farkındalığı olan bir page cache katmanı kuruyoruz.
• CDN üzerinde ise bu boyutları cache‑key içinde minimum ama yeterli olacak şekilde tanımlıyoruz.

Daha ileri seviyede, yoğun trafiğe sahip mağazalarda GeoDNS ve çok bölgeli hosting mimarisi ile farklı coğrafyalara yakın origin sunucular konumlandırıyor, CDN katmanıyla birlikte çalışacak şekilde kurguluyoruz. Böylece hem TTFB düşük kalıyor hem de dil/para birimi tarafında tutarlılığı koruyoruz.

Altyapı tarafında NVMe diskli VPS veya dedicated sunucular, Redis/Memcached nesne önbelleği, optimize edilmiş PHP-FPM ve veritabanı ayarlarıyla, CDN katmanının size sunduğu kazanımı maksimuma çıkarmak mümkün.

Test, Log Analizi ve Geri Alma (Rollback) Stratejisi

Cache‑key mimarisini kâğıt üzerinde ne kadar doğru tasarlasanız da, mutlaka kontrollü bir test süreci kurgulamanız gerekir:

1. Staging ortamı: Canlıya geçmeden önce CDN ve cache kurallarını staging'de deneyin.
2. Debug header'ları: CDN'in gönderdiği cache-status (HIT/MISS), kullanılan cache‑key, vary bilgilerini görünür kılın.
3. Farklı senaryoları test edin: TR/EU IP, farklı dil/para birimi kombinasyonları, sıfırdan gelen ziyaretçi vs. daha önce sepet oluşturmuş kullanıcı.
4. Log analizi: Yanlış dil/para birimi ile görüntülenen sayfa şikayetleri için access log ve CDN loglarını inceleyin.

Özellikle e-ticaret tarafında log analizi, dönüşüm kaybını fark etmek için kritik. Bunun için e-ticaret siteleri için log analizi rehberimizden yararlanabilirsiniz.

Son olarak, CDN tarafında yaptığınız her kural değişikliğinin geri alma planı olmalı. Örneğin yeni bir cache‑key stratejisini önce belirli bir path veya ülke segmentinde deneyip, sorun görmezseniz kademeli olarak tüm siteye yayabilirsiniz.

Sonuç: Doğru Cache‑Key ile Hız ve Doğruluğu Aynı Anda Yakalamak

Çok dilli ve çok para birimli WooCommerce projelerinde performans sorunları sıklıkla “sunucu yetersiz” sanılsa da, gerçek sebep çoğu zaman yanlış kurgulanmış CDN ve cache‑key mimarisi oluyor. Dil ve para birimi bilgisi URL, cookie ve header seviyesinde netleştirilmediğinde; aynı sayfanın onlarca gereksiz varyantı saklanıyor veya tam tersi, farklı içerikler aynı cache girdisini paylaşıyor.

Doğru yaklaşım; önce bilgi mimarisini ve URL yapısını sadeleştirip, ardından sadece gerçekten içerik farkı yaratan dil ve para birimi sinyallerini cache‑key içine almaktır. Sepet ve ödeme adımlarını güvenle cache dışına çıkarırken, vitrin ve içerik sayfalarında agresif ama kontrollü bir cache politikası kurabilirsiniz. Bu noktada WordPress için CDN önbellek kuralları rehberimiz de size pratik bir kontrol listesi sunacaktır.

Eğer WooCommerce mağazanız çok dilli ve çok para birimli yapıda büyüyorsa ve CDN tarafında hangi yönden başlayacağınız net değilse, DCHost ekibi olarak hem altyapı (VPS, dedicated, colocation) hem de CDN ve cache mimarisi tarafında yanınızdayız. Mevcut trafiğinizi, eklentilerinizi ve URL yapınızı birlikte analiz edip, hızlı ama doğru sonuç veren bir cache‑key stratejisini adım adım hayata geçirebiliriz.