Ziyaretçiler Başkasının Sepetini Görüyor: WooCommerce'de Önbelleğe Alınmaması Gereken Sayfalar

Destek kutunuza gelen mesaj şöyle: "Ödeme sayfasına geldim, adres alanında benim değil, başka birinin adı ve telefonu yazıyordu." Ya da daha yumuşak bir varyantı: "Sepete üç ürün ekledim, sayfayı yenileyince sepet boş göründü." Ya da en sinsisi: "Giriş yapıyorum, iki sayfa sonra tekrar 'Giriş yap' butonu çıkıyor."

Bu üç şikâyet kulağa üç ayrı arıza gibi gelir ama pratikte neredeyse her zaman aynı kökten gelir: sayfa önbelleği, kişiye özel bir yanıtı alıp herkese servis ediyor. Önbellek katmanı, bir ziyaretçi için üretilmiş HTML'i diske yazar ve sonraki ziyaretçilere aynı dosyayı verir. O HTML'in içinde üst köşede "Merhaba Ayşe", sepet göstergesinde "3 ürün — 1.240 TL", ödeme formunda dolu adres alanları varsa, o veriler artık ziyaretçiye değil URL'e bağlanmıştır ve sıradaki herkese gider.

Burada iki ayrı problem iç içe geçiyor ve karıştırılmamaları gerekiyor. Birincisi ticari: sepet boş görünen müşteri sipariş vermez. İkincisi ve daha ağırı hukuki: ad, soyad, adres, telefon ve sipariş içeriği KVKK kapsamında kişisel veridir; bunların başka bir ziyaretçinin ekranında görünmesi bir performans hatası değil, bildirime tabi bir veri ihlalidir. Önbelleğin performans tarafını WooCommerce mağazasını hızlandırma yazısında, katmanların genel mantığını ise WordPress önbellek türleri yazısında ele almıştık; bu yazı doğrudan sızıntı tarafına odaklanıyor.

Belirtiyi Eşleştirin: Hangi Şikâyet Hangi Kurala İşaret Eder#

Önbellek arızalarında en çok kaybedilen zaman, yanlış katmanda arama yapmaktır. Şikâyeti aşağıdaki tabloyla eşleştirip doğrudan ilgili bölüme geçin:

Son satır özellikle önemli. Eklenti tarafındaki kurallarınız doğru olsa bile CDN katmanı kendi kararını verir; bu yüzden aynı kuralları iki yerde tanımlamak zorundasınız. Bunu ayrı bir başlıkta ele alacağız.

Neden Oluyor: Statik HTML Kişiye Özel Veriyi Taşıdığında#

Sayfa önbelleği tek bir varsayıma dayanır: aynı URL herkese aynı içeriği döndürür. Bir blog yazısı için bu doğrudur. WooCommerce içinse aynı URL, ziyaretçinin oturumuna göre farklı içerik üretir. Mağaza ana sayfası bile bundan muaf değildir; üst köşedeki sepet göstergesi ve "Merhaba" satırı sayfanın içine gömülüdür.

WooCommerce bu farkı çerezlerle takip eder. Ziyaretçi sepete ilk ürünü ekler eklemez tarayıcısına şu çerezler yazılır:

Doğru kurulmuş bir önbellek katmanı, bu çerezlerden herhangi birini taşıyan isteği görünce hiç önbelleğe bakmaz ve isteği PHP'ye geçirir. Yanlış kurulmuş olan ise ya bu çerezleri hiç kontrol etmez (herkese aynı sepeti gösterir) ya da sepetli ziyaretçiye anonim kopyayı verir (sepet boş görünür).

İkinci bir kaynak daha var ve gözden kaçar: önbelleğe alınan yanıtın kendisi bir Set-Cookie başlığı taşıyorsa o çerez de kopyalanır. Bu, "başka müşterinin oturumuna düştüm" gibi en ağır belirtinin sebebidir. Bu yüzden hiçbir önbellek katmanı, Set-Cookie içeren bir yanıtı saklamamalıdır; ciddi eklentiler ve Cloudflare bunu varsayılan olarak yapar, ancak elle yazılmış proxy_cache yapılandırmalarında bu kural sık sık unutulur.

