E-ticaret kurulum hataları, çoğu zaman eksik kabul testi veya belirsiz sorumluluk nedeniyle yayına taşınır. Tema, ürün aktarımı, ödeme ve URL geçişi ayrı ayrı çalışıyor görünebilir; fakat gerçek müşteri görevi boyunca birleşmeleri gerekir. Bu rehber yaygın hata türlerini onları ortaya çıkaracak kontrollerle eşleştirir.
Katalog sorununu kaynağı, aktarımı ve görünümü ayırarak bulun
SKU, varyant, paket adedi veya görsel yanlış alana aktarılabilir. Toplam ürün sayısının doğru olması bütün ürünlerin doğru olduğu anlamına gelmez. Tek ürün, çok varyant, farklı paket ve stok dışı örneği seçip müşteri görünümünde karşılaştırın. Veri hatasını sadece hedef panelde düzeltmeyin; asıl kaynağı da güncelleyin.
Temsili kabul: üç bedenli üründe her seçim gerçek fiyat ve stokla eşleşecek; satılamayan varyant için yanlış satın alma vaadi görünmeyecek. Bu koşul ekran görüntüsünden daha güçlü davranış kontrolüdür.
Hatanın oluştuğu katmanı belirleyin
Temsili örnekte müşterinin seçtiği mavi varyant sepette siyah görünür. Önce kaynak dosyadaki varyant anahtarı, sonra mağazadaki eşleme, ardından seçimin sepet satırına aktarılması incelenir. Üç katmanı aynı anda rastgele değiştirmek sorunu gizleyebilir. Tek değişiklik ve tekrar test yöntemiyle hangi alanın etkili olduğunu kaydedin.
Yanlış veriyi sadece hedef panelde düzeltmek sonraki aktarımda geri getirebilir. Kaynağın sahibi ve düzeltme yöntemi belli olmalıdır. Toplam kayıt sayısı, doğru eşleşme kontrolünün yerine geçmez. Zor örneklemde çok varyant, boş alan, paket adedi ve stok dışı ürün bulunmalıdır; yalnız kusursuz demo kayıtları kabul için yeterli değildir.
Hata yolunu test etmeden başarı yolunu tamamlanmış saymayın
Ödeme kabulünü denemek tek başına yeterli değildir. Ret, ağ kesilmesi, tekrar tıklama ve siparişin geri açılması incelenmelidir. Yanlış hata metni veya geri bildirim eksikliği müşteriyi aynı işlemi tekrar yapmaya yöneltebilir. Mağaza kaydı ve ödeme sağlayıcısı cevabı birlikte değerlendirilmelidir.
Uygulama, ödeme kabulü ve müşteri bildirimi için hangi kaydın esas olduğu yazılmalıdır. Form veya webhook kabulü gelen kutusu teslimi değildir. Test sağlayıcısıyla geçen senaryo canlı hesap onayı sayılmamalıdır.
Ödeme ret mesajının anlaşılır olması kadar müşterinin güvenli biçimde devam edebilmesi önemlidir. Aynı işlemi tekrar yapmasının ikinci tahsilata yol açıp açmadığı sağlayıcı kaydıyla incelenir. Temsili ağ kesintisinde tarayıcı sonucu belirsizdir; müşteriye yeniden ödeme önermeden işlem referansı araştırılmalıdır. Bu mevcut mağazanızda hata bulunduğu iddiası değil, test senaryosudur.
Form kabulü, bildirim ve teslim ayrı sonuçlardır
Teklif formu başarılı mesaj gösterebilir fakat e-posta sağlayıcısı isteği reddetmiş olabilir. Uygulama kabulü, sağlayıcı kabulü ve gelen kutusu teslimi ayrı kanıtlarla raporlanmalıdır. Gizli değerleri kontrol raporuna yazmadan tanımlı/eksik durumu ve yetkili sorumluyu belirleyin. Test alıcısıyla gerçek teslim kontrolünü yetkili ekip yürütür.
URL hatasını yalnız durum koduyla değerlendirmeyin
Geçişte bütün eski adresleri HTTP 200 dönen ana sayfaya yönlendirmek içerik devamlılığını sağlamaz. Ürün, hizmet, arşiv ve medya adreslerini gerçek eşdeğerleriyle eşleştirin. Eşdeğer bulunamıyorsa sayfanın gerçek içeriğini koruma, açık kaldırma veya uygun 404/410 kararı değerlendirilmelidir.
Google site taşıma kaynağı URL envanteri ve takip için resmî başvurudur. Kalıcı yönlendirme çalışsa bile trafik ve sıralamanın kesin korunacağı söylenemez. Gerçek hedefin içeriğini de test edin.
Eski ürün bağlantısı HTTP 200 veren ilgisiz bir kategoriye gidiyorsa teknik erişim vardır fakat içerik devamlılığı yoktur. Beklenen hedefi ve sayfanın gerçek içeriğini birlikte kontrol edin. Yönlendirme zincirleri, yanlış canonical ve sitemap dışı önemli adresler ayrı kaydedilmelidir. Eşdeğer bulunmayan sayfada karar bilinçli verilmelidir; tüm eksikleri ana sayfaya yığmak çözüm değildir.
Eski görsel adresleri de trafik veya dış bağlantı taşıyabilir. Dosyayı taşımak, yeni sayfada başka fotoğraf göstermekle aynı şey değildir. Özgün dosya bulunamadığında eksikliği açık raporlayın; geçici çizimi özgün görsel diye sunmayın. İçerik kaybının etkisini kaynak arşivi ve sayfa bağlamıyla değerlendirin.
Mobil kontrolde gerçek görev ve hata mesajı kullanın
Sayfa mobilde güzel görünürken ürün filtresi, varyant seçimi veya hata mesajı çalışmayabilir. Klavye, küçük ekran ve dokunmatik seçimle görev yürütün. Tablo yatay kayacaksa kaydırma alanı sayfanın içine taşmamalı; önemli metin dar hücrelerde parçalanmamalıdır.
Erişilebilir alan ve hata yönetimi için W3C form rehberleri kullanılabilir. Bu kontrol tek başına kapsamlı erişilebilirlik uygunluğu onayı vermez; görsel incelemeyi işlevsel testle tamamlar.
Tablonun kendi içinde yatay kayması bazı içeriklerde uygundur; bütün sayfanın yana taşması farklı bir kalite sorunudur. Başlık, ilk sütun ve açıklamanın okunabilirliğini gerçek dar ekranda değerlendirin. Küçük hücreye çok uzun metin koymak, taşma olmasa da karşılaştırmayı zorlaştırabilir. Gerektiğinde tablo içeriği sadeleştirilir; önemli teknik koşul silinmez.
Telefon klavyesi açıldığında form düğmesi ve hata açıklaması erişilebilir mi? Sabit başlık hedeflenen bölümü kapatıyor mu? Ürün görseli geç yüklenirken içerik yer değiştiriyor mu? Bu sorular ekran görüntüsünden tek başına yanıtlanamaz; sayfa üzerinde etkileşim ve yükleme kontrolü gerekir.
Hata dosyasını sahiplik ve geri dönüş kararıyla kapatın
Alan adı, ödeme hesabı veya mağaza lisansı dış kişinin kişisel hesabında kalırsa devir ve bakım güçleşebilir. İşletme sahipliği, rol bazlı erişim ve çalışma sonu yetki kaldırmayı planlayın. Güncelleme sonrası ödeme, katalog ve ölçüm testlerini kimin tekrarlayacağını yazın.
- Kaynak ve veri yedeği gerçek geri açma kontrolünden geçti mi?
- Yayın değişikliği mevcut posta DNS’ini etkiliyor mu?
- Açık sağlayıcı onayı veya secret yapılandırması kaldı mı?
- Rollback’in başlatma koşulu ve sorumlusu belirli mi?
Teknik proje rehberi kabul kapılarını, SEO kontrol listesi indeksleme tarafını tamamlar. Kurulum hizmeti görüşmesinde testleri ve istisna kabulünü kapsamın parçası yapın. Teslim raporu hangi hatanın hangi kanıtla giderildiğini göstermelidir.
Her bulgu için dört alan yeterli bir başlangıçtır
- Tekrarlama: hangi adres, veri ve adımla oluşuyor?
- Etki: ödeme, veri, erişim veya görünümde neyi bozuyor?
- Çözüm: hangi değişiklik yapıldı, hangi kanıtla doğrulandı?
- Sahip: kim kabul etti, açık istisna ne zaman değerlendirilecek?
Çözümden sonra yalnız hatalı adımı değil komşu işlevi de kontrol edin. Varyant düzeltmesi fiyatı, form değişikliği hata mesajını, yönlendirme düzeltmesi canonical tercihini etkileyebilir. Gereksiz kapsam genişletmeden ilgili regresyonu test edin. Açık kalan kritik bağımlılığı raporda başarı işaretiyle kapatmayın; yayın kararı gerçek kanıt ve etkisi değerlendirilmiş istisnalarla verilmelidir.
Geri dönüşün kendisini de test kapsamına alın
Eski dosyaya dönmek yeni siparişi korumaz
Temsili bir güncellemede eski tema geri yüklenebilir fakat veri tabanındaki yeni alan değişmiştir. Başka durumda yedekten sonraki siparişler ve tahsilatlar oluşmuştur. Bu iki senaryonun geri dönüş yöntemi aynı değildir. Kod, veri ve dış sağlayıcı işlemleri ayrı değerlendirilmelidir; “yedek var” cümlesi tek başına kurtarma kanıtı değildir.
Yedek dosyasının açılabildiği, gerekli medya ve yapılandırmayı içerdiği, yetkili kişinin erişebildiği güvenli bir ortamda kontrol edilmelidir. Canlı DNS veya ödeme üzerinde yetkisiz prova yapılmaz. Geri dönüş kararı için hangi hata düzeyinin yeterli olduğu, kimin karar verdiği ve yeni siparişlerin nasıl mutabık tutulacağı önceden belirlenir.
Hata düzeltildikten sonra kayıt kapanırken etkilenmiş müşteriler veya işlemler de araştırılır. Teknik sorun giderilmiş olabilir fakat yanlış fiyatlı sipariş, eksik bildirim veya çift paket ayrı operasyon işi bırakabilir. Bunları yazılım düzeltmesinin otomatik çözdüğünü varsaymayın. Kapanış dosyası hem yeni davranışın testini hem geçmiş etkinin sorumlusunu gösterdiğinde gerçekten kullanılabilir hale gelir.
