WooCommerce Sitesi Taşıma: Sipariş ve Ödeme Ayarlarını Koruma

WooCommerce site taşıma işini normal bir WordPress taşıması sanıp başlayan çok kişi gördüm; hemen hepsi aynı yerde tökezledi. Sıradan bir blogda yedek alırsınız, aktarırsınız, DNS'i çevirirsiniz, olası bir kayıp en fazla iki yorumdur. Canlı bir mağazada ise yedeği aldığınız an ile DNS'in yayıldığı an arasındaki her dakikada gerçek para hareket eder: müşteri sipariş verir, banka ödemeyi onaylar, stok düşer, kargo etiketi basılır. O aradaki siparişler yeni sunucuya taşınmazsa, sistemde hiç olmamış gibi davranırlar — ama müşterinin kartından para çekilmiştir.

Bu yazıda canlı mağaza taşıma işini para ve sipariş kaybı olmadan yapmanın sırasını anlatacağım. Yedek alma ve dosya kopyalama kısmını kısa geçeceğim, çünkü onu her yerde bulabilirsiniz. Asıl üzerinde duracağım şeyler şunlar: yedekten sonra oluşan siparişlerin nasıl kurtarılacağı, ödeme sağlayıcı panelindeki webhook ve callback adreslerinin neden ayrı bir iş kalemi olduğu, sipariş numarası çakışmasının nasıl önleneceği ve stok senkronizasyonunun taşımadan sonra nasıl doğrulanacağı. Bunlar Türkçe kaynaklarda neredeyse hiç konuşulmuyor ama bir mağaza taşımasında kaybın kaynağı tam olarak burası.

WooCommerce Taşımasını Normal WordPress Taşımasından Ayıran Ne#

WooCommerce taşımasını zorlaştıran şey dosyalar değil, taşıma sırasında sitenin dışında da devam eden süreçlerdir.

Sıradan bir WordPress sitesinde tüm durum veritabanı ile dosya sisteminde durur. WooCommerce'de ise mağazanızın durumu üç ayrı yerde birden tutulur:

1. Kendi veritabanınız — siparişler, müşteriler, stok, kuponlar.
2. Ödeme sağlayıcısının sistemi — işlem kayıtları, iade durumları ve size geri bildirim gönderdiği webhook adresi.
3. Kargo, muhasebe ve pazaryeri entegrasyonları — çoğu, sizin sitenizin adresine periyodik istek gönderir.

Taşıma yaptığınızda yalnızca birinci grubu kopyalarsınız. İkinci ve üçüncü gruptaki sistemler ise hâlâ eski sunucuyla konuşmaya devam eder. Bu yüzden "site açıldı, ürünler görünüyor, tamamdır" demek yanıltıcıdır; asıl kırılma, ilk gerçek siparişte ortaya çıkar.

Aradaki farkı somutlaştıralım:

Son satır en önemlisidir. Bir mağaza taşımasının başarı ölçütü sitenin açılması değil, gerçek bir kartla verilen bir test siparişinin ödeme onayı, sipariş kaydı, stok düşümü ve bilgilendirme e-postası dahil eksiksiz tamamlanmasıdır.

Taşıma Öncesi Envanter: Neyi Not Almalısınız#

Taşımaya başlamadan önce mağazanın dışa bağlı her noktasını yazılı bir listeye dökmelisiniz, çünkü bunların yarısı taşıma sonrası elle güncellenecek.

Şu tabloyu bir dosyaya kopyalayıp doldurun; taşıma günü elinizde olsun:

Son satırı özellikle not edin, birazdan neden kritik olduğuna geleceğiz.

WooCommerce'in webhook listesini komut satırından da alabilirsiniz:

wp wc webhook list --user=1 --fields=id,name,status,delivery_url

Bu komutun çıktısı, sizin sitenizin dışarıya gönderdiği webhook'ları gösterir. Sağlayıcıların size gönderdiği callback adresleri ise bu listede değildir; onlar için ilgili sağlayıcının paneline bakmanız gerekir.

Sipariş Kaybı Olmayan Taşıma Planı#

Doğru sıra şudur: önce yeni sunucuyu tamamen hazırlayın, siteyi orada test edin, sonra mağazayı kısa bir süre için kapatıp son senkronizasyonu yapın ve ancak ondan sonra DNS'i çevirin.

