616.000 Aufrufe mit add-to-cart in acht Tagen: die Warenkorb-Falle

Angefangen hat es mit einer Kleinigkeit. Beim Aufräumen der Weiterleitungen im Onlineshop der Bauerntüte, einem Bio-Lieferdienst aus Köln, fiel uns im 404-Protokoll ein seltsames Muster auf: Hunderte Adressen endeten auf /null, etwa /produkt-schlagwort/marmelade/null. Zusammen kamen sie auf 17.665 Aufrufe. Die Geschichte dazu steht in unserer Fallstudie zu 7.740 Seiten mit Weiterleitung.

Um herauszufinden, wer diese Adressen aufruft, haben wir die Zugriffsprotokolle des Servers aus acht Tagen ausgewertet. Die /null-Adressen waren dabei das kleinere Problem.

Was im Zugriffsprotokoll stand

Der Shop bekam in diesen acht Tagen zwischen 100.000 und 270.000 Aufrufe am Tag. Ein großer Teil davon trug den Parameter add-to-cart:

WooCommerce wertet ?add-to-cart= bei jedem normalen Seitenaufruf aus, bevor die Seite gebaut wird. Das ist für Besucher ohne JavaScript gedacht. Wer so eine Adresse aufruft, legt das Produkt in einen Warenkorb, und WooCommerce legt dafür eine Gastsitzung in der Datenbank an. Danach baut der Server die komplette Seite, bei 72 Produkten rund 540 KB.

Echte Kunden nutzen diesen Weg auf den Übersichtsseiten des Shops kaum. Dort legen sie per AJAX in den Warenkorb, und dabei steht add-to-cart gar nicht in der Adresse. Die Hunderttausende kamen also von woanders.

Die Falle: Sortierlinks, die add-to-cart weitertragen

Das Theme Enfold bringt auf Shop-Kategorien ein Formular mit, über das Besucher Sortierung und Anzahl wählen. Die Links darin baut es aus der aktuellen Adresse. Steht dort schon add-to-cart, steht es danach auch in jedem Sortierlink:

<a href='?paged=1&avia_extended_shop_select=yes&product_order=default
    &product_count=24&add-to-cart=57851'>Standard</a>

Für einen Crawler ist das eine Falle. Er findet einen Warenkorb-Link, ruft ihn auf, findet auf der Ergebnisseite zehn Sortierlinks mit demselben Parameter, ruft jeden davon auf, und so weiter. Multipliziert man die Sortierungen, die Anzahlen und die Produkt-IDs, entstehen Millionen Adressen. Jede davon legt wieder etwas in einen Warenkorb.

Die robots.txt des Shops sperrte add-to-cart und die Sortierparameter längst. Für die beiden Crawler, die wir gefunden haben, spielte das keine Rolle.

Wer darin steckte

Die Kennung, mit der sich ein Aufrufer meldet, steht in jeder Zeile des Protokolls. Bei den add-to-cart-Aufrufen der acht Tage ergab sich ein eindeutiges Bild:

• 396.599 Aufrufe von einem getarnten Scraper. Er meldet sich immer mit derselben Kennung eines Chrome-Browsers auf einem Mac. In drei Stunden kam er über 3.625 verschiedene IP-Adressen, fast jede nur einmal. So verhält sich kein Mensch, und so lässt er sich auch nicht über eine einzelne Adresse sperren.
• 219.159 Aufrufe vom Crawler meta-externalagent. Damit sammelt Meta Inhalte für seine KI-Modelle. An manchen Tagen stellte er über die Hälfte aller Seitenaufrufe des Shops, am 27. Oktober 53 Prozent.
• Rund 500 Aufrufe von allen anderen zusammen. Darunter ein paar echte Browser.

Und die Adressen auf /null?

Sie kamen in unserer Stichprobe ausschließlich vom Meta-Crawler, und zwar immer direkt nach einer Sortier-Adresse mit add-to-cart. Im ausgelieferten HTML steht nirgends ein Link auf „null“, das haben wir mit normaler Kennung und mit der Kennung des Crawlers geprüft. Ein normaler Browser fordert die Adresse auch nicht an. Vermutlich entsteht sie, wenn Metas Umgebung ein Skript der Seite ausführt und dabei einen leeren Wert als Adresse verwendet. Welches Skript das ist, haben wir nicht gefunden. Für die Lösung mussten wir es auch nicht wissen.

