WooCommerce Hosting: Mağaza İçin Sunucu Gereksinimleri ve Ayarlar
Mağaza sayfalarının önemli bir kısmı önbelleğe alınamaz, arka plan işleri kuyrukta bekler ve sipariş tabloları her gün büyür. WooCommerce’in sunucudan beklediklerini, HPOS’u, önbellek istisnalarını, Action Scheduler için gerçek cron’u ve büyüme sinyallerini anlatıyoruz.
WooCommerce hosting, bir WordPress mağazasının en ağır anlarına, yani aynı anda çok sayıda ziyaretçinin sepete ürün eklediği ve ödeme yaptığı anlara göre boyutlandırılmış barındırmadır. Bir blogun sayfaları neredeyse tamamen önbellekten sunulabilirken mağazada sepet, ödeme ve hesap sayfaları her ziyaretçiye özeldir, her sipariş veritabanına yazılır ve abonelik yenilemesi ya da webhook gibi işler arka planda kuyruğa alınır.
Platform seçimi, kampanya kapasitesi, PCI DSS (kart verisi güvenlik standardı) ve KVKK gibi genel e-ticaret kararları e-ticaret hosting seçimi yazısında ele alındı. Aşağıdaki gereksinimler ve ayarlar WooCommerce’e özgüdür; LIONFIN WordPress hosting paketlerinde de kendi yönettiğiniz bir sunucuda da geçerlidir.
Kısa cevap
WooCommerce hosting, bir WooCommerce mağazasının önbelleğe alınamayan sepet, ödeme ve hesap sayfalarını, büyüyen sipariş veritabanını ve arka plan görevlerini kaldıracak şekilde yapılandırılmış barındırmadır. Temel gereksinimler güncel bir PHP 8.x, MySQL 8 ya da güncel MariaDB, en az 256 MB WordPress bellek sınırı ve sitenin tamamında HTTPS’tir; bunlara HPOS sipariş tabloları, nesne önbelleği, gerçek cron ve siparişleri kapsayan sık yedek eklenmelidir.
WooCommerce hosting için sunucu gereksinimleri nelerdir?
Bir WooCommerce mağazası için sunucuda güncel bir PHP 8.x, MySQL 8.0 ya da MariaDB 10.6 ve üzeri bir veritabanı, en az 256 MB WordPress belleği, geçerli bir SSL sertifikası ve sistem cron’u bulunmalıdır. Resmî öneriler sürümle birlikte güncellendiği için kurulumdan önce güncel WooCommerce gereksinimlerine de bakın; tablo, hangi değerin neden önemli olduğunu gösterir:
| Bileşen | Hedef | Neden önemli |
|---|---|---|
| PHP | Güvenlik desteği süren güncel bir 8.x sürümü, OPcache açık | Eklenti uyumu ve sayfa üretim süresi |
| Veritabanı | MySQL 8.0 ve üzeri ya da MariaDB 10.6 ve üzeri | Sipariş, stok ve rapor sorguları |
| Bellek | WP_MEMORY_LIMIT en az 256M; PHP memory_limit bundan düşük olmamalı | Raporlar, toplu ürün içe aktarma, yönetim ekranları |
| HTTPS | Sitenin tamamında geçerli sertifika | Ödeme sağlayıcıları ve tarayıcılar şart koşar |
| Disk | NVMe ya da SSD | Sürekli yazılan sipariş ve oturum tabloları |
| Zamanlayıcı | Sistem cron’u | Arka plan görev kuyruğu (Action Scheduler) |
Mevcut değerleri WooCommerce → Durum (Status) ekranındaki sistem raporu gösterir; düşük bellek ve eski sürüm uyarıları da burada çıkar. Bellek sınırını yükseltme yolları PHP memory limit artırma rehberinde anlatılır.
HPOS nedir, mağazanızda açık mı?
HPOS (High-Performance Order Storage, yüksek performanslı sipariş depolama), siparişleri WordPress’in genel wp_posts ve wp_postmeta tabloları yerine yalnızca siparişlere ayrılmış tablolarda tutan yapıdır. Sipariş arama, listeleme ve raporlama sorguları bu sayede daha az veri tarar; büyüyen mağazalarda sipariş ekranları hızlanır. WooCommerce 8.2’den bu yana yeni kurulan mağazalarda varsayılan olarak açıktır.
Durumu WooCommerce → Ayarlar → Gelişmiş → Özellikler ekranından kontrol edin. Eski bir mağazada geçiş sırası:
- Tam yedek alın ve geçişi önce test kopyasında deneyin.
- Ekranda HPOS ile uyumsuz görünen eklentileri güncelleyin ya da alternatiflerini bulun.
- Uyumluluk modunu (iki depolama arasında senkronizasyon) açın; mevcut siparişler arka planda yeni tablolara kopyalanır.
- Senkronizasyon bitince HPOS’u etkin depolama olarak seçin; uyumluluk modunu bir süre açık tutup sorun görmezseniz kapatın.
Yeni tabloların adı wc_order ile başlar (önünde sitenizin tablo öneki bulunur); yedek ve taşıma betiklerinizin bu tabloları kapsadığından emin olun.
Hangi sayfalar ve istekler önbellek dışında kalmalı?
Sepet, ödeme ve hesabım sayfaları ile sepetinde ürün bulunan ziyaretçinin istekleri sayfa önbelleğini atlamalıdır; aksi hâlde müşteri başkasının sepetini ya da eski bir fiyatı görebilir. Yaygın önbellek eklentileri WooCommerce’in bu sayfalar için gönderdiği önbellek karşıtı işaretleri tanır; sunucu düzeyinde önbellek (Nginx FastCGI önbelleği, Varnish) kullanıyorsanız kuralları kendiniz yazmanız gerekir:
| Önbelleği atlatan koşul | Örnek |
|---|---|
| Sayfa yolu | /sepet/, /odeme/, /hesabim/ (kalıcı bağlantı ayarınıza göre) |
| Çerez | woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_* |
| Sorgu parametresi | ?add-to-cart=, ?wc-ajax= |
| Oturum | wordpress_logged_in_* çerezi taşıyan istekler |
Önbelleğe alınamayan bu istekler için asıl hızlandırıcı nesne önbelleğidir: Redis ya da Memcached, ürün, vergi ve kargo ayarları gibi tekrar eden sorguları bellekten döndürür. LiteSpeed sunucularda istisnaların ve ESI’nin nasıl ayarlandığı LiteSpeed Cache ayarları rehberinde anlatılır.
Action Scheduler için gerçek cron neden şart?
Action Scheduler, WooCommerce’in abonelik yenilemeleri, webhook teslimleri, analiz verilerinin içe aktarılması ve pek çok eklenti işi gibi görevleri sıraya koyup arka planda çalıştıran kuyruktur; kuyruk büyük ölçüde WP-Cron ile tetiklendiği için ziyaretçi az olduğunda ya da sayfalar önbellekten sunulduğunda işler birikir. Belirtisi, gecikmiş (past-due) eylem uyarıları ve zamanında gitmeyen webhook ya da yenileme işlemleridir.
- Bekleyen ve başarısız işleri WooCommerce → Durum → Zamanlanmış Eylemler (Scheduled Actions) ekranında kontrol edin.
- WP-Cron’u sayfa yüklemesinden ayırıp sistem cron’una bağlayın; mağazalarda dakikada bir çalıştırmak uygundur.
wp-config.phpayarı ve cron satırı WordPress hızlandırma rehberindeki adımlarla aynıdır. - Birikmiş kuyruğu bir kerelik eritmek için SSH erişiminiz varsa WP-CLI komutunu kullanın:
cd /home/KULLANICI/public_html
wp action-scheduler run --batches=10Başarısız işlerin çoğu bir eklentinin hatasından kaynaklanır; listede her işin kanca (hook) adı ve günlük notları, hangi işin neden başarısız olduğunu gösterir.
Mağaza yedeğinde ve staging aktarımında sipariş kaybı nasıl önlenir?
Mağaza yedeğinde asıl değerli veri dosyalar değil siparişler, müşteriler ve stok bilgisidir; bu yüzden veritabanı yedeği dosya yedeğinden daha sık alınmalı ve sunucu dışına kopyalanmalıdır. Kopya sayısı ve konumu için 3-2-1 yedekleme stratejisi iyi bir çerçevedir.
En sinsi kayıp ise staging’den canlıya aktarımda yaşanır. Test kopyasında tema ya da eklenti değişikliği yapıp veritabanının tamamını canlıya gönderirseniz, kopya alındıktan sonra canlı sitede oluşan siparişler, müşteri hesapları ve stok hareketleri silinir. Güvenli yol:
- Canlıya yalnızca dosyaları (tema, eklenti) aktarın, ayar değişikliklerini canlıda elle tekrarlayın.
- Veritabanı aktarımı şartsa yalnızca değiştirdiğiniz tabloları seçin; siparişlerin eski depolamada
wp_postsiçinde, HPOS’ta ise ayrı tablolarda durduğunu hesaba katın. - Aktarımdan hemen önce canlı veritabanının ayrı bir yedeğini alın.
Test ortamının kurulumu WordPress staging ortamı rehberindedir; test kopyasında ödeme yöntemini test moduna almayı ve müşteri e-postalarını kapatmayı unutmayın.
Ödeme güvenliği hosting tarafında neyi değiştirir?
Kart bilgisinin sizin sunucunuza hiç uğramadığı ödeme yöntemleri, hosting tarafındaki güvenlik yükünü belirgin biçimde azaltır. Ödeme sağlayıcısının barındırdığı ödeme sayfasına yönlendiren ya da kart alanlarını sağlayıcının çerçevesinde (iframe) gösteren eklentiler PCI DSS kapsamınızı daraltır; 3D Secure doğrulaması da kart sahibini bankanın ekranında doğruladığı için dolandırıcılık riskini düşürür.
Bu, sunucuyu güvenlik denkleminden çıkarmaz: sitenize sızan bir betik, ödeme adımını sahte bir forma yönlendirebilir. Hosting tarafında şunları sağlayın:
- Ödeme eklentisini yalnızca resmî kaynaktan kurun ve güncel tutun.
- Yönetici hesaplarında iki adımlı doğrulama ve güçlü parola kullanın; yetkileri gereken kişilerle sınırlayın.
- Sipariş bildirimleri ve fatura e-postaları için kimlik doğrulamalı SMTP kullanın; SmartHost SMTP relay bu iletilerin spam klasörüne düşme olasılığını azaltır, kurulum WordPress SMTP ayarları rehberinde.
Ne zaman kurumsal hosting ya da VPS’e geçmelisiniz?
Optimizasyondan sonra da kaynak sınırına takılıyorsanız büyüme zamanı gelmiştir; WooCommerce hosting kararını sipariş sayısından çok sunucunun verdiği sinyallere göre verin:
| Sinyal | Ne anlatır | Önerilen adım |
|---|---|---|
| Kampanyada ödeme adımı yavaşlıyor ya da 503/508 hatası | Eş zamanlı PHP işlem sınırı doluyor | Kaynakları ayrılmış bir kurumsal hosting paketine geçiş |
| Yönetim paneli ve raporlar sürekli yavaş | Veritabanı ve bellek yetersiz | HPOS ve nesne önbelleği, ardından üst paket |
| Zamanlanmış eylem kuyruğu hiç erimiyor | Arka plan işleri için işlemci süresi yetmiyor | Gerçek cron; sürerse VPS |
| Redis, özel PHP ayarı ya da ayrı arama servisi gerekiyor | Sunucu düzeyinde yapılandırma ihtiyacı | Tam yetkili VPS ya da ayrılmış çekirdekli VDS |
Paketinizdeki limitlerin ne anlama geldiğini hosting kaynak limitleri rehberinden okuyabilirsiniz. Geçişten önce mağazanın bir kopyasını yeni ortamda yük altında denemek, yeni paketin kampanya gününü kaldırıp kaldırmayacağını gösterir.
Sık Sorulan Sorular
WooCommerce paylaşımlı hostingde çalışır mı?
Çalışır; az ürünlü ve günde birkaç sipariş alan bir mağaza için yeterli kaynaklı bir paylaşımlı paket iyi bir başlangıçtır. Belirleyici olan PHP sürümü, bellek sınırı, eş zamanlı işlem limiti ve nesne önbelleği desteğidir. Kampanya dönemlerinde ödeme adımı yavaşlıyor ya da zamanlanmış eylemler birikiyorsa ayrılmış kaynaklı bir pakete geçmeyi planlayın.
WooCommerce için ne kadar RAM gerekir?
Tek bir doğru sayı yoktur; ürün sayısı, eklenti yükü ve aynı anda alışveriş yapan ziyaretçi sayısı belirleyicidir. Pratikte WordPress bellek sınırını en az 256 MB yapın ve kaynak kullanım grafiğindeki tepe değerlere bakın. Kendi sunucunuzda MySQL ya da MariaDB, PHP-FPM ve Redis aynı belleği paylaştığı için toplam ihtiyacı bu servislerin toplamı olarak hesaplayın.
HPOS’u açınca eski siparişlerim kaybolur mu?
Hayır. Geçiş sırasında uyumluluk modu siparişleri eski tablolardan yeni HPOS tablolarına kopyalar ve iki depolamayı senkron tutar; senkronizasyon tamamlanmadan HPOS etkin depolama olarak seçilemez. Yine de geçişi önce test kopyasında deneyin, tam yedek alın ve sipariş eklentilerinizin HPOS uyumlu olduğunu ayarlar ekranındaki uyumluluk listesinden kontrol edin.
WooCommerce sepet sayfası neden önbelleğe alınmamalı?
Sepet, ödeme ve hesap sayfaları her ziyaretçiye özel içerik gösterir. Bu sayfalar önbelleğe alınırsa bir müşterinin sepeti ya da adres bilgisi başka bir ziyaretçiye sunulabilir, kuponlar ve fiyatlar yanlış görünebilir. Bu yüzden önbellek eklentileri ve sunucu kuralları bu sayfaları, sepette ürün olduğunu gösteren çerezleri ve AJAX isteklerini önbellek dışında bırakır.
WooCommerce mağazası için ayrı veritabanı sunucusu gerekir mi?
Çoğu mağaza için gerekmez; aynı sunucuda nesne önbelleği ve HPOS ile veritabanı yükü uzun süre yönetilebilir. Veritabanının sürekli en çok kaynak tüketen bileşen olduğu, raporların ve sipariş aramalarının yavaşladığı büyük mağazalarda ise veritabanını ayrı bir sunucuya almak web katmanını rahatlatır ve iki katmanı bağımsız büyütmenizi sağlar.
