Warteraum für Black Friday: Den Shop unter Last steuern

Der Black Friday fällt 2026 auf den 27. November: Der Duden definiert ihn als Freitag nach dem Thanksgiving Day, und Thanksgiving liegt laut U.S. Office of Personnel Management 2026 auf Donnerstag, dem 26. November. Für einen Online-Shop ist allerdings nicht der Tag das Problem, sondern die Minute, in der die Angebote starten. Dann treffen Newsletter, Anzeigen und Stammkunden gleichzeitig auf Warenkorb, Lagerbestand und Zahlungsschnittstelle. Ein virtueller Warteraum lässt Besucher in geordneter Reihenfolge und in dem Tempo hinein, das der Shop tatsächlich verarbeiten kann. Dieser Beitrag zeigt, wo ein Warteraum technisch sitzt, wie Durchlass, Sitzung und Warenkorb zusammenspielen, welche Statuscodes Browser und Suchmaschinen sehen sollten, wie Sie die Auslöseschwelle festlegen und welcher Zeitplan bis Ende November realistisch ist.

Warum sich der Aufwand vor dem Black Friday lohnt

Der Handelsverband Deutschland (HDE) erwartete für Black Friday und Cyber Monday 2025 zusammen einen Umsatz von 5,8 Milliarden Euro und damit erstmals einen Rückgang. Die Prognose lag knapp zwei Prozent unter dem Vorjahr; für 2024 hatte der Verband 5,9 Milliarden Euro erwartet. Beides sind Verbandsprognosen auf Grundlage von Befragungen, keine gemessenen Umsätze, und eine HDE-Prognose für 2026 war bei Redaktionsschluss noch nicht erschienen. Für die Technik ist die leichte Delle ohnehin nebensächlich. Entscheidend ist, dass sich ein Milliardengeschäft auf wenige Aktionstage verdichtet – und innerhalb dieser Tage auf die Stunden, in denen Rabatte freigeschaltet werden.

Auch die Nachfrage liegt überwiegend im Netz. Laut Bitkom wollte rund jede und jeder Zweite der Internetnutzenden ab 16 Jahren (52 Prozent) die Angebote rund um den Black Friday 2025 nutzen. Von denen, die an Black Friday und Cyber Week einkaufen wollten, planten 69 Prozent, das ausschließlich online zu tun, 26 Prozent wollten online und im Laden kaufen und 4 Prozent nur im Geschäft vor Ort (Befragung in KW 40 bis 41/2025). In der HDE-Umfrage unter Online-Shoppern gaben 48 Prozent an, am Black Friday auf Schnäppchenjagd gehen zu wollen. Für den Shop heißt das: Wer online kommt, steht nicht vor einer Ladentür, an der sich von selbst eine Schlange bildet. Ohne eigene Vorkehrung trifft jeder Besucher sofort auf den Server.

Das Statistische Bundesamt (Destatis) ordnete schon die Novemberentwicklung 2024 den Aktionstagen zu: Ein Teil des Weihnachtsgeschäfts hat sich durch Aktionen rund um Black Friday und Cyber Monday vor allem im Internet- und Versandhandel in den November verlagert. Für November 2025 meldete Destatis nach vorläufigen Werten im Internet- und Versandhandel real 5,9 % mehr Umsatz als im Vorjahresmonat, im Einzelhandel insgesamt kalender- und saisonbereinigt real 1,1 %. Der Onlinehandel wuchs in diesem Monat also deutlich schneller als der Handel insgesamt. Wer online verkauft, erlebt seine höchste Last darum häufig nicht im Dezember, sondern Ende November.

Was ein Warteraum ist – und was nicht

Ein virtueller Warteraum ist eine Einlasskontrolle vor dem Shop. Solange genug Kapazität frei ist, merkt niemand etwas von ihm: Besucher gelangen direkt auf die gewünschte Seite. Erst wenn eine festgelegte Grenze erreicht ist, erhalten neue Besucher eine schlanke Warteseite mit ihrer Position und werden automatisch hineingelassen, sobald ein Platz frei wird. Wer schon im Shop ist, bleibt ungestört – gerade Kunden im Bezahlvorgang dürfen nicht zurück in die Schlange fallen. Damit unterscheidet sich der Warteraum von drei verwandten Maßnahmen: von der Wartungsseite, die alle aussperrt, von der Ratenbegrenzung, die einzelne zu schnelle Clients bremst, und vom automatischen Skalieren bei Traffic-Spitzen, das mehr Rechenleistung bereitstellt. Skalieren hilft, solange der Engpass in den Anwendungsservern liegt. Datenbank, Sperren auf dem Lagerbestand und die Schnittstelle des Zahlungsanbieters wachsen aber nicht automatisch mit – genau dort setzt der Warteraum an.

