Technisches SEO im E-Commerce: Crawling, Rendering und Indexierung im großen Maßstab

Technisches SEO im E-Commerce ist die Arbeit, die Suchmaschinen erlaubt, die richtigen URLs eines Onlineshops zu crawlen, zu rendern und zu indexieren und zu verstehen, was jede Produktseite verkauft. Es umfasst Crawl-Steuerung, JavaScript-Rendering, Indexregeln pro Seitentyp, Seitenarchitektur, Paginierung, XML-Sitemaps, strukturierte Daten und Ladezeit. Auf einer Broschüren-Website mit zehn Seiten erledigt sich das meiste von selbst. In einem Katalog nicht, denn jedes Produkt, jede Variante, jeder Filter, jede Sortierung, jede Seitenzahl und jede Sprache vervielfacht die Zahl der URLs, die ein Crawler finden kann.

Dieser Ratgeber ist für Shops, die die Grundlagen schon erledigt haben. Für einen ersten Durchgang starte mit dem E-Commerce-SEO-Audit, und für Filter lies den Ratgeber zu Faceted Navigation und SEO. Hier gehen wir eine Ebene tiefer: wie du misst, was der Googlebot in deinem Shop wirklich tut, und wie du Regeln pro Template festlegst, die auch dann halten, wenn sich der Katalog verdoppelt.

Das URL-Inventar: Zähle, was ein Crawler finden könnte, bevor du etwas reparierst

Die meisten technischen SEO-Probleme in Shops sind Rechenaufgaben. Bevor du auch nur ein Tag änderst, schreib auf, wie viele URLs jedes Template erzeugen kann. Als durchgehendes Beispiel nehmen wir einen Outdoor-Shop:

• 4.200 Produkte, davon 1.300 mit Varianten, insgesamt 11.000 Varianten-SKUs.
• 180 Kategorien, jede mit 5 Filtern, 4 Sortierungen und 24 Produkten pro Seite.
• 3 Sprachen (Englisch, Niederländisch, Deutsch) in Unterordnern.
• Variantenauswahl über einen ?variant=-Parameter, interne Suche unter /search?q=.

Allein die Produkte ergeben 12.600 Produkt-URLs in drei Sprachen. Variantenparameter fügen bis zu 33.000 weitere hinzu, wenn sie verlinkt sind. Kategorien mit durchschnittlich 3 Seiten ergeben 1.620 Listing-URLs, und die 4 Sortierungen vervielfachen das auf 6.480, bevor auch nur ein Filter angeklickt ist. Kombiniere zwei Filter, und du landest im sechsstelligen Bereich. Der Shop will etwa 14.200 URLs im Index: Produkte, Kategorien und deren Paginierung, in drei Sprachen.

Diese Lücke zwischen möglichen und gewünschten URLs ist die ganze Aufgabe. Jede Regel im Rest dieses Ratgebers verhindert entweder, dass unerwünschte URLs gefunden werden, sagt Google, welche Version es indexieren soll, oder macht die gewünschten URLs leichter erreichbar und verständlich.

Serverlogs zeigen, was der Googlebot wirklich anfragt

Ein Crawler wie Screaming Frog zeigt, was sich von der Startseite aus finden lässt. Deine Serverlogs zeigen, was der Googlebot wirklich abgerufen hat, wie oft und mit welcher Antwort. In einem Katalog ist das selten dasselbe. Bitte deinen Hoster oder deine Plattform um rohe Access-Logs für mindestens 30 Tage, filtere auf den Googlebot-User-Agent und verwirf Zugriffe, die einen Reverse-DNS-Check nicht bestehen, denn viele Scraper fälschen diesen User-Agent.

Gruppiere dann jede Anfrage nach Template, mit URL-Mustern, die du schon kennst (/products/, /collections/, ?sort=, ?page=, /search). Die nützlichen Fragen sind einfach:

• Anteil der Anfragen pro Template. Wenn Sortier- und Filter-URLs 40 % der Googlebot-Zugriffe ausmachen, Produkte aber nur 25 %, geht die Crawl-Aktivität an die falsche Stelle.
• Tage seit dem letzten Crawl pro Produkt. Produkte, die der Googlebot seit 30 Tagen nicht angefragt hat, zeigen in der Suche veraltete Preise und Bestände.
• Statuscodes pro Template. Ein Haufen 301er auf Produkt-URLs bedeutet meist, dass interne Links noch auf alte URLs zeigen.
• Nie gecrawlte Produkte. Produkte in deinem Katalogexport, die in 30 Tagen Logs nicht auftauchen, sind praktisch unsichtbar.

