Her panosu yolunda görünen bir mağaza hayal edin. Ana sayfa indekslenmiş, Lighthouse yeşil ve yapılandırılmış veri doğrulayıcısı hiçbir hata göstermiyor. Ama tam da o anda, Google Shopping’deki fiyat sepetteki fiyatla uyuşmuyor, mobil filtre çekmecesi klavye kullanıcılarını tuzağa düşürüyor ve her satın alma iki kez kaydediliyor.
Bunların hiçbiri hızlı bir sağlık kontrolünde ortaya çıkmaz. Çünkü bir çevrimiçi mağaza, sadece sayfalardan oluşan basit bir koleksiyon değil, birbirine bağlı bir sistemdir. Ürün verileri sayfaya, yapılandırılmış veriye ve alışveriş akışlarına (feed) akar. Script’ler ve üçüncü taraf etiketleri her şeyin ne kadar hızlı yükleneceğini belirler. Ödeme adımı ilgiyi gelire dönüştürür ve analitiğin tüm yolculuğu doğru şekilde kaydetmesi beklenir. Bir parça bozulduğunda, sessizce diğer her şeyi çarpıtabilir.
İşte bu yüzden faydalı bir e-ticaret denetimi site haritasını değil, alışverişçiyi takip eder. Aşağıdaki kontrol listesi mağazanın keşfedilmesiyle başlar ve tamamlanmış bir siparişle biter. Size her biri kanıtı, bir sorumlusu ve düzeltildiğinin nasıl test edileceği net olan, önem sırasına dizilmiş gerçek sorunlardan oluşan bir liste verir.
Bu denetim ne zaman yapılmalı ve sıralama neden önemli
Yeni bir e-ticaret müşterisini devraldığınızda, bir yeniden tasarım veya platform taşımasından sonra, büyük bir büyüme atağı öncesinde ya da rutin bir kontrol mağaza genelinde bir gerileme ortaya çıkardığında tam denetimi yapın. Hafif bir geçiş için üç ila altı saat, her önemli şablonu düzgün test eden standart bir denetim için bir iki gün ayırın. Log, feed veya analitik üzerine derin incelemeler genellikle ayrı zaman gerektirir.
Bu sıralama bilinçlidir. Google kategori sayfalarını indeksleyemiyorsa dönüşüm sürtünmesini değerlendirmenin bir anlamı yoktur; satın alma etiketi iki kez tetikleniyorsa huni raporuna güvenmenin de bir anlamı yoktur.
İki kez kaydedilen bir satın alma etkinliği daha fazla satışın kanıtı değildir ve Google’ın gördüğü fiyat sepetteki fiyattan farklıysa hızlı bir ürün sayfası da sağlıklı değildir. Bu yüzden denetim aşamalar halinde ilerler. İlk keşifle başlar, ardından ürün gerçeğine, hıza ve satın almanın kendisine geçer; ancak ondan sonra ölçüme geçer.
Başlamadan önce ihtiyaç duyduklarınızı toplayın. Yani şunlara erişim:
- Search Console,
- Analytics,
- Etiket yöneticisi (tag manager),
- Katalog veya feed kaynağı,
- Merchant Center,
- siteye yapılan son değişikliklerin listesi.
Aşama 1: Arama motorları kataloğu bulabiliyor mu?
1. Tüm mağazayı temsil eden bir örneklem oluşturun
E-ticaret hatalarının çoğu ortak şablonlarda ve alışılmadık ürün durumlarında yaşar. Temiz bir ana sayfa size filtrelenmiş kategoriler, varyant mantığı, stokta olmayan ürünler veya ödeme adımı hakkında hiçbir şey söylemez. Bu yüzden doğru pazar, para birimi ve dilde canlı üretim sitesini test ettiğinizi doğrulayarak başlamalısınız. Ardından aşağıdakilerin her biri için en az bir URL seçin:
- ana sayfa
- öncelikli bir kategori
- daha derin bir kategori veya onaylanmış bir filtre sayfası
- tipik bir ürün
- varyantları olan bir ürün
- stokta olmayan veya üretimden kaldırılmış bir ürün
- bir dahili arama sonuçları sayfası, sonuç döndürmeyen bir tanesi dahil
- sepet, ödeme ve sipariş onayı sayfası
Riskli görünen her şablon için zor veya alışılmadık bir örnek ekleyin. Analitik açılış sayfası raporunuz ve bir katalog dışa aktarımı seçim yapmanıza yardımcı olur.
Her önemli şablon ve ödeme durumu için adlandırılmış bir test URL’si olduğunda ve test edemediğiniz her şey “test edilmedi” olarak işaretlendiğinde tamamsınız.
2. Taranabilirliği, indekslemeyi, canonical etiketlerini ve site haritalarını kontrol edin
Tarama yolu bozuksa, daha fazla ürün yayınlamak etkilenen URL sayısını çoğaltmaktan başka işe yaramaz. Karışık sinyaller sorunları teşhis etmeyi de zorlaştırır. Robots kuralları bir şey söyleyebilirken canonical etiketleri ve site haritası tamamen başka bir şey söyleyebilir.
robots.txt’yi, XML site haritalarını, yanıt kodlarını, robots meta etiketlerini ve başlıklarını, canonical etiketlerini, sayfalamayı ve dahili bağlantıları inceleyin. Google’ın örnek sayfalarınız için gerçekte hangi canonical’ı seçtiğini görmek üzere Search Console’daki URL Inspection özelliğini kullanın. Ardından site haritasını gerçekle karşılaştırın. Canlı, indekslenebilir ve 200 durumu döndüren sayfaları listeliyor olmalı; yönlendirmeler, hatalar, noindex’lenmiş sayfalar veya kopyalar değil.
Hedeflediğiniz açılış sayfaları 200 döndürdüğünde, taranabildiğinde, tutarlı bir canonical ve indeksleme politikası izlediğinde ve site haritasında göründüğünde tamamsınız. Önemli her dışlamanın bir açıklaması veya bir sorumlusu olmalı.
3. Bağlantıları takip edin: yönlendirmeler, hatalar ve JavaScript
Bir mağaza tarayıcıda eksiksiz görünebilirken tarayıcı botları ve yardımcı teknolojiler çok daha yetersiz bir sürüm görebilir. Kırık dahili bağlantıları, yönlendirme zincirlerini, döngüleri ve yumuşak (soft) 404’leri bulmak için bir tarayıcı çalıştırın. Ardından işlenmiş sayfayı ham HTML ile karşılaştırın. Ürün kartları, sayfalama, breadcrumb’lar ve kategori bağlantıları gerçek ve taranabilir olmalı; önemli içerik yalnızca JavaScript’e bağlı olmamalıdır.
Dahili bağlantılar doğrudan nihai hedeflerine işaret ettiğinde, hata sayfaları doğru durum kodunu döndürdüğünde ve öncelikli ürünler sonsuz kaydırmaya (infinite scroll) bağlı olmadan bulunabildiğinde tamamsınız.
4. Kategorileri, filtreleri, sayfalamayı ve site içi aramayı test edin
Kategori ve filtre sistemleri arama motorları için tarama tuzakları ve alışverişçiler için hayal kırıklığı yaratabilir. Bir sayfa teknik olarak indekslenebilir olduğu halde üzerindeki ürünlerin yarısı alakasızsa zayıf bir açılış sayfası olabilir.
Filtreleri masaüstünde ve mobilde deneyin. Çoklu seçimi, “tümünü temizle” seçeneğini, sonuç sayılarını, sıralamayı, sayfalamayı veya “daha fazla yükle” seçeneğini ve hiçbir sonuç döndürmeyen filtre kombinasyonlarını kontrol edin. Filtrelerin oluşturduğu URL’lere bakın ve bunları mağazanın indeksleme politikasıyla karşılaştırın. Uzun bir kategori metni bloğunun ürün ızgarasını ekranın alt kısmına itip itmediğine de dikkat edin.
Kontroller tutarlı davrandığında, rastgele filtre kombinasyonları kazara açılış sayfalarına dönüşmediğinde ve alışverişçiler yerlerini kaybetmeden bir filtreyi geri alabildiğinde tamamsınız.
İşinizi büyütmeye hazır mısınız?
Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.
Aşama 2: Ürün verileri doğruyu mu söylüyor?
5. Ürün kimliğini, fiyatı, stoğu ve varyantları uzlaştırın
Tek bir yanlış alan sadece alışverişçiyi yanıltmakla kalmaz, ödeme adımında bir uyuşmazlığa kadar gidebilir. Öte yandan veriler mükemmel biçimde biçimlendirilmiş olup yine de yanlış olabilir.
Birkaç temsili ürün için adı, markayı, SKU’yu, GTIN veya EAN’ı, seçili varyantı, fiyatı, para birimini, stok durumunu, görselleri ve temel özellikleri göründükleri her yerde karşılaştırın. Sayfada, yapılandırılmış veride, satıcı feed’inde, sepette ve ödeme adımında neyin gösterildiğini kontrol edin. İndirimli ürünleri, varyantları, stokta olmayanları, ön siparişleri ve üretimden kaldırılmış ürünleri de dahil edin.
Örneklenen bilgiler her yüzeyde birbiriyle eşleştiğinde ve marka ile üretici arasındaki fark gibi kasıtlı her farklılık veri modelinde açıkça belirtildiğinde tamamsınız.
6. Yapılandırılmış veriyi alışverişçilerin gördükleriyle karşılaştırarak doğrulayın
Yapılandırılmış veri ancak sayfayı doğru tanımladığında işe yarar. Bir doğrulayıcı, sayfa ve ödeme adımı ürünün mevcut olmadığını söylerken “InStock” değerini memnuniyetle kabul eder. Bu yüzden her ürün durumunu Google Rich Results Test veya Schema.org Validator üzerinden geçirmelisiniz. Ardından işaretlenmiş değerleri görünür içerikle ve kaynak feed ile karşılaştırın. Varyantlı ürünler için işaretleme yaklaşımınızın ve canonical kurulumunuzun sayfaların gerçekte nasıl oluşturulduğuyla uyuştuğunu kontrol edin.
Örneklenen uygun sayfalarda eksik zorunlu özellik olmadığında, işaretleme görünenle eşleştiğinde ve yorumlar ile puanlar yalnızca alışverişçiler onları o üründe görebildiğinde işaretlendiğinde tamamsınız.
Aşama 3: Mağaza gerçek alışverişçiler için hızlı mı?
7. Önce saha (field) verisinden Core Web Vitals metriklerini ölçün
Gerçek kullanıcı verileri ile tek bir Lighthouse çalıştırması farklı sorulara yanıt verir. Lighthouse bir sorunu yeniden üretmenize yardımcı olur ama gerçek alışverişçilerin geçip geçmediğini söyleyemez.
PageSpeed Insights ve Search Console’daki Core Web Vitals raporuyla başlayın. Saha verisinin tam olarak o URL için mi yoksa yalnızca tüm site için mi mevcut olduğunu not edin. Google’ın 75. yüzdelik dilimde ölçülen “iyi” eşikleri şunlardır:
- LCP (yükleme): 2,5 saniye veya altı
- INP (yanıt verebilirlik): 200 milisaniye veya altı
- CLS (görsel kararlılık): 0,1 veya altı
Mobil ve masaüstüne ayrı ayrı bakın. Saha verisi yoksa sonucu bilinmiyor olarak kaydedin ve laboratuvar sonuçlarını geçici sayın. Bilinmiyor, yeşil ile aynı şey değildir.
Her öncelikli şablonun cihaz başına bir saha kararı ya da açıkça belirtilmiş bir veri eksikliği olduğunda ve kaynak ile tarih aralığı kaydedildiğinde tamamsınız.
8. Sadece puanı değil, nedeni bulun
“Görsellerinizi sıkıştırın” veya “JavaScript’i azaltın” gibi genel tavsiyeler genellikle gerçek darboğazı kaçırır ve başarısız metriği hareket ettirmeyen işler yaratır. Sorumlu olan belirli öğeyi, isteği veya script’i bulun.
LCP öğesini ve onu neyin geciktirdiğini belirleyin. Ardından görsel boyutlandırma, ekranın üst kısmındaki görsellerde lazy-loading, render’ı engelleyen CSS, font yükleme, üçüncü taraf script’ler, uzun görevler, önbellekleme, sunucu yanıt süresi, düzen kayması kaynakları ve iki kez yüklenen etiketler gibi olağan şüphelileri kontrol edin.
Aynı koşullar altında tekrarlanan testler yapın ve en iyi çalıştırmanızı değil, tutarlı bir istatistiği karşılaştırın. Toplam Engelleyici Süre’nin (Total Blocking Time) faydalı bir laboratuvar sinyali olduğunu ama INP olmadığını unutmayın.
Her önemli performans bulgusu başarısız metriği, etkilenen şablonu, yeniden üretilebilir bir nedeni ve bir sorumluyu adlandırdığında tamamsınız.
Bültenimize katılın
En son ipuçlarını, trendleri ve teklifleri ücretsiz alın.
Aşama 4: İnsanlar gerçekten bir şey satın alabiliyor mu?
9. Mobil kullanılabilirliği ve erişilebilirliği gerçek alışveriş kontrolleri üzerinde test edin
Otomatik puanlar her etkileşimi kapsamaz. Bir mağaza taramayı geçebilirken filtre çekmecesi klavye odağını tuzağa düşürebilir, çerez bildirimi sepete ekle düğmesini kapatabilir veya beden seçicinin erişilebilir bir etiketi olmayabilir.
360 ila 390 piksel telefon genişliklerinde test edin, metni yakınlaştırın ve tüm yolculuğu yalnızca klavyeyle deneyin. Menülerde, çekmecelerde ve iletişim kutularında odak sırasını ve görünürlüğünü izleyin. Etiketlerin, düğmelerin, form hatalarının ve dokunma hedeflerinin hâlâ anlamlı olduğunu kontrol edin.
Bir alışverişçi gizli kontroller veya odak tuzakları olmadan ana yolculuğu tamamlayabildiğinde ve mobilde hiçbir şey fiyatı, stok durumunu, varyant seçimini, sepete ekle düğmesini veya ödeme adımını gizlemediğinde tamamsınız.
10. Sepeti ve ödeme adımını kontrollü bir test olarak çalıştırın
Görünür bir ödeme düğmesi ödeme adımının çalıştığını kanıtlamaz. Ödeme hataları ticari olaylardır ve analitiğinizi de zayıflatır.
Bunu test etmek için sepete normal bir ürün ve bir varyant ekleyin. Miktarı değiştirin, bir ürünü çıkarın ve varsa bir kupon (veya kasıtlı olarak geçersiz bir kupon) uygulayın. Ardından misafir ve hesap ile ödeme, kargo seçenekleri, ödeme yöntemi seçimi, doğrulama hataları, geri düğmesi ve mobil düzeni test edin. Bir test siparişi veya onaylanmış, ücret almayan bir yol kullanın. İzin olmadan asla gerçek sipariş vermeyin.
Satın alma tamamlandığında veya kararlaştırılan test sınırına ulaştığında, toplamlar doğru kaldığında, hata mesajları insanlara ne yapacaklarını söylediğinde ve engellenen her yol kanıt ve ticari etkiyle belgelendiğinde tamamsınız.
Aşama 5: Yolculuğu doğru ölçüyor musunuz?
11. Analitiği, yinelenen etiketleri ve onayı doğrulayın
Yinelenen etiketler sayfa görüntülemelerini, sepete ekleme etkinliklerini ve satın almaları şişirir. Eksik veya hatalı biçimlendirilmiş değerler gelir raporlarını karar vermek için güvensiz hale getirir. Amaç basittir: bir alışverişçi eylemi, doğru ürün, değer, para birimi, işlem kimliği ve onay durumuyla birlikte bir etkinlik üretmelidir.
Her etiket yöneticisi konteynerini, Google etiketini, reklam pikselini, ortaklık script’ini ve sunucu tarafı entegrasyonu listeleyin. Ardından kontrollü bir oturumda view_item, add_to_cart, begin_checkout ve purchase olaylarını izleyin. Tarayıcının gönderdiklerini GA4 DebugView ve arka uçtaki sipariş kaydıyla karşılaştırın. Alışverişçi bir onay tercihi yapmadan önce ve sonra test edin.
Her eylem kendi etkinliğini tam olarak bir kez tetiklediğinde, satın almalar sabit bir işlem kimliği taşıdığında, değerler ve para birimi arka uçla uzlaştığında ve zorunlu olmayan etiketler onay politikasına uyduğunda tamamsınız.
12. Search Console ve Merchant Center’ı bulduklarınızla uzlaştırın
Yerel bir sayfa testi size her indekslenmiş canonical’ı, site haritası uyarısını, ürün reddini veya kaybedilen arama sorgusunu gösteremez. Öte yandan bir pano uyarısı, çoktan düzeltilmiş bir sorunu tanımlıyor olabilir.
Öncelikli URL’lerinizi Search Console’da inceleyin, ürün ve satıcı liste raporlarını gözden geçirin ve Merchant Center teşhislerini canlı sitede gördüklerinizle karşılaştırın. Tarihleri not edin, çünkü yeniden tarama ve feed işleme dağıtımların gerisinde kalır.
Her önemli pano sorunu canlı kanıtla eşleştiğinde veya yayılmayı bekliyor olarak işaretlendiğinde ve açık her sorunun bir sorumlusu olduğunda tamamsınız.
Aşama 6: Bir alışverişçi bu mağazaya güvenir miydi?
13. Güven sinyallerini, iletişim bilgilerini, kargo ve iadeleri kontrol edin
Gizli veya çelişkili ticari bilgiler alışverişçileri tereddüde düşürür ve destek taleplerini artırır. Başlığı ve altbilgiyi, iletişim sayfasını, ödeme adımını ve politika sayfalarını karşılaştırın.
İşletme kimliği net olduğunda, kargo, iade ve ödeme iddiaları yolculuk boyunca tutarlı olduğunda ve hiçbir güven rozeti doğrulanamaz durumda olmadığında tamamsınız.
14. HTTPS’i, karma içeriği ve ön uç hijyenini kontrol edin
Bu bir sızma testi değil, temel veri hijyeni meselesidir. HTTP’nin tek atlamada HTTPS’e yönlendirdiğini, sertifikanın geçerli olduğunu, karma içerik olmadığını ve formların doğru şekilde gönderildiğini doğrulayın. Konsolu ciddi hatalar için kontrol edin. Bir şey gerçek bir güvenlik açığı gibi görünüyorsa, genel bir uyarıdan teşhis koymak yerine bir uzmana iletin.
Öncelikli sayfalar ve ödeme adımı güvenli şekilde yüklendiğinde, yönlendirmeler tek atlamada gerçekleştiğinde ve formlar beklendiği gibi davrandığında tamamsınız.
Bulgulardan düzeltmelere
15. Bulguları sahiplenilmiş bir düzeltme kuyruğuna dönüştürün
Ekran görüntüleriyle veya bir puanla biten bir denetim riski azaltmaz. Tek bir bozuk şablonun neden olduğu elli belirti, birbiriyle ilgisiz elli bilete dönüşmemelidir. Bulguları kök nedenlerine göre gruplandırın. Bunun bileşen, şablon, feed kuralı ya da izleme kurulumu olup olmadığını not edin. Etkilenen URL’leri kanıt olarak saklayın. Ardından önceliklendirin:
- P0: işi engelleyen aktif bir arıza veya kritik, site geneli bir sorun
- P1: emin olduğunuz önemli bir kusur
- P2: kapsamı sınırlı önemli bir sorun
- P3: izlenmesi gereken bir iyileştirme
Her önemli bulgunun tek bir sorumlusu, bir teslim tarihi, “düzeltildi” için bir testi ve sürümden sonra tekrar kontrol edileceği bir tarihi olduğunda tamamsınız.
Teslim edilecek ürün
Sürümlenmiş bir belge veya elektronik tablo teslim edin; her bulgu için bir satır ve en üstte kısa bir özet olsun. Her satır şunları kapsamalıdır:
- Davranış,
- beklenen davranış,
- etkilenen URL’ler,
- kanıt ve toplandığı tarih,
- önem derecesi ve güven,
- muhtemel neden,
- önerilen düzeltme,
- sorumlu ve tamamlandığını kanıtlayan test.
Ama bir sorunu biri bileti kapattı diye düzeltilmiş saymamanız gerektiğini unutmayın. Test üretimde geçtiğinde onu doğrulanmış olarak işaretleyin.
İş için araçlar
Güçlü bir ilk geçiş yapmak için hiçbir aboneliğe ihtiyacınız yok. İhtiyacınız olan tek şey şu ücretsiz araçlar:
- Google PageSpeed Insights saha verisi (mevcut olduğunda) ve Lighthouse teşhisleri için
- Google Search Console indeksleme, site haritaları, URL Inspection, Core Web Vitals ve yapılandırılmış veri raporları için
- Google Rich Results Test ve Schema.org Validator yapılandırılmış veri için
- Chrome DevTools ve Lighthouse ağ, performans, düzen kaymaları, erişilebilirlik ve konsol kontrolleri için
- Google Tag Assistant ve GA4 DebugView etkinlik izleme için
- SSL Labs Server Test TLS yapılandırması için
Kısa yoldan gitmek isterseniz, AmICited tüm bu kanıtları bir araya getirmenize ve başlangıç temelini sonrası için saklamanıza olanak tanır. Performance Impact görünümü şablonları LCP, INP, CLS ve sunucu yanıt süresine göre karşılaştırır. URL Inspection ve Sitemaps and Indexing öncelikli URL’ler için indekslemeyi takip eder. Products ve Assortment kataloğun hangi bölümlerinin ticari olarak en ağır olduğunu gösterir. Reports Hub’daki Annotations her sürümü sonrasında ne olduğuyla ilişkilendirir. Kanıtı araçlar sağlar. Neyin doğru olduğuna ve hangi ödünleşmelerin kabul edilebilir olduğuna hâlâ mağaza sahibi, geliştirici veya analist karar verir.
Denetimden sonra
Onaylanan her sorunu kapatabilecek uzman iş akışına gönderin: tarama ve render sorunlarını bir teknik SEO denetimine , saha performansı başarısızlıklarını Core Web Vitals iyileştirmesine , facet ve stok durumu sorunlarını bir kategori ve ürün incelemesine , izleme sorunlarını da analitiğin sahibi olan kişiye.
Her düzeltmeden sonra tüm denetimi yeniden çalıştırmaya gerek yoktur. Etkilenen alanı yeniden test edin, sürümü notlayın ki sonrasında neyin değiştiğini görebilesiniz ve düzenli sağlık kontrolünün bir sonraki gerilemeyi yakalamasına izin verin.
Her şeyin yolunda göründüğü mağazaya dönelim
Baştaki mağazayı hatırlıyor musunuz? Ana sayfası indekslenmişti, Lighthouse yeşildi ve doğrulayıcı temizdi. Yine de Google Shopping yanlış fiyatı gösteriyordu, filtre çekmecesi klavye kullanıcılarını tuzağa düşürüyordu ve her satış iki kez sayılıyordu.
Hiçbir pano bunlardan hiçbirini işaretlemedi. Bu kontrol listesi üçünü de yakalardı: fiyat uyuşmazlığını 5. adımda, odak tuzağını 9. adımda ve iki kez sayılan satın almayı 11. adımda. Her biri alışverişçinin yolculuğunda bir yerde bozuluyor ve denetim tam da oraya bakıyor.
Site haritası yerine alışverişçiyi takip etmek size bunu kazandırır. “Site sağlıklı görünüyor mu?” diye sormayı bırakıp daha zor dört soru sormaya başlarsınız. İnsanlar ürünü bulabiliyor mu? Mağazanın onun hakkında söyledikleri doğru mu? Gerçekten satın alabiliyorlar mı? Ve bunu yaptıklarını görebiliyor musunuz? Bu dört sorunun hepsine evet diyebilen bir mağaza, mükemmel puana sahip olandan daha iyi durumdadır.
O halde örnek URL’lerinizi seçin, zamanınızı ayırın ve Aşama 1 ile başlayın. İlk geçiş en yavaşıdır. Ondan sonra iş çoğunlukla düzelttiğiniz şeylerin düzeltilmiş kaldığından emin olmaktır.