Adım adım:

1. Yeni sunucuda ortamı kurun. PHP sürümü, bellek limiti, gerekli PHP eklentileri ve veritabanı hazır olsun. WooCommerce özellikle mysqli, curl, gd, intl ve soap eklentilerine bağımlı entegrasyonlarla çalışır.
2. İlk kopyayı alın ve yeni sunucuya kurun. Bu kopya "sıcak" değildir, sadece yapıyı taşır. Manuel yöntemin ayrıntıları için WordPress manuel site taşıma yazısındaki dosya ve veritabanı adımlarını uygulayın.
3. DNS'e dokunmadan yeni sunucuda test edin. Bilgisayarınızın hosts dosyasına yeni sunucunun IP'sini yazarak siteyi gerçek alan adıyla, ama yalnızca sizin bilgisayarınızda açabilirsiniz. Yöntem için hosts dosyası ile site test etme yazısına bakın. Bu adım pazarlık konusu değildir; ürün sayfası, sepet ve ödeme adımını burada görmeniz gerekir.
4. Taşıma penceresini seçin. Mağazanızın Analytics verisinden en az sipariş alınan saat dilimini bulun. Türkiye'deki çoğu mağazada bu saat 04:00–06:00 arasıdır.
5. Bakım moduna alın. Aşağıda ayrıntısı var.
6. Son senkronizasyonu yapın. Sadece değişen veriyi aktarın.
7. DNS'i çevirin, eski sunucuyu kapatmayın.
8. Webhook ve callback adreslerini güncelleyin.
9. Uçtan uca test siparişi verin.
10. En az yetmiş iki saat iki sunucuyu da izleyin.

Bu on adımın altı ile dokuz arası, mağaza taşımasını normal taşımadan ayıran kısımdır ve aşağıda tek tek açıyorum.

Bakım Modu: Sipariş Penceresini Doğru Kapatmak#

Bakım modunun amacı ziyaretçiye özür dilemek değil, yedek aldıktan sonra yeni sipariş oluşmasını engellemektir.

Burada en yaygın hata, bakım modunu yanlış katmanda uygulamaktır. Bir bakım modu eklentisi genellikle sadece sayfayı gizler; sepet, ödeme geri dönüşü ve REST API çalışmaya devam eder. Yani müşteri sepette ilerleyemez ama banka onay bildirimi hâlâ girer ve sipariş oluşur.

Daha kontrollü yöntem, mağazayı sipariş alamaz hâle getirmektir. WooCommerce'de bunun için ödeme yöntemlerini geçici olarak kapatmak en temiz çözümdür:

# Aktif ödeme yöntemlerini listele
wp wc payment_gateway list --user=1 --fields=id,title,enabled

Bunun yanında dosya düzeyinde tam kapatma isterseniz .maintenance dosyası WordPress'in kendi mekanizmasıdır:

echo '<?php $upgrading = time(); ?>' > /home/kullanici/public_html/.maintenance

Bu dosya varken WordPress her isteğe bakım ekranı döndürür. İşiniz bitince silmeniz gerekir; unutulursa site kapalı kalır. WordPress'in kendi güncelleme mekanizması da aynı dosyayı kullanır, dolayısıyla bir güncelleme yarıda kaldıysa bu dosya orada takılı kalmış olabilir.

Bakım ekranının 503 durum kodu ile sunulmasına dikkat edin. Google 503'ü "geçici, sonra tekrar gel" olarak okur ve sayfayı dizinden düşürmez. 200 kodu ile sunulan bir bakım sayfası ise Google'a "sayfanın içeriği artık budur" der ve taşıma sonrası sıralama sorunlarına yol açar; bu konudaki tanı sırası için site taşıma sonrası SEO trafik kaybı yazısı ayrıntılı.

Bakım penceresini olabildiğince kısa tutun. İyi hazırlanmış bir taşımada bu pencere on beş dakikayı geçmez.

Son Senkronizasyon: İki Yedek Arasındaki Siparişler#

Sipariş kaybının tek gerçek kaynağı, ilk yedek ile geçiş anı arasında oluşan kayıtlardır ve bunlar ancak ikinci bir kısmi aktarımla kurtarılır.