Wenn du keine Logs bekommst, ist der Crawling-Statistikbericht in der Search Console die nächstbeste Quelle. Er schlüsselt Anfragen nach Antwortcode, Dateityp, Googlebot-Typ und Zweck auf, wobei Erkennung (Discovery) eine URL bedeutet, die Google noch nie gecrawlt hat, und Aktualisierung (Refresh) einen erneuten Crawl einer bekannten Seite. Ein Shop, der 300 neue Produkte pro Woche launcht und kaum Erkennungsanfragen sieht, hat ein Discovery-Problem, meist in den Sitemaps oder internen Links.

Crawl-Verschwendung im Katalog: Soft 404s, Weiterleitungsketten und noindex

Googles Leitfaden zum Crawl-Budget richtet sich an Websites mit 1 Million oder mehr einzigartigen Seiten, die sich etwa wöchentlich ändern, oder 10.000 oder mehr Seiten, die sich täglich ändern. Ein Shop mit 4.200 Produkten liegt unter beiden Grenzen, aber Filter- und Sortierkombinationen können die Zahl crawlbarer URLs weit darüber treiben, und Preis- oder Bestandsänderungen lassen Produktseiten sich täglich ändern. Behandle Crawl-Effizienz also als echte Einschränkung, sobald deine Logs zeigen, dass der Googlebot die meiste Zeit außerhalb deiner gewünschten URLs verbringt.

Derselbe Leitfaden nennt, was in Shops Crawling verschwendet:

• Soft 404s. Eine ausverkaufte Produktseite, die „nicht mehr verfügbar“ mit Status 200 meldet, wird weiter gecrawlt. Gib für verschwundene Produkte einen echten 404 oder 410 zurück, oder leite sie auf einen passenden Nachfolger weiter.
• Lange Weiterleitungsketten. Ein dreimal umbenanntes Produkt kann hinter drei Sprüngen liegen. Lass interne Links und Sitemap-Einträge direkt auf die finale URL zeigen.
• noindex als Crawl-Sparer. Google fragt eine Seite mit noindex trotzdem an und verwirft sie dann, noindex spart also kein Crawling. Nutze robots.txt für URL-Muster, die nie gecrawlt werden sollen, etwa Sortierungen und interne Suche.
• Fehlendes lastmod. Google liest Sitemaps regelmäßig. Ein korrektes <lastmod> bei geänderten Produkten hilft bei der Auswahl, was erneut gecrawlt wird.
• Keine 304-Unterstützung. Server, die für unveränderte Seiten 304 Not Modified antworten, lassen Google seine Kopie wiederverwenden, was zählt, wenn sich Tausende Produktseiten seit dem letzten Besuch nicht geändert haben.

Auch die Servergesundheit zählt. Wenn der Shop mit 5xx-Fehlern oder 429-Rate-Limits antwortet, verlangsamt Google das Crawling und beschleunigt erst allmählich wieder. Ein langsames Kategorie-Template während eines Sales kann dich erneute Crawls genau der Produkte kosten, die du gerade neu bepreist hast.

Rendering: was der Googlebot vor und nach JavaScript sieht

Google verarbeitet JavaScript-Websites in drei Phasen: Crawling, Rendering und Indexierung. Laut Googles JavaScript-SEO-Grundlagen kommt jede Seite mit Status 200 in eine Render-Warteschlange, wo sie einige Sekunden oder länger warten kann. Für Shops zählen zwei Folgen. Erstens erkennt Google nur Links, die <a>-Elemente mit einem href sind, ein „Ähnliche Produkte“-Karussell aus Klick-Handlern gibt also keine Links weiter. Zweitens kommt alles, was erst nach dem Rendering existiert, später an als das, was im HTML steht.

Dieser zweite Punkt ist für Produktdaten entscheidend. Google sagt, dass dynamisch generiertes Product-Markup Shopping-Crawls seltener und weniger zuverlässig machen kann, was bei schnell wechselnden Inhalten wie Preis und Verfügbarkeit ein Problem ist. Wenn dein Theme oder dein Headless-Frontend Product-JSON-LD per JavaScript nach einem clientseitigen API-Aufruf einfügt, verschiebe es ins serverseitig gerenderte HTML.

Ein schneller Test pro Template: Öffne den Seitenquelltext (nicht den Inspector) und suche nach Produktname, Preis, GTIN und den ersten beiden Kategorielinks. Führe dann die URL-Prüfung in der Search Console aus und vergleiche mit dem gerenderten HTML. Alles, was im Quelltext fehlt, aber nach dem Rendering da ist, hängt von der Render-Warteschlange ab.

• Muss im Server-HTML stehen: Title-Tag, Canonical, Robots-Meta, H1, Preis, Verfügbarkeit, Product-JSON-LD, Breadcrumb-Links, Links zu Produkten auf Kategorieseiten, Paginierungslinks.
• Darf clientseitig gerendert werden: Bewertungs-Widgets unterhalb des sichtbaren Bereichs, zuletzt angesehene Artikel, personalisierte Empfehlungen, Chat.

