Technisches SEO für Shops: Crawling, Duplikate, Parameter

Technische Suchmaschinenoptimierung (SEO) entscheidet, ob eine Suchmaschine die Seiten eines Shops abrufen, lesen und einer Adresse zuordnen kann. Der Audit prüft deshalb zuerst die Erreichbarkeit und die Steuerungsdateien, danach doppelte Adressen und Parameteradressen. Die technischen Aussagen stammen aus der Dokumentation von Google Search und aus RFC 9309, dem Standard für die Robots-Exclusion-Protocol-Datei (IETF, September 2022); die Schweregrade sind eine redaktionelle Einschätzung. Eine Reihenfolge der Maßnahmen steht in SEO-Grundlagen für Onlineshops. Ausgesagt wird hier über Google; andere Suchmaschinen können abweichen.

Was Sie vorab brauchen

• Zugriff auf die Search Console des Shops: Bericht zur Seitenindexierung und URL-Prüfung.
• Eine Liste der wichtigen Adressen (Startseite, Kategorien, Produktseiten, Rechtstexte); ein Export der Sitemap oder des Shopsystems genügt.
• Zugriff auf die Datei robots.txt und auf die Stelle, an der Weiterleitungen gesetzt werden.
• Eine Entscheidung je Seitentyp, ob er in den Suchergebnissen erscheinen soll. Ohne sie lassen sich Sperren nicht beurteilen.

Schritt für Schritt: der technische Audit

Schritt 1: Statuscodes der wichtigen Adressen erheben

Rufen Sie jede wichtige Adresse ab und notieren Sie den HTTP-Statuscode. Google beschreibt in seiner Dokumentation zu HTTP-Statuscodes: 2xx wertet den Inhalt zur Indexierung aus, ohne Indexgarantie. Bei 3xx folgen die Crawler standardmäßig bis zu zehn Weiterleitungssprüngen. 4xx außer 429 bedeutet: Der Inhalt wird ignoriert, eine bereits indexierte Adresse verschwindet aus dem Index. 5xx und 429 gelten als Serverfehler; sie bremsen das Crawlen, und Adressen, die dauerhaft mit einem Serverfehler antworten, nimmt Google aus dem Index.

Prüfen Sie zusätzlich auf soft 404: Die Adresse antwortet mit 200, zeigt aber eine Fehlerseite (“Artikel nicht gefunden”). Die Seite wird weiter gecrawlt und im Bericht zur Seitenindexierung als soft 404 geführt. Ob Ihre Ladezeiten eine Rolle spielen, behandelt Ladezeit und Core Web Vitals.

Ergebnis: eine Liste mit Adresse, Statuscode und Auffälligkeit.

Schritt 2: robots.txt lesen und gegen die Wunschliste halten

Die Datei liegt unter /robots.txt im Wurzelverzeichnis, ist UTF-8-kodiert und gilt nur für den Host, das Protokoll und den Port, unter dem sie liegt. Zulässig sind die Zeilen user-agent, allow, disallow und sitemap. Der Pfadwert ist groß- und kleinschreibungssensitiv, * steht für beliebig viele Zeichen, $ für das Ende der Adresse. Bei widersprüchlichen Regeln gilt die spezifischste; sind allow und disallow gleich spezifisch, gilt allow. Google verarbeitet die Datei bis zu einer Größe von 500 KiB; RFC 9309 verlangt, dass ein Crawler mindestens so viel liest.