Senaryo şu: Cuma günü yedek aldınız, hafta sonu yeni sunucuda test ettiniz, Pazartesi gece DNS'i çevirdiniz. Bu üç günde eski sitede altmış sipariş oluştu. Yeni sunucudaki veritabanında bu altmış sipariş yok. Müşteriler ödeme yaptı, ürün stoktan düştü, kargo süreci başladı — ama yeni sistemde hiçbiri görünmüyor.

Çözüm, bakım moduna aldıktan sonra ikinci bir veritabanı dökümü almak ve tam kopyayı yeniden yüklemektir. Kısmi tablo aktarmaya kalkışmak cazip görünür ama tehlikelidir, çünkü bir siparişin verisi tek tabloda durmaz.

En güvenli yöntem şudur:

# Bakım moduna aldıktan SONRA, eski sunucuda:
mysqldump -u kullanici -p --single-transaction --quick veritabani > son_hal.sql
gzip son_hal.sql

# Yeni sunucuda, mevcut veritabanını boşaltıp yükleyin:
gunzip < son_hal.sql.gz | mysql -u kullanici -p yeni_veritabani

--single-transaction bayrağı InnoDB tablolarında tutarlı bir anlık görüntü alır ve tabloları kilitlemez; canlı bir mağazada bu bayrağı atlamayın.

Yükleme sonrası site adresini yeni ortama göre güncellemeniz gerekebilir. Arama-değiştirme işlemini asla düz SQL ile yapmayın — WooCommerce ayarlarının bir kısmı serileştirilmiş (serialized) veri olarak saklanır ve düz REPLACE bu yapıyı bozar, ayarlar sessizce kaybolur. Doğru araç WP-CLI'nin kendi komutudur:

wp search-replace 'https://eski.alanadi.com' 'https://alanadi.com' --all-tables --precise --report-changed-only

Önce --dry-run ile çalıştırıp kaç satırın etkileneceğini görmenizi öneririm.

Alternatif senaryo: Bazı mağazalarda toplam kapalı kalma süresi hiç kabul edilemez. Bu durumda sipariş penceresini kapatmak yerine, taşıma sonrası eski sunucuda oluşmuş siparişleri WooCommerce'in dışa/içe aktarma araçlarıyla elle taşımak gerekir. Bu yöntem sipariş numaralarını korumaz ve ödeme kayıtlarıyla eşleştirme el emeği ister; ancak birkaç siparişlik bir fark için pratiktir.

Ödeme Sağlayıcı Webhook ve Callback Adresleri#

Taşımadan sonra ödeme akışının yarısı sessizce kırılır, çünkü sağlayıcı size hâlâ eski sunucunun bilgisi üzerinden dönüş yapmaya çalışır.

Bir online ödemenin akışı iki yönlüdür. Müşteri kart bilgisini sağlayıcıda girer, sağlayıcı sonucu iki kanaldan bildirir: kullanıcıyı bir adrese geri yönlendirerek (return / success URL) ve sunucudan sunucuya bir bildirim göndererek (callback / notification / webhook URL). İkincisi görünmezdir ama siparişin "ödendi" durumuna geçmesini sağlayan asıl mekanizmadır.

Taşımadan sonra bu iki adres genellikle şu nedenlerle çalışmaz:

• Alan adı değiştiyse adres tamamen yanlıştır.
• Alan adı aynı ama sağlayıcı panelinde IP kısıtlaması tanımlıysa, bildirim yeni sunucunun IP'sinden geldiği için reddedilir.
• Sağlayıcı bildirimi eski IP'ye gönderiyorsa (bazı sistemler alan adı yerine kayıtlı IP'yi kullanır) bildirim eski sunucuya düşer.
• SSL sertifikası yeni sunucuda henüz kurulmamışsa sağlayıcı bağlantıyı kurmaz ve bildirim düşer.

Belirti çok tipiktir: müşteri ödemeyi yapar, banka ekranı başarılı der, ama sipariş "Ödeme bekleniyor" durumunda kalır. Bu tabloyu görüyorsanız hata sitenizde değil, callback zincirindedir.

Kontrol sırası:

1. Sağlayıcı panelinde tanımlı callback/return adreslerini yeni ortama göre güncelleyin.
2. IP beyaz listesi varsa yeni sunucunun çıkış IP'sini ekleyin, eskisini bir süre daha bırakın.
3. Yeni sunucuda SSL'in geçerli ve zincirin eksiksiz olduğundan emin olun:

curl -sI https://alanadiniz.com/ | head -1
openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com < /dev/null 2>/dev/null | grep -E "Verify return code"

4. Sunucu güvenlik duvarının sağlayıcının bildirim IP'lerini engellemediğini doğrulayın. Yeni kurulmuş bir sunucuda fail2ban veya WAF kuralları, arka arkaya gelen POST isteklerini saldırı sanıp engelleyebilir.
5. Bildirimin gerçekten geldiğini erişim kaydından doğrulayın:

grep -i "callback\|notify\|wc-api" /var/log/nginx/access.log | tail -20

WooCommerce'in ödeme geri bildirimleri genellikle /?wc-api=... biçiminde bir adrese düşer; bu satırları görüyorsanız bildirim ulaşıyor demektir, sorun işlemededir.

Türkiye'de yaygın kullanılan sanal pos entegrasyonlarının kendi ayar ekranları vardır; taşımadan sonra bu ekranlardaki mağaza anahtarı, gizli anahtar ve bildirim adresi alanlarını tek tek gözden geçirin. Entegrasyonun kurulum mantığını hatırlamak isterseniz WooCommerce PayTR entegrasyonu yazısı akışı adım adım gösteriyor.

Sipariş Numarası Çakışması ve Stok Tutarsızlığı#

Taşıma sonrası en sinsi hasar, iki farklı siparişin aynı numarayı almasıdır ve bu genellikle haftalar sonra muhasebe tarafında ortaya çıkar.

Neden olur? WooCommerce varsayılan olarak sipariş numarası için WordPress'in gönderi kimliği sayacını kullanır. Eğer eski sunucuda taşıma sonrası birkaç sipariş daha oluştuysa ve siz o siparişleri sonradan elle eklediyseniz, ya da iki sunucu bir süre paralel çalıştıysa, aynı numara iki farklı satışa verilmiş olur. Sonuç: fatura eşleşmez, kargo takibi yanlış siparişe bağlanır, iade süreci kilitlenir.

Önlemek için taşımadan hemen önce son sipariş numarasını not alın:

SELECT MAX(ID) FROM wp_posts WHERE post_type = 'shop_order';

Yeni sipariş depolama yapısını kullanan kurulumlarda aynı bilgi kendi tablosundan okunur:

SELECT MAX(id) FROM wp_wc_orders;

Taşıma sonrası ilk gerçek siparişin numarası bu değerin üstünde olmalıdır. Altında bir numara görüyorsanız, veritabanı tam aktarılmamıştır ve derhal durup son senkronizasyonu tekrarlamanız gerekir.

Stok tarafında da benzer bir kontrol yapın. Eski sunucuda taşıma penceresinden önce satılan ürünlerin stok düşümü yeni veritabanına yansımış olmalıdır. En hızlı doğrulama, en çok satan beş ürünün stok adedini iki tarafta karşılaştırmaktır:

SELECT p.post_title, pm.meta_value AS stok
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID
WHERE pm.meta_key = '_stock' AND p.post_type = 'product'
ORDER BY p.post_modified DESC LIMIT 5;

Sayılar tutmuyorsa, aradaki fark tam olarak kaybettiğiniz sipariş sayısına işaret eder. Stok yönetiminin WooCommerce tarafındaki mantığını tazelemek isterseniz WooCommerce stok yönetimi yazısı ayrıntılı anlatıyor.

Bir de Action Scheduler var. WooCommerce, stok senkronizasyonu, abonelik yenileme ve e-posta kuyruğu gibi işleri bu zamanlanmış görev altyapısıyla yürütür. Taşımadan sonra yeni sunucuda cron çalışmıyorsa bu görevler birikir ve mağaza "sessizce" bozulur: sipariş durumları güncellenmez, e-postalar gitmez. Doğrulama için:

wp action-scheduler list --status=pending --per-page=5

Bekleyen görev sayısı sürekli artıyorsa, sunucudaki cron yapılandırmasını gözden geçirin.

Taşımadan Sonra İlk 24 Saatte Yapılacak Doğrulamalar#

Taşıma, DNS çevrildiğinde değil, uçtan uca test siparişi başarıyla tamamlandığında biter.

İlk 24 saatte şu listeyi sırayla uygulayın:

1. Gerçek kartla küçük tutarlı bir test siparişi verin. Ödeme onayı geldi mi, sipariş "İşleniyor" durumuna geçti mi, stok düştü mü, müşteriye ve size bilgilendirme e-postası gitti mi — dördünü de tek tek doğrulayın.
2. Ödeme yöntemlerinin hepsini test edin. Kredi kartı çalışıyor olabilir ama kapıda ödeme veya havale seçeneği kapalı kalmış olabilir.
3. E-posta gönderimini kontrol edin. Yeni sunucunun IP'si mail açısından itibarsızsa siparişi onay maili spam'a düşer. SMTP eklentisi kullanıyorsanız ayarlarının taşındığını doğrulayın.
4. Kargo ve fatura entegrasyonlarını tetikleyin. Test siparişini kargoya verilmiş olarak işaretleyip entegrasyonun çalışıp çalışmadığına bakın.
5. Eski sunucunun kayıtlarını izleyin. Oraya hâlâ istek düşüyorsa, ya DNS tam yayılmamıştır ya da bir dış sistem hâlâ eski IP'yi kullanıyordur. Eski sunucuyu en az yetmiş iki saat kapatmayın.
6. Sipariş numarası devamlılığını kontrol edin. İlk yeni siparişin numarası, taşımadan önce not aldığınız değerin üstünde mi?
7. Kuponları ve KDV/vergi ayarlarını doğrulayın. Vergi tabloları içe aktarım sırasında en sık eksik kalan verilerden biridir.

Bu yedi maddeyi geçmeden taşımayı tamamlanmış saymayın. Mağazanın "açık" görünmesi ile "satış yapabiliyor" olması iki ayrı durumdur ve aradaki fark doğrudan ciro demektir.

Sıkça Sorulan Sorular#

WooCommerce mağazasını taşırken sipariş kaybı nasıl önlenir#

Sipariş kaybını önlemenin tek güvenilir yolu, mağazayı kısa süreliğine sipariş alamaz hâle getirip son bir tam veritabanı dökümü almaktır. Önceden alınan yedekle geçiş anı arasındaki her sipariş, o dökümü almadığınız takdirde yeni sistemde bulunmaz. Ödeme yöntemlerini kapatarak veya bakım moduna alarak bu pencereyi kapatın, ardından dökümü alıp yeni sunucuya tam olarak yükleyin. Kısmi tablo aktarımı denemeyin; bir siparişin verisi birden fazla tabloya dağılmıştır.

Taşıma sırasında mağazayı kaç saat kapatmam gerekir#

İyi hazırlanmış bir taşımada mağazanın kapalı kalma süresi on beş dakikanın altındadır. Uzun süren kısımlar — dosya aktarımı, yeni sunucu kurulumu, test — mağaza açıkken önceden yapılır. Kapalı kalması gereken tek aşama, son veritabanı dökümünün alınıp yüklenmesi ve DNS'in çevrilmesidir. Kapanma süresi saatler alıyorsa, hazırlık adımlarını taşıma gününe bırakmışsınız demektir.

DNS değişikliği sırasında iki sunucuda birden sipariş oluşabilir mi#

Evet, oluşabilir ve bu taşımalardaki en tehlikeli durumdur. DNS yayılımı sırasında bazı ziyaretçiler hâlâ eski sunucuya, bazıları yeni sunucuya yönlenir. İki tarafta da mağaza sipariş kabul ediyorsa, eski sunucuda oluşan siparişler yeni veritabanında hiç görünmez ve sipariş numaraları çakışır. Bunu önlemek için DNS çevrildikten sonra eski sunucudaki mağazayı sipariş alamaz hâle getirin, ama sunucuyu kapatmayın.

Ödeme sonrası sipariş ödeme bekleniyor durumunda kalıyor, neden#

Bu belirti neredeyse her zaman ödeme sağlayıcısının callback bildiriminin sitenize ulaşamamasından kaynaklanır. Müşteri ödemeyi yapar, banka onaylar, ancak sağlayıcının sunucudan sunucuya gönderdiği bildirim ya eski adrese gider ya IP kısıtlamasına takılır ya da güvenlik duvarı tarafından engellenir. Sağlayıcı panelindeki bildirim adresini ve IP beyaz listesini güncelleyin, ardından sunucunun erişim kayıtlarında bildirim isteğinin düşüp düşmediğini kontrol edin.