Für den Fall, dass ein Geschäft vorübergehend nicht verkaufen kann, beschreibt die Google-Dokumentation zwei Pole. Nur die Warenkorbfunktion abzuschalten, ist laut Google der einfachste Weg und ändert nichts an der Sichtbarkeit in der Suche. Vom Abschalten der gesamten Website rät Google dagegen ab; wer das dennoch dringend für 1 bis 2 Tage tun muss, soll statt aller Inhalte eine Informationsseite mit dem Statuscode 503 ausliefern. Ein Warteraum liegt zwischen diesen Polen: Er schaltet nichts ab, sondern dosiert den Zugang – und wenn er richtig gebaut ist, sehen Suchmaschinen davon so wenig wie möglich.

Der Statuscode 503 (Service Unavailable) zeigt an, dass der Server die Anfrage wegen einer vorübergehenden Überlastung oder einer geplanten Wartung derzeit nicht bearbeiten kann; dieser Zustand behebt sich voraussichtlich nach einer gewissen Verzögerung.

RFC 9110, Abschnitt 15.6.4 (eigene Übersetzung)

Die Architektur: Wo der Warteraum sitzt

Die Entscheidung, wer hinein darf, fällt vor der Shop-Anwendung – im Reverse Proxy, im Load Balancer oder in einer vorgeschalteten Randschicht. Dort ist sie billig: Ein signiertes Cookie zu prüfen und einen Zähler hochzuzählen, kostet nur wenig Rechenzeit, während jede Anfrage, die bis in die Anwendung durchläuft, PHP, Datenbank und Zwischenspeicher beschäftigt. Die Warteseite selbst ist eine statische Datei, die ohne Anwendung und ohne Datenbank ausgeliefert wird. Wer den Warteraum dagegen als Plugin in den Shop baut, lässt die Last erst herein und sortiert sie danach – das entlastet kaum. Im Rahmen unseres Shopware-Hostings mit eigener Vorschaltebene planen wir diese Schicht deshalb vor der Anwendung und ohne Fremddienst.

Für die Steuerung gibt es zwei Modelle. Im Ratenmodell lässt der Warteraum eine feste Zahl neuer Besucher pro Minute ein, gleichgültig, wie viele schon im Shop sind. Das ist einfach und gut vorhersagbar, reagiert aber nicht darauf, dass Besucher unterschiedlich lange bleiben. Im Kapazitätsmodell zählt der Warteraum die gültigen Durchlässe und lässt erst nach, wenn einer frei wird – etwa weil eine Bestellung abgeschlossen ist oder ein Durchlass abgelaufen ist. Das bildet die tatsächliche Last besser ab, kann nach einer Stoßphase aber schlagartig viele Plätze gleichzeitig freigeben. In der Praxis bewährt sich eine Kombination: Kapazität als Obergrenze, dazu ein Deckel für den Zulauf pro Minute, damit der Shop nach einer Welle nicht sofort die nächste abbekommt.

Fair wird der Warteraum durch eine klare Reihenfolge. Startet ein Angebot zu einer festen Uhrzeit, empfiehlt sich ein Vorraum: Wer vor dem Start kommt, erhält eine Wartemarke, und zum Startzeitpunkt wird die Reihenfolge der bis dahin Wartenden zufällig festgelegt. So hat niemand einen Vorteil, der schon Minuten vorher die Seite im Sekundentakt neu lädt. Wer nach dem Start kommt, reiht sich hinten ein. Neu laden darf die Position weder verschlechtern noch verbessern – die Wartemarke steckt im Cookie, nicht in der einzelnen Anfrage. Technisch ergibt sich daraus folgender Ablauf:

1. Die Anfrage wird zuerst gegen die Ausnahmeliste geprüft: robots.txt, Sitemaps, statische Dateien, die Rückkehr vom Zahlungsanbieter und Statusabfragen laufen immer durch.
2. Trägt die Anfrage einen gültigen, signierten Durchlass, geht sie direkt in den Shop, und die Ablaufzeit des Durchlasses verlängert sich.
3. Ist im Zähler noch Kapazität frei, erhält der Besucher einen neuen Durchlass und landet ohne Umweg auf der gewünschten Seite.
4. Andernfalls bekommt er eine Wartemarke und unter derselben Adresse die statische Warteseite, ausgeliefert mit Statuscode 503 und Retry-After.
5. Die Warteseite fragt in Abständen einen schlanken Statusendpunkt ab und zeigt Position und geschätzte Wartezeit.
6. Ist der Besucher an der Reihe, tauscht der Statusendpunkt die Wartemarke gegen einen Durchlass, und die Seite lädt dieselbe Adresse neu – ohne Weiterleitung.

// Entscheidung am Rand: durchlassen, einlassen oder warten lassen
const AUSNAHMEN = [
  /^\/robots\.txt$/,
  /^\/sitemap/,
  /^\/(theme|media|bundles|thumbnail)\//,
  /^\/payment\/(finalize-transaction|webhook)/,
  /^\/api\/_info\/health-check$/,
  /^\/warteraum\/status$/
];

async function entscheide(anfrage, zaehler, schluessel) {
  const pfad = new URL(anfrage.url).pathname;
  if (AUSNAHMEN.some((muster) => muster.test(pfad))) {
    return 'durch';
  }

  // Gültiger Durchlass: Ablaufzeit verlängern und weiter in den Shop
  const durchlass = leseCookie(anfrage, 'wr_pass');
  if (durchlass && await signaturGueltig(durchlass, schluessel)) {
    return verlaengern(durchlass);
  }

  // Freier Platz: neuen Durchlass ausstellen, Seite direkt ausliefern
  if (await zaehler.belegen()) {
    return neuerDurchlass({ gueltigMinuten: 45 });
  }

  // Kein Platz: Warteseite unter derselben Adresse, 503 statt 200
  const marke = leseCookie(anfrage, 'wr_marke') || await zaehler.einreihen();
  return new Response(WARTESEITE, {
    status: 503,
    headers: {
      'Retry-After': '30',
      'Cache-Control': 'no-store',
      'Content-Type': 'text/html; charset=utf-8',
      'Set-Cookie': `wr_marke=${marke}; Path=/; Secure; HttpOnly; SameSite=Lax`
    }
  });
}

Durchlass, Sitzung und Warenkorb sauber trennen

Naheliegend wäre, den Durchlass einfach an die Shop-Sitzung zu hängen. Das ist aus zwei Gründen keine gute Idee. Erstens kennt der Rand die Sitzung nicht, ohne die Anwendung zu fragen – und genau das soll er vermeiden. Zweitens ist die Lebensdauer einer PHP-Sitzung kein verlässlicher Taktgeber: Ohne eigene Einstellung gelten Sitzungsdaten laut PHP-Handbuch nach 1440 Sekunden, also 24 Minuten, als Datenmüll und können ab dann bei einer Speicherbereinigung gelöscht werden; ob diese beim Sitzungsstart läuft, hängt von session.gc_probability und session.gc_divisor ab. Die 24 Minuten sind also eine Frühestgrenze, keine feste Ablauffrist. Shopware verweist laut eigener Dokumentation auf denselben PHP-Wert, solange Symfony keine eigene Lebensdauer setzt.

Der Durchlass bekommt deshalb eine eigene, bewusst gewählte Lebensdauer, die der Rand selbst prüft. Sie sollte großzügig genug sein, dass ein Besucher in Ruhe vergleichen und bestellen kann, und kurz genug, dass verlassene Plätze zeitnah wieder frei werden. Jede Anfrage mit gültigem Durchlass verlängert ihn. Wer den Bezahlvorgang betritt, erhält eine längere Frist, damit niemand zwischen Adresseingabe und Zahlungsbestätigung zurück in die Schlange fällt. Einen Platz gibt der Zähler frei, sobald der Durchlass abläuft oder die Bestellung abgeschlossen ist.

