Bir WooCommerce mağazası, aynı ziyaretçi sayısına sahip bir blogdan çok daha fazla kaynak tüketir. Sepet, ödeme ve üye sayfaları önbellekten sunulamaz; her tıklama PHP'yi ve veritabanını çalıştırır. Bu yüzden “WordPress çalışıyor, WooCommerce de çalışır” varsayımı çoğu zaman yavaş sepet sayfası, yarım kalan ödeme ve kaybolan siparişle sonuçlanır. Bu yazıda bir mağaza için paket seçerken bakılacak somut kriterleri sırayla ele alıyoruz: eş zamanlı işlem kapasitesi, nesne önbelleği, PHP işçisi sayısı, SSL ve PCI kapsamı, ödeme altyapısıyla uyum, yedek sıklığı ve VPS'e geçiş zamanı.
Mağaza trafiği neden farklıdır?
Klasik bir içerik sitesinde ziyaretçilerin büyük bölümü aynı sayfaları okur; sayfa önbelleği bir kez üretilen HTML'yi binlerce kişiye dağıtır ve PHP neredeyse hiç çalışmaz. Mağazada ise durum tersine döner:
- Sepete ürün eklemek, kargo hesaplatmak ve ödeme adımı her kullanıcı için ayrı üretilir; önbellek bu sayfaları atlar.
- Giriş yapmış müşteriler için ürün sayfaları bile kişiye özel (fiyat grubu, stok uyarısı) olabilir.
- Stok, kupon ve sipariş tabloları sürekli yazılır; okuma ağırlıklı bir blogdan farklı olarak veritabanı yazma yükü taşır.
- Ödeme sağlayıcıdan dönen bildirimler (webhook) sunucunun her an yanıt vermesini gerektirir.
Sonuç: Mağazanın gerçek yükünü ziyaretçi sayısı değil, aynı anda sepetle uğraşan kullanıcı sayısı belirler. Paket seçerken sormanız gereken ilk soru budur.
Eş zamanlı işlem ve PHP işçisi
PHP işçisi (worker), sunucunun aynı anda yürütebildiği PHP isteği sayısıdır. İki işçili bir hesapta üçüncü istek sıraya girer; kampanya saatinde sıra uzadıkça ödeme sayfası açılmaz ve müşteri vazgeçer. Paylaşımlı paketlerde bu sınır çoğunlukla “giriş süreci” (entry process) ya da “eş zamanlı bağlantı” adıyla paket sayfasında yazar; yazmıyorsa destek ekibine sorun.
Kabaca bir ölçek: bir işçi aynı anda tek istek işler; isteğin süresine göre saniyede birkaç dinamik isteği karşılayabilir. Günde birkaç sipariş alan küçük bir mağaza için iki üç işçi yeterli olabilir; aynı dakikada onlarca kişinin sepete ürün eklediği kampanya dönemlerinde bu sayı hızla yetersiz kalır. WordPress ya da e-ticaret etiketli paketler bazen daha yüksek işçi sayısı ve bellek sınırıyla sunulur, ancak bu her firmada geçerli değildir; işçi sayısı paket sayfalarında çoğu zaman yazmaz, bu yüzden firmaya sorarak doğrulayın. Ayrıntılı farkları paylaşımlı hosting mi, WordPress hosting mi? yazısında bulabilirsiniz.
Bakılacak diğer kaynak sınırları:
- PHP bellek sınırı: WooCommerce'in kendi sistem gereksinimleri 256 MB ve üzerini önerir; altındaki değerlerde eklentiler hata verebilir.
- İşlemci payı: Paylaşımlı pakette hesap başına ayrılan çekirdek oranı; CloudLinux kullanan cPanel sunucularında kaynak kullanımı (Resource Usage) ekranı bunu gösterir.
- Veritabanı bağlantı sayısı: MySQL'in aynı anda açık tutabildiği bağlantı; işçi sayısıyla uyumlu olmalı.
- Inode ve disk: Ürün görselleri ve üretilen küçük resimler hesabı beklenenden hızlı doldurur.
Nesne önbelleği ve veritabanı
Sayfa önbelleği mağazada sınırlı işe yarar; asıl kazanç nesne önbelleğinden gelir. Redis ya da Memcached, WordPress'in her istekte tekrar tekrar okuduğu ayarları, ürün verilerini ve sorgu sonuçlarını bellekte tutar; veritabanına giden sorgu sayısı belirgin biçimde düşer. Sepet ve ödeme sayfaları da bu katmandan yararlanır, çünkü önbelleklenen şey sayfa değil, sayfayı üreten verilerdir.
Paket sayfasında Redis ya da Memcached açıkça yazmalı; “önbellek var” ifadesi çoğu zaman yalnızca sayfa önbelleğini anlatır. Veritabanı tarafında ise MariaDB ya da MySQL'in güncel sürümü, InnoDB depolama motoru ve yeterli tampon belleği (buffer pool) önemlidir. Paylaşımlı pakette bu ayarları siz değiştiremezsiniz; ancak wp_options tablosundaki otomatik yüklenen verileri temizlemek, eski sipariş notlarını ve geçici verileri (transient) silmek sizin elinizdedir.
SSL, PCI ve ödeme altyapısı
Mağaza için SSL zorunludur; ücretsiz Let's Encrypt sertifikası teknik olarak yeterlidir ve Ekim 2026 itibarıyla listemizdeki 25 firmadan 19'u ücretsiz SSL sunuyor. Asıl karar, kart bilgisinin nerede girildiğidir:
- Yönlendirmeli ödeme: Müşteri ödeme adımında iyzico, PayTR ya da bankanın sanal POS sayfasına gider, kart bilgisini orada girer. Kart verisi sunucunuza hiç uğramaz; PCI DSS kapsamınız en dar seviyede kalır.
- Gömülü form (iframe): Form sağlayıcının alanından sizin sayfanıza gömülür; kart verisi yine sağlayıcıda kalır, kapsam yönlendirmeliye yakındır.
- Sitede kart formu: Kart numarası sizin sunucunuzdan geçer. Bu durumda PCI DSS'in çok daha geniş gereksinimleri size ve barındırma firmanıza düşer; paylaşımlı pakette bu gereksinimleri karşılamak çok zordur.
Küçük ve orta ölçekli mağazalar için ilk iki yol hem güvenlik hem de uyum yükü açısından daha makuldür. Barındırma tarafında ise sağlayıcının bildirim adreslerine erişimi engellemeyen bir güvenlik duvarı, güncel TLS sürümleri ve sunucu saatinin doğru olması (imzalı API isteklerindeki ve ödeme bildirimlerindeki zaman damgaları için) yeterlidir. Bazı firmalar ülke bazlı erişim kısıtlaması uygular; ödeme sağlayıcınızın sunucuları yurt dışındaysa bu kısıtlama ödeme bildirimlerini engelleyebilir.
Yedek sıklığı ve geri yükleme
Blogda günlük yedek bir günlük yazıyı kurtarır; mağazada bir günlük kayıp, o gün verilen tüm siparişler demektir. Bu nedenle:
- Firmanın yedek aralığını ve kaç kopya sakladığını sorun; günlükten sık yedek ya da veritabanı için ayrı saatlik yedek seçeneği değerlidir.
- Geri yüklemenin ücretli olup olmadığını ve kimin yapacağını öğrenin.
- Kendi yedeğinizi ayrı bir konuma (bulut depolama) gönderin; firmanın yedeğiyle aynı makinede duran kopya felaket anında işe yaramaz.
- Yedeği en az bir kez test ortamına geri yükleyin; açılmayan yedek, yedek değildir.
Hangi paket türü hangi mağazaya?
| Mağaza profili | Uygun paket | Dikkat edilecek |
|---|
| Deneme aşaması, az ürün, günde birkaç sipariş | WordPress paketi (paylaşımlı) | Redis ve işçi sayısı yazıyor mu |
| Düzenli satış, kampanya dönemleri var | Üst seviye WordPress / e-ticaret paketi | Eş zamanlı bağlantı sınırı, saatlik yedek |
| Yüksek ürün sayısı, ERP entegrasyonu | VPS ya da bulut makine | Yönetim sorumluluğu, veritabanı ayarları |
| Birden fazla mağaza, ajans işi | Yönetimli VPS | Hesap izolasyonu, yedek politikası |
Ne zaman VPS'e geçmeli?
Şu belirtilerden ikisi bir arada görünüyorsa paylaşımlı paket sınırına gelmişsiniz demektir:
- Kampanya saatlerinde “kaynak sınırı aşıldı” ya da 503 hataları.
- Sepet sayfasının açılma süresi ürün sayfalarının birkaç katı.
- Firmanın işçi ya da bellek sınırını artırmayı reddetmesi.
- ERP, kargo ya da muhasebe entegrasyonlarının zamanlanmış görevlerinin (cron) yarıda kesilmesi.
- Nesne önbelleği ya da özel PHP eklentisi kurulamaması.
VPS'te işlemci, bellek ve işçi sayısı tamamen size ayrılır; Redis'i, PHP ayarlarını ve veritabanı yapılandırmasını kendiniz belirlersiniz. Karşılığında güncelleme, güvenlik ve yedek sorumluluğu size geçer; bu yükü taşımak istemiyorsanız yönetimli VPS ya da firmanın yönetim hizmeti eklenir. Geçiş belirtilerini ve adımlarını paylaşımlı hostingten VPS'e ne zaman geçmeli? yazısında ayrıntılı anlattık. Güncel seçenekleri VPS sunucu firmaları sayfasında karşılaştırabilirsiniz.
Satın almadan önce kontrol listesi
- PHP işçisi ya da eş zamanlı bağlantı sınırı paket sayfasında yazıyor mu?
- Redis veya Memcached dahil mi, ek ücretli mi?
- PHP bellek sınırı ve en yüksek yükleme boyutu kaç MB?
- Yedek aralığı, saklanan kopya sayısı ve geri yükleme ücreti ne?
- Ücretsiz SSL ve otomatik yenileme var mı?
- Ödeme sağlayıcınızın bildirim adresleri güvenlik duvarından geçiyor mu?
- Sunucu lokasyonu müşterilerinize yakın mı?
- Paket yükseltme ve VPS'e taşıma aynı firmada yapılabiliyor mu?
Bu sekiz soruya net yanıt veren paket, mağazanız için yalnızca ucuz olanından daha güvenli bir başlangıçtır. Güncel paketleri fiyat, lokasyon ve yenileme tutarına göre WordPress hosting firmaları sayfasında karşılaştırabilirsiniz.