Zwei Befunde wiegen schwer: eine gesperrte Seite, die erscheinen soll, und eine Datei, die mit einem Serverfehler antwortet. Bei einem Abruffehler stellt Google das Crawlen der Website zunächst zwölf Stunden ein und versucht weiter, die Datei zu holen. Gelingt das nicht und liegt eine gespeicherte Fassung vor, gilt diese bis zu 30 Tage weiter; ohne gespeicherte Fassung geht Google für diese Zeit von keinen Crawlbeschränkungen aus. Sind die Fehler nach 30 Tagen nicht behoben, verhält sich Google so, als gäbe es die Datei nicht, solange die Website sonst erreichbar ist; hat die Website allgemeine Erreichbarkeitsprobleme, stellt Google das Crawlen ein. RFC 9309 schreibt für eine nicht erreichbare Datei sogar vor, dass der Crawler zunächst vollständig sperrt. Ein 4xx außer 429 wirkt umgekehrt: Google behandelt die Datei dann, als gäbe es keine robots.txt, also ohne Einschränkung; ein 429 zählt dagegen wie ein 5xx als Serverfehler. Google speichert die Datei nach eigener Angabe in der Regel bis zu 24 Stunden und länger, wenn sie sich nicht aktualisieren lässt; über den HTTP-Header Cache-Control max-age kann Google die Speicherdauer verlängern oder verkürzen, eine Änderung wirkt daher verzögert.

Ergebnis: eine robots.txt ohne Fehlerstatus, in der jede Zeile einer bewussten Entscheidung entspricht.

Schritt 3: robots.txt und noindex auseinanderhalten

Die beiden Mittel haben unterschiedliche Wirkung: robots.txt steuert das Crawlen, noindex den Index. Eine per robots.txt gesperrte Adresse kann Google allein aus Links kennen und ohne Beschreibung anzeigen, weil der Inhalt nie gelesen wurde. Ein noindex-Meta-Element oder ein X-Robots-Tag wirkt nur, wenn Google die Seite abrufen darf; eine gleichzeitige robots.txt-Sperre verhindert genau das. noindex in der robots.txt unterstützt Google nicht.

Für Adressen, die nur nicht gecrawlt werden sollen, etwa Sortiervarianten, ist robots.txt das passende Mittel: noindex lässt Google die Seite erst abrufen und danach verwerfen, was Crawling-Zeit kostet. Steht eine solche Adresse schon im Index und soll dort nicht mehr erscheinen, nimmt die Crawlsperre sie nicht heraus: Dafür lassen Sie die Adresse crawlbar und setzen noindex; eine Entfernungsanfrage im Entfernungswerkzeug beschleunigt das nur vorübergehend, weil sie nach Google-Angabe etwa sechs Monate gilt.

Ergebnis: Je Adresstyp ist notiert, ob er nicht gecrawlt oder nicht indexiert werden soll.

Schritt 4: Doppelte Adressen bündeln

Derselbe Inhalt unter mehreren Adressen entsteht in Shops durch HTTP und HTTPS, mit und ohne www, durch Groß- und Kleinschreibung, Sortierung, Filter, Sitzungsnummern und Kampagnenparameter. Ohne Ihre Angabe wählt Google selbst eine kanonische Adresse; Ihre Wahl beeinflussen Sie mit Signalen.

Am stärksten wirkt eine Weiterleitung, danach das rel=“canonical”-Element, am schwächsten die Aufnahme in die Sitemap. Google folgt Weiterleitungen und behandelt den Zielort einer dauerhaften Weiterleitung (301 oder 308) als kanonisch; eine temporäre Weiterleitung (302, 307) leistet das nicht. Setzen Sie das Canonical selbstreferenziell, also auch auf der bevorzugten Seite selbst, und verwenden Sie absolute Adressen. Widersprechen sich Canonical, Sitemap und Weiterleitung, ist das Ergebnis offen. Fragmente wie #farbe sind als Canonical ungeeignet, weil Google Fragmente nach eigener Aussage im Allgemeinen nicht auswertet.

Ein Sonderfall ist die Schreibweise: Google behandelt Adressen groß- und kleinschreibungssensitiv. Behandelt Ihr Server beide gleich, vereinheitlichen Sie sie, sonst entstehen zwei Adressen für eine Seite.

Ergebnis: eine bevorzugte Adresse je Seite, alle anderen leiten dorthin oder tragen ein Canonical.

Schritt 5: Parameter- und Filteradressen begrenzen