Auch hinter dem Warteraum bleibt der Warenkorb ein möglicher Engpass. Laut Shopware-Dokumentation kann die Datenbank als Warenkorbspeicher bei hohem Durchsatz, etwa Tausenden Bestellungen pro Minute, zum Engpass werden; für solche Szenarien empfiehlt die Dokumentation Redis als Speicher für den Warenkorb. Die Umstellung ist kein Schalter für den Vorabend: Redis muss dauerhaft speichernd eingerichtet sein, damit Warenkörbe einen Neustart überstehen, bestehende Warenkörbe müssen übernommen werden, und das Ganze gehört in den Lasttest. Wie Redis darüber hinaus Seiten und Abfragen entlastet, beschreibt unser Beitrag zu Redis-Caching für Shopware.

• Durchlass als eigenes, signiertes Cookie, unabhängig von der Shop-Sitzung
• Lebensdauer des Durchlasses festgelegt und im Lasttest mit echten Einkaufswegen erprobt
• Längere Frist ab dem Betreten des Bezahlvorgangs
• Rückkehradressen und Schnittstellen der Zahlungsanbieter auf der Ausnahmeliste
• Warenkorbspeicher für hohen Durchsatz vorbereitet und dauerhaft speichernd eingerichtet
• Bei B2B-Shops mit Kundenkonto: Anmeldung und Preisabfrage liegen hinter dem Warteraum, nicht davor

Statuscodes: Was Browser, Crawler und Zwischenspeicher sehen

Welche Antwort die Warteseite trägt, entscheidet darüber, wie Browser, Suchmaschinen und Zwischenspeicher sie deuten. Die HTTP-Norm RFC 9110 sieht für eine vorübergehende Überlastung den Statuscode 503 vor. Mit dem Header Retry-After lässt sich dazu angeben, wann ein neuer Versuch sinnvoll ist – entweder als Datum oder als Anzahl Sekunden. Der Statuscode 429 aus RFC 6585 meint etwas anderes: Ein einzelner Client hat in einem Zeitraum zu viele Anfragen gestellt, und Antworten mit 429 darf ein Cache nicht speichern. Daraus folgt eine klare Arbeitsteilung: 503 mit Retry-After für die Warteseite, weil der Shop als Ganzes gerade ausgelastet ist, und 429 für die Ratenbegrenzung einzelner Clients.

Wie Google damit umgeht, steht in der Dokumentation der Crawling-Infrastruktur. Googles Crawler werten 429 als Zeichen eines überlasteten Servers und damit als Serverfehler. Serverfehler der Klasse 5xx und der Statuscode 429 veranlassen die Crawler, vorübergehend langsamer zu crawlen. Zur 503-Seite empfiehlt Google den Header Retry-After mit einem nach bestem Wissen geschätzten Zeitpunkt oder einer Dauer. Wichtig ist die Einordnung: 503, 429 und Retry-After sind Signale. Weder Browser noch Crawler sind verpflichtet, sich an den genannten Zeitpunkt zu halten, und keine Suchmaschine sagt zu, wie sie eine bestimmte Antwort im Einzelfall bewertet.

Ebenso wichtig ist, Besucher nicht per Weiterleitung auf eine eigene Warteadresse zu schicken. Googles Crawler folgen standardmäßig bis zu 10 Weiterleitungen hintereinander, doch jede zusätzliche Station kostet Zeit, und die ursprünglich angefragte Produktseite geht verloren, wenn der Besucher später eingelassen wird. Besser ist es, die Warteseite unter der angefragten Adresse selbst auszuliefern und nach dem Einlass dieselbe Adresse neu zu laden. Für die Dauer gilt eine weitere Grenze: Google rät davon ab, Crawlern länger als 1 bis 2 Tage 500, 503 oder 429 zu liefern, weil das die Darstellung der Website in Google-Produkten beeinträchtigen kann. Ein Warteraum, der nur in Stoßzeiten für Minuten oder Stunden greift, bleibt deutlich darunter. Die 1 bis 2 Tage sind allerdings eine Einschätzung aus der Dokumentation, keine Zusage für das Ranking.

Crawler, Bots und robots.txt