Indexregeln pro Template, einmal für den ganzen Katalog festgelegt

Entscheidungen pro URL skalieren nicht. Lege eine Regel pro Template fest und setze sie in den Theme- oder Plattformeinstellungen durch. Für den Outdoor-Shop sieht das so aus:

Regeln auf Feldebene wie Titel, Beschreibungen und Bilder pro Produktseite behandelt der Ratgeber zu Produktseiten-SEO. Plattformspezifische Einstellungen findest du in der Shopify-SEO-Checkliste und im Magento-SEO-Ratgeber.

Seitenarchitektur für große Kataloge: Tiefe, Hubs und verwaiste Produkte

Die Architektur entscheidet, wie schnell ein Crawler ein Produkt erreicht und wie viel internes Linkgewicht es bekommt. In einem Katalog verlinkt das Menü auf Kategorien, Kategorien auf Produkte, und Produkte verlinken seitlich auf ähnliche Produkte und über Breadcrumbs zurück nach oben. Drei Checks halten diese Struktur gesund, während der Katalog wächst:

• Klicktiefe. Crawle von der Startseite und zähle die Klicks bis zu jedem Produkt. Wenn Listing-Seiten nur auf die nächste Seite verlinken, liegt ein Produkt auf Seite 6 einer Kategorie mit 140 Produkten 7 Klicks von der Startseite entfernt. Teilst du diese Kategorie in vier Unterkategorien mit je 35 Produkten auf, sind es wieder 4.
• Kategoriegröße. Eine Kategorie mit 1.200 Produkten und 24 pro Seite hat 50 Seiten, und die Produkte auf den letzten Seiten werden am wenigsten gecrawlt. Unterkategorien auf Basis echter Attribute (Isolationsart, Füllgewicht) verkürzen diesen Schwanz und geben dir Landingpages für echte Suchanfragen.
• Waisen. Vergleiche die URLs in deinem Produktexport mit den URLs, die ein Crawler erreicht hat. Produkte, die im Export, aber nicht im Crawl stehen, haben keine internen Links: oft Artikel ohne Kategorie oder solche, die nur in einer im Menü ausgeblendeten Kategorie gelistet sind.

Verwaiste Produkte sind meist ein Produktdatenproblem, kein Theme-Problem. Ein Produkt mit leerem Kategoriefeld erscheint nie auf einer Listing-Seite. Korrigiere zuerst die Kategoriezuordnung in deinem Katalog und prüfe dann, ob das Template den Link als crawlbares <a href> ausgibt.

Seitenzahlen, Mehr-laden-Buttons und Infinite Scroll

Googles Paginierungs-Leitfaden für E-Commerce ist kurz und konkret. Gib jeder Seite eine eigene URL, zum Beispiel ?page=2. Setze nicht Seite 1 als Canonical für die ganze Serie, denn das sagt Google, dass Seite 2 und folgende Duplikate sind, und die Produkte darauf verlieren einen Weg, gefunden zu werden. Verlinke die Seiten mit normalen <a href>-Links untereinander. Google nutzt rel="next" und rel="prev" nicht mehr, andere Suchmaschinen eventuell schon.

Mehr-laden-Buttons und Infinite Scroll brauchen Sorgfalt. Googles Crawler klicken keine Buttons und lösen in der Regel kein JavaScript aus, das eine Nutzeraktion braucht. Wenn deine Kategorie Infinite Scroll nutzt, halte dahinter eine paginierte Version mit echten Links bereit, und sorge dafür, dass jedes Produkt auch in deiner XML-Sitemap oder einem Merchant-Center-Feed steht, damit es ohne das Listing gefunden werden kann.

Zwei katalogspezifische Tipps: Wähle eine Seitengröße, die die meisten Kategorien unter fünf Seiten hält, und setze Seitenzahlen nie hinter ein #-Fragment, denn Google ignoriert Fragment-Identifier.

XML-Sitemaps aus Produktdaten generieren

Eine Sitemap ist eine Liste der URLs, die du in der Suche haben willst. In einem Shop sollte sie aus dem Katalog generiert werden, nicht aus einem Crawl. Googles Sitemap-Dokumentation legt Grenzen und Regeln fest:

• Jede Sitemap enthält höchstens 50.000 URLs oder 50 MB unkomprimiert. Nutze einen Sitemap-Index, um mehrere Dateien zusammenzufassen.
• Nutze absolute URLs und liste nur kanonische URLs auf, also die Version, die in den Ergebnissen erscheinen soll.
• Google ignoriert <priority> und <changefreq>, verschwende also keine Zeit damit.
• Google nutzt <lastmod> nur, wenn es durchgehend korrekt ist. Ändere es bei relevanten Updates an Hauptinhalt, strukturierten Daten oder Links, nicht für ein neues Copyright-Jahr.

