Gestern lief dein Checkout noch einwandfrei. Heute klicken Kunden auf „Bestellung abschicken“ und nichts passiert. Oder sie sehen die kryptische Meldung „Nonce verification failed“. So findest und behebst du die Ursache.
Was ist ein WordPress-Nonce und warum ist er wichtig?
Ein Nonce, kurz für „number used once“, ist ein Sicherheits-Token. WordPress nutzt ihn, um zu prüfen, ob eine Formularübermittlung beabsichtigt und aktuell ist. Jedes Checkout-Formular, jede Login-Seite und jede Admin-Aktion in WordPress enthält einen Nonce.
Scheitert die Nonce-Prüfung, lehnt WordPress die Anfrage ab. Für deine Kunden bedeutet das:
Das Checkout-Formular wird nicht abgeschickt
Die Meldung „Der Link, dem du gefolgt bist, ist abgelaufen“ erscheint
Die Zahlung schlägt ohne klare Fehlermeldung fehl
„Nonce verification failed“ steht in deinen Server-Logs
Die Folge: verlorene Verkäufe, verwirrte Kunden und Support-Tickets ohne erkennbare Ursache.
Der Punkt, den viele Anleitungen übergehen: Ein Nonce ist abhängig vom Erstellungszeitpunkt etwa 12 bis 24 Stunden gültig. Technisch gilt er für zwei Zeitfenster von je 12 Stunden. Das ist meist unproblematisch. Kommt Seiten-Caching hinzu, kann es jedoch schiefgehen.
Dieses Szenario überrascht viele Shop-Betreiber. So läuft es ab:
1
Erstellung
WordPress erzeugt einen Nonce für das aktuelle Zeitfenster und fügt ihn in das HTML deines Checkouts ein.
2
Aktuelles Zeitfenster
Dein Caching-Plugin, etwa WP Rocket, LiteSpeed Cache, W3 Total Cache oder Cloudflare, speichert die gesamte Seite samt Nonce als statische Datei.
3
Nächstes Zeitfenster
Der Nonce in der gecachten Seite kann noch gültig sein, nähert sich aber dem Ende seiner Gültigkeitsdauer.
4
Nach Ablauf
Der Nonce ist abgelaufen. Dein Caching-Plugin liefert Besuchern trotzdem weiterhin dieselbe gecachte HTML-Datei.
5
Kunde klickt
„Bestellung abschicken“: WordPress prüft den Nonce, erkennt den Ablauf und lehnt die Anfrage ab.
Die Checkout-Seite sieht völlig normal aus. Häufig erscheint nicht einmal eine Fehlermeldung. Die Bestellung wird einfach nicht abgeschlossen. Das ist ein stiller Fehler, der unbemerkt über Tage Umsatz kosten kann.
Nonce lifecycle animation
Animiertes Diagramm: Ein Nonce läuft nach seiner Gültigkeitsdauer ab, während ein Seiten-Cache weiter die alte Kopie ausliefert.
So bestätigst du, dass das dein Problem ist
Öffne deine Checkout-Seite in einem Inkognito-Fenster. Rufe den Seitenquelltext auf (Strg+U / Cmd+U) und suche nach nonce. Du findest einen Eintrag wie diesen:
Prüfe zuerst, ob die Checkout-Seite aus dem Cache kommt. Vergleiche dazu die Cache-Header der Antwort. Prüfe den Nonce-Wert dann erneut nach dem nächsten Zeitfensterwechsel. Liefert der Seiten-Cache weiter die alte HTML-Datei, enthält sie einen veralteten Nonce.
Diagnose-Ablauf: Nonce-Problem eingrenzen
Starte mit diesem Entscheidungsbaum:
Schritt 1: Liefert der Seiten-Cache die Checkout-Seite aus?
Prüfe die Cache-Header und vergleiche den Nonce-Wert vor und nach dem nächsten Zeitfensterwechsel.
Fix #1: Cache-Ausschlüsse
Sorge dafür, dass dein Caching-Plugin die dynamischen WooCommerce-Seiten nie speichert. Viele Plugins erkennen WooCommerce automatisch. Diese Erkennung kann jedoch nach Migrationen, Plugin-Updates oder mit einer zusätzlichen CDN-Schicht versagen.
Gehe zu Einstellungen → WP Rocket → Erweiterte Regeln → URLs nie cachen und füge hinzu:
/checkout/(.*)
/cart/(.*)
/my-account/(.*)
Außerdem sollten unter WP Rocket → Erweiterte Regeln → Cookies nie cachen diese Einträge gelistet sein:
Nach dem Speichern Cache leeren und dann Preload Cache ausführen.
Nach jeder Cache-Änderung prüfen
1Leere alle Caches: Plugin, CDN und gegebenenfalls die Serverebene.
2Öffne die Checkout-Seite im Inkognito-Modus.
3Prüfe die Cache-Header der Antwort.
4Prüfe den Nonce-Wert erneut nach dem nächsten Zeitfensterwechsel.
5Die Checkout-Seite darf nicht aus dem Cache kommen. Andernfalls kann eine alte HTML-Datei mit abgelaufenem Nonce ausgeliefert werden.
Fix #2: Plugin-Konflikte
Einige Plugins fügen eigene Nonces ein oder stören WooCommerces Nonce-Prüfung. Diese Kandidaten treten besonders häufig auf:
Sicherheits-Plugins wie Wordfence, Sucuri oder iThemes Security können zusätzliche Nonce-Prüfungen hinzufügen oder automatisiert wirkende Anfragen blockieren.
Performance-Plugins können JavaScript minimieren oder verzögert laden. Wird WooCommerces wc-checkout.js falsch behandelt, ist das Nonce-Feld beim Absenden möglicherweise leer.
Eigene Checkout-Plugins wie CheckoutWC, Fluid Checkout oder FunnelKit ersetzen das Standard-Template und behandeln Nonces teilweise anders.
Mehrwährungs- oder Geolocation-Plugins können Seitenvarianten erzeugen, die unvorhersehbar mit dem Cache zusammenspielen.
So isolierst du den Konflikt
1Erstelle eine Staging-Website oder nutze die Staging-Funktion deines Hosters. Debugge nie direkt in der Produktion.
2Alle Plugins außer WooCommerce deaktivieren.
3Zum Storefront-Theme wechseln.
4Den WooCommerce-Checkout testen. Ist die Nonce-Prüfung wieder erfolgreich, liegt die Ursache bei einem Plugin oder Theme.
5Plugins einzeln wieder aktivieren und nach jeder Aktivierung den WooCommerce-Checkout testen.
6Kehrt der Fehler zurück, hast du den Auslöser gefunden.
Wenn ein JavaScript-Optimierungs-Plugin die Ursache ist
Fix #3: Nonce-Lebensdauer verlängern (nur zur Diagnose)
Das ist keine dauerhafte Lösung. Du kannst damit aber prüfen, ob ablaufende Nonces die Ursache sind. Füge den Code in die functions.php deines Themes oder in ein eigenes Plugin ein:
add_filter( 'nonce_life', function() {
return 48 * HOUR_IN_SECONDS; // Extend to 48 hours (default is 24)
});
Verschwindet der Fehler nach der Verlängerung, laufen die Nonces ab, bevor Kunden sie nutzen. Das weist wieder auf Caching als eigentliche Ursache hin. Entferne den Code, sobald du die richtigen Cache-Ausschlüsse eingerichtet hast. Eine längere Nonce-Lebensdauer schwächt den Schutz, den Nonces bieten.
Fix #4: Serverzeit synchronisieren
WordPress-Nonces sind zeitbasiert. Weicht die Serverzeit von einer verlässlichen Zeitquelle ab, können Nonce-Prüfungen fehlschlagen.
Das passiert am häufigsten bei:
günstigem Shared Hosting mit schlecht gewarteten Servern
VPS-Instanzen ohne NTP-Konfiguration (Network Time Protocol)
Docker-Containern ohne Zeitsynchronisation mit dem Host
Prüfe die Serverzeit per SSH oder im Hosting-Terminal:
date -u
Vergleiche die Ausgabe mit UTC auf time.is/UTC. Lass die Zeitsynchronisierung durch die für den Server verantwortliche Person prüfen und bei Bedarf korrigieren. Auf einem selbst verwalteten VPS:
sudo timedatectl set-ntp on
sudo systemctl restart systemd-timesyncd
Fix #5: Sitzungsprobleme bei Hosting mit Load-Balancer
Betreibt dein Hosting mehrere App-Server hinter einem Load-Balancer, muss die Konfiguration auf allen Servern übereinstimmen. Das kommt etwa bei Cloudways, Kinsta oder WP Engine in höheren Tarifen sowie bei eigenen AWS- oder GCP-Setups vor.
Sticky Sessions
Option A: Aktiviere Sticky Sessions. Konfiguriere den Load-Balancer so, dass die Anfragen eines Nutzers während seiner Sitzung denselben Backend-Server erreichen. Bei AWS ALB heißt das „Session Stickiness“ oder „Target Group Stickiness“.
Gemeinsamer Session-Store
Option B: Stelle sicher, dass alle Server dieselbe Datenbank, identische WordPress-Salts und dieselbe Cache-Konfiguration nutzen. Salts sind geheime Schlüssel für die Validierung von Anmeldungen und Nonces. Ein gemeinsamer Session-Store kann für zusätzliche Session-Komponenten sinnvoll sein.
Das größere Problem: stille Fehler
Nonce-Fehler sind besonders tückisch, weil sie leise bleiben. Ein Uptime-Monitor meldet eine erreichbare Website. Die Checkout-Seite lädt und der Button „Bestellung abschicken“ sieht normal aus. Trotzdem gehen Bestellungen nicht durch.
Das fällt oft erst Stunden oder Tage später auf. Meldet sich ein Kunde, können bereits viele Verkäufe an einem veralteten Nonce gescheitert sein, den ein Caching-Plugin unwissentlich ausgeliefert hat.
Genau hier hilft automatisiertes Checkout-Monitoring. Statt auf Kundenbeschwerden zu warten, führt ein Monitoring-Tool regelmäßig eine Testbestellung aus und warnt dich, sobald der Checkout scheitert. Auslöser können fehlgeschlagene Nonce-Prüfungen, eine falsch konfigurierte Zahlungsart oder andere stille Fehler sein.
ShopMonitor führt auf deinem WooCommerce-Shop automatisierte Checkout-Tests mit echten Browser-Sitzungen aus. Sie durchlaufen jeden Schritt, den auch ein Kunde durchläuft. Stoppt eine fehlgeschlagene Nonce-Prüfung oder ein anderes Problem den Checkout, erhältst du eine Warnung. Siehe auch unseren Leitfaden zur WooCommerce-Checkout-Fehlersuche für den vollständigen Diagnoseablauf.
Stille Checkout-Fehler erkennen, bevor Kunden sie melden
ShopMonitor führt echte Testkäufe über deinen WooCommerce-Checkout aus und warnt dich, sobald etwas scheitert, etwa durch fehlgeschlagene Nonce-Prüfungen, Cache-Fehlkonfigurationen oder Fehler bei der Zahlungsart.
Keine Kreditkarte erforderlich. Ohne Code-Änderungen eingerichtet.
Prüfe die Cache-Konfiguration nach jedem Plugin-Update. Caching-Plugins setzen ihre Ausschlussregeln bei Updates gelegentlich zurück. Nimm das in deine Checkliste auf.
Teste den Checkout nach jedem Deployment. Aktualisierst du WooCommerce, wechselst das Theme oder ergänzt eine Zahlungsart, führe eine Testbestellung aus. Wenn dafür Zeit fehlt, automatisiere den Test.
Das Feld woocommerce-process-checkout-nonce überwachen. Prüfe nach Cache-Änderungen, ob die Checkout-Seite aus dem Cache kommt.
Verlasse dich nicht allein auf Verfügbarkeits-Monitoring. Pingdom und UptimeRobot prüfen nur, ob dein Server mit Status 200 antwortet. Ob der WooCommerce-Checkout tatsächlich funktioniert, prüfen sie nicht. Bei fehlgeschlagenen Nonce-Prüfungen kann die Seite laden, während der Checkout still scheitert.
Häufige Fragen
WordPress hat eine Formularübermittlung mit einem Sicherheits-Token erhalten. Der Nonce ist abgelaufen, ungültig oder fehlt. WordPress lehnt die Übermittlung ab, um Cross-Site-Request-Forgery-Angriffe (CSRF) zu verhindern. In WooCommerce scheitert der Checkout dann häufig still oder zeigt beim Bestellen einen Fehler.
Ja. Seiten-Caching-Plugins speichern eine statische Kopie deiner Checkout-Seite inklusive des Nonce-Tokens. Läuft der gecachte Nonce nach 12 bis 24 Stunden ab, erhält jeder Besucher dieser Cache-Version einen ungültigen Nonce. Schließe deshalb Seiten für Checkout, Warenkorb und Kundenkonto vom Seiten-Cache aus.
Standardmäßig ist ein WordPress-Nonce über zwei Zeitfenster von je 12 Stunden gültig. Ein Nonce, der zu Beginn eines Zeitfensters erzeugt wird, gilt für dieses und das nächste. Die tatsächliche Gültigkeitsdauer liegt daher zwischen 12 und 24 Stunden, abhängig vom Zeitpunkt der Erstellung.
Eine längere Nonce-Lebensdauer, etwa 48 oder 72 Stunden, reduziert die Sicherheit. Angreifer haben dann mehr Zeit, abgefangene Nonces wiederzuverwenden. Nutze das nur als temporäre Diagnose. Die richtige Lösung ist, die Checkout-Seite vom Seiten-Cache auszunehmen, damit dort kein veralteter Nonce ausgeliefert wird.
Stille Checkout-Fehler sind schwer zu erkennen, weil die Seite normal lädt und Status 200 zurückgibt. Hinweise sind ein plötzlicher Bestellrückgang, obwohl der Traffic nicht sinkt, Beschwerden über nicht abgeschlossene Bestellungen und Einträge zu fehlgeschlagenen Nonce-Prüfungen in den Server-Logs. Checkout-Monitoring-Tools wie ShopMonitor erkennen solche Fehler durch regelmäßige echte Testkäufe.
Der Checkout-Block nutzt seit WooCommerce 8.3+ eine andere Architektur als der klassische Shortcode-Checkout. Er verarbeitet Nonces über die Store API statt über herkömmliche Formularübermittlungen. Das kann einige Nonce-Probleme reduzieren. Caching kann den Nonce-Mechanismus der Store API jedoch weiterhin stören. Dieselben Cache-Ausschlussregeln gelten.
Zuletzt aktualisiert: Juli 2026. Dieser Leitfaden gilt für WooCommerce 8.x+ mit WordPress 6.5+. Die Anleitungen für Caching-Plugins wurden mit aktuellen Versionen abgeglichen.
Über das Autorenteam
Verfasst vom Winning Solutions-Team, der Agentur hinter ShopMonitor. ShopMonitor wurde von Gründern entwickelt, die seit mehr als einem Jahrzehnt WooCommerce-Shops betreiben. Jeder Fix in diesem Leitfaden stammt aus echten Kundennotfällen. ShopMonitor soll Probleme melden, bevor der Kunde zum Telefon greifen muss.
