Stell dir einen Shop vor, in dem jedes Dashboard gut aussieht. Die Startseite ist indexiert, Lighthouse ist grün und der Validator für strukturierte Daten zeigt keine Fehler. Doch genau gleichzeitig stimmt der Preis in Google Shopping nicht mit dem Preis im Warenkorb überein, die mobile Filter-Schublade sperrt Tastaturnutzer ein und jeder Kauf wird doppelt erfasst.
Nichts davon zeigt sich bei einem schnellen Gesundheitscheck. Denn ein Onlineshop ist ein zusammenhängendes System, nicht nur eine einfache Sammlung von Seiten. Produktdaten fließen in die Seite, die strukturierten Daten und die Shopping-Feeds. Skripte und Third-Party-Tags entscheiden darüber, wie schnell alles lädt. Der Checkout verwandelt Interesse in Umsatz, und Analytics soll die gesamte Reise korrekt erfassen. Wenn ein Teil ausfällt, kann es still alles andere verzerren.
Deshalb folgt ein nützliches E-Commerce-Audit dem Kunden und nicht der Sitemap. Die folgende Checkliste beginnt mit der Entdeckung des Shops und endet mit einer abgeschlossenen Bestellung. Sie liefert dir eine priorisierte Liste echter Probleme, jedes mit Belegen, einem Verantwortlichen und einem klaren Test, wann es behoben ist.
Wann dieses Audit durchgeführt werden sollte und warum die Reihenfolge zählt
Führe das vollständige Audit durch, wenn du einen neuen E-Commerce-Kunden übernimmst, nach einem Redesign oder einer Plattformmigration, vor einem großen Wachstumsschub oder wenn ein Routinecheck eine shopweite Verschlechterung aufdeckt. Plane drei bis sechs Stunden für einen leichten Durchlauf ein oder ein bis zwei Tage für ein Standard-Audit, das jedes wichtige Template ordentlich testet. Tiefgehende Untersuchungen von Logs, Feeds oder Analytics brauchen meist separate Zeit.
Die Reihenfolge ist bewusst gewählt. Es bringt nichts, Reibung im Conversion-Prozess zu beurteilen, wenn Google die Kategorieseiten nicht indexieren kann, und es bringt nichts, dem Funnel-Report zu vertrauen, wenn das Purchase-Tag zweimal ausgelöst wird.
Ein doppeltes Purchase-Event ist kein Beweis für mehr Verkäufe, und eine schnelle Produktseite ist nicht gesund, wenn der Preis, den Google sieht, vom Preis im Warenkorb abweicht. Deshalb läuft das Audit in Etappen ab. Es beginnt mit der ersten Entdeckung, geht dann weiter zur Wahrheit der Produktdaten, zur Geschwindigkeit und zum Kauf selbst, und erst danach zur Messung.
Bevor du beginnst, sammle, was du brauchst. Das bedeutet Zugriff auf:
- die Search Console,
- Analytics,
- den Tag Manager,
- die Katalog- oder Feed-Quelle,
- das Merchant Center,
- eine Liste der jüngsten Änderungen an der Website.
Stufe 1: Können Suchmaschinen den Katalog finden?
1. Baue eine Stichprobe, die den ganzen Shop repräsentiert
Die meisten E-Commerce-Bugs stecken in gemeinsam genutzten Templates und ungewöhnlichen Produktzuständen. Eine saubere Startseite sagt dir nichts über gefilterte Kategorien, Variantenlogik, Ausverkäufe oder Checkout. Deshalb solltest du zuerst bestätigen, dass du die Live-Produktionsseite im richtigen Markt, in der richtigen Währung und Sprache testest. Wähle dann mindestens eine URL für jeden der folgenden Fälle:
- die Startseite
- eine priorisierte Kategorie
- eine tiefere Kategorie oder eine zugelassene Filterseite
- ein typisches Produkt
- ein Produkt mit Varianten
- ein nicht vorrätiges oder eingestelltes Produkt
- eine interne Suchergebnisseite, einschließlich einer, die keine Ergebnisse liefert
- den Warenkorb, den Checkout und die Bestellbestätigungsseite
Ergänze ein kniffliges oder ungewöhnliches Beispiel für jedes Template, das riskant aussieht. Dein Landing-Page-Report in Analytics und ein Katalog-Export helfen dir bei der Auswahl.
Du bist fertig, wenn jedes wichtige Template und jeder Checkout-Status eine benannte Test-URL hat und alles, was du nicht testen konntest, als “nicht getestet” markiert ist.
2. Prüfe Crawlbarkeit, Indexierung, Canonicals und Sitemaps
Wenn der Crawl-Pfad kaputt ist, vervielfacht das Veröffentlichen weiterer Produkte nur die Zahl der betroffenen URLs. Widersprüchliche Signale machen Probleme außerdem schwerer zu diagnostizieren. Robots-Regeln können das eine sagen, während Canonical-Tags und Sitemap etwas völlig anderes sagen.
Prüfe robots.txt, die XML-Sitemaps, Response-Codes, Robots-Meta-Tags und -Header, Canonical-Tags, Paginierung und interne Links. Nutze die URL-Prüfung in der Search Console, um zu sehen, welches Canonical Google für deine Beispielseiten tatsächlich gewählt hat. Vergleiche dann die Sitemap mit der Realität. Sie sollte Live-, indexierbare Seiten auflisten, die den Status 200 zurückgeben, keine Weiterleitungen, Fehler, noindexierten Seiten oder Duplikate.
Du bist fertig, wenn deine beabsichtigten Landingpages 200 zurückgeben, gecrawlt werden können, einer konsistenten Canonical- und Indexierungsrichtlinie folgen und in der Sitemap auftauchen. Jeder bedeutende Ausschluss sollte eine Erklärung oder einen Verantwortlichen haben.
3. Folge den Links: Weiterleitungen, Fehler und JavaScript
Ein Shop kann im Browser vollständig aussehen, während Crawler und assistive Technologien eine viel dünnere Version sehen. Lass einen Crawler laufen, um defekte interne Links, Weiterleitungsketten, Schleifen und Soft-404s zu finden. Vergleiche dann die gerenderte Seite mit dem rohen HTML. Produktkarten, Paginierung, Breadcrumbs und Kategorielinks sollten echt und crawlbar sein, und wichtige Inhalte sollten nicht allein von JavaScript abhängen.
Du bist fertig, wenn interne Links direkt auf ihr endgültiges Ziel zeigen, Fehlerseiten den richtigen Statuscode zurückgeben und priorisierte Produkte gefunden werden können, ohne sich auf endloses Scrollen zu verlassen.
4. Teste Kategorien, Filter, Paginierung und Seitensuche
Kategorie- und Filtersysteme können gleichzeitig Crawl-Fallen für Suchmaschinen und Frust für Kunden erzeugen. Eine Seite kann technisch indexierbar und trotzdem eine schwache Landingpage sein, wenn die Hälfte der Produkte darauf irrelevant ist.
Probiere die Filter auf Desktop und Mobil aus. Prüfe Mehrfachauswahl, “Alle löschen”, Ergebniszahlen, Sortierung, Paginierung oder “Mehr laden” und Filterkombinationen, die nichts zurückgeben. Sieh dir die URLs an, die die Filter erzeugen, und vergleiche sie mit der Indexierungsrichtlinie des Shops. Achte auch darauf, ob ein langer Block mit Kategorietext das Produktraster unter den sichtbaren Bereich schiebt.
Du bist fertig, wenn die Bedienelemente sich konsistent verhalten, zufällige Filterkombinationen nicht zu versehentlichen Landingpages werden und Kunden einen Filter rückgängig machen können, ohne ihre Position zu verlieren.
Bereit, Ihr Geschäft zu erweitern?
Starten Sie heute Ihre kostenlose Testversion und sehen Sie innerhalb weniger Tage Ergebnisse.
Stufe 2: Sagen die Produktdaten die Wahrheit?
5. Gleiche Produktidentität, Preis, Lager und Varianten ab
Ein falsches Feld kann einen Kunden nicht nur in die Irre führen, sondern bis zu einer Abweichung im Checkout führen. Gleichzeitig können die Daten perfekt formatiert und trotzdem falsch sein.
Vergleiche für eine Handvoll repräsentativer Produkte Name, Marke, SKU, GTIN oder EAN, ausgewählte Variante, Preis, Währung, Verfügbarkeit, Bilder und wichtige Spezifikationen überall dort, wo sie erscheinen. Prüfe, was auf der Seite, in den strukturierten Daten, im Merchant-Feed, im Warenkorb und im Checkout angezeigt wird. Beziehe Angebotsartikel, Varianten, Ausverkäufe, Vorbestellungen und eingestellte Produkte ein.
Du bist fertig, wenn die geprüften Fakten über alle Oberflächen hinweg übereinstimmen und jede beabsichtigte Abweichung, etwa Marke gegenüber Hersteller, im Datenmodell ausdrücklich ist.
6. Validiere strukturierte Daten gegen das, was Kunden sehen
Strukturierte Daten helfen nur, wenn sie die Seite korrekt beschreiben. Ein Validator akzeptiert ohne Weiteres “InStock”, während die Seite und der Checkout beide sagen, dass das Produkt nicht verfügbar ist. Deshalb solltest du jeden Produktstatus durch den Google Rich Results Test oder den Schema.org Validator laufen lassen. Vergleiche dann die ausgezeichneten Werte mit dem sichtbaren Inhalt und dem Quell-Feed. Prüfe bei Produkten mit Varianten, ob dein Auszeichnungsansatz und dein Canonical-Setup dazu passen, wie die Seiten tatsächlich aufgebaut sind.
Du bist fertig, wenn geprüfte berechtigte Seiten keine fehlenden Pflichteigenschaften haben, die Auszeichnung mit dem Sichtbaren übereinstimmt und Bewertungen und Ratings nur dann ausgezeichnet werden, wenn Kunden sie auf diesem Produkt sehen können.
Stufe 3: Ist der Shop für echte Kunden schnell?
7. Miss Core Web Vitals zuerst anhand der Felddaten
Echte Nutzerdaten und ein einzelner Lighthouse-Lauf beantworten unterschiedliche Fragen. Lighthouse hilft dir, ein Problem zu reproduzieren, kann dir aber nicht sagen, ob echte Kunden bestehen oder durchfallen.
Beginne mit PageSpeed Insights und dem Core-Web-Vitals-Bericht in der Search Console. Notiere, ob Felddaten für die exakte URL oder nur für die gesamte Website vorliegen. Googles “gute” Schwellenwerte, gemessen im 75. Perzentil, sind:
- LCP (Laden): 2,5 Sekunden oder weniger
- INP (Reaktionsfähigkeit): 200 Millisekunden oder weniger
- CLS (visuelle Stabilität): 0,1 oder weniger
Betrachte Mobil und Desktop getrennt. Wenn keine Felddaten vorliegen, notiere das Ergebnis als unbekannt und behandle Laborergebnisse als vorläufig. Unbekannt ist nicht dasselbe wie grün.
Du bist fertig, wenn jedes priorisierte Template ein Feldurteil pro Gerät hat oder ein klar benanntes Fehlen von Daten, mit Quelle und Zeitraum festgehalten.
8. Finde die Ursache, nicht nur den Score
Allgemeine Ratschläge wie “komprimiere deine Bilder” oder “reduziere JavaScript” verfehlen oft den echten Engpass und erzeugen Arbeit, die die fehlerhafte Kennzahl nicht bewegt. Finde das konkrete Element, die Anfrage oder das Skript, das dafür verantwortlich ist.
Identifiziere das LCP-Element und was es verzögert. Prüfe dann die üblichen Verdächtigen, etwa Bildgrößen, Lazy-Loading bei Bildern im sichtbaren Bereich, render-blockierendes CSS, Schriftladen, Third-Party-Skripte, lange Tasks, Caching, Serverantwortzeit, Quellen für Layout-Verschiebungen und doppelt geladene Tags.
Führe Wiederholungstests unter denselben Bedingungen durch und vergleiche eine konsistente Statistik, nicht deinen besten Lauf. Denk daran, dass Total Blocking Time ein nützliches Laborsignal ist, aber nicht INP.
Du bist fertig, wenn jeder bedeutende Performance-Befund die fehlerhafte Kennzahl, das betroffene Template, eine reproduzierbare Ursache und einen Verantwortlichen nennt.
Abonnieren Sie unseren Newsletter
Erhalten Sie die neuesten Tipps, Trends und Angebote kostenlos.
Stufe 4: Können Menschen tatsächlich etwas kaufen?
9. Teste mobile Nutzbarkeit und Barrierefreiheit an echten Shopping-Bedienelementen
Automatisierte Scores decken nicht jede Interaktion ab. Ein Shop kann einen Scan bestehen, während die Filter-Schublade den Tastaturfokus einsperrt, das Cookie-Banner den In-den-Warenkorb-Button verdeckt oder der Größenauswahl ein zugängliches Label fehlt.
Teste bei Telefonbreiten von 360 bis 390 Pixeln, zoome den Text und versuche die ganze Reise nur mit einer Tastatur. Beobachte Fokusreihenfolge und Sichtbarkeit in Menüs, Schubladen und Dialogen. Prüfe, ob Labels, Buttons, Formularfehler und Touch-Ziele noch Sinn ergeben.
Du bist fertig, wenn ein Kunde die Hauptreise ohne versteckte Bedienelemente oder Fokus-Fallen durchlaufen kann und auf Mobil nichts den Preis, die Verfügbarkeit, die Variantenauswahl, den In-den-Warenkorb-Button oder den Checkout verdeckt.
10. Führe Warenkorb und Checkout als kontrollierten Test durch
Ein sichtbarer Checkout-Button beweist nicht, dass der Checkout funktioniert. Checkout-Bugs sind kommerzielle Vorfälle und untergraben außerdem deine Analytics.
Um das zu testen, lege ein normales Produkt und eine Variante in den Warenkorb. Ändere die Menge, entferne einen Artikel und wende einen Gutschein (oder einen absichtlich ungültigen) an, falls du einen hast. Teste dann Gast- und Konto-Checkout, Versandoptionen, Zahlungsauswahl, Validierungsfehler, die Zurück-Schaltfläche und das mobile Layout. Nutze eine Testbestellung oder einen genehmigten, nicht belastenden Pfad. Gib niemals ohne Erlaubnis eine echte Bestellung auf.
Du bist fertig, wenn der Kauf abgeschlossen wird oder die vereinbarte Testgrenze erreicht, Summen korrekt bleiben, Fehlermeldungen den Leuten sagen, was zu tun ist, und jeder blockierte Pfad mit Belegen und geschäftlicher Auswirkung dokumentiert ist.
Stufe 5: Misst du die Reise korrekt?
11. Überprüfe Analytics, doppelte Tags und Consent
Doppelte Tags blähen Seitenaufrufe, Add-to-Cart-Events und Käufe auf. Fehlende oder fehlerhafte Werte machen Umsatzberichte zu einer unsicheren Entscheidungsgrundlage. Das Ziel ist einfach: Eine Kundenaktion sollte genau ein Event erzeugen, mit dem richtigen Produkt, Wert, der richtigen Währung, Transaktions-ID und dem richtigen Consent-Status.
Liste jeden Tag-Manager-Container, jedes Google-Tag, jedes Ad-Pixel, jedes Affiliate-Skript und jede serverseitige Integration auf. Verfolge dann in einer kontrollierten Sitzung view_item, add_to_cart, begin_checkout und purchase. Vergleiche, was der Browser sendet, mit der GA4-DebugView und dem Bestelldatensatz im Backend. Teste vor und nach der Consent-Entscheidung des Kunden.
Du bist fertig, wenn jede Aktion ihr Event genau einmal auslöst, Käufe eine stabile Transaktions-ID tragen, Werte und Währung mit dem Backend übereinstimmen und nicht wesentliche Tags die Consent-Richtlinie respektieren.
12. Gleiche Search Console und Merchant Center mit dem ab, was du gefunden hast
Ein lokaler Seitentest kann dir nicht jedes indexierte Canonical, jede Sitemap-Warnung, jede Produktablehnung oder jede verlorene Suchanfrage zeigen. Ein Dashboard-Alarm kann andererseits ein Problem beschreiben, das bereits behoben wurde.
Prüfe deine priorisierten URLs in der Search Console, sieh dir die Produkt- und Merchant-Listing-Berichte an und vergleiche die Merchant-Center-Diagnosen mit dem, was du auf der Live-Website gesehen hast. Notiere die Daten, denn Re-Crawling und Feed-Verarbeitung hinken Deployments hinterher.
Du bist fertig, wenn jedes bedeutende Dashboard-Problem mit Live-Belegen übereinstimmt oder als noch in Ausbreitung befindlich markiert ist und jedes offene Problem einen Verantwortlichen hat.
Stufe 6: Würde ein Kunde diesem Shop vertrauen?
13. Prüfe Vertrauenssignale, Kontaktdaten, Versand und Rückgabe
Versteckte oder widersprüchliche kommerzielle Informationen lassen Kunden zögern und treiben Support-Tickets in die Höhe. Vergleiche Header und Footer, Kontaktseite, Checkout und Richtlinienseiten.
Du bist fertig, wenn die Unternehmensidentität klar ist, Aussagen zu Versand, Rückgabe und Zahlung über die gesamte Reise übereinstimmen und kein Vertrauens-Badge unüberprüfbar ist.
14. Prüfe HTTPS, gemischte Inhalte und Front-End-Hygiene
Das ist kein Penetrationstest, sondern eine Frage grundlegender Datenhygiene. Bestätige, dass HTTP in einem einzigen Sprung auf HTTPS weiterleitet, das Zertifikat gültig ist, es keine gemischten Inhalte gibt und Formulare korrekt übermittelt werden. Prüfe die Konsole auf schwerwiegende Fehler. Wenn etwas wie eine echte Sicherheitslücke aussieht, gib es an einen Spezialisten weiter, statt es anhand einer allgemeinen Warnung zu diagnostizieren.
Du bist fertig, wenn priorisierte Seiten und der Checkout sicher laden, Weiterleitungen einen Sprung brauchen und Formulare sich wie erwartet verhalten.
Von Befunden zu Korrekturen
15. Verwandle Befunde in eine verantwortete Abarbeitungsliste
Ein Audit, das mit Screenshots oder einem Score endet, reduziert kein Risiko. Fünfzig Symptome, die durch ein einziges defektes Template verursacht werden, sollten nicht zu fünfzig unzusammenhängenden Tickets werden. Gruppiere Befunde nach ihrer Ursache. Notiere, ob es die Komponente, das Template, die Feed-Regel oder das Tracking-Setup ist. Behalte die betroffenen URLs als Belege. Priorisiere dann:
- P0: ein aktiver Ausfall, der das Geschäft blockiert, oder ein kritisches websiteweites Problem
- P1: ein bedeutender Defekt, bei dem du dir sicher bist
- P2: ein wichtiges Problem mit begrenztem Umfang
- P3: eine Verbesserung, die beobachtet werden sollte
Du bist fertig, wenn jeder bedeutende Befund einen Verantwortlichen, ein Fälligkeitsdatum, einen Test für “behoben” und ein Datum hat, an dem er nach dem Release erneut geprüft wird.
Das Ergebnis
Übergib ein versioniertes Dokument oder eine Tabelle mit einer Zeile pro Befund und einer kurzen Zusammenfassung oben. Jede Zeile sollte abdecken:
- das Verhalten,
- das erwartete Verhalten,
- die betroffenen URLs,
- die Belege und wann du sie gesammelt hast,
- Schweregrad und Sicherheit,
- die wahrscheinliche Ursache,
- die empfohlene Korrektur,
- den Verantwortlichen und den Test, der beweist, dass es erledigt ist.
Aber denk daran: Du solltest ein Problem nicht als behoben markieren, weil jemand das Ticket geschlossen hat. Markiere es als verifiziert, wenn der Test in der Produktion besteht.
Tools für die Aufgabe
Du brauchst keine Abonnements, um einen starken ersten Durchlauf erfolgreich zu machen. Alles, was du brauchst, sind diese kostenlosen Tools:
- Google PageSpeed Insights für Felddaten (sofern verfügbar) und Lighthouse-Diagnosen
- Google Search Console für Indexierung, Sitemaps, URL-Prüfung, Core Web Vitals und Berichte zu strukturierten Daten
- Google Rich Results Test und der Schema.org Validator für strukturierte Daten
- Chrome DevTools und Lighthouse für Netzwerk-, Performance-, Layout-Verschiebungs-, Barrierefreiheits- und Konsolenprüfungen
- Google Tag Assistant und GA4 DebugView für Event-Tracking
- SSL Labs Server Test für die TLS-Konfiguration
Wenn du eine Abkürzung möchtest, kannst du mit AmICited all diese Belege zusammenführen und die Baseline für später behalten. Die Ansicht Performance Impact vergleicht Templates nach LCP, INP, CLS und Serverantwortzeit. URL Inspection und Sitemaps and Indexing verfolgen die Indexierung für priorisierte URLs. Products und Assortment zeigen, welche Teile des Katalogs das größte kommerzielle Gewicht tragen. Annotations im Reports Hub verbinden jedes Release mit dem, was danach passiert ist. Die Tools liefern die Belege. Der Shop-Inhaber, Entwickler oder Analyst entscheidet weiterhin, was korrekt ist und welche Kompromisse akzeptabel sind.
Nach dem Audit
Sende jedes bestätigte Problem an den spezialisierten Workflow, der es schließen kann: Crawl- und Rendering-Probleme an ein technisches SEO-Audit , Feld-Performance-Fehler an die Core-Web-Vitals-Behebung , Facetten- und Lagerstatus-Probleme an ein Kategorie- und Produkt-Review und Tracking-Probleme an die Person, die für Analytics verantwortlich ist.
Es ist nicht nötig, das ganze Audit nach jeder Korrektur erneut durchzuführen. Teste den betroffenen Bereich erneut, kommentiere das Release, damit du siehst, was sich danach geändert hat, und lass den regulären Gesundheitscheck die nächste Verschlechterung aufdecken.
Zurück zu dem Shop, in dem alles gut aussah
Erinnerst du dich an den Shop vom Anfang? Seine Startseite war indexiert, Lighthouse war grün und der Validator war sauber. Trotzdem zeigte Google Shopping den falschen Preis, die Filter-Schublade sperrte Tastaturnutzer ein und jeder Verkauf wurde doppelt gezählt.
Kein Dashboard meldete etwas davon. Diese Checkliste hätte alle drei erfasst: die Preisabweichung in Schritt 5, die Fokus-Falle in Schritt 9 und den doppelt gezählten Kauf in Schritt 11. Jedes davon bricht irgendwo entlang des Kundenpfads, und genau dort schaut das Audit hin.
Das bringt es, dem Kunden statt der Sitemap zu folgen. Du hörst auf zu fragen: “Sieht die Website gesund aus?” und beginnst, vier schwierigere Fragen zu stellen. Können Menschen das Produkt finden? Ist wahr, was der Shop darüber sagt? Können sie es tatsächlich kaufen? Und kannst du sehen, dass sie es getan haben? Ein Shop, der alle vier mit Ja beantworten kann, ist in besserer Verfassung als einer mit einem perfekten Score.
Also wähle deine Beispiel-URLs, blockiere die Zeit und beginne mit Stufe 1. Der erste Durchlauf ist der langsamste. Danach geht es vor allem darum, sicherzustellen, dass das, was du behoben hast, behoben bleibt.
