Lighthouse SEO-betyg: 100 på en e-handelskategorisida
Ett Lighthouse SEO-betyg på 100 är lätt att förfalska på en liten statisk sida. Det är svårare på en riktig e-handelskategorisida med produktkort, bilder, priser, lagerstatus, filter, canonicals, strukturerad data och ett backend som fortfarande måste leverera färska kommersiella data.
Jag körde Lighthouse den 17 juni 2026 för `https://www.cigge.se/e-cigaretter/engangs-vape`. Desktop-resultatet var rent över hela linjen: 100 Prestanda, 100 Tillgänglighet, 100 Bästa praxis och 100 SEO. Mobilresultatet höll också måttet: 97 Prestanda, 100 Tillgänglighet, 100 Bästa praxis och 100 SEO.
Det betyder inte att sidan är "klar" med SEO. Det betyder att den tekniska grunden är stark nog för att SEO-arbetet kan fokusera på innehåll, avsikt, interna länkar, kommersiella data och auktoritet istället för att kämpa mot trasig markup, långsam rendering eller röriga crawlsignaler.
Resultatet
| Lighthouse-granskning | Desktop | Mobil |
|---|---|---|
| --- | ---: | ---: |
| Prestanda | 100 | 97 |
| Tillgänglighet | 100 | 100 |
| Bästa praxis | 100 | 100 |
| SEO | 100 | 100 |
Den testade URL:en var en live e-handelskategorisida, inte en avskalad demo-rutt. Det spelar roll. Kategorisidor är oftast där headless e-handel först blir rörig.
Bland svenska vape e-handelssidor jag har arbetat med eller testat har jag inte sett ett snabbare kategorisideresultat. Jag skulle bara kalla det Sveriges snabbaste vape-webbplats efter en kontrollerad konkurrentbenchmark, men denna sida är en seriös kandidat: perfekta Lighthouse-betyg på desktop, 97 i mobil prestanda och riktiga handelsdata på sidan.
En produktdetaljsida har en huvudprodukt. En kategorisida har många produkter, många bilder, sortering, filter, paginering, produkttillgänglighet, prisändringar, marknadstext och intern länkning. Sidan måste betjäna shoppers, sökmotorer och CMS-teamet samtidigt.
Vad ett Lighthouse SEO-betyg bevisar
Lighthouse är ett automatiserat granskningsverktyg från Googles Chrome-team. Det kontrollerar prestanda, tillgänglighet, bästa praxis, SEO och andra webbkvalitetssignaler. Google PageSpeed Insights använder också Lighthouse för labbdiagnostik.
Ett grönt betyg är ingen rankinggaranti. Googles egen dokumentation behandlar 90 och uppåt som bra, och ett perfekt 100 som svårt att upprätthålla när en sida bär på riktiga produktdata och produktionsskript.
Så jag läser detta Lighthouse SEO-betyg som ett tekniskt bevis, inte en segerdans. Sidan klarar baslinjekontrollerna som ofta blockerar e-handels-SEO: crawlerbar HTML, korrekt metadata, tillgänglig struktur, stabil prestanda och inga uppenbara webbläsar- eller säkerhetsmisstag.
Varför e-handel gör detta svårt
E-handelssidor skapar SEO-felfall som inte dyker upp på enkla marknadsföringssidor.
Produktrutor kan leverera för mycket JavaScript. Produktbilder kan förstöra prestanda om de inte är storleksoptimerade och prioriterade korrekt. Filter kan skapa crawl-fällor. Paginering kan splittra signaler. CMS-beskrivningar kan bryta rubrikstrukturen. Variant-URL:er kan skapa duplicerade sidor. Lageruppdateringar kan tvinga fram breda cache-raderingar. Backend-bild-URL:er kan läcka lokala eller privata sökvägar. Strukturerad data kan driva iväg från vad shopparen ser.
Ett svagt lager kan dra ner hela sidan.
Detta betyg kom från att behandla kategorisidan som ett system, inte som en mall med några få meta-taggar. Samma systemvy ligger bakom mitt arbete med skalning av e-handel med Next.js→.
SEO-arbetet bakom betyget
Det viktiga arbetet skedde innan Lighthouse-körningen.
Vi städade upp kategoricanonicals så att sida ett och paginerade kategorirutter delar en konsekvent bas. Det minskar förvirring kring duplicerade sidor och hindrar paginering från att kämpa mot huvudkategori-URL:en.
Vi återställde en mall-H1-reserv när den redigerbara kategoribeskrivningen inte tillhandahåller en. Det låter litet, men saknade H1:or var en av de tydligaste tekniska SEO-defekterna i crawl-datan.
Vi fixade hanteringen av sitemap-ursprung så att offentliga URL:er löses från korrekt butiksur sprung istället för att läcka backend-antaganden. En sitemap bör vara tråkig. Om den innehåller fel värdar, icke-indexerbara URL:er eller blockerade URL:er slösar den crawl-uppmärksamhet.
Vi skärpte lokaliserade canonicals och hreflang-returlänkar. Flerspråkig e-handels-SEO misslyckas när varje språk pekar utåt men inte tar emot en matchande returväg.
Vi härdade också produkt- och merchant-strukturerad data. E-handelsschema måste matcha verkligheten: produkt, erbjudande, tillgänglighet, merchant-detaljer och leveransdetaljer måste stämma överens med sidan och backend-tillståndet.
Crawl-upprensningen var större än ett betyg
Lighthouse-skärmdumpen är en ren artefakt, men det djupare SEO-värdet kom från crawl-fixarna runt omkring den.
En uppföljande teknisk revision visade riktningen tydligt:
| Problemtyp | Före | Efter |
|---|---|---|
| --- | ---: | ---: |
| Robots-blockerade URL:er | 1 612 | 7 |
| Saknade H1:or | 999 | 67 |
| Icke-indexerbara URL:er i sitemap | 1 185 | 14 |
| Saknade hreflang-returlänkar | 102 | 4 |
| Flera H1:or | 245 | 2 |
| Icke-sekventiell H1-struktur | 2 529 | 2 |
Det är de siffror jag bryr mig mer om än de gröna cirklarna. Lighthouse berättar för mig att sidan klarar en högkvalitativ labbkontroll. Crawl-data berättar för mig att webbplatsen blir lättare för sökmotorer att förstå i stor skala.
Prestanda krävde cachedisciplin
Prestandabetyget kom inte från en enda bildjustering.
Butiksfronten använder en Next.js-frontend över ett PrestaShop-backend. Den setupen ger dig hastighet när cache-gränser är tydliga, och smärta när ogiltigförklaring är för bred.
Vi movede mot scoped invalidation istället för webbplatsomfattande raderingar. Produkthändelser, lagerhändelser, kategoriändringar, tillverkareuppdateringar, bildändringar, CMS-redigeringar och blog/bootstrap-händelser behöver inte alla ha samma sprängradie. När en lagerhändelse raderar hela butiksfronten betalar användarna för det med långsammare sidor och kallare cachar.
Den bättre modellen är enkel: ogiltigförklara den minsta användbara uppsättningen av cache-taggar, låt sedan frontend fortsätta servera stabila kategori- och produktsidor snabbt. Samma engineering-mönster dyker upp i mitt arbete med anpassat CRM CMS med Next.js→: ge redaktörer makt utan att låta dynamiska data skada frontend.
Det är därför kategorisidan kan bära riktiga e-handelsdata och ändå nå 100 i desktop-prestanda och 97 i mobil prestanda.
Ren HTML spelar fortfarande roll
Moderna e-handelsteam behandlar ofta SEO som metadata plus schema. Det är för snävt.
Sidan behöver fortfarande semantisk HTML. Den behöver en förnuftig H1. Den behöver kategoritext som kan redigeras utan att bryta dokumentet. Den behöver produktlänkar som renderas som länkar. Den behöver bilder med korrekta dimensioner och alt-text. Den behöver canonical-URL:er som inte ändras eftersom ett filter eller pagineringstillstånd blandades in i fel lager.
Det är här PageBuilder och rich-text-arbetet spelar roll. En CMS-redaktör bör göra innehåll lättare, inte skapa missformad kategori-HTML. Arbetet med Tiptap React-editor→ hjälpte till att hålla redigerbara block praktiska samtidigt som butikens HTML och säkerhetsregler respekterades.
Samma regel gällde när jag byggde om äldre innehållssystem under en headless WordPress-migrering→: håll redaktörsupplevelsen flexibel, men håll den offentliga HTML:n förutsägbar.
Vad jag inte skulle hävda från detta
Jag skulle inte hävda att ett Lighthouse 100 SEO-betyg betyder att sidan kommer att ranka först.
Sökrankingar beror fortfarande på frågeavsikt, produktsortiment, prissättning, varumärkesförtroende, intern länkning, bakåtlänkar, innehållskvalitet, användarbeteende och hur Google tolkar hela webbplatsen.
Jag skulle inte heller använda Lighthouse som den enda prestandakällan. Labbresultat är användbara eftersom de är repeterbara. Fältdata spelar roll eftersom de kommer från riktiga användare på riktiga enheter och nätverk.
Det ärliga påståendet är smalare och starkare: denna e-handelskategorisida klarade en strikt teknisk kvalitetsgräns samtidigt som den fortfarande betedde sig som en kommersiell sida.
Den praktiska slutsatsen
För e-handels-SEO vill jag att den tekniska plattformen ska flytta sig ur vägen.
Det betyder att kategorisidor renderar användbar HTML. Canonicals och sitemaps berättar en historia. Hreflang är ömsesidigt. Produktdata och strukturerad data matchar. Cachar förblir varma efter små backend-ändringar. Redaktörer kan lägga till innehåll utan att skada sidstrukturen. Bilder laddas snabbt utan att dölja produkten.
När dessa bitar stämmer överens blir ett Lighthouse SEO-betyg som detta möjligt. Viktigare är att SEO-teamet kan spendera tid på det arbete som faktiskt ger avkastning: innehåll, produkttäckning, interna länkar, konvertering och auktoritet.
Jag ser Lighthouse-resultatet som bevis på engineering-kvalitet. Betyget är den synliga delen. Värdet är systemet bakom det.