Asla Önbelleğe Alınmaması Gereken Sayfalar ve URL'ler#

Kural setinin ilk yarısı yol bazlıdır. Aşağıdaki adreslerin hiçbiri, hiçbir katmanda önbelleğe alınmamalıdır:

• Sepet sayfası
• Ödeme sayfası
• Sipariş alındı / teşekkür sayfası (order-received)
• Hesabım ve altındaki tüm alt sayfalar (siparişlerim, adresler, indirmeler)
• Şifre sıfırlama bağlantısının açtığı sayfa
• /wp-admin ve /wp-login.php
• Store API uç noktaları: /wp-json/wc/store/
• wc-ajax= parametresi taşıyan istekler
• add-to-cart=, removed_item=, remove_item= gibi eylem parametresi taşıyan URL'ler

Türkçe kalıcı bağlantı kullanan mağazalarda en sık yapılan hata, kuralları İngilizce varsayılan slug'larla (/cart/, /checkout/) yazmaktır. Sizin sayfalarınız /sepet/ ve /odeme/ ise o kurallar hiçbir şeye denk gelmez ve sessizce boşa çalışır. Gerçek slug'ları tahmin etmeyin, sorun:

# WooCommerce sayfalarinin gercek slug'lari: kurallara BUNLARI yazacaksiniz
for opt in woocommerce_cart_page_id woocommerce_checkout_page_id woocommerce_myaccount_page_id; do
  id=$(wp option get "$opt")
  printf "%-34s /%s/\n" "$opt" "$(wp post get "$id" --field=post_name)"
done

Store API satırı da yeni ve önemlidir: blok tabanlı sepet ve ödeme sayfaları verilerini /wp-json/wc/store/ uç noktalarından çeker. Yalnızca /sepet/ yolunu hariç tutup bu uç noktayı unutursanız, blok sepet önbellekten gelen eski JSON ile dolar; sayfa doğru görünürken içindeki tutarlar yanlış olur.

Çerez Bazlı Bypass: Asıl Koruma Katmanı Budur#

Yol bazlı kurallar yalnızca dört beş sayfayı korur. Sızıntının büyük kısmı ise ana sayfa, kategori ve ürün sayfalarında yaşanır; çünkü sepet göstergesi ve karşılama satırı oralarda da vardır. Bunları koruyan tek mekanizma çerez bazlı bypass'tır.

Kural şudur: istek yukarıdaki dört çerezden herhangi birini taşıyorsa, URL'i ne olursa olsun önbellek atlanır. Bu, sepeti dolu ziyaretçinin ve giriş yapmış kullanıcının tüm gezintisini dinamik moda alır. Maliyeti kabul edilebilir düzeydedir, çünkü ziyaretçilerin çoğunluğu sepetine hiç ürün eklemeden ayrılır ve onlar önbellekten yararlanmaya devam eder.

Nginx tarafında map yönergesi bu kuralı okunabilir biçimde kurmanızı sağlar. map blokları http bağlamına, yani server bloğunun dışına yazılır:

# --- http baglami ---
# 1) Onbellege ALINMAYACAK oturum cerezleri
map $http_cookie $wc_oturum {
    default                        0;
    "~*wordpress_logged_in_"       1;
    "~*wp_woocommerce_session_"    1;
    "~*woocommerce_items_in_cart"  1;
    "~*woocommerce_cart_hash"      1;
}

# 2) Onbellege ALINMAYACAK yollar (Turkce ve Ingilizce slug birlikte)
map $request_uri $wc_dinamik {
    default                                              0;
    "~*^/(sepet|odeme|hesabim|siparis-alindi)"           1;
    "~*^/(cart|checkout|my-account|order-received)"      1;
    "~*^/wp-admin|^/wp-login\.php"                       1;
    "~*^/wp-json/wc/store/"                              1;
    "~*[?&](add-to-cart|wc-ajax|removed_item)="          1;
}

# --- server baglami ---
set $atla 0;
if ($wc_oturum)  { set $atla 1; }
if ($wc_dinamik) { set $atla 1; }

