Lighthouse SEO Score: 100 auf einer Ecommerce-Kategorieseite
Eine Lighthouse SEO-Bewertung von 100 ist auf einer kleinen statischen Seite leicht zu fälschen. Es ist schwieriger auf einer echten Ecommerce-Kategorieseite mit Produktkarten, Bildern, Preisen, Lagerzuständen, Filtern, Canonicals, strukturierten Daten und einem Backend, das immer noch frische kommerzielle Daten bereitstellen muss.
Ich habe Lighthouse am 17. Juni 2026 für `https://www.cigge.se/e-cigaretter/engangs-vape` ausgeführt. Das Desktop-Ergebnis war durchweg sauber: 100 Leistung, 100 Barrierefreiheit, 100 Best Practices und 100 SEO. Das mobile Ergebnis hielt ebenfalls stand: 97 Leistung, 100 Barrierefreiheit, 100 Best Practices und 100 SEO.
Das bedeutet nicht, dass die Seite mit SEO „fertig“ ist. Es bedeutet, dass die technische Basis stark genug ist, damit die SEO-Arbeit sich auf Inhalte, Absicht, interne Links, kommerzielle Daten und Autorität konzentrieren kann, anstatt gegen fehlerhafte Markups, langsame Renderingzeiten oder chaotische Crawlsignale zu kämpfen.
Das Ergebnis
| Lighthouse-Audit | Desktop | Mobil |
|---|---|---|
| --- | ---: | ---: |
| Leistung | 100 | 97 |
| Barrierefreiheit | 100 | 100 |
| Best Practices | 100 | 100 |
| SEO | 100 | 100 |
Die getestete URL war eine live Ecommerce-Kategorieseite, keine abgespeckte Demoroute. Das ist wichtig. Kategorieseiten sind normalerweise der Punkt, an dem headless Ecommerce zuerst chaotisch wird.
Unter den schwedischen Vape-Ecommerce-Seiten, mit denen ich gearbeitet oder die ich getestet habe, habe ich kein schnelleres Ergebnis für eine Kategorieseite gesehen. Ich würde es nur als Schwedens schnellste Vape-Seite nach einem kontrollierten Wettbewerbsbenchmark bezeichnen, aber diese Seite ist ein ernsthafter Kandidat: perfekte Lighthouse-Werte auf Desktop, 97 mobile Leistung und echte Handelsdaten auf der Seite.
Eine Produktdetailseite hat ein Hauptprodukt. Eine Kategorieseite hat viele Produkte, viele Bilder, Sortierung, Filter, Pagination, Produktverfügbarkeit, Preisänderungen, Marketingtexte und interne Verlinkungen. Die Seite muss gleichzeitig Käufer, Suchmaschinen und das CMS-Team bedienen.
Was ein Lighthouse SEO Score beweist
Lighthouse ist ein automatisiertes Audit-Tool vom Chrome-Team von Google. Es überprüft Leistung, Barrierefreiheit, Best Practices, SEO und andere Webqualitätszeichen. Google PageSpeed Insights verwendet ebenfalls Lighthouse für Labordiagnosen.
Ein grüner Score ist keine Rankinggarantie. Die eigene Dokumentation von Google behandelt 90 und darüber als gut, und ein perfektes 100 als schwer aufrechtzuerhalten, sobald eine Seite echte Produktdaten und Produktionsskripte enthält.
Ich lese diesen Lighthouse SEO Score daher als technischen Beweis, nicht als Siegesrunde. Die Seite besteht die grundlegenden Prüfungen, die oft die Ecommerce-SEO blockieren: crawlbares HTML, richtige Metadaten, zugängliche Struktur, stabile Leistung und keine offensichtlichen Browser- oder Sicherheitsfehler.
Warum Ecommerce das schwer macht
Ecommerce-Seiten erzeugen SEO-Fehlermodi, die auf einfachen Marketingseiten nicht auftreten.
Produktgitter können zu viel JavaScript laden. Produktbilder können die Leistung beeinträchtigen, wenn sie nicht richtig dimensioniert und priorisiert sind. Filter können Crawlfallen erzeugen. Pagination kann Signale aufteilen. CMS-Beschreibungen können die Überschriftenstruktur brechen. Varianten-URLs können doppelte Seiten erzeugen. Lageraktualisierungen können umfassende Cache-Löschungen erzwingen. Backend-Bild-URLs können lokale oder private Pfade preisgeben. Strukturierte Daten können von dem abweichen, was der Käufer sieht.
Eine schwache Schicht kann die gesamte Seite nach unten ziehen.
Dieser Score entstand, weil die Kategorieseite als System behandelt wurde, nicht als Vorlage mit ein paar Metatags. Diese Systemansicht liegt auch meiner Arbeit über das Skalieren von Ecommerce mit Next.js→ zugrunde.
Die SEO-Arbeit hinter dem Score
Die wichtige Arbeit fand vor dem Lighthouse-Lauf statt.
Wir haben die Kategorieseiten-Canonicals bereinigt, damit Seite eins und paginierte Kategorieseiten eine konsistente Basis teilen. Das reduziert Verwirrung durch doppelte Seiten und verhindert, dass die Pagination gegen die Hauptkategorie-URL kämpft.
Wir haben einen H1-Fallback für die Vorlage wiederhergestellt, wenn die bearbeitbare Kategoriebeschreibung keinen bereitstellt. Das klingt klein, aber fehlende H1s waren eines der deutlichsten technischen SEO-Defekte in den Crawl-Daten.
Wir haben die Handhabung des Sitemap-Ursprungs korrigiert, sodass öffentliche URLs vom richtigen Storefront-Ursprung aufgelöst werden, anstatt Backend-Annahmen preiszugeben. Eine Sitemap sollte langweilig sein. Wenn sie falsche Hosts, nicht indexierbare URLs oder blockierte URLs enthält, verschwendet sie Crawlanfragen.
Wir haben die lokalisierten Canonicals und hreflang-Rückverlinkungen verschärft. Multilinguale Ecommerce-SEO scheitert, wenn jede Sprache nach außen zeigt, aber keinen passenden Rückweg erhält.
Wir haben auch die strukturierten Daten für Produkte und Händler verstärkt. Ecommerce-Schema muss der Realität entsprechen: Produkt, Angebot, Verfügbarkeit, Händlerinformationen und Versanddetails müssen mit der Seite und dem Backend-Zustand übereinstimmen.
Die Crawl-Bereinigung war größer als ein Score
Der Lighthouse-Screenshot ist ein sauberes Artefakt, aber der tiefere SEO-Wert kam von den Crawl-Fixes darum herum.
Ein nachfolgendes technisches Audit zeigte die Richtung klar:
| Problematik | Vorher | Nachher |
|---|---|---|
| --- | ---: | ---: |
| Von Robots blockierte URLs | 1.612 | 7 |
| Fehlende H1s | 999 | 67 |
| Nicht indexierbare URLs in der Sitemap | 1.185 | 14 |
| Fehlende hreflang-Rückverlinkungen | 102 | 4 |
| Mehrere H1s | 245 | 2 |
| Nicht-sequenzielle H1-Struktur | 2.529 | 2 |
Das sind die Zahlen, die mich mehr interessieren als die grünen Kreise. Lighthouse sagt mir, dass die Seite einen hochwertigen Labortest bestanden hat. Crawldaten sagen mir, dass die Seite für Suchmaschinen einfacher zu verstehen wird.
Leistung benötigte Cache-Disziplin
Der Leistungswert kam nicht von einer Bildanpassung.
Der Storefront verwendet ein Next.js-Frontend über ein PrestaShop-Backend. Dieses Setup bietet Geschwindigkeit, wenn die Cache-Grenzen klar sind, und Schmerzen, wenn die Ungültigung zu umfassend ist.
Wir haben uns in Richtung gezielter Ungültigung bewegt, anstatt siteweite Löschungen durchzuführen. Produktereignisse, Lagerereignisse, Kategoriewechsel, Herstelleraktualisierungen, Bildänderungen, CMS-Bearbeitungen und Blog-/Bootstrap-Ereignisse benötigen nicht alle denselben Radius. Wenn ein Lagerereignis den gesamten Storefront löscht, zahlen die Benutzer dafür mit langsameren Seiten und kälteren Caches.
Das bessere Modell ist einfach: Ungültige die kleinste nützliche Menge an Cache-Tags und lasse dann das Frontend weiterhin stabile Kategorie- und Produktseiten schnell bereitstellen. Dasselbe Ingenieurmuster zeigt sich in meiner benutzerdefinierten CRM-CMS mit Next.js→ Arbeit: Gib den Redakteuren Macht, ohne dass dynamische Daten das Frontend beschädigen.
Deshalb kann die Kategorieseite echte Ecommerce-Daten tragen und dennoch 100 Desktop-Leistung und 97 mobile Leistung erreichen.
Sauberes HTML zählt immer noch
Moderne Ecommerce-Teams behandeln SEO oft als Metadaten plus Schema. Das ist zu eng.
Die Seite benötigt immer noch semantisches HTML. Sie benötigt eine sinnvolle H1. Sie benötigt Kategorietexte, die bearbeitet werden können, ohne das Dokument zu brechen. Sie benötigt Produktlinks, die als Links gerendert werden. Sie benötigt Bilder mit den richtigen Abmessungen und Alt-Text. Sie benötigt kanonische URLs, die sich nicht ändern, weil ein Filter oder ein Paginierungszustand in die falsche Schicht geraten ist.
Hier ist die PageBuilder- und Rich-Text-Arbeit wichtig. Ein CMS-Redakteur sollte Inhalte einfacher machen, nicht fehlerhaftes Kategoriene-HTML erzeugen. Die Tiptap React-Editor→ Arbeit half, bearbeitbare Blöcke praktisch zu halten und gleichzeitig die HTML- und Sicherheitsregeln des Storefronts zu respektieren.
Die gleiche Regel galt, als ich ältere Inhaltssysteme während einer headless WordPress-Migration→ neu aufbaute: Halte die Redakteurerfahrung flexibel, aber halte das öffentliche HTML vorhersehbar.
Was ich nicht behaupten würde
Ich würde nicht behaupten, dass ein Lighthouse 100 SEO-Score bedeutet, dass die Seite an erster Stelle rangiert.
Suchrankings hängen weiterhin von der Suchabsicht, dem Produktsortiment, den Preisen, dem Markenvertrauen, internen Verlinkungen, Backlinks, der Inhaltsqualität, dem Nutzerverhalten und der Interpretation der gesamten Seite durch Google ab.
Ich würde auch Lighthouse nicht als einzige Leistungsquelle verwenden. Laborergebnisse sind nützlich, weil sie wiederholbar sind. Felddaten sind wichtig, weil sie von echten Benutzern auf echten Geräten und Netzwerken stammen.
Die ehrliche Behauptung ist enger und stärker: Diese Ecommerce-Kategorieseite hat ein strenges technisches Qualitätsgate bestanden, während sie sich weiterhin wie eine kommerzielle Seite verhält.
Die praktische Erkenntnis
Für Ecommerce-SEO möchte ich, dass die technische Plattform aus dem Weg geräumt wird.
Das bedeutet, dass Kategorieseiten nützliches HTML rendern. Canonicals und Sitemaps erzählen eine Geschichte. Hreflang ist reziprok. Produktdaten und strukturierte Daten stimmen überein. Caches bleiben warm nach kleinen Backend-Änderungen. Redakteure können Inhalte hinzufügen, ohne die Seitenstruktur zu beschädigen. Bilder laden schnell, ohne das Produkt zu verbergen.
Wenn diese Teile zusammenpassen, wird ein Lighthouse SEO-Score wie dieser möglich. Wichtiger ist, dass das SEO-Team Zeit mit der Arbeit verbringen kann, die tatsächlich kumuliert: Inhalte, Produktabdeckung, interne Links, Konversion und Autorität.
Ich sehe das Lighthouse-Ergebnis als Beweis für Ingenieurqualität. Der Score ist der sichtbare Teil. Der Wert ist das System dahinter.