Wyobraź sobie sklep, w którym każdy dashboard wygląda dobrze. Strona główna jest zaindeksowana, Lighthouse świeci na zielono, a walidator danych strukturalnych nie pokazuje błędów. Ale w tym samym momencie cena w Google Shopping nie zgadza się z ceną w koszyku, mobilny panel filtrów więzi użytkowników klawiatury, a każdy zakup jest rejestrowany dwukrotnie.
Nic z tego nie wychodzi w szybkiej kontroli stanu. Dzieje się tak, bo sklep internetowy to połączony system, a nie tylko podstawowy zbiór stron. Dane produktowe trafiają na stronę, do danych strukturalnych i do feedów zakupowych. Skrypty i tagi stron trzecich decydują, jak szybko to wszystko się ładuje. Finalizacja zamówienia zamienia zainteresowanie w przychód, a analityka powinna dokładnie rejestrować całą ścieżkę. Gdy jedna część się psuje, może po cichu zniekształcić wszystko inne.
Dlatego użyteczny audyt e-commerce podąża za kupującym, a nie za mapą strony. Poniższa lista kontrolna zaczyna się od odkrycia sklepu, a kończy na złożonym zamówieniu. Da ci rankingową listę rzeczywistych problemów, każdy z dowodami, osobą odpowiedzialną i jasnym testem potwierdzającym, że został naprawiony.
Kiedy przeprowadzić ten audyt i dlaczego kolejność ma znaczenie
Pełny audyt przeprowadzaj, gdy przejmujesz nowego klienta e-commerce, po redesignie lub migracji platformy, przed dużym działaniem rozwojowym albo gdy rutynowa kontrola wykaże regresję w całym sklepie. Zarezerwuj od trzech do sześciu godzin na lekki przegląd lub od jednego do dwóch dni na standardowy audyt, który porządnie przetestuje każdy ważny szablon. Głębsze analizy logów, feedów lub danych analitycznych zwykle wymagają osobnego czasu.
Kolejność jest zamierzona. Nie ma sensu oceniać tarcia w konwersji, jeśli Google nie może zaindeksować stron kategorii, i nie ma sensu ufać raportowi o lejku sprzedaży, jeśli tag zakupu odpala się dwa razy.
Zduplikowane zdarzenie zakupu nie jest dowodem na większą sprzedaż, a szybka strona produktu nie jest zdrowa, jeśli cena widziana przez Google różni się od ceny w koszyku. Dlatego audyt przebiega etapami. Zaczyna się od pierwszego odkrycia, potem przechodzi do prawdy o produkcie, szybkości i samego zakupu, a dopiero na końcu do pomiarów.
Zanim zaczniesz, zbierz to, co potrzebne. To znaczy dostęp do:
- Search Console,
- analityki,
- menedżera tagów,
- źródła katalogu lub feedu,
- Merchant Center,
- listy ostatnich zmian w witrynie.
Etap 1: Czy wyszukiwarki mogą znaleźć katalog?
1. Zbuduj próbkę reprezentującą cały sklep
Większość błędów w e-commerce tkwi we wspólnych szablonach i nietypowych stanach produktów. Czysta strona główna nie mówi nic o filtrowanych kategoriach, logice wariantów, brakach towaru ani finalizacji zamówienia. Dlatego zacznij od potwierdzenia, że testujesz produkcyjną wersję witryny na właściwym rynku, w odpowiedniej walucie i języku. Następnie wybierz co najmniej jeden adres URL dla każdego z poniższych:
- strona główna
- priorytetowa kategoria
- głębsza kategoria lub zatwierdzona strona filtrów
- typowy produkt
- produkt z wariantami
- produkt niedostępny lub wycofany
- strona wyników wyszukiwania wewnętrznego, w tym taka, która nie zwraca żadnych wyników
- koszyk, finalizacja zamówienia i strona potwierdzenia zamówienia
Dodaj trudny lub nietypowy przykład dla każdego szablonu, który wygląda ryzykownie. Raport stron wejściowych w analityce i eksport katalogu pomogą ci wybrać.
Zadanie masz zrobione, gdy każdy ważny szablon i stan finalizacji zamówienia ma nazwany adres URL do testu, a wszystko, czego nie udało się przetestować, jest oznaczone jako „nietestowane”.
2. Sprawdź indeksowalność, indeksowanie, adresy kanoniczne i mapy strony
Jeśli ścieżka indeksowania jest zepsuta, publikowanie kolejnych produktów tylko pomnoży liczbę dotkniętych adresów URL. Sprzeczne sygnały utrudniają też diagnozowanie problemów. Reguły w robots mogą mówić jedno, podczas gdy tagi kanoniczne i mapa strony mogą mówić coś zupełnie innego.
Przejrzyj robots.txt, mapy strony XML, kody odpowiedzi, meta tagi i nagłówki robots, tagi kanoniczne, paginację i linki wewnętrzne. Użyj funkcji Sprawdzenie adresu URL w Search Console, aby zobaczyć, który adres kanoniczny Google faktycznie wybrał dla twoich przykładowych stron. Następnie porównaj mapę strony z rzeczywistością. Powinna zawierać aktywne, indeksowalne strony zwracające status 200, a nie przekierowania, błędy, strony z noindex czy duplikaty.
Zadanie masz zrobione, gdy zamierzone strony docelowe zwracają 200, można je zaindeksować, stosują spójną politykę kanoniczną i indeksowania oraz pojawiają się w mapie strony. Każde istotne wykluczenie powinno mieć wyjaśnienie lub osobę odpowiedzialną.
3. Podążaj za linkami: przekierowania, błędy i JavaScript
Sklep może wyglądać kompletnie w przeglądarce, podczas gdy crawlery i technologie wspomagające widzą znacznie uboższą wersję. Uruchom crawler, aby znaleźć zepsute linki wewnętrzne, łańcuchy przekierowań, pętle i miękkie błędy 404. Następnie porównaj wyrenderowaną stronę z surowym HTML. Karty produktów, paginacja, okruszki i linki kategorii powinny być prawdziwe i indeksowalne, a ważna treść nie powinna zależeć wyłącznie od JavaScriptu.
Zadanie masz zrobione, gdy linki wewnętrzne prowadzą prosto do miejsca docelowego, strony błędów zwracają właściwy kod statusu, a priorytetowe produkty można znaleźć bez polegania na nieskończonym przewijaniu.
4. Przetestuj kategorie, filtry, paginację i wyszukiwarkę na stronie
Systemy kategorii i filtrów mogą jednocześnie tworzyć pułapki indeksowania dla wyszukiwarek i frustrację dla kupujących. Strona może być technicznie indeksowalna, a mimo to słabą stroną docelową, jeśli połowa produktów na niej jest nieistotna.
Wypróbuj filtry na komputerze i na urządzeniu mobilnym. Sprawdź wielokrotny wybór, „wyczyść wszystko”, liczby wyników, sortowanie, paginację lub „wczytaj więcej” oraz kombinacje filtrów, które nie zwracają nic. Przyjrzyj się adresom URL generowanym przez filtry i porównaj je z polityką indeksowania sklepu. Zauważ też, czy długi blok tekstu w kategorii spycha siatkę produktów poniżej linii zagięcia.
Zadanie masz zrobione, gdy kontrolki działają spójnie, losowe kombinacje filtrów nie zamieniają się w przypadkowe strony docelowe, a kupujący mogą cofnąć filtr bez utraty miejsca, w którym byli.
Gotowy na rozwój swojej firmy?
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Etap 2: Czy dane produktowe mówią prawdę?
5. Uzgodnij tożsamość produktu, cenę, stan magazynowy i warianty
Jedno błędne pole może nie tylko wprowadzić kupującego w błąd, ale nawet doprowadzić do niezgodności przy finalizacji zamówienia. Jednocześnie dane mogą być idealnie sformatowane i nadal być błędne.
Dla kilku reprezentatywnych produktów porównaj nazwę, markę, SKU, GTIN lub EAN, wybrany wariant, cenę, walutę, dostępność, zdjęcia i kluczowe specyfikacje wszędzie, gdzie się pojawiają. Sprawdź, co jest wyświetlane na stronie, w danych strukturalnych, w feedzie produktowym, w koszyku i przy finalizacji zamówienia. Uwzględnij produkty przecenione, warianty, braki towaru, przedsprzedaże i produkty wycofane.
Zadanie masz zrobione, gdy wybrane fakty są zgodne na każdej powierzchni, a każda zamierzona różnica, na przykład marka versus producent, jest wyraźnie określona w modelu danych.
6. Zweryfikuj dane strukturalne względem tego, co widzą kupujący
Dane strukturalne pomagają tylko wtedy, gdy dokładnie opisują stronę. Walidator bez problemu zaakceptuje „InStock”, podczas gdy strona i finalizacja zamówienia mówią, że produkt jest niedostępny. Dlatego każdy stan produktu przepuść przez Test wyników rozszerzonych Google lub walidator Schema.org. Następnie porównaj oznaczone wartości z widoczną treścią i źródłowym feedem. W przypadku produktów z wariantami sprawdź, czy twoje podejście do znaczników i konfiguracja kanoniczna odpowiadają temu, jak strony są faktycznie zbudowane.
Zadanie masz zrobione, gdy wybrane kwalifikujące się strony nie mają brakujących wymaganych właściwości, znaczniki zgadzają się z tym, co widać, a opinie i oceny są oznaczone tylko wtedy, gdy kupujący mogą je zobaczyć na danym produkcie.
Etap 3: Czy sklep jest szybki dla prawdziwych kupujących?
7. Najpierw zmierz Core Web Vitals na podstawie danych terenowych
Dane rzeczywistych użytkowników i pojedyncze uruchomienie Lighthouse odpowiadają na różne pytania. Lighthouse pomaga odtworzyć problem, ale nie powie ci, czy prawdziwi kupujący zaliczają test, czy nie.
Zacznij od PageSpeed Insights i raportu Core Web Vitals w Search Console. Zanotuj, czy dane terenowe istnieją dla dokładnego adresu URL, czy tylko dla całej witryny. „Dobre” progi Google, mierzone na 75. percentylu, to:
- LCP (ładowanie): 2,5 sekundy lub mniej
- INP (responsywność): 200 milisekund lub mniej
- CLS (stabilność wizualna): 0,1 lub mniej
Patrz na urządzenia mobilne i komputery osobno. Jeśli nie ma danych terenowych, zapisz wynik jako nieznany i traktuj wyniki laboratoryjne jako wstępne. Nieznany to nie to samo co zielony.
Zadanie masz zrobione, gdy każdy priorytetowy szablon ma werdykt terenowy dla każdego typu urządzenia lub jasno stwierdzony brak danych, z zapisanym źródłem i zakresem dat.
8. Znajdź przyczynę, nie tylko wynik
Ogólne porady typu „skompresuj obrazy” czy „ogranicz JavaScript” często mijają prawdziwe wąskie gardło i tworzą pracę, która nie poprawia niedziałającej metryki. Znajdź konkretny element, żądanie lub skrypt, który jest za to odpowiedzialny.
Zidentyfikuj element LCP i to, co go opóźnia. Następnie sprawdź typowych podejrzanych, takich jak rozmiary obrazów, lazy loading na obrazach powyżej linii zagięcia, blokujący renderowanie CSS, ładowanie czcionek, skrypty stron trzecich, długie zadania, buforowanie, czas odpowiedzi serwera, źródła przesunięć układu i tagi ładowane dwukrotnie.
Powtarzaj testy w tych samych warunkach i porównuj spójną statystykę, a nie swój najlepszy przebieg. Pamiętaj, że Total Blocking Time to przydatny sygnał laboratoryjny, ale to nie INP.
Zadanie masz zrobione, gdy każde istotne ustalenie dotyczące wydajności wskazuje niedziałającą metrykę, dotknięty szablon, odtwarzalną przyczynę i osobę odpowiedzialną.
Dołącz do naszego newslettera
Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.
Etap 4: Czy ludzie mogą faktycznie coś kupić?
9. Przetestuj użyteczność mobilną i dostępność na prawdziwych kontrolkach zakupowych
Automatyczne wyniki nie obejmują każdej interakcji. Sklep może przejść skan, podczas gdy panel filtrów więzi fokus klawiatury, baner cookie zasłania przycisk dodania do koszyka albo selektor rozmiaru nie ma dostępnej etykiety.
Testuj przy szerokościach telefonu od 360 do 390 pikseli, powiększ tekst i spróbuj przejść całą ścieżkę używając tylko klawiatury. Obserwuj kolejność i widoczność fokusu w menu, panelach i oknach dialogowych. Sprawdź, czy etykiety, przyciski, błędy formularzy i obszary dotyku nadal mają sens.
Zadanie masz zrobione, gdy kupujący może przejść główną ścieżkę bez ukrytych kontrolek i pułapek fokusu, a na urządzeniu mobilnym nic nie zasłania ceny, dostępności, wyboru wariantu, przycisku dodania do koszyka ani finalizacji zamówienia.
10. Przeprowadź test koszyka i finalizacji zamówienia jako kontrolowany test
Widoczny przycisk finalizacji zamówienia nie dowodzi, że finalizacja działa. Błędy w finalizacji zamówienia to incydenty komercyjne, które podważają też twoją analitykę.
Aby to przetestować, dodaj do koszyka zwykły produkt i wariant. Zmień ilość, usuń pozycję i zastosuj kupon (albo celowo nieprawidłowy), jeśli go masz. Następnie przetestuj finalizację jako gość i jako zalogowany użytkownik, opcje dostawy, wybór płatności, błędy walidacji, przycisk wstecz i układ mobilny. Użyj zamówienia testowego lub zatwierdzonej ścieżki bez obciążania płatnością. Nigdy nie składaj prawdziwego zamówienia bez zgody.
Zadanie masz zrobione, gdy zakup się kończy lub dociera do uzgodnionej granicy testu, sumy pozostają prawidłowe, komunikaty błędów mówią ludziom, co mają zrobić, a każda zablokowana ścieżka jest udokumentowana wraz z dowodami i wpływem na biznes.
Etap 5: Czy mierzysz ścieżkę prawidłowo?
11. Zweryfikuj analitykę, zduplikowane tagi i zgodę
Zduplikowane tagi zawyżają odsłony stron, zdarzenia dodania do koszyka i zakupy. Brakujące lub nieprawidłowe wartości sprawiają, że raporty przychodów są niebezpieczne jako podstawa decyzji. Cel jest prosty: jedna akcja kupującego powinna generować jedno zdarzenie, z właściwym produktem, wartością, walutą, identyfikatorem transakcji i stanem zgody.
Wypisz wszystkie kontenery menedżera tagów, tagi Google, piksele reklamowe, skrypty afiliacyjne i integracje server-side. Następnie w kontrolowanej sesji prześledź view_item, add_to_cart, begin_checkout i purchase. Porównaj to, co wysyła przeglądarka, z GA4 DebugView i rekordem zamówienia w backendzie. Przetestuj przed i po podjęciu decyzji o zgodzie przez kupującego.
Zadanie masz zrobione, gdy każda akcja wywołuje swoje zdarzenie dokładnie raz, zakupy niosą stabilny identyfikator transakcji, wartości i waluta zgadzają się z backendem, a tagi niekonieczne respektują politykę zgody.
12. Uzgodnij Search Console i Merchant Center z tym, co znalazłeś
Lokalny test strony nie pokaże ci każdego zaindeksowanego adresu kanonicznego, ostrzeżenia o mapie strony, odrzuconego produktu czy utraconego zapytania. Alert w dashboardzie może natomiast opisywać problem, który został już naprawiony.
Sprawdź priorytetowe adresy URL w Search Console, przejrzyj raporty produktów i ofert sprzedawcy oraz porównaj diagnostykę Merchant Center z tym, co widziałeś na żywej witrynie. Zanotuj daty, ponieważ ponowne indeksowanie i przetwarzanie feedów pozostają w tyle za wdrożeniami.
Zadanie masz zrobione, gdy każde istotne zgłoszenie z dashboardu zgadza się z dowodami na żywo lub jest oznaczone jako oczekujące na propagację, a każde otwarte zgłoszenie ma osobę odpowiedzialną.
Etap 6: Czy kupujący zaufałby temu sklepowi?
13. Sprawdź sygnały zaufania, dane kontaktowe, dostawę i zwroty
Ukryte lub sprzeczne informacje handlowe sprawiają, że kupujący się wahają, i zwiększają liczbę zgłoszeń do wsparcia. Porównaj nagłówek i stopkę, stronę kontaktową, finalizację zamówienia i strony polityk.
Zadanie masz zrobione, gdy tożsamość firmy jest jasna, informacje o dostawie, zwrotach i płatnościach są spójne w całej ścieżce, a żadna plakietka zaufania nie jest niezweryfikowana.
14. Sprawdź HTTPS, mieszaną treść i higienę front-endu
To nie test penetracyjny, ale kwestia podstawowej higieny danych. Potwierdź, że HTTP przekierowuje na HTTPS jednym przeskokiem, certyfikat jest ważny, nie ma mieszanej treści, a formularze wysyłają się poprawnie. Sprawdź konsolę pod kątem poważnych błędów. Jeśli coś wygląda na prawdziwą lukę bezpieczeństwa, przekaż to specjaliście, zamiast diagnozować to na podstawie ogólnego ostrzeżenia.
Zadanie masz zrobione, gdy priorytetowe strony i finalizacja zamówienia ładują się bezpiecznie, przekierowania zajmują jeden przeskok, a formularze działają zgodnie z oczekiwaniami.
Od ustaleń do poprawek
15. Zamień ustalenia w kolejkę napraw z przypisanymi właścicielami
Audyt, który kończy się zrzutami ekranu lub wynikiem punktowym, nie zmniejsza ryzyka. Pięćdziesiąt objawów spowodowanych jednym zepsutym szablonem nie powinno zamienić się w pięćdziesiąt niepowiązanych zgłoszeń. Grupuj ustalenia według ich przyczyny źródłowej. Zanotuj, czy chodzi o komponent, szablon, regułę feedu czy konfigurację śledzenia. Zachowaj dotknięte adresy URL jako dowody. Następnie ustal priorytety:
- P0: aktywna awaria blokująca biznes lub krytyczny problem w całej witrynie
- P1: istotny defekt, co do którego masz pewność
- P2: ważny problem o ograniczonym zakresie
- P3: usprawnienie do monitorowania
Zadanie masz zrobione, gdy każde istotne ustalenie ma jednego właściciela, termin, test na „naprawione” i datę ponownego sprawdzenia po wdrożeniu.
Produkt końcowy
Przekaż wersjonowany dokument lub arkusz z jednym wierszem na ustalenie i krótkim podsumowaniem na górze. Każdy wiersz powinien obejmować:
- zachowanie,
- oczekiwane zachowanie,
- dotknięte adresy URL,
- dowody i datę ich zebrania,
- wagę i pewność,
- prawdopodobną przyczynę,
- zalecaną poprawkę,
- właściciela i test potwierdzający, że zadanie jest wykonane.
Pamiętaj jednak, że nie powinieneś uznawać problemu za naprawiony tylko dlatego, że ktoś zamknął zgłoszenie. Oznacz go jako zweryfikowany, gdy test przejdzie na produkcji.
Narzędzia do zadania
Nie potrzebujesz żadnych subskrypcji, aby skutecznie przeprowadzić solidny pierwszy przegląd. Wystarczą ci te darmowe narzędzia:
- Google PageSpeed Insights do danych terenowych (tam, gdzie są dostępne) i diagnostyki Lighthouse
- Google Search Console do raportów o indeksowaniu, mapach strony, sprawdzaniu adresów URL, Core Web Vitals i danych strukturalnych
- Google Rich Results Test i walidator Schema.org do danych strukturalnych
- Chrome DevTools i Lighthouse do sprawdzania sieci, wydajności, przesunięć układu, dostępności i konsoli
- Google Tag Assistant i GA4 DebugView do śledzenia zdarzeń
- SSL Labs Server Test do konfiguracji TLS
Jeśli chcesz skrótu, AmICited pozwoli ci zebrać wszystkie te dowody razem i zachować punkt odniesienia na później. Widok Performance Impact porównuje szablony według LCP, INP, CLS i czasu odpowiedzi serwera. Sprawdzanie adresów URL i Mapy strony i indeksowanie śledzą indeksowanie priorytetowych adresów URL. Produkty i Asortyment pokazują, które części katalogu mają największą wagę komercyjną. Adnotacje w centrum raportów wiążą każde wdrożenie z tym, co stało się później. Narzędzia dostarczają dowodów. Właściciel sklepu, deweloper lub analityk nadal decyduje, co jest poprawne i jakie kompromisy są do przyjęcia.
Po audycie
Wyślij każdy potwierdzony problem do wyspecjalizowanego procesu, który może go zamknąć: problemy z indeksowaniem i renderowaniem do audytu SEO technicznego , problemy z wydajnością terenową do naprawy Core Web Vitals , problemy z fasetami i stanem magazynowym do przeglądu kategorii i produktów , a problemy ze śledzeniem do osoby odpowiedzialnej za analitykę.
Nie ma potrzeby powtarzać całego audytu po każdej poprawce. Ponownie przetestuj dotknięty obszar, dodaj adnotację do wdrożenia, aby zobaczyć, co zmieniło się później, i pozwól regularnej kontroli stanu wychwycić kolejną regresję.
Powrót do sklepu, w którym wszystko wyglądało dobrze
Pamiętasz sklep z początku? Jego strona główna była zaindeksowana, Lighthouse świecił na zielono, a walidator był czysty. A jednak Google Shopping pokazywał złą cenę, panel filtrów więził użytkowników klawiatury, a każda sprzedaż była liczona dwa razy.
Żaden dashboard tego nie zgłosił. Ta lista kontrolna wychwyciłaby wszystkie trzy problemy: niezgodność ceny w kroku 5, pułapkę fokusu w kroku 9 i podwójnie policzony zakup w kroku 11. Każdy z nich psuje się gdzieś na ścieżce kupującego i właśnie tam zagląda audyt.
Właśnie to zyskujesz, podążając za kupującym, a nie za mapą strony. Przestajesz pytać „czy strona wygląda zdrowo?” i zaczynasz zadawać cztery trudniejsze pytania. Czy ludzie mogą znaleźć produkt? Czy to, co sklep o nim mówi, jest prawdą? Czy mogą go faktycznie kupić? I czy widzisz, że to zrobili? Sklep, który może odpowiedzieć „tak” na wszystkie cztery, jest w lepszej formie niż ten z idealnym wynikiem.
Więc wybierz przykładowe adresy URL, zarezerwuj czas i zacznij od etapu 1. Pierwszy przegląd jest najwolniejszy. Potem zadanie polega głównie na pilnowaniu, żeby to, co naprawiłeś, pozostało naprawione.