Teile Sitemaps nach Template und Sprache auf, zum Beispiel products-en.xml, products-nl.xml und categories-en.xml. Die Search Console meldet die Indexierung dann pro Datei, und du siehst, dass 96 % der englischen Produkte indexiert sind, aber nur 61 % der deutschen. Lass weitergeleitete, auf noindex gesetzte, kanonisierte und gelöschte URLs weg. Und steuere <lastmod> aus dem Produktdatensatz: Eine Preisänderung aktualisiert das Offer-Markup, zählt also als Änderung der strukturierten Daten.

Strukturierte Daten im großen Maßstab: aus dem Katalog generieren, nicht aus dem Theme

Die meisten Shops geben Product-Markup aus einem Theme-Template aus, was funktioniert, bis die Daten dahinter unvollständig sind oder die Varianten kompliziert werden. Bei Katalog-Größe behandelst du strukturierte Daten als Export deiner Produktdaten und prüfst sie so, wie du einen Feed prüfst.

Für Varianten unterstützt Google ProductGroup-Markup. Das Elternprodukt trägt eine productGroupID (die Eltern-SKU), variesBy nennt die Dimensionen, die sich ändern, und hasVariant listet jede Variante als Product auf. Unterstützte variesBy-Werte sind color, size, suggestedAge, suggestedGender, material und pattern. Es gibt zwei Setups:

• Eine Seite: Alle Varianten leben auf einer Seite, mit einer kanonischen URL für die Gruppe. Jede Variante braucht trotzdem eine eigene URL, die sie vorauswählt, meist ein Query-Parameter.
• Mehrere Seiten: Jede Variante hat ihre eigene Seite mit vollständigem, eigenständigem Markup. Es gibt kein gemeinsames Canonical für die Gruppe.

Nimm eine Daunenjacke in 3 Farben und 5 Größen: 15 Varianten, jede mit eigener GTIN, eigenem Preis und eigenem Bestand. Wenn das Template Farbe und Größe aus dem Elternprodukt liest, melden alle 15 Variantenobjekte dieselben Werte, und Google sieht Duplikate. Wenn 4 der 15 GTINs leer sind, gehen diese Varianten ohne Identifier raus. Keines der beiden Probleme zeigt sich in einer Theme-Vorschau, und beide werden in den Daten behoben, nicht im Markup.

Praktische Checks im großen Maßstab: Validiere eine URL pro Template mit dem Test für Rich-Suchergebnisse und beobachte dann die Berichte zu Händlereinträgen und Produkt-Snippets in der Search Console auf Fehler, die sich über viele URLs verteilen. Zähle leere GTIN-, Marken-, Farb- und Größenwerte pro Kategorie in deinem Katalog, bevor du dem Template die Schuld gibst. Als Referenzbeispiel zum Vergleich mit deiner Ausgabe nutze den Product-Schema-Generator.

LCP-Bilder, Layoutverschiebungen und App-Skripte in Katalog-Templates

Geschwindigkeitsprobleme in Shops wiederholen sich pro Template, also miss pro Template-Typ eine Produktseite und eine Kategorieseite auf einem Mittelklasse-Smartphone und behebe dann das Template. Das Produktbild ist meist das Largest-Contentful-Paint-Element. Lade es nie per Lazy Loading, mach es im HTML-Quelltext auffindbar, statt es per JavaScript einzufügen, und gib ihm fetchpriority="high". Zerlege einen langsamen LCP in seine Teile (Serverantwort, Ladeverzögerung, Ladezeit und Renderverzögerung), bevor du einen schnelleren Hoster kaufst, denn die Verzögerung ist oft ein Skript, das läuft, bevor das Bild angefragt wird.

Layoutverschiebungen auf Katalogseiten kommen oft aus den Daten: Bilder ohne Breite und Höhe, Farbfelder, die nach dem Preis laden, ein „Nur noch wenige“-Badge, das den In-den-Warenkorb-Button nach unten schiebt. Speichere Bildabmessungen mit dem Bilddatensatz, damit das Template Platz reservieren kann. Interaktionsverzögerungen kommen meist von Filterskripten und Drittanbieter-Apps, also liste jedes Skript auf einer Kategorieseite mit der App auf, die es lädt, und entferne, was niemand nutzt.

Eine vierteljährliche Routine für technisches SEO in einem wachsenden Katalog

Mehrere dieser Checks beginnen im Katalog statt im Code. WISEPIMs Sitemap-Coverage-Analyse ordnet deine Sitemap-URLs Produktdatensätzen zu, und die Analyse interner Links listet verwaiste Produkte neben ihren Search-Console-Daten auf. Weil WISEPIM GTINs, Kategorien und Variantenattribute vollständig hält, bevor sie in deinen Shop übertragen werden, bleiben die daraus gebauten strukturierten Daten und Sitemaps korrekt, während der Katalog wächst.