location ~ \.php$ {
    fastcgi_cache_bypass $atla;
    fastcgi_no_cache     $atla;
    fastcgi_cache        WORDPRESS;
    fastcgi_cache_key    "$scheme$request_method$host$request_uri";
    fastcgi_cache_valid  200 301 302 30m;

    # Dogrulama icin: HIT / BYPASS degerini tarayicidan gorebilmek
    add_header X-WP-Cache $upstream_cache_status always;
}

add_header X-WP-Cache satırı isteğe bağlı görünür ama bırakın: doğrulama bölümünde kuralın gerçekten çalıştığını tek curl ile görmenizi sağlayan şey odur.

LiteSpeed tabanlı bir hostingteyseniz aynı iki kuralı .htaccess üzerinden kurabilirsiniz:

<IfModule LiteSpeed>
    RewriteEngine On

    # Oturum ya da sepet cerezi tasiyan istekleri onbellege alma
    RewriteCond %{HTTP_COOKIE} (wordpress_logged_in_|wp_woocommerce_session_|woocommerce_items_in_cart|woocommerce_cart_hash) [NC]
    RewriteRule .* - [E=Cache-Control:no-cache]

    # Sepet, odeme, hesabim ve siparis sonucu sayfalari
    RewriteCond %{REQUEST_URI} ^/(sepet|odeme|hesabim|siparis-alindi)/ [NC]
    RewriteRule .* - [E=Cache-Control:no-cache]

    # Store API uc noktalari (blok sepet/odeme sayfalari bunu kullanir)
    RewriteCond %{REQUEST_URI} ^/wp-json/wc/store/ [NC]
    RewriteRule .* - [E=Cache-Control:no-cache]
</IfModule>

Kendi eklentinizin ürettiği özel bir sayfa varsa (bayi paneli, özel hesap ekranı, kişiye özel fiyat listesi) yol yazmak yerine WordPress'in ortak sinyalini kullanmak daha güvenlidir. DONOTCACHEPAGE sabitini WP Rocket, LiteSpeed Cache, W3 Total Cache ve WP Super Cache birlikte tanır:

// Kisiye ozel her ciktiyi tum onbellek katmanlarina "saklama" diye bildir
add_action( 'template_redirect', function () {
    if ( ! function_exists( 'is_cart' ) ) {
        return;
    }

    if ( is_cart() || is_checkout() || is_account_page() || is_wc_endpoint_url() ) {
        if ( ! defined( 'DONOTCACHEPAGE' ) ) {
            define( 'DONOTCACHEPAGE', true );
        }
        nocache_headers();
    }
} );

is_wc_endpoint_url() çağrısı, "hesabım" altındaki tüm alt uç noktaları (siparişlerim, adresler, indirmeler, şifre değiştirme) tek satırda kapsar; bunları elle listelemeye çalışmak, birini unutmanın en garantili yoludur.

Eklenti Katmanı: WP Rocket, LiteSpeed Cache ve W3 Total Cache#

Popüler eklentiler WooCommerce'i tanır ve sepet/ödeme/hesabım sayfalarını kurulumda otomatik hariç tutar. Buna güvenmeyin, gözle doğrulayın; özellikle Türkçe slug kullanan ya da sayfaları sonradan taşınmış mağazalarda otomatik algılama şaşabilir. Ayarların bulunduğu yerler:

Üç eklentide de "giriş yapmış kullanıcılar için önbellek" seçeneği ayrı bir anahtardır ve varsayılan olarak kapalıdır. Onu açmayın. Bu seçenek kullanıcı başına ayrı önbellek üretmeyi vaat eder, ancak yanlış yapılandırıldığında tam olarak aramakta olduğunuz sızıntıyı yaratır ve e-ticarette getirdiği kazanç riskini karşılamaz. WP Rocket'ın ayar ekranlarının tamamı için WP Rocket kurulumu, LiteSpeed tarafı için LiteSpeed Cache yapılandırması yazılarına bakabilirsiniz.