Nach der Google-Dokumentation erzeugt eine facettierte Navigation aus Parametern eine sehr große Zahl von Adressen, die ein Crawler erst abrufen muss; das bindet Crawling-Zeit und verzögert das Finden neuer Seiten. Entscheiden Sie je Adressmuster, ob die gefilterten Adressen erscheinen sollen. Sollen sie es nicht, sperren Sie das Crawlen der Parameter und erlauben Sie die Produktseiten sowie eine Listenseite ohne Filter:

user-agent: Googlebot
disallow: /*?*farbe=
allow: /*?farbe=alle$

Steht eine Filteradresse bereits im Index und soll dort verschwinden, hilft die Crawlsperre nicht: Lassen Sie diese Adresse crawlbar und setzen Sie noindex; eine Entfernungsanfrage im Entfernungswerkzeug beschleunigt die Entfernung nur, weil sie nach Google-Angabe etwa sechs Monate gilt.

Sollen die Adressen erscheinen können, halten Sie das Schema sauber: & als Trennzeichen zwischen Parametern, bei Filtern im Pfad immer dieselbe Reihenfolge und keine doppelten Filter. Eine Filterkombination ohne Treffer und eine nicht vorhandene Seitenzahl beantworten Sie mit Status 404 unter der aufgerufenen Adresse, nicht mit einer Weiterleitung auf eine allgemeine Fehlerseite. Fragmente wie #farbe=gruen wertet Google beim Crawlen und Indexieren nach eigener Aussage im Allgemeinen nicht aus. Wie die Vorlage einer Kategorieseite und die URL-Regeln dazu aussehen, steht unter Kategorieseiten optimieren.

Ergebnis: Filter- und Sortierparameter sind erlaubt oder gesperrt, leere Kombinationen liefern 404.

Schritt 6: Links, Sitemap und gerenderten Inhalt prüfen

Google findet Seiten über Links und wertet nach seiner Dokumentation im Allgemeinen nur Links in a-Elementen mit href aus; Navigation über Skript-Ereignisse auf anderen Elementen ist dafür ungeeignet. Verlinkt eine Kategorieseite nicht auf alle Produkte, findet das Crawlen sie womöglich nicht über die Navigation; dann helfen Sitemap oder Produktfeed. Das Suchfeld des Shops hilft dabei nicht, weil Googlebot nach der Google-Dokumentation Suchanfragen in ein Suchfeld im Allgemeinen nicht eingibt. Strukturierte Daten auf Produktseiten können Google die Seitenart verdeutlichen (Produktseiten und strukturierte Daten).

Eine Sitemap hilft großen oder neuen Websites beim Finden von Adressen, garantiert aber weder Crawling noch Indexierung; halten Sie sie aktuell und nutzen Sie lastmod. Dauerhaft entfernte Seiten beantwortet Google nach seiner Empfehlung mit 404 oder 410. Rendert Ihr Shop Inhalte erst per JavaScript, prüfen Sie die gerenderte Fassung mit der URL-Prüfung. Löst eine nicht gefundene Produktseite nur im Browser eine Umleitung aus, entsteht ein soft 404; leiten Sie auf eine Adresse um, die serverseitig 404 liefert, oder setzen Sie auf Fehlerseiten ein noindex.

Ergebnis: Jede wichtige Seite ist über mindestens einen a-Link erreichbar, und die Sitemap passt zum Bestand.

Audit-Checkliste mit Schweregrad und Behebung

Die Tabelle ordnet die Befunde nach Schweregrad. Hoch bedeutet: Der Befund kann eine Seite aus den Ergebnissen nehmen oder das Crawlen dauerhaft bremsen. Mittel: Er kostet Crawling-Zeit oder lässt die falsche Adresse erscheinen. Gering: Es geht um Pflege. Schweregrad und Reihenfolge sind redaktionelle Einschätzungen; die Kurzbezeichnung in der Spalte Beleg verweist auf das Dokument in der Quellenliste.

Befund	Schweregrad	Behebung	Beleg
Eine wichtige Adresse antwortet mit 5xx oder 429	hoch	Ursache beheben; dauerhaft fehlerhafte Adressen nimmt Google aus dem Index	Statuscodes
robots.txt ist nicht abrufbar (5xx, DNS- oder Netzfehler)	hoch	Erreichbarkeit herstellen; nach zwölf Stunden greift Google bis zu 30 Tage auf die letzte gespeicherte Fassung zurück, ohne gespeicherte Fassung auf keine Crawlbeschränkung	robots.txt; RFC 9309 § 2.3.1.4
robots.txt sperrt eine Seite, die erscheinen soll	hoch	Eintrag entfernen; die Adresse kann ohne Beschreibung erscheinen	robots.txt
noindex steht auf einer per robots.txt gesperrten Seite	hoch	Sperre entfernen, damit Google das noindex lesen kann	noindex
Eine Adresse liefert 200 mit Fehlertext (soft 404)	hoch	echten 404-Status senden	Statuscodes; Crawl-Budget
Produktseite ist nur über das Suchfeld oder ein Skript-Ereignis erreichbar	hoch	a-Link mit href aus der Kategorie ergänzen, sonst Sitemap oder Produktfeed	Links; Shopstruktur
Zwei Adressen (HTTP und HTTPS, mit und ohne www, Schreibweise) zeigen denselben Inhalt	mittel	dauerhaft (301 oder 308) auf die bevorzugte Adresse weiterleiten, Canonical selbstreferenziell setzen	Canonical; Weiterleitungen
Umgezogene Adresse nutzt eine temporäre Weiterleitung (302, 307)	mittel	auf 301 oder 308 umstellen	Weiterleitungen
Weiterleitungskette mit mehreren Sprüngen	mittel	auf einen Sprung kürzen; Google folgt bis zu zehn	Crawl-Budget
Filter- oder Sortieradresse erscheint, soll aber nicht	mittel	Adresse crawlbar lassen und noindex setzen; eine Entfernungsanfrage im Entfernungswerkzeug beschleunigt das nur und gilt nach Google-Angabe etwa sechs Monate. Die Parameter in robots.txt zu sperren nimmt die Adresse nicht aus den Ergebnissen und verhindert, dass Google das noindex erneut liest	noindex; Removals; Facettennavigation
Leere Filterkombination liefert 200 oder leitet auf eine allgemeine Fehlerseite um	mittel	Status 404 unter der aufgerufenen Adresse senden	Facettennavigation
Sitzungs- oder Kampagnenparameter stehen in internen Links	mittel	Parameter aus internen Links entfernen, Sitzungen über Cookies führen	URL-Struktur
Ein Fragment dient als Variante oder als Canonical	mittel	eigene Adresse je Variante anlegen, Fragment nicht als Canonical	URL-Struktur; Canonical
Canonical, Sitemap und Weiterleitung nennen verschiedene bevorzugte Adressen	gering bis mittel	eine bevorzugte Adresse je Seite festlegen und überall dieselbe nennen	Canonical
Sitemap enthält entfernte Adressen oder kein lastmod	gering	Sitemap pflegen; entfernte Seiten mit 404 oder 410 beantworten	Sitemaps; Crawl-Budget

Wann Sie Hilfe holen sollten

Ein technischer Audit setzt Zugriff auf Server oder Shopsystem voraus. Holen Sie Unterstützung, wenn

• der Shop Inhalte erst im Browser per JavaScript aufbaut und Statuscodes oder Canonical nicht serverseitig gesetzt werden können,
• eine Weiterleitungskette, eine robots.txt-Sperre oder ein Canonical-Widerspruch nach einem Umbau unklar bleibt,
• nach einem Relaunch Adressen aus dem Index fallen und die Ursache sich nicht eingrenzen lässt.

Für den Umbau gibt es ein eigenes Vorgehen: Shop-Relaunch und SEO.