Der Fix

Wir haben die Falle dort geschlossen, wo sie entsteht, ohne Kunden etwas wegzunehmen. Die Regel sitzt in einem Must-use-Plugin und läuft, bevor WooCommerce den Warenkorb anfasst:

// Adressen auf /null: sofort 410, ohne dass das Theme eine 404-Seite baut
if ( preg_match( '#/null/?$#', (string) strtok( $_SERVER['REQUEST_URI'] ?? '', '?' ) ) ) {
	status_header( 410 );
	header( 'Cache-Control: public, max-age=86400' );
	exit;
}

add_action( 'wp_loaded', function () {
	if ( empty( $_GET['add-to-cart'] ) || wp_doing_ajax() || is_admin() ) {
		return;
	}
	$sortierung = isset( $_GET['avia_extended_shop_select'] ) || isset( $_GET['product_order'] )
		|| isset( $_GET['product_count'] ) || isset( $_GET['product_sort'] );
	$bot = (bool) preg_match( '/bot|crawl|spider|externalagent|facebookexternalhit|headless/i',
		$_SERVER['HTTP_USER_AGENT'] ?? '' );
	if ( $sortierung || $bot ) {
		wp_safe_redirect( remove_query_arg( 'add-to-cart' ), 301 );
		exit;
	}
}, 0 ); // vor WooCommerce (wp_loaded, Priorität 20)

Was die Regel tut:

• Sortierung plus add-to-cart wird ohne Warenkorb auf dieselbe Adresse ohne add-to-cart umgeleitet. Damit fällt der Faktor „Anzahl der Produkte“ aus der Rechnung, und die Zahl möglicher Adressen schrumpft um genau diesen Faktor.
• add-to-cart von erkennbaren Bots legt ebenfalls nichts mehr in einen Warenkorb.
• Adressen auf /null bekommen ein 410, bevor das Theme geladen wird. Das sagt dem Crawler, dass es die Adresse nicht gibt und nicht geben wird, und kostet den Server fast nichts.

Was die Regel bewusst nicht anfasst: den AJAX-Warenkorb, Produktseiten und einfache Warenkorb-Links ohne Sortierung, wie sie etwa in Newslettern stehen. Live geprüft haben wir alle drei Fälle direkt nach dem Einspielen: /null antwortet mit 410, Sortierung mit add-to-cart mit einer Weiterleitung ohne Warenkorb, normale Seiten mit 200.

Was der Fix nicht löst

Der getarnte Scraper ruft weiter Sortier-Adressen auf, jetzt eben ohne Warenkorb. Jede davon baut der Server weiterhin komplett. Gegen einen Crawler, der sich als Browser ausgibt und für fast jeden Aufruf eine neue IP-Adresse nutzt, hilft keine Regel im Plugin zuverlässig. Dafür braucht es eine Begrenzung oder einen Bot-Schutz vor der Website, beim Hoster oder in einem vorgeschalteten Dienst. Das ist der nächste Schritt.

Wie sich die Zahlen nach dem Fix entwickeln, tragen wir hier nach, sobald wir ein paar Tage Protokoll haben.

Was du für deinen eigenen Shop mitnimmst

• Zähle add-to-cart im Zugriffsprotokoll. Ein paar Dutzend Aufrufe am Tag sind normal. Gehen sie in die Tausende, steckt fast immer ein Crawler dahinter.
• Prüfe, ob deine Sortier- und Filterlinks Parameter weitertragen. Ruf eine Kategorie mit ?add-to-cart= auf und sieh nach, ob der Parameter in den Links der Ergebnisseite wieder auftaucht.
• Nutze den AJAX-Warenkorb auf Übersichten. Dann braucht kein Kunde die GET-Adresse, und du kannst sie für Bots eng fassen.
• Verlass dich nicht auf die robots.txt. Sie ist eine Bitte. Was nicht passieren darf, muss der Server verhindern.
• Lies dein 404-Protokoll. Seltsame Muster wie /null sind oft das erste sichtbare Zeichen eines Crawlers, der sich verlaufen hat.

Wie du eine langsame WordPress-Seite insgesamt wieder schnell bekommst, steht in WordPress langsam? So machst du deine Seite in 10 Schritten wieder schnell.

Häufige Fragen