Bir de sık yapılan bir ayar hatası var: sorgu parametreli URL'lerin önbelleğe alınması. Eklentilerin "Cache Query String(s)" alanına orderby, filter_* gibi parametreleri eklemek performans için mantıklıdır; ancak add-to-cart ya da wc-ajax parametrelerini oraya eklemek felakettir, çünkü bu URL'ler bir eylemi tetikler ve önbellekten servis edildiklerinde eylem hiç çalışmaz.

İkinci Katman: Aynı Kuralları CDN Tarafında da Tanımlayın#

Bu, atlanması en kolay ve sonucu en ağır adımdır. Eklentide tanımladığınız kurallar yalnızca kendi sunucunuzu bağlar. Önünüzde Cloudflare gibi bir CDN varsa, kenar düğümler isteği sizin sunucunuza hiç ulaştırmadan kendi kopyalarından yanıtlayabilir. Eklenti kuralınız o anda hiç çalışmaz.

Cloudflare varsayılan olarak HTML'i önbelleğe almaz, dolayısıyla temiz bir kurulumda risk düşüktür. Sorun, "sayfa hızını artıralım" diye eklenen bir Cache Rule ya da eski "Cache Everything" Page Rule'unda çıkar. Böyle bir kuralınız varsa, önüne mutlaka bir bypass kuralı koyun. Cloudflare panelinde Caching > Cache Rules > Create rule yolunu izleyin, ifade düzenleyicisine şunu yazın ve eylemi Bypass cache seçin:

(http.cookie contains "wordpress_logged_in_") or
(http.cookie contains "wp_woocommerce_session_") or
(http.cookie contains "woocommerce_items_in_cart") or
(http.cookie contains "woocommerce_cart_hash") or
(starts_with(http.request.uri.path, "/sepet")) or
(starts_with(http.request.uri.path, "/odeme")) or
(starts_with(http.request.uri.path, "/hesabim")) or
(starts_with(http.request.uri.path, "/wp-admin")) or
(starts_with(http.request.uri.path, "/wp-login")) or
(starts_with(http.request.uri.path, "/wp-json/wc/store"))

Kural sıralaması önemlidir: bypass kuralı, "Cache Everything" davranışını getiren kuraldan önce gelmelidir; Cloudflare kuralları yukarıdan aşağıya değerlendirir ve eşleşen ilk kuralda karar verir. Ayrıca hangi DNS kayıtlarının Cloudflare üzerinden geçtiğini de gözden geçirin; ayrıntısı turuncu bulut mu gri bulut mu yazısında. Cloudflare'ı WordPress ile birlikte kurarken kapatılması gereken diğer anahtarlar için WordPress Cloudflare kurulumu yazısına bakın.

Aynı mantık diğer CDN'ler için de geçerlidir: hangi sağlayıcıyı kullanırsanız kullanın, sorulacak soru sabittir — "Bu kenar düğüm, oturum çerezi taşıyan bir isteği kendi kopyasıyla yanıtlayabilir mi?" Cevap evet ise oraya da bir bypass kuralı gerekir.

Doğrulama: İki Tarayıcı Testi ve Yanıt Başlıkları#

Kuralları yazdıktan sonra "sanırım düzeldi" ile yetinmeyin. İki adımda kesin sonuç alırsınız.

1. İki tarayıcı testi. Normal pencerede A müşterisi olarak giriş yapın, sepete bir ürün ekleyin ve ödeme sayfasına kadar ilerleyin. Aynı anda farklı bir tarayıcıda (aynı tarayıcının gizli penceresi değil, gerçekten başka bir tarayıcı) anonim ziyaretçi olarak aynı sayfaları gezin. İkinci pencerede A müşterisinin adı, sepeti ya da adresi görünüyorsa kurallar hâlâ eksiktir. Gizli pencerenin yetmemesinin sebebi, bazı tarayıcıların gizli oturumda da aynı HTTP önbelleğini kısmen paylaşmasıdır; testin temiz olması için farklı tarayıcı ya da farklı cihaz kullanın.

2. Yanıt başlıklarını okuyun. En hızlı ve en objektif kontrol budur:

# a) Anonim sepet istegi: onbellekten GELMEMELI
curl -sI https://magaza.com/sepet/ \
  | grep -iE 'cf-cache-status|x-litespeed-cache|x-wp-cache|^age:|cache-control'

# b) Sepeti dolu ziyaretci taklidi: ana sayfa da bypass olmali
curl -sI -H 'Cookie: woocommerce_items_in_cart=1' https://magaza.com/ \
  | grep -iE 'cf-cache-status|x-litespeed-cache|x-wp-cache'

# c) Giris yapmis kullanici taklidi
curl -sI -H 'Cookie: wordpress_logged_in_test=deneme' https://magaza.com/ \
  | grep -iE 'cf-cache-status|x-litespeed-cache|x-wp-cache'

# d) Kiyas icin: anonim ana sayfa ONBELLEKTEN gelmeli
curl -sI https://magaza.com/ | grep -iE 'cf-cache-status|x-wp-cache'

Beklenen sonuçlar: (a), (b) ve (c) isteklerinde cf-cache-status: BYPASS veya DYNAMIC, x-wp-cache: BYPASS, x-litespeed-cache: no-cache görmelisiniz. (d) isteğinde ise HIT görmeniz iyi haberdir; kuralları yazarken tüm siteyi yanlışlıkla önbellek dışına çıkarmadığınızı kanıtlar. (b) veya (c) isteğinde HIT görüyorsanız çerez bypass'ı çalışmıyor demektir ve sızıntı hâlâ açıktır.

Bir de age: başlığına bakın. Sepet ya da ödeme yanıtında sıfırdan büyük bir age değeri, yanıtın bir ara katmanda beklediğini gösterir; bu tek başına yeterli kanıttır.

Başka Müşterinin Verisi Göründüyse: KVKK Tarafında Ne Yapılır#

Teknik düzeltmeyi yapmakla iş bitmez. Bir ziyaretçinin ekranında başka bir müşterinin adı, adresi, telefonu ya da sipariş içeriği göründüyse ortada kişisel verilere hukuka aykırı erişim vardır ve bu, KVKK anlamında bir veri ihlalidir. Mağaza sahibi olarak siz veri sorumlususunuz; hosting sağlayıcınız ya da eklenti geliştiricisi bu sorumluluğu üstlenmez.

Sıralama şöyle olmalı:

1. Sızıntıyı durdurun. Kural yazmayı beklemeden sayfa önbelleğini geçici olarak tamamen kapatın ve tüm katmanlardaki mevcut önbelleği temizleyin — eklenti, sunucu ve CDN. Yalnızca eklentiyi temizlemek yetmez; kenar düğümlerdeki kopya orada durmaya devam eder.
2. Kapsamı belirleyin. Hangi URL'ler önbelleğe alınmış, ilk ne zaman alınmış, o dosya kaç kez servis edilmiş? Sunucu erişim günlükleri ve önbellek dizinindeki dosya tarihleri bu sorulara yaklaşık da olsa yanıt verir. Etkilenen müşteri sayısı ve veri kategorilerini yazılı olarak kayda geçirin.
3. Bildirim yükümlülüğünü değerlendirin. Kişisel Verileri Koruma Kurulu'nun yerleşik uygulamasına göre veri sorumlusu, ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurul'a bildirimde bulunur; ilgili kişilere de makul olan en kısa sürede bilgi verilir. Süre kısadır, bu yüzden değerlendirmeyi teknik düzeltmenin arkasına bırakmayın.
4. Kayıt tutun. İhlalin kendisini, etkilerini ve aldığınız aksiyonları içeren bir kayıt oluşturun. Bu kayıt, Kurul denetiminde ilk istenen belgedir.
5. Kuralları kalıcı hâle getirin. Bu yazıdaki üç katmanı (sunucu, eklenti, CDN) tanımlayın, doğrulama komutlarını çalıştırın ve sonucu bir yere not edin. Aynı doğrulamayı her tema değişikliğinden, her CDN kural düzenlemesinden ve her hosting taşımasından sonra tekrarlayın.