Die robots.txt gehört nie hinter den Warteraum. Nach dem Robots Exclusion Protocol (RFC 9309) muss ein Crawler, der die robots.txt wegen Server- oder Netzfehlern nicht erreicht, ein vollständiges Crawlverbot annehmen. Google rät ausdrücklich davon ab, die robots.txt mit 503 zu beantworten, weil das Crawling dann blockiert wird. Wie das im Einzelnen abläuft, beschreibt Googles robots.txt-Dokumentation: Bei einem Serverfehler stoppt Google in den ersten 12 Stunden das Crawling der Website und versucht weiter, die Datei abzurufen; gelingt das danach nicht, verwendet Google für die folgenden 30 Tage die letzte gültige Fassung. Die Norm beschreibt also, was ein Crawler annehmen muss, die Google-Dokumentation, wie ein bestimmter Crawler das umsetzt. Für den Shop ist die Folgerung in beiden Fällen dieselbe: Die robots.txt steht ganz oben auf der Ausnahmeliste.

Umgekehrt taugt die robots.txt auch nicht als kurzfristiges Ventil, um Crawler während des Angebotsstarts fernzuhalten. RFC 9309 sieht vor, dass Crawler eine zwischengespeicherte Fassung nicht länger als 24 Stunden verwenden sollen, außer die Datei ist nicht erreichbar. Google speichert den Inhalt in der Regel bis zu 24 Stunden zwischen, bei Zeitüberschreitungen oder 5xx-Fehlern auch länger. Eine Änderung am Vormittag des Black Friday wirkt also womöglich erst, wenn der Andrang vorbei ist – und eine vergessene Sperre wirkt noch Tage danach. Auf die Ausnahmeliste des Warteraums gehören darum mindestens:

• robots.txt und alle Sitemaps
• Statische Dateien wie Bilder, Schriften, Stylesheets und Skripte, die ohnehin aus dem Zwischenspeicher kommen
• Rückkehradressen, Benachrichtigungen und Schnittstellen der Zahlungsanbieter sowie Rückmeldungen aus Warenwirtschaft und Versand
• Health-Checks von Load Balancer und Überwachung
• Der Statusendpunkt des Warteraums und die Warteseite selbst
• Impressum, Datenschutzerklärung und Kontaktseite, damit Pflichtangaben jederzeit erreichbar bleiben

Nicht jeder Besucher in der Schlange ist ein Mensch. Wie stark Bots die Last verzerren können, zeigt ein Beispiel außerhalb des Handels: Bei den Wikimedia-Projekten stammten mindestens 65 Prozent des teuren Verkehrs, der bis in die Kernrechenzentren durchschlägt, von Bots, obwohl Bots nur rund 35 Prozent aller Seitenabrufe ausmachten (Wikimedia Foundation, Beitrag vom 01.04.2025). Das ist kein Shopverkehr und lässt keinen Schluss auf den Bot-Anteil in einem Shop zu. Es zeigt aber, dass Last und Besucherzahl auseinanderfallen können: Wenige automatisierte Clients, die ungecachte Seiten wie Suche, Filter oder Warenkorb abfragen, belasten den Server stärker als viele Menschen auf zwischengespeicherten Kategorieseiten. Wie Sie solchen Verkehr erkennen und aussteuern, beschreibt unser Beitrag zu Bot-Traffic und Scraping im Online-Shop.

Für den Warteraum ergeben sich daraus drei Regeln. Erstens: Eine Ratenbegrenzung vor dem Warteraum bremst einzelne Clients, die in kurzer Zeit auffällig viele Anfragen stellen, mit 429 und Cache-Control: no-store – Antworten mit 429 darf nach RFC 6585 ohnehin kein Cache speichern. Zweitens: Warenkorb-, Bestands- und Suchschnittstellen sind nur mit gültigem Durchlass erreichbar, damit Skripte die Schlange nicht über die Schnittstelle umgehen. Drittens: Bekannte Suchmaschinen-Crawler bekommen ein eigenes, kleines Kontingent außerhalb der Schlange. Erkannt werden sie über einen Reverse-DNS-Abgleich mit anschließender Vorwärtsauflösung, nicht über die Kennung im User-Agent, die jeder Client frei setzen kann.

Schwellen festlegen: Wann der Warteraum greift