Taşımadan sonra ürün görselleri kayboldu, ne yapmalıyım#

Görsellerin kaybolmasının iki tipik nedeni vardır: yükleme klasörünün eksik aktarılması ve veritabanındaki adreslerin eski alan adını göstermeye devam etmesi. Önce sunucuda yükleme klasörünün gerçekten dolu olduğunu doğrulayın; FTP aktarımı büyük klasörlerde sıklıkla yarıda kesilir. Klasör doluysa sorun adreslerdedir ve serileştirilmiş veriyi bozmayan bir arama-değiştirme aracıyla düzeltilmelidir. Dosya izinlerinin de doğru olduğundan emin olun, aksi hâlde dosya var ama sunucu okuyamıyor olabilir.

Aynı sunucuda hem eski hem yeni mağazayı bir süre çalıştırabilir miyim#

Teknik olarak çalıştırabilirsiniz ancak ikisinin de sipariş kabul etmesine izin vermemelisiniz. Paralel çalışma yalnızca doğrulama amacıyla, eski taraf salt okunur hâldeyken anlamlıdır. İki mağaza da satış yaparsa stok iki ayrı yerde düşer, sipariş numaraları çakışır ve müşteri iletişimi karışır. Doğru yaklaşım, geçişten sonra eski mağazada ödeme yöntemlerini kapatıp yalnızca kayıtlara erişim için ayakta bırakmaktır.

WooCommerce REST API anahtarlarını yeniden oluşturmam gerekir mi#

Alan adı değişmediyse anahtarları yeniden oluşturmanız gerekmez, veritabanıyla birlikte taşınırlar. Ancak anahtarları kullanan dış uygulamaların — mobil uygulama, pazaryeri entegrasyonu, muhasebe yazılımı — yeni sunucuya erişebildiğini test etmelisiniz. Bu uygulamalar bazen alan adı yerine IP adresi üzerinden bağlanacak şekilde yapılandırılmıştır ve taşımadan sonra sessizce kopar. Güvenlik açısından şüpheniz varsa anahtarları yenileyip bağlı uygulamaları tek tek güncellemek daha temizdir.

Taşıma sonrası e-posta bildirimleri gitmiyorsa nereden başlamalıyım#

Önce sunucudan bir test maili gönderip gerçekten çıkıp çıkmadığını doğrulayın, sonra teslimat tarafına bakın. Yeni sunucularda en sık görülen iki neden, sunucunun kendi posta hizmetinin yapılandırılmamış olması ve yeni IP adresinin alıcı tarafından güvenilmez bulunmasıdır. Kalıcı çözüm, mağaza e-postalarını kimlik doğrulamalı bir SMTP servisi üzerinden göndermek ve alan adınıza SPF, DKIM, DMARC kayıtlarını tanımlamaktır. Ayrıca zamanlanmış görevlerin çalıştığını kontrol edin; WooCommerce bazı e-postaları kuyruğa alarak gönderir.

Kapanış#

Bir WooCommerce mağazasının taşınmasında zor olan kısım dosya kopyalamak değil, taşıma anında sitenin dışında devam eden süreçleri yönetmektir. Yedek ile geçiş arasındaki siparişleri son bir tam dökümle kurtarmak, ödeme sağlayıcısının callback adresini ve IP kısıtını güncellemek, sipariş numarası devamlılığını doğrulamak ve stok tutarlılığını kontrol etmek — bu dördü yapılmadığı sürece taşıma tamamlanmış sayılmaz. Sitenin açılıyor olması hiçbir şey kanıtlamaz; kanıt, gerçek bir kartla verilen ve dört aşamayı da geçen bir test siparişidir.

Canlı bir mağazayı kendi başınıza taşımak istemiyorsanız site taşıma hizmetimiz aktarımı sipariş penceresi ve DNS geçişi dahil planlı biçimde üstlenir. Mağazanız trafik ve sipariş yoğunluğu nedeniyle mevcut sunucuyu zorluyorsa e-ticaret hosting paketleri veya kaynakları size ayrılmış bir VDS sunucu daha kararlı bir zemin sağlar; bir mağazada taşıma sonrası ilk günlerin sorunsuz geçmesi, çoğu zaman sunucunun yoğun saatteki yükü kaldırıp kaldıramamasına bağlıdır.