Bu adımlar sırasında mağazanın genel güvenlik yüzeyini de gözden geçirmek mantıklıdır; WooCommerce güvenliği yazısı yönetici erişimi, eklenti hijyeni ve ödeme akışı tarafındaki kontrol listelerini içeriyor.

Sıkça Sorulan Sorular#

Sepet ve ödeme sayfalarını hariç tutmak mağazamı yavaşlatır mı?#

Ölçülebilir bir yavaşlama beklemeyin. Bir mağazada trafiğin büyük çoğunluğu ana sayfa, kategori ve ürün sayfalarındadır; bunlar önbellekten servis edilmeye devam eder. Sepet ve ödeme sayfaları toplam görüntülemenin küçük bir yüzdesidir ve zaten kişiye özel olduğu için önbelleğe alınmaları mümkün değildir. Çerez bazlı bypass da yalnızca sepetine ürün eklemiş ziyaretçileri kapsar; ziyaretçilerin çoğunluğu bu gruba hiç girmez.

Cloudflare zaten HTML'i önbelleğe almıyor, yine de kural yazmalı mıyım?#

Evet. Varsayılan davranış güvenlidir, ancak "Cache Everything" içeren bir Page Rule ya da Cache Rule eklendiği anda bu koruma ortadan kalkar. Böyle bir kuralı siz eklemeseniz bile bir eklenti, bir tema ya da daha önce siteye dokunmuş bir geliştirici eklemiş olabilir. Bypass kuralını önceden tanımlamak, ileride eklenecek herhangi bir agresif önbellek kuralının sızıntıya dönüşmesini yapısal olarak engeller.

Giriş yapmış kullanıcılar için önbellek seçeneğini açmak güvenli mi?#

E-ticarette önermiyorum. Bu seçenek kullanıcı başına ayrı önbellek kovaları üretir; doğru çalıştığında hızlıdır, ancak kova anahtarı yanlış hesaplandığında iki kullanıcının aynı kovaya düşmesi mümkündür ve sonuç tam olarak veri sızıntısıdır. Bir mağazada giriş yapmış kullanıcı oranı düşük, taşıdığı veri ise yüksek hassasiyettedir. Risk ile kazanç dengesi bu anahtarı kapalı tutmayı gerektirir.

Kuralları yazdım ama sorun devam ediyor, ne kaçırmış olabilirim?#

En sık üç sebep var. Birincisi, önbellek temizlenmemiştir; kurallar yalnızca yeni isteklere uygulanır, diskte ve kenar düğümlerde duran eski kopyalar servis edilmeye devam eder. İkincisi, kuralları İngilizce slug'larla yazmışsınızdır ama sayfalarınız Türkçe adreslerdedir. Üçüncüsü, kuralı yalnızca bir katmana yazmışsınızdır; sunucu, eklenti ve CDN üçlüsünden biri eksik kalmıştır. Doğrulama komutlarıyla hangi katmanın HIT döndürdüğünü bulun.

Sepet göstergesi üst köşede güncellenmiyor, bu da aynı sorun mu?#

Aynı ailedendir ama daha hafif bir biçimidir. WooCommerce sepet göstergesini AJAX ile güncelleyen bir mekanizma kullanır; sayfa önbellekten geliyorsa gösterge sayfa yüklendiği andaki değerde donar. Çerez bazlı bypass kuralı bu belirtiyi de çözer, çünkü sepete ilk ürün eklendiği anda ziyaretçi dinamik moda geçer. Bazı performans eklentileri bu AJAX çağrısını tümüyle kapatan bir seçenek sunar; o seçenek açıksa gösterge yine güncellenmez.

Statik dosyalar ve görseller için de kural yazmam gerekir mi?#

Hayır. CSS, JavaScript, görsel ve font dosyaları kişiye özel veri taşımaz; bunları uzun süreli önbelleğe almak hem güvenli hem de istenen davranıştır. Bu yazıdaki kuralların tamamı yalnızca HTML yanıtlarını ve JSON uç noktalarını hedefler. Statik dosyaları yanlışlıkla kural kapsamına almak, hiçbir güvenlik kazancı sağlamadan sitenizi belirgin biçimde yavaşlatır.