Představte si obchod, kde každý dashboard vypadá v pořádku. Domovská stránka je indexovaná, Lighthouse je zelený a validátor strukturovaných dat nehlásí žádné chyby. Ale ve stejnou chvíli cena v Google Shopping neodpovídá ceně v košíku, mobilní panel filtrů uvězní uživatele klávesnice a každý nákup se zaznamená dvakrát.
Nic z toho se v rychlé kontrole stavu neobjeví. Je to proto, že online obchod je propojený systém, ne jen základní sbírka stránek. Produktová data proudí do stránky, strukturovaných dat a nákupních feedů. Skripty a značky třetích stran rozhodují o tom, jak rychle se všechno načte. Objednávkový proces mění zájem v tržby a analytika má zaznamenat celou cestu přesně. Když se jedna část pokazí, může tiše zkreslit všechno ostatní.
Proto užitečný audit e-shopu sleduje nakupujícího, ne mapu stránek. Kontrolní seznam níže začíná objevením obchodu a končí dokončenou objednávkou. Dá vám seřazený seznam skutečných problémů, každý s důkazy, odpovědnou osobou a jasným testem, kdy je vyřešen.
Kdy tento audit spustit a proč záleží na pořadí
Celý audit spusťte, když převezmete nového e-shopového klienta, po redesignu nebo migraci platformy, před velkým rozjezdem růstu, nebo když rutinní kontrola odhalí regresi v rámci celého obchodu. Na lehký průchod si vyhraďte tři až šest hodin, na standardní audit, který pořádně otestuje každou důležitou šablonu, jeden až dva dny. Hloubková šetření logů, feedů nebo analytiky obvykle potřebují samostatný čas.
Pořadí je záměrné. Nemá smysl hodnotit tření v konverzi, když Google nedokáže indexovat stránky kategorií, a nemá smysl věřit reportu o trychtýři, když se značka nákupu spustí dvakrát.
Zdvojená událost nákupu není důkazem více prodejů a rychlá produktová stránka není v pořádku, když se cena, kterou Google vidí, liší od ceny v košíku. Proto audit postupuje po etapách. Začíná prvním objevením, pak přechází k pravdě o produktech, rychlosti a samotnému nákupu a teprve potom k měření.
Než začnete, shromážděte, co potřebujete. To znamená přístup k:
- Search Console,
- analytice,
- správci značek (tag manager),
- zdroji katalogu nebo feedu,
- Merchant Center,
- seznamu nedávných změn na webu.
Etapa 1: Dokážou vyhledávače najít katalog?
1. Sestavte vzorek, který zastupuje celý obchod
Většina chyb v e-shopu žije ve sdílených šablonách a neobvyklých stavech produktů. Čistá domovská stránka vám neřekne nic o filtrovaných kategoriích, logice variant, vyprodání zásob nebo objednávkovém procesu. Proto začněte tím, že potvrdíte, že testujete živý produkční web ve správném trhu, měně a jazyce. Pak vyberte alespoň jednu URL adresu pro každou z těchto položek:
- domovská stránka
- prioritní kategorie
- hlubší kategorie nebo schválená stránka filtru
- typický produkt
- produkt s variantami
- produkt nedostupný nebo vyřazený z nabídky
- stránka výsledků interního vyhledávání, včetně té, která nic nevrací
- košík, objednávkový proces a stránka s potvrzením objednávky
Pro každou šablonu, která vypadá riskantně, přidejte záludný nebo neobvyklý příklad. Pomůže vám s výběrem report vstupních stránek v analytice a export katalogu.
Hotovo máte, když má každá důležitá šablona a stav objednávky pojmenovanou testovací URL adresu a všechno, co jste nemohli otestovat, je označeno jako „netestováno“.
2. Zkontrolujte procházetelnost, indexaci, kanonické adresy a mapy stránek
Pokud je cesta procházení přerušená, publikování dalších produktů jen znásobí počet zasažených URL adres. Smíšené signály také ztěžují diagnostiku problémů. Pravidla v robots mohou říkat jedno, zatímco kanonické značky a mapa stránek říkají něco úplně jiného.
Prověřte robots.txt, XML mapy stránek, stavové kódy odpovědí, meta značky a hlavičky robots, kanonické značky, stránkování a interní odkazy. Pomocí nástroje URL Inspection v Search Console zjistěte, kterou kanonickou adresu Google skutečně zvolil pro vaše vzorové stránky. Pak porovnejte mapu stránek s realitou. Měla by uvádět živé, indexovatelné stránky, které vracejí stav 200, ne přesměrování, chyby, stránky s noindex nebo duplicity.
Hotovo máte, když vaše zamýšlené vstupní stránky vracejí 200, lze je procházet, řídí se konzistentní politikou kanonických adres a indexace a objevují se v mapě stránek. Každé významné vyloučení by mělo mít vysvětlení nebo odpovědnou osobu.
3. Následujte odkazy: přesměrování, chyby a JavaScript
Obchod může v prohlížeči vypadat kompletní, zatímco crawlery a asistenční technologie vidí mnohem hubenější verzi. Spusťte crawler, abyste našli nefunkční interní odkazy, řetězce přesměrování, smyčky a měkké 404. Pak porovnejte vykreslenou stránku s hrubým HTML. Produktové karty, stránkování, drobečkovou navigaci a odkazy v kategoriích by měly být skutečné a procházetelné a důležitý obsah by neměl záviset jen na JavaScriptu.
Hotovo máte, když interní odkazy směřují přímo do cíle, chybové stránky vracejí správný stavový kód a prioritní produkty lze najít bez spoléhání na nekonečné načítání.
4. Otestujte kategorie, filtry, stránkování a vyhledávání na webu
Systémy kategorií a filtrů mohou zároveň vytvářet pasti pro crawlery vyhledávačů a frustraci pro nakupující. Stránka může být technicky indexovatelná a přesto být slabou vstupní stránkou, pokud je polovina produktů na ní irelevantní.
Vyzkoušejte filtry na desktopu i mobilu. Zkontrolujte vícenásobný výběr, „vymazat vše“, počty výsledků, řazení, stránkování nebo „načíst další“ a kombinace filtrů, které nic nevrací. Podívejte se na URL adresy, které filtry generují, a porovnejte je s politikou indexace obchodu. Všimněte si také, zda dlouhý blok textu v kategorii netlačí mřížku produktů pod okraj obrazovky.
Hotovo máte, když se ovládací prvky chovají konzistentně, náhodné kombinace filtrů se nezmění v nechtěné vstupní stránky a nakupující mohou filtr zrušit, aniž by ztratili své místo.
Připraveni rozšířit své podnikání?
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Etapa 2: Říkají produktová data pravdu?
5. Uveďte do souladu identitu produktu, cenu, sklad a varianty
Jedno chybné pole může nejen uvést nakupujícího v omyl, ale může vést až k nesouladu při dokončení objednávky. Data přitom mohou být dokonale naformátovaná a přesto nesprávná.
U několika reprezentativních produktů porovnejte název, značku, SKU, GTIN nebo EAN, zvolenou variantu, cenu, měnu, dostupnost, obrázky a klíčové parametry všude, kde se objevují. Zkontrolujte, co je zobrazeno na stránce, ve strukturovaných datech, v merchant feedu, v košíku a při dokončení objednávky. Zahrňte zboží v akci, varianty, vyprodané zboží, předobjednávky a vyřazené produkty.
Hotovo máte, když se vzorkované údaje shodují na všech místech a každý záměrný rozdíl, například značka versus výrobce, je explicitně vyjádřen v datovém modelu.
6. Ověřte strukturovaná data podle toho, co nakupující vidí
Strukturovaná data pomáhají jen tehdy, když stránku popisují přesně. Validátor ochotně přijme „InStock“, zatímco stránka i objednávkový proces uvádějí, že produkt není dostupný. Proto byste měli každý stav produktu protáhnout nástrojem Google Rich Results Test nebo validátorem Schema.org. Pak porovnejte označené hodnoty s viditelným obsahem a zdrojovým feedem. U produktů s variantami zkontrolujte, že váš přístup k označování a nastavení kanonických adres odpovídá tomu, jak jsou stránky skutečně postavené.
Hotovo máte, když vzorkované způsobilé stránky nemají žádné chybějící povinné vlastnosti, označení odpovídá viditelnému obsahu a recenze a hodnocení jsou označena jen tehdy, když je nakupující na daném produktu vidí.
Etapa 3: Je obchod rychlý pro skutečné nakupující?
7. Měřte Core Web Vitals nejprve z terénních dat
Data od skutečných uživatelů a jedno spuštění Lighthouse odpovídají na různé otázky. Lighthouse vám pomůže problém reprodukovat, ale neřekne vám, zda skuteční nakupující procházejí, nebo neprocházejí.
Začněte s PageSpeed Insights a reportem Core Web Vitals v Search Console. Poznamenejte si, zda terénní data existují pro přesnou URL adresu, nebo jen pro celý web. Hranice „dobré“ podle Googlu, měřené na 75. percentilu, jsou:
- LCP (načítání): 2,5 sekundy nebo méně
- INP (odezva): 200 milisekund nebo méně
- CLS (vizuální stabilita): 0,1 nebo méně
Podívejte se na mobil a desktop zvlášť. Pokud terénní data nejsou, zaznamenejte výsledek jako neznámý a laboratorní výsledky berte jako předběžné. Neznámý není totéž jako zelený.
Hotovo máte, když má každá prioritní šablona verdikt z terénních dat pro každé zařízení, nebo jasně uvedený nedostatek dat, se zaznamenaným zdrojem a obdobím.
8. Najděte příčinu, ne jen skóre
Obecné rady jako „komprimujte obrázky“ nebo „omezujte JavaScript“ často míjejí skutečné úzké místo a vytvářejí práci, která selhávající metriku neposune. Najděte konkrétní prvek, požadavek nebo skript, který za to může.
Určete prvek LCP a co ho zdržuje. Pak zkontrolujte obvyklé podezřelé, jako je dimenzování obrázků, líné načítání u obrázků nad okrajem obrazovky, CSS blokující vykreslování, načítání písem, skripty třetích stran, dlouhé úlohy, cache, doba odpovědi serveru, zdroje posunu rozvržení a značky načtené dvakrát.
Spouštějte opakované testy za stejných podmínek a porovnávejte konzistentní statistiku, ne svůj nejlepší běh. Pamatujte, že Total Blocking Time je užitečný laboratorní signál, ale není to INP.
Hotovo máte, když každé významné zjištění o výkonu pojmenovává selhávající metriku, zasaženou šablonu, reprodukovatelnou příčinu a odpovědnou osobu.
Přihlaste se k odběru newsletteru
Získejte nejnovější tipy, trendy a nabídky zdarma.
Etapa 4: Dokážou lidé skutečně něco koupit?
9. Otestujte použitelnost na mobilu a přístupnost u skutečných nákupních prvků
Automatizovaná skóre nepokrývají každou interakci. Obchod může projít skenem, i když panel filtrů uvězní fokus klávesnice, banner se soubory cookie zakrývá tlačítko přidání do košíku nebo volič velikosti nemá přístupný popisek.
Testujte při šířkách telefonu 360 až 390 pixelů, zvětšete text a zkuste celou cestu jen s klávesnicí. Sledujte pořadí fokusu a viditelnost v menu, panelech a dialogových oknech. Zkontrolujte, že popisky, tlačítka, chyby formulářů a dotykové cíle stále dávají smysl.
Hotovo máte, když se nakupující dostane hlavní cestou bez skrytých ovládacích prvků nebo pastí na fokus a nic na mobilu neskrývá cenu, dostupnost, volbu varianty, tlačítko přidání do košíku ani dokončení objednávky.
10. Projděte košík a objednávkový proces jako řízený test
Viditelné tlačítko pro dokončení objednávky nedokazuje, že objednávkový proces funguje. Chyby v objednávkovém procesu jsou obchodní incidenty a podkopávají také vaši analytiku.
Pro otestování přidejte do košíku běžný produkt a variantu. Změňte množství, odeberte položku a použijte kupón (nebo záměrně neplatný), pokud nějaký máte. Pak otestujte objednávku jako host i s účtem, možnosti dopravy, výběr platby, validační chyby, tlačítko zpět a rozvržení na mobilu. Použijte testovací objednávku nebo schválenou cestu bez účtování. Nikdy nezadávejte skutečnou objednávku bez svolení.
Hotovo máte, když se nákup dokončí nebo dosáhne dohodnuté testovací hranice, součty zůstávají správné, chybové zprávy lidem říkají, co mají dělat, a každá blokovaná cesta je zdokumentována s důkazy a dopadem na byznys.
Etapa 5: Měříte cestu správně?
11. Ověřte analytiku, duplicitní značky a souhlas
Duplicitní značky nafukují zobrazení stránek, události přidání do košíku a nákupy. Chybějící nebo chybně formátované hodnoty činí reporty o tržbách nebezpečnými pro rozhodování. Cíl je jednoduchý: jedna akce nakupujícího má vytvořit jednu událost se správným produktem, hodnotou, měnou, ID transakce a stavem souhlasu.
Vypište každý kontejner správce značek, značku Google, reklamní pixel, partnerský skript a integraci na straně serveru. Pak v řízené relaci vysledujte view_item, add_to_cart, begin_checkout a purchase. Porovnejte, co posílá prohlížeč, s GA4 DebugView a záznamem objednávky v backendu. Testujte před volbou souhlasu nakupujícího i po ní.
Hotovo máte, když každá akce spustí svou událost právě jednou, nákupy nesou stabilní ID transakce, hodnoty a měna se shodují s backendem a nezbytné značky respektují politiku souhlasu.
12. Porovnejte Search Console a Merchant Center s tím, co jste našli
Lokální test stránky vám neukáže každou indexovanou kanonickou adresu, varování v mapě stránek, zamítnutý produkt nebo ztracený vyhledávací dotaz. Upozornění na dashboardu naopak může popisovat problém, který už byl opraven.
Prohlédněte si prioritní URL adresy v Search Console, zkontrolujte reporty produktů a nabídek merchant a porovnejte diagnostiku Merchant Center s tím, co jste viděli na živém webu. Poznamenejte si data, protože opětovné procházení a zpracování feedu zaostávají za nasazením.
Hotovo máte, když každý významný problém z dashboardu odpovídá důkazům z živého webu nebo je označen jako čekající na propagaci, a každý otevřený problém má odpovědnou osobu.
Etapa 6: Věřil by nakupující tomuto obchodu?
13. Zkontrolujte signály důvěry, kontaktní údaje, dopravu a vrácení
Skryté nebo si odporující obchodní informace nutí nakupující váhat a zvyšují počet požadavků na podporu. Porovnejte hlavičku a patičku, kontaktní stránku, objednávkový proces a stránky se zásadami.
Hotovo máte, když je identita podniku jasná, tvrzení o dopravě, vrácení a platbách si po celou cestu neodporují a žádný znak důvěry není neověřitelný.
14. Zkontrolujte HTTPS, smíšený obsah a čistotu front-endu
Toto není penetrační test, ale otázka základní hygieny dat. Potvrďte, že HTTP přesměrovává na HTTPS v jednom kroku, certifikát je platný, neexistuje smíšený obsah a formuláře se odesílají správně. Zkontrolujte konzoli kvůli vážným chybám. Pokud něco vypadá jako skutečná bezpečnostní zranitelnost, předejte to specialistovi, místo abyste to diagnostikovali z obecného varování.
Hotovo máte, když se prioritní stránky a objednávkový proces načítají bezpečně, přesměrování zvládne jeden krok a formuláře se chovají podle očekávání.
Od zjištění k opravám
15. Proměňte zjištění ve frontu oprav s odpovědnostmi
Audit, který skončí snímky obrazovky nebo skóre, nesnižuje riziko. Padesát příznaků způsobených jednou rozbitou šablonou by se nemělo stát padesáti nesouvisejícími tikety. Seskupte zjištění podle jejich kořenové příčiny. Poznamenejte, zda jde o komponentu, šablonu, pravidlo feedu nebo nastavení měření. Zasažené URL adresy si ponechte jako důkazy. Pak stanovte priority:
- P0: aktivní selhání, které blokuje byznys, nebo kritický problém v rámci celého webu
- P1: významná vada, u níž jste si jistí
- P2: důležitý problém s omezeným rozsahem
- P3: vylepšení ke sledování
Hotovo máte, když každé významné zjištění má jednoho odpovědného, termín, test pro stav „opraveno“ a datum, kdy to po vydání zkontrolovat znovu.
Výstup
Předejte verzovaný dokument nebo tabulku s jedním řádkem na zjištění a krátkým shrnutím na začátku. Každý řádek by měl pokrývat:
- chování,
- očekávané chování,
- zasažené URL adresy,
- důkazy a kdy jste je shromáždili,
- závažnost a míru jistoty,
- pravděpodobnou příčinu,
- doporučenou opravu,
- odpovědnou osobu a test, který prokáže, že je hotovo.
Pamatujte ale, že problém byste neměli označit za opravený jen proto, že někdo zavřel tiket. Za ověřený ho označte, když test projde v produkci.
Nástroje pro tuto práci
K úspěšnému solidnímu prvnímu průchodu nepotřebujete žádná předplatná. Stačí vám tyto bezplatné nástroje:
- Google PageSpeed Insights pro terénní data (kde jsou k dispozici) a diagnostiku Lighthouse
- Google Search Console pro indexaci, mapy stránek, URL Inspection, Core Web Vitals a reporty strukturovaných dat
- Google Rich Results Test a validátor Schema.org pro strukturovaná data
- Chrome DevTools a Lighthouse pro kontrolu sítě, výkonu, posunů rozvržení, přístupnosti a konzole
- Google Tag Assistant a GA4 DebugView pro měření událostí
- SSL Labs Server Test pro konfiguraci TLS
Pokud byste chtěli zkratku, AmICited vám umožní shromáždit všechny tyto důkazy na jednom místě a uchovat výchozí stav pro později. Pohled Performance Impact porovnává šablony podle LCP, INP, CLS a doby odpovědi serveru. URL Inspection a Sitemaps and Indexing sledují indexaci prioritních URL adres. Products a Assortment ukazují, které části katalogu nesou největší obchodní váhu. Poznámky v Reports Hub propojují každé vydání s tím, co se stalo potom. Nástroje dodávají důkazy. Majitel obchodu, vývojář nebo analytik stále rozhoduje o tom, co je správné a které kompromisy jsou přijatelné.
Po auditu
Pošlete každý potvrzený problém do specializovaného pracovního postupu, který ho dokáže uzavřít: problémy s procházením a vykreslováním do auditu technického SEO , selhání výkonu v terénu k nápravě Core Web Vitals , problémy s facety a stavem skladu do revize kategorií a produktů a problémy s měřením tomu, kdo vlastní analytiku.
Není třeba po každé opravě spouštět celý audit znovu. Otestujte znovu zasaženou oblast, označte vydání, abyste viděli, co se potom změnilo, a nechte pravidelnou kontrolu stavu odhalit další regresi.
Zpět k obchodu, kde všechno vypadalo v pořádku
Pamatujete si ten obchod ze začátku? Jeho domovská stránka byla indexovaná, Lighthouse byl zelený a validátor čistý. Přesto Google Shopping ukazoval špatnou cenu, panel filtrů uvězňoval uživatele klávesnice a každý prodej se počítal dvakrát.
Žádný dashboard na nic z toho neupozornil. Tento kontrolní seznam by zachytil všechny tři: nesoulad ceny v kroku 5, past na fokus v kroku 9 a dvakrát započítaný nákup v kroku 11. Každý z nich se láme někde na cestě nakupujícího, a právě tam se audit dívá.
To vám přinese sledování nakupujícího místo mapy stránek. Přestanete se ptát „vypadá web zdravě?“ a začnete si klást čtyři těžší otázky. Dokážou lidé produkt najít? Je pravda, co o něm obchod říká? Dokážou ho skutečně koupit? A vidíte, že to udělali? Obchod, který na všechny čtyři odpoví ano, je v lepší kondici než ten s dokonalým skóre.
Takže si vyberte vzorové URL adresy, vyhraďte si čas a začněte etapou 1. První průchod je nejpomalejší. Potom už jde hlavně o to zajistit, aby to, co jste opravili, zůstalo opravené.