Die wichtigste Zahl im ganzen Aufbau ist die Kapazitätsgrenze – und sie lässt sich nicht aus einer Tabelle ablesen. Sie entsteht aus einem Lasttest mit realistischen Einkaufswegen: Startseite, Kategorie, Filter, Produktseite, Warenkorb und Kasse, in dem Mischungsverhältnis, das Ihre Protokolle aus dem Vorjahr zeigen. Gesucht ist der Kipppunkt, ab dem Antwortzeiten und Fehlerquote sprunghaft steigen. Die Grenze des Warteraums liegt mit deutlichem Abstand darunter, denn im Ernstfall kommen Effekte hinzu, die kein Test vollständig abbildet. Wie ein solcher Test aufgebaut wird und welcher Notfallplan dazugehört, beschreibt unser Beitrag Peak Season: Lasttest und Notfallplan für den Shop.

Für die Auslösung im laufenden Betrieb eignen sich Antwortzeiten besser als Besucherzahlen, weil sie die tatsächliche Belastung widerspiegeln. Einen Anhaltspunkt liefern die Richtwerte von web.dev: Als gute Nutzererfahrung gilt ein Largest Contentful Paint innerhalb von 2,5 Sekunden nach Beginn des Ladens, gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Für die Time to First Byte nennt web.dev 0,8 Sekunden oder weniger als gut und Werte über 1,8 Sekunden als schlecht. Diese Werte sind für die Bewertung von Felddaten gedacht, nicht als Auslöseschwelle eines Warteraums. Als Ausgangspunkt für einen Vorschlag taugen sie trotzdem, denn sie beschreiben, ab wann Besucher eine Seite als langsam erleben. Warum Felddaten dabei mehr aussagen als einzelne Testläufe, erklärt unser Beitrag Felddaten statt Laborwerte.

Die Stufen funktionieren als Regelkreis: Kapazität langsam erhöhen, wenn die Antwortzeiten über mehrere Minuten stabil bleiben, und schnell senken, wenn sie steigen. Wer in großen Schritten nachsteuert, erzeugt ein Pendeln zwischen Überlast und leerem Shop. Beobachten sollten Sie mindestens die Antwortzeiten der Kasse, die Fehlerquote, die Zahl aktiver Durchlässe, die Länge der Schlange und die Bestellungen pro Minute. Aus Einlassrate und Schlangenlänge lassen sich außerdem der Wert für Retry-After und die angezeigte Wartezeit schätzen. Wie Sie diese Werte dauerhaft erfassen und Alarme sinnvoll setzen, zeigt unser Beitrag zur Überwachung von Verfügbarkeit und Performance.

Die Warteseite: statisch, mobil, ehrlich

Die Warteseite ist oft der erste Eindruck, den ein Besucher an diesem Tag vom Shop bekommt – und meist sieht er sie auf dem Smartphone. Beim Online-Shopping wird laut Bitkom-Studienbericht zum digitalen Handel am häufigsten das Smartphone genutzt, mit 73 Prozent deutlich vor allen anderen Geräten. Die Seite wird deshalb mobil zuerst gestaltet und muss auch über ein schwaches Mobilfunknetz schnell stehen: eine einzelne HTML-Datei von wenigen Kilobyte, mit eingebettetem CSS, ohne Webfonts, ohne Bilder aus dem Katalog und ohne Skripte von Drittanbietern. Wie Seiten auf mobilen Geräten schnell werden, beschreibt unsere Leistung zur PageSpeed-Optimierung.

• Eine klare Überschrift: Der Shop ist gerade sehr gefragt, Sie sind in der Warteschlange.
• Position oder Fortschrittsbalken, dazu die geschätzte Wartezeit als Spanne statt als sekundengenaue Angabe
• Der Hinweis, die Seite geöffnet zu lassen, weil Neuladen nichts beschleunigt und die Position nicht verbessert
• Ein Satz zum Warenkorb, wenn der Shop gespeicherte Warenkörbe beim nächsten Besuch wiederherstellt
• Barrierefreiheit: ausreichender Kontrast, Statusänderungen über eine Live-Region für Screenreader, keine reine Farbcodierung
• Verweise auf Impressum, Datenschutzerklärung und Kontakt
• Keine Tracking-Skripte und keine Einwilligungsabfrage – die Seite soll so wenig wie möglich laden

