Predstavte si obchod, v ktorom každý dashboard vyzerá v poriadku. Domovská stránka je zaindexovaná, Lighthouse je zelený a validátor štruktúrovaných dát nehlási žiadne chyby. No v tej istej chvíli cena v Google Shopping nezodpovedá cene v košíku, mobilný panel filtrov uväzňuje používateľov klávesnice a každý nákup sa zaznamená dvakrát.
Nič z toho sa neukáže pri rýchlej kontrole stavu. Je to preto, že online obchod je prepojený systém, nie len základná zbierka stránok. Údaje o produktoch prúdia do stránky, do štruktúrovaných dát aj do nákupných feedov. Skripty a značky tretích strán rozhodujú o tom, ako rýchlo sa všetko načíta. Pokladňa premieňa záujem na tržby a analytika má celú cestu zaznamenať presne. Keď sa jedna časť pokazí, môže potichu skresliť všetko ostatné.
Preto užitočný audit e-shopu sleduje nakupujúceho, nie mapu stránok. Checklist nižšie začína objavením obchodu a končí dokončenou objednávkou. Dá vám zoradený zoznam skutočných problémov, každý s dôkazom, zodpovednou osobou a jasným testom, kedy je opravený.
Kedy tento audit spustiť a prečo záleží na poradí
Celý audit spustite, keď preberáte nového e-commerce klienta, po redizajne alebo migrácii platformy, pred veľkou kampaňou na podporu rastu alebo keď rutinná kontrola odhalí regresiu v celom obchode. Vyhraďte si tri až šesť hodín na ľahký priechod alebo jeden až dva dni na štandardný audit, ktorý poriadne otestuje každú dôležitú šablónu. Hĺbkové vyšetrovania logov, feedov alebo analytiky si zvyčajne vyžadujú samostatný čas.
Poradie je zámerné. Nemá zmysel hodnotiť trenie v konverzii, ak Google nedokáže zaindexovať stránky kategórií, a nemá zmysel dôverovať reportu o funneli, ak sa značka nákupu spustí dvakrát.
Duplikovaná udalosť nákupu nie je dôkazom vyšších predajov a rýchla produktová stránka nie je v poriadku, ak sa cena, ktorú vidí Google, líši od ceny v košíku. Preto audit postupuje po etapách. Začína prvým objavením, potom prechádza k pravde o produktoch, rýchlosti a samotnému nákupu a až nakoniec k meraniu.
Skôr než začnete, zozbierajte, čo potrebujete. To znamená prístup k:
- Search Console,
- Analytike,
- správcovi značiek (tag manager),
- zdroju katalógu alebo feedu,
- Merchant Center,
- zoznamu nedávnych zmien na webe.
Etapa 1: Dokážu vyhľadávače nájsť katalóg?
1. Zostavte vzorku, ktorá reprezentuje celý obchod
Väčšina chýb e-shopov žije v zdieľaných šablónach a nezvyčajných stavoch produktov. Čistá domovská stránka vám nepovie nič o filtrovaných kategóriách, logike variantov, vypredaní skladu ani pokladni. Preto začnite tým, že si potvrdíte, že testujete živý produkčný web v správnom trhu, mene a jazyku. Potom vyberte aspoň jednu URL adresu pre každé z tohto:
- domovskú stránku
- prioritnú kategóriu
- hlbšiu kategóriu alebo schválenú stránku filtra
- typický produkt
- produkt s variantmi
- produkt, ktorý nie je na sklade alebo sa už nepredáva
- stránku výsledkov interného vyhľadávania vrátane takej, ktorá nevráti žiadne výsledky
- košík, pokladňu a stránku s potvrdením objednávky
Pre každú šablónu, ktorá vyzerá rizikovo, pridajte záludný alebo nezvyčajný príklad. Pri výbere vám pomôže report vstupných stránok v analytike a export katalógu.
Hotovo máte vtedy, keď má každá dôležitá šablóna a stav pokladne pomenovanú testovaciu URL adresu a všetko, čo ste nedokázali otestovať, je označené ako „netestované".
2. Skontrolujte prehľadávateľnosť, indexovanie, kanonické adresy a mapy stránok
Ak je cesta prehľadávania pokazená, publikovanie ďalších produktov len znásobí počet postihnutých URL adries. Zmiešané signály tiež sťažujú diagnostiku problémov. Pravidlá v robots.txt môžu hovoriť jedno, zatiaľ čo kanonické značky a mapa stránok môžu hovoriť niečo úplne iné.
Prejdite robots.txt, XML mapy stránok, kódy odpovedí, meta značky a hlavičky robots, kanonické značky, stránkovanie a interné odkazy. V Search Console použite Kontrolu URL adresy, aby ste videli, ktorú kanonickú adresu Google pre vaše vzorové stránky naozaj zvolil. Potom porovnajte mapu stránok s realitou. Mala by uvádzať živé, indexovateľné stránky, ktoré vracajú stav 200, nie presmerovania, chyby, stránky s noindex alebo duplicity.
Hotovo máte vtedy, keď vaše zamýšľané vstupné stránky vracajú 200, dajú sa prehľadať, riadia sa konzistentnou politikou kanonických adries a indexovania a objavujú sa v mape stránok. Každé významné vylúčenie by malo mať vysvetlenie alebo zodpovednú osobu.
3. Sledujte odkazy: presmerovania, chyby a JavaScript
Obchod môže v prehliadači vyzerať kompletne, zatiaľ čo crawleri a asistenčné technológie vidia oveľa tenšiu verziu. Spustite crawler, aby ste našli pokazené interné odkazy, reťazce presmerovaní, slučky a mäkké 404. Potom porovnajte vykreslenú stránku s pôvodným HTML. Produktové karty, stránkovanie, drobčeková navigácia a odkazy v kategóriách by mali byť skutočné a prehľadateľné a dôležitý obsah by nemal závisieť len od JavaScriptu.
Hotovo máte vtedy, keď interné odkazy smerujú priamo na svoj konečný cieľ, chybové stránky vracajú správny stavový kód a prioritné produkty sa dajú nájsť bez spoliehania sa na nekonečné posúvanie.
4. Otestujte kategórie, filtre, stránkovanie a vyhľadávanie na webe
Systémy kategórií a filtrov dokážu zároveň vytvoriť pasce pre crawler vyhľadávačov a frustráciu pre nakupujúcich. Stránka môže byť technicky indexovateľná a napriek tomu slabou vstupnou stránkou, ak je polovica produktov na nej irelevantná.
Vyskúšajte filtre na počítači aj na mobile. Skontrolujte viacnásobný výber, „zrušiť všetko", počty výsledkov, triedenie, stránkovanie alebo „načítať viac" a kombinácie filtrov, ktoré nevracajú nič. Pozrite sa na URL adresy, ktoré filtre generujú, a porovnajte ich s politikou indexovania obchodu. Všimnite si tiež, či dlhý blok textu kategórie zatláča mriežku produktov pod okraj obrazovky.
Hotovo máte vtedy, keď sa ovládacie prvky správajú konzistentne, náhodné kombinácie filtrov sa nestávajú nechcenými vstupnými stránkami a nakupujúci dokážu filter vrátiť späť bez toho, aby stratili svoje miesto.
Pripravení rozšíriť svoje podnikanie?
Začnite svoju 30-dňovú skúšobnú verziu ešte dnes a vidzte výsledky behom pár dní.
Etapa 2: Hovoria údaje o produktoch pravdu?
5. Zosúlaďte identitu produktu, cenu, sklad a varianty
Jedno nesprávne pole môže nielen uviesť nakupujúceho do omylu, ale pokojne viesť až k nezhode v pokladni. Zároveň môžu byť dáta dokonale naformátované a napriek tomu nesprávne.
Pri hŕstke reprezentatívnych produktov porovnajte názov, značku, SKU, GTIN alebo EAN, zvolený variant, cenu, menu, dostupnosť, obrázky a kľúčové špecifikácie všade, kde sa objavujú. Skontrolujte, čo je zobrazené na stránke, v štruktúrovaných dátach, v merchant feede, v košíku a v pokladni. Zahrňte zľavnené položky, varianty, vypredané položky, predobjednávky a produkty, ktoré sa už nepredávajú.
Hotovo máte vtedy, keď sa vzorkované údaje zhodujú na všetkých plochách a každý zámerný rozdiel, napríklad značka verzus výrobca, je explicitne vyjadrený v dátovom modeli.
6. Overte štruktúrované dáta voči tomu, čo vidia nakupujúci
Štruktúrované dáta pomáhajú len vtedy, keď stránku opisujú presne. Validátor ochotne prijme „InStock", aj keď stránka aj pokladňa hovoria, že produkt nie je dostupný. Preto každý stav produktu prežeňte cez Google Rich Results Test alebo Schema.org Validator. Potom porovnajte označené hodnoty s viditeľným obsahom a so zdrojovým feedom. Pri produktoch s variantmi skontrolujte, či váš prístup k značkovaniu a nastavenie kanonických adries zodpovedá tomu, ako sú stránky naozaj postavené.
Hotovo máte vtedy, keď vzorkované spôsobilé stránky nemajú chýbajúce povinné vlastnosti, značkovanie zodpovedá tomu, čo je viditeľné, a recenzie a hodnotenia sú označené len vtedy, keď ich nakupujúci na danom produkte vidia.
Etapa 3: Je obchod naozaj rýchly pre skutočných nakupujúcich?
7. Najprv merajte Core Web Vitals z terénnych dát
Dáta od skutočných používateľov a jedno spustenie Lighthouse odpovedajú na odlišné otázky. Lighthouse vám pomôže reprodukovať problém, ale nepovie, či skutoční nakupujúci prejdú, alebo neprejdú.
Začnite s PageSpeed Insights a reportom Core Web Vitals v Search Console. Všimnite si, či terénne dáta existujú pre presnú URL adresu alebo len pre celý web. Prahové hodnoty „good" od Google, merané na 75. percentile, sú:
- LCP (načítanie): 2,5 sekundy alebo menej
- INP (odozva): 200 milisekúnd alebo menej
- CLS (vizuálna stabilita): 0,1 alebo menej
Pozerajte sa na mobil a počítač oddelene. Ak terénne dáta neexistujú, zaznamenajte výsledok ako neznámy a laboratórne výsledky berte ako predbežné. Neznámy nie je to isté ako zelený.
Hotovo máte vtedy, keď má každá prioritná šablóna terénny verdikt pre každé zariadenie, alebo jasne uvedený nedostatok dát, so zaznamenaným zdrojom a dátumovým rozsahom.
8. Nájdite príčinu, nielen skóre
Všeobecné rady ako „skomprimujte obrázky" alebo „znížte JavaScript" často minú skutočné úzke miesto a vytvoria prácu, ktorá nehne zlyhávajúcou metrikou. Nájdite konkrétny prvok, požiadavku alebo skript, ktorý je zodpovedný.
Identifikujte LCP prvok a to, čo ho zdržuje. Potom skontrolujte obvyklých podozrivých, ako je veľkosť obrázkov, lazy-loading obrázkov nad okrajom obrazovky, CSS blokujúce vykreslenie, načítanie fontov, skripty tretích strán, dlhé úlohy, cachovanie, čas odpovede servera, zdroje posunov rozloženia a značky načítané dvakrát.
Spúšťajte opakované testy za rovnakých podmienok a porovnávajte konzistentnú štatistiku, nie svoj najlepší beh. Pamätajte, že Total Blocking Time je užitočný laboratórny signál, ale nie je to INP.
Hotovo máte vtedy, keď každé významné zistenie o výkone pomenuje zlyhávajúcu metriku, postihnutú šablónu, reprodukovateľnú príčinu a zodpovednú osobu.
Prihláste sa na newsletter
Získajte najnovšie tipy, trendy a ponuky zadarmo.
Etapa 4: Dokážu ľudia naozaj niečo kúpiť?
9. Otestujte použiteľnosť na mobile a prístupnosť na skutočných nákupných ovládacích prvkoch
Automatizované skóre nepokrýva každú interakciu. Obchod môže prejsť skenom, aj keď panel filtrov uväzňuje fokus klávesnice, banner s cookies zakrýva tlačidlo pridať do košíka alebo výber veľkosti nemá prístupný label.
Testujte pri šírkach telefónu 360 až 390 pixelov, priblížte text a skúste celú cestu len s klávesnicou. Sledujte poradie fokusu a viditeľnosť v menu, paneloch a dialógoch. Skontrolujte, či labely, tlačidlá, chyby formulárov a dotykové ciele stále dávajú zmysel.
Hotovo máte vtedy, keď sa nakupujúci dokáže dostať cez hlavnú cestu bez skrytých ovládacích prvkov alebo pascí fokusu a na mobile nič neskrýva cenu, dostupnosť, výber variantu, tlačidlo pridať do košíka ani pokladňu.
10. Prejdite košík a pokladňu ako kontrolovaný test
Viditeľné tlačidlo pokladne nedokazuje, že pokladňa funguje. Chyby v pokladni sú obchodné incidenty a zároveň podkopávajú vašu analytiku.
Pri teste pridajte do košíka bežný produkt a variant. Zmeňte množstvo, odstráňte položku a ak máte, použite kupón (alebo zámerne neplatný). Potom otestujte pokladňu ako hosť aj ako registrovaný zákazník, možnosti dopravy, výber platby, validačné chyby, tlačidlo späť a rozloženie na mobile. Použite testovaciu objednávku alebo schválenú cestu bez zaúčtovania. Nikdy nezadajte skutočnú objednávku bez povolenia.
Hotovo máte vtedy, keď sa nákup dokončí alebo dosiahne dohodnutú testovaciu hranicu, súčty zostanú správne, chybové správy ľuďom povedia, čo majú robiť, a každá zablokovaná cesta je zdokumentovaná s dôkazmi a dopadom na biznis.
Etapa 5: Meriate cestu správne?
11. Overte analytiku, duplicitné značky a súhlas
Duplicitné značky nafukujú zobrazenia stránok, udalosti pridania do košíka a nákupy. Chýbajúce alebo nesprávne formátované hodnoty robia reporty o tržbách nebezpečnými pre rozhodovanie. Cieľ je jednoduchý: jedna akcia nakupujúceho má vyprodukovať jednu udalosť, so správnym produktom, hodnotou, menou, ID transakcie a stavom súhlasu.
Vypíšte každý kontajner správcu značiek, Google tag, reklamný pixel, affiliate skript a serverovú integráciu. Potom v kontrolovanej relácii vystopujte view_item, add_to_cart, begin_checkout a purchase. Porovnajte, čo posiela prehliadač, s GA4 DebugView a so záznamom objednávky v backende. Testujte pred voľbou súhlasu nakupujúceho aj po nej.
Hotovo máte vtedy, keď každá akcia spustí svoju udalosť presne raz, nákupy nesú stabilné ID transakcie, hodnoty a mena sa zhodujú s backendom a nepodstatné značky rešpektujú politiku súhlasu.
12. Zosúlaďte Search Console a Merchant Center s tým, čo ste našli
Lokálny test stránky vám neukáže každú zaindexovanú kanonickú adresu, upozornenie v mape stránok, zamietnutý produkt alebo stratenú vyhľadávaciu požiadavku. Upozornenie na dashboarde zas môže opisovať problém, ktorý je už dávno opravený.
Skontrolujte svoje prioritné URL adresy v Search Console, prejdite reporty o produktoch a merchant listings a porovnajte diagnostiku Merchant Center s tým, čo ste videli na živom webe. Zapisujte si dátumy, pretože opätovné prehľadávanie a spracovanie feedu zaostávajú za nasadeniami.
Hotovo máte vtedy, keď každý významný problém na dashboarde zodpovedá dôkazom z živého webu alebo je označený ako čakajúci na propagáciu, a každý otvorený problém má zodpovednú osobu.
Etapa 6: Dôveroval by nakupujúci tomuto obchodu?
13. Skontrolujte signály dôveryhodnosti, kontaktné údaje, dopravu a vrátenie tovaru
Skryté alebo protichodné obchodné informácie nútia nakupujúcich váhať a zvyšujú počet podporných tiketov. Porovnajte hlavičku a pätičku, kontaktnú stránku, pokladňu a stránky s pravidlami.
Hotovo máte vtedy, keď je identita firmy jasná, tvrdenia o doprave, vrátení tovaru a platbách sú v celej ceste v súlade a žiadny odznak dôveryhodnosti nie je neoveriteľný.
14. Skontrolujte HTTPS, zmiešaný obsah a hygienu front-endu
Toto nie je penetračný test, ale otázka základnej hygieny dát. Potvrďte, že sa HTTP presmeruje na HTTPS v jednom kroku, certifikát je platný, neexistuje zmiešaný obsah a formuláre sa odosielajú správne. Skontrolujte konzolu, či nehlási vážne chyby. Ak niečo vyzerá ako skutočná bezpečnostná zraniteľnosť, odovzdajte to špecialistovi namiesto toho, aby ste ho diagnostikovali na základe všeobecného upozornenia.
Hotovo máte vtedy, keď sa prioritné stránky a pokladňa načítavajú bezpečne, presmerovania trvajú jeden krok a formuláre sa správajú podľa očakávania.
Od zistení k opravám
15. Premeňte zistenia na front opráv s vlastníkmi
Audit, ktorý skončí pri snímkach obrazovky alebo skóre, neznižuje riziko. Päťdesiat príznakov spôsobených jednou pokazenou šablónou by sa nemalo stať päťdesiatimi nesúvisiacimi tikety. Zoskupujte zistenia podľa ich koreňovej príčiny. Poznamenajte, či ide o komponent, šablónu, pravidlo feedu alebo nastavenie merania. Postihnuté URL adresy si ponechajte ako dôkazy. Potom nastavte priority:
- P0: aktívne zlyhanie, ktoré blokuje biznis, alebo kritický problém v celom webe
- P1: významná chyba, ktorou ste si istí
- P2: dôležitý problém s obmedzeným rozsahom
- P3: zlepšenie na sledovanie
Hotovo máte vtedy, keď každé významné zistenie má jedného vlastníka, termín, test na „opravené" a dátum, kedy to po nasadení skontrolovať znova.
Výstup
Odovzdajte verzovaný dokument alebo tabuľku s jedným riadkom na zistenie a krátkym zhrnutím na začiatku. Každý riadok by mal pokrývať:
- správanie,
- očakávané správanie,
- postihnuté URL adresy,
- dôkazy a kedy ste ich zozbierali,
- závažnosť a mieru istoty,
- pravdepodobnú príčinu,
- odporúčanú opravu,
- vlastníka a test, ktorý dokazuje, že je hotovo.
Pamätajte však, že problém by ste nemali označiť za opravený len preto, že niekto zavrel tiket. Za overený ho označte, keď test prejde v produkcii.
Nástroje na túto prácu
Na úspešný silný prvý priechod nepotrebujete žiadne predplatné. Stačia vám tieto bezplatné nástroje:
- Google PageSpeed Insights na terénne dáta (ak sú k dispozícii) a diagnostiku Lighthouse
- Google Search Console na indexovanie, mapy stránok, Kontrolu URL adresy, Core Web Vitals a reporty štruktúrovaných dát
- Google Rich Results Test a Schema.org Validator na štruktúrované dáta
- Chrome DevTools a Lighthouse na kontrolu siete, výkonu, posunov rozloženia, prístupnosti a konzoly
- Google Tag Assistant a GA4 DebugView na meranie udalostí
- SSL Labs Server Test na konfiguráciu TLS
Ak by ste chceli skratku, AmICited vám umožní spojiť všetky tieto dôkazy a uchovať východiskový stav aj pre neskôr. Pohľad Performance Impact porovnáva šablóny podľa LCP, INP, CLS a času odpovede servera. URL Inspection a Sitemaps and Indexing sledujú indexovanie prioritných URL adries. Products a Assortment ukazujú, ktoré časti katalógu nesú najväčšiu obchodnú váhu. Anotácie v Reports Hub spájajú každé nasadenie s tým, čo sa stalo potom. Nástroje dodajú dôkazy. Majiteľ obchodu, vývojár alebo analytik stále rozhoduje o tom, čo je správne a aké kompromisy sú prijateľné.
Po audite
Pošlite každý potvrdený problém do špecializovaného postupu, ktorý ho dokáže uzavrieť: problémy s prehľadávaním a vykresľovaním do auditu technického SEO , zlyhania výkonu v teréne do nápravy Core Web Vitals , problémy s facetmi a stavom skladu do revízie kategórií a produktov a problémy s meraním tomu, kto vlastní analytiku.
Nie je potrebné opakovať celý audit po každej oprave. Otestujte znova postihnutú oblasť, anotujte nasadenie, aby ste videli, čo sa potom zmenilo, a nechajte pravidelnú kontrolu stavu zachytiť ďalšiu regresiu.
Späť do obchodu, kde všetko vyzeralo v poriadku
Pamätáte si obchod zo začiatku? Jeho domovská stránka bola zaindexovaná, Lighthouse bol zelený a validátor čistý. A predsa Google Shopping zobrazoval nesprávnu cenu, panel filtrov uväzňoval používateľov klávesnice a každý predaj sa počítal dvakrát.
Žiadny dashboard na nič z toho neupozornil. Tento checklist by zachytil všetky tri: nezhodu v cene v kroku 5, pascu fokusu v kroku 9 a dvakrát započítaný nákup v kroku 11. Každý z nich sa láme niekde na ceste nakupujúceho a presne tam sa audit pozerá.
To vám prináša sledovanie nakupujúceho namiesto mapy stránok. Prestanete sa pýtať „vyzerá web zdravo?" a začnete si klásť štyri ťažšie otázky. Dokážu ľudia produkt nájsť? Je pravda to, čo o ňom obchod hovorí? Dokážu ho naozaj kúpiť? A vidíte, že to urobili? Obchod, ktorý dokáže na všetky štyri odpovedať áno, je v lepšej kondícii než ten s dokonalým skóre.
Takže si vyberte vzorové URL adresy, vyhraďte si čas a začnite Etapou 1. Prvý priechod je najpomalší. Potom je už úlohou hlavne dávať pozor, aby to, čo ste opravili, zostalo opravené.
