Imaginează-ți un magazin în care fiecare dashboard arată bine. Pagina principală este indexată, Lighthouse este verde, iar validatorul de date structurate nu arată nicio eroare. Dar, exact în același timp, prețul din Google Shopping nu se potrivește cu prețul din coș, sertarul de filtre de pe mobil blochează utilizatorii care navighează de la tastatură, iar fiecare achiziție este înregistrată de două ori.
Nimic din toate acestea nu apare la o verificare rapidă de sănătate. Asta pentru că un magazin online este un sistem conectat, nu doar o simplă colecție de pagini. Datele despre produse ajung în pagină, în datele structurate și în feedurile de shopping. Scripturile și tag-urile terțe decid cât de repede se încarcă totul. Checkout-ul transformă interesul în venit, iar analitica ar trebui să înregistreze corect întreaga călătorie. Când o parte se strică, poate distorsiona în tăcere tot restul.
De aceea un audit e-commerce util urmărește cumpărătorul, nu harta site-ului. Lista de verificare de mai jos începe cu descoperirea magazinului și se termină cu o comandă finalizată. Îți va oferi o listă prioritizată de probleme reale, fiecare cu dovezi, un responsabil și un test clar pentru a ști când este rezolvată.
Când să rulezi acest audit și de ce contează ordinea
Rulează auditul complet când preiei un client nou de e-commerce, după o reproiectare sau o migrare de platformă, înainte de o campanie mare de creștere sau când o verificare de rutină scoate la iveală o regresie la nivelul întregului magazin. Rezervă trei până la șase ore pentru o trecere ușoară sau una până la două zile pentru un audit standard care testează corect fiecare șablon important. Investigațiile aprofundate în loguri, feeduri sau analitică necesită de obicei timp separat.
Ordinea este deliberată. Nu are sens să judeci frecarea din conversie dacă Google nu poate indexa paginile de categorie și nu are sens să ai încredere în raportul de funnel dacă tag-ul de achiziție se declanșează de două ori.
Un eveniment de achiziție duplicat nu este dovada unor vânzări mai multe, iar o pagină de produs rapidă nu este sănătoasă dacă prețul pe care îl vede Google diferă de prețul din coș. De aceea auditul avansează în etape. Începe cu prima descoperire, apoi trece la adevărul despre produse, la viteză și la achiziția în sine, iar abia apoi ajunge la măsurare.
Înainte de a începe, adună ce ai nevoie. Adică acces la:
- Search Console,
- Analytics,
- Tag manager,
- sursa catalogului sau a feedului,
- Merchant Center,
- o listă cu modificările recente ale site-ului.
Etapa 1: Pot motoarele de căutare să găsească catalogul?
1. Construiește un eșantion care reprezintă întregul magazin
Majoritatea erorilor de e-commerce trăiesc în șabloanele comune și în stările neobișnuite ale produselor. O pagină principală curată nu-ți spune nimic despre categoriile filtrate, logica variantelor, lipsurile din stoc sau checkout. De aceea ar trebui să începi prin a confirma că testezi site-ul de producție live, în piața, moneda și limba corecte. Apoi alege cel puțin un URL pentru fiecare dintre acestea:
- pagina principală
- o categorie prioritară
- o categorie mai profundă sau o pagină de filtrare aprobată
- un produs tipic
- un produs cu variante
- un produs epuizat sau scos din producție
- o pagină de rezultate a căutării interne, inclusiv una care nu returnează rezultate
- coșul, checkout-ul și pagina de confirmare a comenzii
Adaugă un exemplu dificil sau neobișnuit pentru orice șablon care pare riscant. Raportul de pagini de destinație din analitica ta și un export de catalog te vor ajuta să alegi.
Ai terminat când fiecare șablon important și fiecare stare de checkout are un URL de test numit, iar tot ce nu ai putut testa este marcat „netestat".
2. Verifică crawlability, indexarea, canonicalele și sitemap-urile
Dacă traseul de crawl este rupt, publicarea mai multor produse va multiplica doar numărul de URL-uri afectate. Semnalele mixte fac, de asemenea, problemele mai greu de diagnosticat. Regulile robots pot spune un lucru, în timp ce tag-urile canonical și sitemap-ul pot spune ceva complet diferit.
Verifică robots.txt, sitemap-urile XML, codurile de răspuns, meta tag-urile și header-ele robots, tag-urile canonical, paginarea și linkurile interne. Folosește URL Inspection din Search Console pentru a vedea ce canonical a ales de fapt Google pentru paginile tale eșantion. Apoi compară sitemap-ul cu realitatea. Ar trebui să listeze pagini live, indexabile, care returnează un status 200, nu redirectări, erori, pagini cu noindex sau duplicate.
Ai terminat când paginile de destinație dorite returnează 200, pot fi crawl-uite, urmează o politică consecventă de canonical și indexare și apar în sitemap. Fiecare excludere semnificativă ar trebui să aibă o explicație sau un responsabil.
3. Urmărește linkurile: redirectări, erori și JavaScript
Un magazin poate părea complet într-un browser, în timp ce crawlerele și tehnologiile asistive văd o versiune mult mai săracă. Rulează un crawler pentru a găsi linkuri interne rupte, lanțuri de redirectări, bucle și 404-uri soft. Apoi compară pagina randată cu HTML-ul brut. Cardurile de produs, paginarea, breadcrumb-urile și linkurile de categorie ar trebui să fie reale și crawl-abile, iar conținutul important nu ar trebui să depindă doar de JavaScript.
Ai terminat când linkurile interne duc direct la destinația lor finală, paginile de eroare returnează codul de status corect, iar produsele prioritare pot fi găsite fără a te baza pe scroll infinit.
4. Testează categoriile, filtrele, paginarea și căutarea pe site
Sistemele de categorii și filtre pot crea capcane de crawl pentru motoarele de căutare și frustrare pentru cumpărători în același timp. O pagină poate fi tehnic indexabilă și totuși o pagină de destinație slabă dacă jumătate dintre produsele de pe ea sunt irelevante.
Încearcă filtrele pe desktop și pe mobil. Verifică selecția multiplă, „șterge tot", numărul de rezultate, sortarea, paginarea sau „încarcă mai multe" și combinațiile de filtre care nu returnează nimic. Uită-te la URL-urile pe care le generează filtrele și compară-le cu politica de indexare a magazinului. Observă, de asemenea, dacă un bloc lung de text de categorie împinge grila de produse sub linia de pliere.
Ai terminat când controalele se comportă consecvent, combinațiile aleatorii de filtre nu devin pagini de destinație accidentale, iar cumpărătorii pot anula un filtru fără să-și piardă locul.
Pregătit să îți dezvolți afacerea?
Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.
Etapa 2: Spun datele despre produse adevărul?
5. Reconciliază identitatea produsului, prețul, stocul și variantele
Un singur câmp greșit nu doar că poate induce în eroare un cumpărător, ci poate ajunge să cauzeze o nepotrivire la checkout. Între timp, datele pot fi perfect formatate și totuși greșite.
Pentru câteva produse reprezentative, compară numele, brandul, SKU-ul, GTIN sau EAN, varianta selectată, prețul, moneda, disponibilitatea, imaginile și specificațiile cheie peste tot unde apar. Verifică ce este afișat pe pagină, în datele structurate, în feedul de merchant, în coș și la checkout. Include produsele la reducere, variantele, produsele epuizate, precomenzile și produsele scoase din producție.
Ai terminat când faptele din eșantion se potrivesc pe fiecare suprafață, iar orice diferență intenționată, cum ar fi brand versus producător, este explicită în modelul de date.
6. Validează datele structurate în raport cu ce văd cumpărătorii
Datele structurate ajută doar atunci când descriu corect pagina. Un validator va accepta fără probleme „InStock" în timp ce pagina și checkout-ul spun ambele că produsul nu este disponibil. De aceea ar trebui să treci fiecare stare de produs prin Google Rich Results Test sau prin Schema.org Validator. Apoi compară valorile marcate cu conținutul vizibil și cu feedul sursă. Pentru produsele cu variante, verifică dacă abordarea ta de marcare și configurarea canonical corespund modului în care sunt construite de fapt paginile.
Ai terminat când paginile eligibile din eșantion nu au proprietăți obligatorii lipsă, marcarea corespunde cu ce este vizibil, iar recenziile și ratingurile sunt marcate doar atunci când cumpărătorii le pot vedea pe acel produs.
Etapa 3: Este magazinul rapid pentru cumpărătorii reali?
7. Măsoară mai întâi Core Web Vitals din datele reale
Datele de la utilizatorii reali și o singură rulare Lighthouse răspund la întrebări diferite. Lighthouse te ajută să reproduci o problemă, dar nu-ți poate spune dacă cumpărătorii reali trec sau nu testul.
Începe cu PageSpeed Insights și cu raportul Core Web Vitals din Search Console. Notează dacă există date reale pentru URL-ul exact sau doar pentru întregul site. Pragurile „bune" ale Google, măsurate la percentila 75, sunt:
- LCP (încărcare): 2,5 secunde sau mai puțin
- INP (reactivitate): 200 de milisecunde sau mai puțin
- CLS (stabilitate vizuală): 0,1 sau mai puțin
Privește mobilul și desktopul separat. Dacă nu există date reale, înregistrează rezultatul ca necunoscut și tratează rezultatele de laborator ca provizorii. Necunoscut nu este același lucru cu verde.
Ai terminat când fiecare șablon prioritar are un verdict din date reale pentru fiecare dispozitiv, sau o lipsă de date declarată clar, cu sursa și intervalul de date înregistrate.
8. Găsește cauza, nu doar scorul
Sfaturile generice precum „comprimă-ți imaginile" sau „redu JavaScript" ratează adesea adevărata blocare și creează muncă ce nu mișcă metrica care eșuează. Găsește elementul, cererea sau scriptul specific responsabil.
Identifică elementul LCP și ce îl întârzie. Apoi verifică suspecții obișnuiți, cum ar fi dimensionarea imaginilor, lazy-loading-ul pe imaginile de deasupra liniei de pliere, CSS-ul care blochează randarea, încărcarea fonturilor, scripturile terțe, sarcinile lungi, caching-ul, timpul de răspuns al serverului, sursele de layout shift și tag-urile încărcate de două ori.
Rulează teste repetate în aceleași condiții și compară o statistică consecventă, nu cea mai bună rulare a ta. Ține minte că Total Blocking Time este un semnal util de laborator, dar nu este INP.
Ai terminat când fiecare constatare semnificativă de performanță numește metrica care eșuează, șablonul afectat, o cauză reproductibilă și un responsabil.
Abonează-te la newsletter-ul nostru
Primește cele mai recente sfaturi, tendințe și oferte gratuit.
Etapa 4: Pot oamenii chiar să cumpere ceva?
9. Testează utilizabilitatea pe mobil și accesibilitatea pe controalele reale de cumpărare
Scorurile automatizate nu acoperă fiecare interacțiune. Un magazin poate trece o scanare în timp ce sertarul de filtre blochează focusul tastaturii, bannerul de cookie-uri acoperă butonul de adăugare în coș sau selectorul de mărime nu are etichetă accesibilă.
Testează la lățimi de telefon de 360 până la 390 de pixeli, mărește textul și încearcă întreaga călătorie folosind doar tastatura. Urmărește ordinea și vizibilitatea focusului în meniuri, sertare și dialoguri. Verifică dacă etichetele, butoanele, erorile de formular și zonele de atingere au încă sens.
Ai terminat când un cumpărător poate parcurge călătoria principală fără controale ascunse sau capcane de focus, iar nimic de pe mobil nu ascunde prețul, disponibilitatea, alegerea variantei, butonul de adăugare în coș sau checkout-ul.
10. Rulează coșul și checkout-ul ca test controlat
Un buton de checkout vizibil nu dovedește că checkout-ul funcționează. Erorile de checkout sunt incidente comerciale și subminează și analitica ta.
Pentru a testa asta, adaugă un produs normal și o variantă în coș. Schimbă cantitatea, elimină un articol și aplică un cupon (sau unul intenționat invalid), dacă ai unul. Apoi testează checkout-ul ca oaspete și ca utilizator cu cont, opțiunile de livrare, selectarea plății, erorile de validare, butonul de înapoi și aspectul pe mobil. Folosește o comandă de test sau o cale aprobată care nu percepe taxe. Nu plasa niciodată o comandă reală fără permisiune.
Ai terminat când achiziția se finalizează sau ajunge la limita de test convenită, totalurile rămân corecte, mesajele de eroare le spun oamenilor ce să facă, iar orice cale blocată este documentată cu dovezi și impact comercial.
Etapa 5: Măsori corect călătoria?
11. Verifică analitica, tag-urile duplicate și consimțământul
Tag-urile duplicate umflă vizualizările de pagină, evenimentele de adăugare în coș și achizițiile. Valorile lipsă sau malformate fac rapoartele de venit nesigure ca bază pentru decizii. Scopul este simplu: o acțiune a cumpărătorului ar trebui să producă un singur eveniment, cu produsul, valoarea, moneda, ID-ul de tranzacție și starea de consimțământ corecte.
Listează fiecare container de tag manager, tag Google, pixel de publicitate, script de afiliere și integrare server-side. Apoi, într-o sesiune controlată, urmărește view_item, add_to_cart, begin_checkout și purchase. Compară ce trimite browserul cu GA4 DebugView și cu înregistrarea comenzii din backend. Testează înainte și după ce cumpărătorul face o alegere privind consimțământul.
Ai terminat când fiecare acțiune își declanșează evenimentul exact o dată, achizițiile poartă un ID de tranzacție stabil, valorile și moneda se reconciliază cu backend-ul, iar tag-urile neesențiale respectă politica de consimțământ.
12. Reconciliază Search Console și Merchant Center cu ce ai găsit
Un test local al paginii nu-ți poate arăta fiecare canonical indexat, avertisment de sitemap, respingere de produs sau interogare de căutare pierdută. O alertă din dashboard, pe de altă parte, ar putea descrie o problemă deja rezolvată.
Inspectează URL-urile prioritare în Search Console, analizează rapoartele de produse și listări de merchant și verifică diagnosticele din Merchant Center în raport cu ce ai văzut pe site-ul live. Notează datele, pentru că recrawl-ul și procesarea feedului întârzie față de implementări.
Ai terminat când fiecare problemă semnificativă din dashboard corespunde dovezilor live sau este marcată ca în așteptarea propagării, iar fiecare problemă deschisă are un responsabil.
Etapa 6: Ar avea un cumpărător încredere în acest magazin?
13. Verifică semnalele de încredere, datele de contact, livrarea și retururile
Informațiile comerciale ascunse sau contradictorii îi fac pe cumpărători să ezite și cresc numărul de tichete de suport. Compară header-ul și footer-ul, pagina de contact, checkout-ul și paginile de politici.
Ai terminat când identitatea afacerii este clară, iar afirmațiile despre livrare, retururi și plată sunt consecvente de-a lungul călătoriei și nicio insignă de încredere nu este neverificabilă.
14. Verifică HTTPS, conținutul mixt și igiena front-end
Acesta nu este un test de penetrare, ci o chestiune de igienă de bază a datelor. Confirmă că HTTP redirecționează către HTTPS într-un singur pas, că certificatul este valid, că nu există conținut mixt și că formularele se trimit corect. Verifică în consolă dacă apar erori grave. Dacă ceva pare o vulnerabilitate reală de securitate, transmite-l unui specialist în loc să-l diagnostichezi pornind de la un avertisment generic.
Ai terminat când paginile prioritare și checkout-ul se încarcă în siguranță, redirectările se fac într-un singur pas, iar formularele se comportă conform așteptărilor.
De la constatări la corecții
15. Transformă constatările într-o coadă de remediere cu responsabili
Un audit care se termină cu capturi de ecran sau cu un scor nu reduce riscul. Cincizeci de simptome cauzate de un singur șablon rupt nu ar trebui să devină cincizeci de tichete fără legătură. Grupează constatările după cauza lor rădăcină. Notează dacă este componenta, șablonul, regula de feed sau configurarea de tracking. Păstrează URL-urile afectate ca dovezi. Apoi prioritizează:
- P0: o defecțiune activă care blochează afacerea sau o problemă critică la nivelul întregului site
- P1: un defect semnificativ de care ești sigur
- P2: o problemă importantă cu domeniu de aplicare limitat
- P3: o îmbunătățire de monitorizat
Ai terminat când fiecare constatare semnificativă are un singur responsabil, un termen limită, un test pentru „rezolvat" și o dată la care să verifici din nou după lansare.
Rezultatul final
Predă un document versionat sau o foaie de calcul cu un rând pentru fiecare constatare și un scurt rezumat la început. Fiecare rând ar trebui să acopere:
- Comportamentul,
- comportamentul așteptat,
- URL-urile afectate,
- dovezile și când le-ai colectat,
- severitatea și gradul de încredere,
- cauza probabilă,
- corecția recomandată,
- responsabilul și testul care dovedește că este gata.
Dar ține minte că nu ar trebui să marchezi o problemă ca rezolvată doar pentru că cineva a închis tichetul. Marcheaz-o ca verificată atunci când testul trece în producție.
Instrumente pentru treabă
Nu ai nevoie de niciun abonament pentru a face cu succes o primă trecere solidă. Tot ce îți trebuie sunt aceste instrumente gratuite:
- Google PageSpeed Insights pentru date reale (unde există) și diagnostice Lighthouse
- Google Search Console pentru indexare, sitemap-uri, URL Inspection, Core Web Vitals și rapoarte de date structurate
- Google Rich Results Test și Schema.org Validator pentru date structurate
- Chrome DevTools și Lighthouse pentru verificări de rețea, performanță, layout shifts, accesibilitate și consolă
- Google Tag Assistant și GA4 DebugView pentru tracking-ul evenimentelor
- SSL Labs Server Test pentru configurarea TLS
Dacă vrei o scurtătură, AmICited îți permite să reunești toate acele dovezi și să păstrezi linia de bază pentru mai târziu. Vizualizarea Performance Impact compară șabloanele după LCP, INP, CLS și timpul de răspuns al serverului. URL Inspection și Sitemaps and Indexing urmăresc indexarea pentru URL-urile prioritare. Products și Assortment arată care părți ale catalogului au cea mai mare greutate comercială. Adnotările din Reports Hub leagă fiecare lansare de ce s-a întâmplat după. Instrumentele furnizează dovezile. Proprietarul magazinului, dezvoltatorul sau analistul decide în continuare ce este corect și ce compromisuri sunt acceptabile.
După audit
Trimite fiecare problemă confirmată către fluxul de lucru specializat care o poate închide: problemele de crawl și randare către un audit SEO tehnic , eșecurile de performanță din teren către remedierea Core Web Vitals , problemele de fațete și stări de stoc către o revizuire de categorii și produse , iar problemele de tracking către cel care răspunde de analitică.
Nu este nevoie să rulezi din nou întregul audit după fiecare corecție. Retestează zona afectată, adnotează lansarea ca să vezi ce s-a schimbat după, și lasă verificarea regulată de sănătate să prindă următoarea regresie.
Înapoi la magazinul unde totul părea în regulă
Îți mai amintești magazinul de la început? Pagina principală era indexată, Lighthouse era verde și validatorul era curat. Și totuși Google Shopping afișa prețul greșit, sertarul de filtre bloca utilizatorii de tastatură și fiecare vânzare era numărată de două ori.
Niciun dashboard nu semnala ceva. Această listă de verificare le-ar fi prins pe toate trei: nepotrivirea de preț la pasul 5, capcana de focus la pasul 9 și achiziția numărată de două ori la pasul 11. Fiecare se rupe undeva pe traseul cumpărătorului, iar exact acolo se uită auditul.
Asta obții dacă urmărești cumpărătorul în locul hărții site-ului. Nu mai întrebi „arată site-ul sănătos?" și începi să pui patru întrebări mai grele. Pot oamenii găsi produsul? Este adevărat ce spune magazinul despre el? Pot chiar să-l cumpere? Și poți vedea că au făcut-o? Un magazin care poate răspunde „da" la toate patru este într-o formă mai bună decât unul cu un scor perfect.
Așa că alege-ți URL-urile eșantion, rezervă-ți timpul și începe cu Etapa 1. Prima trecere este cea mai lentă. După aceea, treaba constă în mare parte în a te asigura că ceea ce ai corectat rămâne corectat.