Einen Teil der Spitze erzeugt der Shop selbst: Ein Newsletter, der um Punkt 20 Uhr an alle Empfänger gleichzeitig geht, schickt einen großen Teil der Leser in derselben Minute auf dieselbe Seite. Gestaffelter Versand in Wellen glättet die Kurve, ohne dass jemand spürbar später vom Angebot erfährt. Wie gut vorbereitet viele Käufer sind, zeigen Zahlen der Bitkom: 61 Prozent der Black-Friday- und Cyber-Week-Shopper 2025 hatten schon eine klare Vorstellung von ihrem Budget, und diese Gruppe plante im Durchschnitt 312 Euro ein; in der entsprechenden Gruppe waren es 2024 noch 280 Euro, damals bei 53 Prozent mit festem Budget. Wer mit festem Budget und Einkaufsliste kommt, will zügig zur Kasse. Eine kurze Wartezeit mit ehrlicher Angabe ist dabei das kleinere Übel gegenüber einer Kasse, die mitten in der Zahlung abbricht.

Zeitplan für den Black Friday 2026

Zwischen Anfang Oktober und dem 27. November liegen gut sieben Wochen. Das reicht für einen sauberen Aufbau, aber nicht für Experimente in der letzten Woche. Ein realistischer Ablauf sieht so aus:

1. KW 42: Architektur festlegen – wo der Warteraum sitzt, welches Steuerungsmodell gilt und welche Adressen auf die Ausnahmeliste gehören.
2. KW 43 bis 44: Warteraum, Warteseite und Statusendpunkt bauen, den Warenkorbspeicher umstellen und Messpunkte einrichten.
3. KW 45: Lasttest mit realistischen Einkaufswegen, Kipppunkt bestimmen, Kapazitätsgrenze und Auslösestufen festlegen.
4. KW 46: Probelauf im Live-Betrieb mit niedriger Grenze, etwa bei einer kleineren Aktion, einschließlich Zahlungsrückkehr und Crawler-Zugriff.
5. KW 47: Änderungsstopp für Shop, Plugins und Infrastruktur; nur noch Fehlerbehebungen nach Freigabe.
6. 27. November: Warteraum scharf, Team in Bereitschaft, Lagebild im Blick.
7. Danach: Protokolle auswerten und die Grenzen für das nächste Jahr und für andere Aktionen anpassen.

Der Änderungsstopp ist kein Formalismus. Jedes Update in den Tagen vor dem Black Friday verändert das Lastverhalten, das Sie im Test gemessen haben. Größere Vorhaben wie die Vorbereitung auf das Upgrade zu Shopware 6.8 gehören deshalb entweder vor den Lasttest oder in den Dezember. Und wenn doch etwas ausgerollt werden muss, dann mit einem Verfahren, das ohne Ausfallzeit umschaltet und sich sofort zurücknehmen lässt, wie es der Beitrag zu Zero-Downtime-Deployments mit Blue-Green-Umschaltung beschreibt.

Häufige Fehler beim Warteraum

• Die Warteseite wird mit Statuscode 200 ausgeliefert und landet in Zwischenspeichern oder im Suchindex.
• Die robots.txt oder die Sitemaps stehen hinter dem Warteraum.
• Die Rückkehr vom Zahlungsanbieter läuft in die Schlange, und bezahlte Bestellungen bleiben offen.
• Der Durchlass hängt an der Shop-Sitzung und verfällt mitten im Bezahlvorgang.
• Der Warteraum ist als Plugin in der Shop-Anwendung gebaut und lässt die Last erst herein, bevor er sie sortiert.
• Die Warteseite lädt Schriften, Bilder und Tracking-Skripte und gerät unter dieselbe Last wie der Shop.
• Neuladen verbessert die Position, und Besucher mit Skripten überholen alle anderen.
• Die Kapazitätsgrenze stammt aus einer Schätzung statt aus einem Lasttest.

So gehen wir dabei vor

Am Anfang steht bei uns eine Bestandsaufnahme: Mit dem Shop-Check sehen wir uns Aufbau, Antwortzeiten, Zwischenspeicher und die Wege zur Kasse an und klären, wo der Engpass heute liegt. Daraus entsteht ein Plan für die Vorschaltebene – im bestehenden Hosting oder auf unserer Cloud-Infrastruktur. Im Rahmen der Shopware-Wartung übernehmen wir Updates, Änderungsstopp und Bereitschaft rund um die Aktionstage; beim Hosting für Shopware können Warteraum, Zähler und Überwachung Teil des laufenden Betriebs werden. Wenn Sie wissen möchten, was für Ihren Shop bis Ende November noch realistisch ist, schreiben Sie uns über das Kontaktformular.