Black Friday 2026: Ihre PrestaShop-Checkliste zur Vorbereitung

Zuletzt geprüft im Juni 2026 für die kommende Saison. Termine bestätigt: Black Friday 2026 = Freitag, 27. November; Cyber Monday = 30. November. Back-Office-Pfade gelten für PrestaShop 1.7, 8 und 9.

Der Black Friday 2026 fällt auf Freitag, den 27. November, der Cyber Monday auf den 30. November — der viertägige Ansturm läuft also vom 27. bis 30. November, und das sinnvolle Vorbereitungsfenster beginnt Ende September. Die Shops, die am Ende vorn liegen, sind nicht unbedingt die mit den höchsten Rabatten; es sind die, deren PrestaShop-Installation vor der ersten Traffic-Welle unter Last getestet, eingefroren und durchgespielt wurde. Dies ist ein wochenweiser Vorbereitungs-Countdown, den Sie auf jeden Freitag anwenden können, auf den der Black Friday fällt — 2026 ist das zum Beispiel der 27. November — mit den konkreten Aufgaben, dem richtigen Zeitpunkt und den genauen Stellen im PrestaShop-Backoffice.

Der Plan bleibt bewusst bei seinem Thema. Wie Sie Rabatte aufbauen, Blitzangebote planen und Warenkörbe zurückgewinnen, behandeln wir jeweils ausführlich an anderer Stelle in diesem Themencluster — dieser Beitrag ist der Zeitplan, der Ihnen sagt, wann Sie welchen Hebel ziehen sollten, inklusive der PrestaShop-spezifischen Vorbereitungsschritte, die Marketing-Leitfäden meist voraussetzen.

Der Countdown für 2026 auf einen Blick

Richten Sie jede Aufgabe am 27. November aus und planen Sie rückwärts. Die folgenden Daten sind Fristen, keine Empfehlungen — die meisten Ausfälle am Aktionstag lassen sich auf einen Schritt zurückführen, der in die letzte Woche gequetscht wurde, obwohl er Puffer gebraucht hätte.

8 Wochen vorher (Anfang Oktober): die Grundlage richtig aufsetzen

Der Black-Friday-Traffic liegt häufig um ein Vielfaches über Ihrem normalen Volumen — das ist eine Richtung, kein Versprechen, und Ihre eigenen Analytics-Daten aus dem letzten November sind die einzig ehrliche Basis. Der Grund, hier zu beginnen: Kapazitäts- und Performance-Arbeiten lassen sich in der letzten Woche nicht sicher erzwingen, weil jede Änderung einen Fehler einschleppen kann, für den Ihnen dann die Zeit zum Entdecken fehlt.

Erst unter Last testen, dann optimieren

Raten Sie nicht, wo Ihr Shop an seine Grenzen kommt — messen Sie es. Tools wie k6 oder Loader.io können Hunderte gleichzeitige Nutzer simulieren, die Ihre Kategorie-, Produkt- und Kassenseiten aufrufen. Führen Sie den Test gegen eine Staging-Kopie aus, nicht gegen die Produktion, und beobachten Sie, wo die Antwortzeiten steigen: Eine Datenbank, die bei 20 gleichzeitigen Nutzern unauffällig ist, kann bei 300 kippen. Der Bestellablauf (der order-Controller) ist die Seite, die nicht ausfallen darf — testen Sie ihn gezielt unter Last, mit Artikeln, die tatsächlich bis zur Bestellbestätigung durchlaufen.

Aktivieren Sie die Performance-Einstellungen, die PrestaShop bereits mitbringt

Das meiste, was Sie brauchen, finden Sie im Backoffice unter Erweiterte Einstellungen → Leistung. Gehen Sie nicht davon aus, dass es aktiv ist — prüfen Sie jeden Punkt:

• Smarty-Cache: Stellen Sie das Caching auf Ja und die Template-Kompilierung auf "Nie neu kompilieren". Templates bei jeder Anfrage während eines Traffic-Peaks neu zu kompilieren, verschwendet CPU-Leistung, die Sie nicht übrig haben.
• CCC (Kombinieren, Komprimieren, Cachen): Aktivieren Sie "Smart cache for CSS" und "Smart cache for JavaScript", damit der Browser weniger und kleinere Dateien lädt. Testen Sie danach das Front Office — CCC verträgt sich gelegentlich schlecht mit einem unsauber gebauten Theme, und das wollen Sie jetzt herausfinden, nicht am 27. November.
• OPcache: Stellen Sie sicher, dass er tatsächlich funktioniert und nicht nur installiert ist. Prüfen Sie den Status mit Ihren Hosting-/Server-Tools oder einer phpinfo/OPcache-Statusseite, statt sich nur auf den PrestaShop-Leistungsbildschirm zu verlassen; wenn er deaktiviert ist, wirkt eine Serveränderung erst, nachdem Sie ihn geleert haben. Prüfen, dann in Ruhe lassen.
• Caching (Redis/Memcached): Unter "Caching" auf derselben Seite können Sie PrestaShops Cache auf Redis oder Memcached zeigen lassen, sofern Ihr Hoster das anbietet — je nach Version sind dafür allerdings oft Server- oder Modulkonfigurationen nötig. Das ist einer der größten Hebel, wenn eine Datenbank unter gleichzeitigen Warenkörben ächzt. Sitzungen von der Festplatte wegzuziehen, ist eine separate Aufgabe: Das wird auf Server-/PHP-Ebene (oder über ein Modul) konfiguriert, nicht über diese Caching-Einstellung.

Verschlanken Sie außerdem Ihre Medien: Überdimensionierte Produktbilder sind der unauffälligste Page-Speed-Killer, wenn Tausende gleichzeitig stöbern. Komprimieren Sie sie jetzt und bringen Sie sie auf die richtige Größe, solange Sie noch Zeit haben, die Ergebnisse stichprobenartig zu prüfen.

6 Wochen vorher (Mitte Oktober): aktualisieren, dann den Freeze vorbereiten

Aktualisieren Sie den PrestaShop-Core, jedes Modul und Ihr Theme jetzt — nicht in der Woche davor. Updates können unerwartetes Verhalten auslösen, und genau deshalb erledigt man sie sechs Wochen vorher: Sie kaufen sich mehrere Wochen Puffer, um alles zu finden und zu beheben, was kaputtgeht. Führen Sie die Updates zuerst in einer Staging-Kopie durch, klicken Sie sich durch die Kasse und eine Testbestellung, und übernehmen Sie sie erst dann in die Produktion.

Die wichtigste Disziplin: Planen Sie einen harten Code-Freeze für den 1. November. Nach diesem Datum keine Modulinstallationen, keine Theme-Anpassungen, keine Core-Änderungen mehr, außer es brennt wirklich. Jede "schnelle Kleinigkeit" im November kann die Kasse beschädigen, ausgerechnet dann, wenn Sie am wenigsten Zeit haben, es zu bemerken. Informieren Sie alle Personen mit Backoffice-Zugang frühzeitig über das Freeze-Datum, damit es keine Überraschung ist.

4 Wochen vorher (Ende Oktober): Rabatte in Staging aufbauen und testen

An dieser Stelle vermischen Händler oft zwei unterschiedliche Aufgaben. Das Gestalten des Angebots — wie hoch der Rabatt sein soll, prozentual vs. fester Betrag, gestaffelt, gebündelt — ist eine Strategiefrage, die wir in Aktionen in PrestaShop durchführen: Warenkorbregeln, spezifische Preise und Rabattstrategien behandeln; die Faustregel zum Schutz Ihrer Marge finden Sie in Rabattausschlüsse: Warum manche Produkte nie reduziert werden sollten. Was hier auf die Checkliste gehört, ist der Vorbereitungsschritt: Bauen Sie das, wofür Sie sich entschieden haben, in einer Staging-Kopie auf und weisen Sie nach, dass es korrekt greift, bevor es jemals einen Live-Warenkorb berührt.

In PrestaShop stehen Ihnen zwei Mechanismen zur Verfügung: Katalog → Rabatte → Warenkorbregeln (Gutscheine, Bedingungen, automatische Codes) und Katalog → Rabatte → Katalogpreisregeln / produktspezifische Spezifische Preise (ein direkt am Produkt angezeigter durchgestrichener Preis). Das müssen Sie mit echten Test-Warenkörben prüfen:

• Der Rabatt greift tatsächlich für die Produkte, für die er gedacht ist — und nicht für die, die Sie ausgeschlossen haben.
• Rabatte stapeln sich nicht so, dass sie Ihre Marge auslöschen. Eine Warenkorbregel plus eine Katalogpreisregel plus eine Kundengruppen-Ermäßigung können sich unbemerkt addieren.
• Schwellen für kostenlosen Versand und Mindestwarenkorb-Bedingungen greifen beim richtigen Betrag, inklusive Steuern, falls Ihr Shop sie anzeigt.
• Die Felder "Verfügbare Menge" und die Datumsfelder einer Warenkorbregel verhalten sich wie erwartet — ein Gutschein, der mitten am Wochenende aufgebraucht ist oder abläuft, sorgt zuverlässig für Kundenservice-Aufwand.

Rabattfehler am Black Friday sind teuer und peinlich zugleich. Die Lösung ist unspektakulär: Testen Sie sie vier Wochen vorher, in Staging, mit einer Checkliste.

Entscheiden Sie, was automatisch läuft und was manuell

Sie möchten am 27. nicht um 6 Uhr morgens manuell Preise umschalten. PrestaShops Warenkorbregeln und spezifische Preise haben beide Datumsbereiche mit "von / bis", sodass ein Angebot Wochen im Voraus konfiguriert werden und planmäßig ohne Eingriff live gehen kann. Wie Sie Aktionen automatisch starten und stoppen lassen — inklusive der Fallstricke rund um Server-Zeitzonen — erklären wir in geplante Rabatte: Aktionen einrichten, die automatisch starten und stoppen. Wenn Ihr Plan vorsieht, über das Wochenende wechselnde Angebote zu fahren statt einer statischen Aktion, behandeln wir die Automatisierung in Black-Friday-Vorbereitung: Rabatte und Aktionen in PrestaShop automatisieren; unser eigenes Modul Sales Revolution übernimmt geplante Blitzangebote, damit die Rotation ohne ständige Aufsicht läuft. Eine ehrliche Einordnung von Dringlichkeits-Taktiken — Countdown-Timer, "nur solange der Vorrat reicht" — finden Sie in Blitzverkäufe: Dringlichkeit erzeugen, ohne manipulativ zu wirken.

2 Wochen vorher (Mitte November): planen, trocken durchlaufen und Datenfeeds vorbereiten

Wenn der Freeze steht und die Rabatte getestet sind, geht es in diesen zwei Wochen um Planung und Probe, nicht mehr ums Bauen.

• Starttermine setzen. Tragen Sie bei jeder Warenkorbregel und jedem spezifischen Preis den Start am 27. Nov. und das Ende am 30. Nov. (oder 1. Dez.) ein. Prüfen Sie die Zeitzone des Shops unter International → Lokalisierung → Lokalisierung doppelt — ein auf "Mitternacht" gesetztes Angebot startet zur Serverzeit, die nicht zwingend der Mitternacht Ihrer Kunden entspricht.
• Zielseite aufbauen. Eine eigene Black-Friday-Kategorie oder CMS-Seite ist der Ort, auf dem Ihr E-Mail- und Anzeigen-Traffic landet. Erstellen Sie sie jetzt (auf Wunsch bis zum Start nicht indexiert oder unveröffentlicht), damit Sie am Aktionstag nur einen Schalter umlegen und nicht unter Druck bauen.
• Banner ohne Designer. Die Titel- und Promo-Grafiken, die Ihre Aktion ankündigen, brauchen keine Designagentur — siehe Banner Revolution: auffällige Aktionen ohne Designer erstellen.
• Google-Merchant-Center-Datenfeed. Wenn Sie Shopping-Anzeigen schalten, befüllen Sie die Attribute sale_price und sale_price_effective_date, damit Google während des Aktionszeitraums den durchgestrichenen Preis anzeigt. Reichen Sie den Datenfeed früh ein; die erneute Datenfeed-Verarbeitung passiert nicht sofort.
• Vollständiger Trockenlauf. Gehen Sie einmal die komplette Kundenreise durch: auf der Black-Friday-Seite landen, ein reduziertes Produkt in den Warenkorb legen, bei Verwendung von Codes einen Gutschein anwenden, bis zur Bestellbestätigung kommen. Dann machen Sie dasselbe noch einmal auf einem Smartphone. Diese eine Probe findet mehr echte Probleme als jeder einzelne Checklistenpunkt.

1 Woche vorher (~20. November): operative Einsatzbereitschaft

Der Code ist eingefroren und getestet; jetzt stellen Sie sicher, dass der Betrieb dahinter mithalten kann.

• Lagerbestand. Prüfen Sie unter Katalog → Lagerbestände die Bestände für alles, was Sie bewerben. Überverkäufe und anschließende Stornierungen beschädigen Vertrauen nachhaltiger als eine verpasste Bestellung. Legen Sie das Verhalten bei nicht verfügbaren Artikeln (ablehnen / Nachbestellung erlauben) bewusst pro Produkt fest.
• Backups. Erstellen Sie am Vortag ein vollständiges Datenbank- und Datei-Backup und bestätigen Sie, dass Sie es tatsächlich wiederherstellen können. Ein nie getestetes Backup ist Hoffnung, kein Sicherheitsnetz. PrestaShops Erweiterte Einstellungen → Datenbank → DB-Sicherung deckt die Datenbank ab; Ihr Hoster oder eine eigene Routine sollte die Dateien abdecken.
• Monitoring. Richten Sie einen Uptime-Monitor (UptimeRobot, Pingdom) auf Ihre Startseite und auf eine tiefe Seite wie die Kasse, damit Sie binnen Minuten alarmiert werden, wenn die Website ins Stolpern kommt — nicht erst, wenn ein Kunde Ihnen schreibt.
• Kundendienst & Versand. Bestätigen Sie die Annahmeschlusszeiten der Versanddienstleister und planen Sie erweiterte Kundendienst-Abdeckung. Schreiben Sie Antworten auf die vorhersehbaren Fragen vor: "Funktioniert mein Code?", "Wann kommt es an?", "Wie ist die Rückgaberegelung?". Realistische Liefererwartungen an der Kasse zu setzen, ist genau der Zweck einer automatisierten Anzeige des voraussichtlichen Liefertermins.

Das Wochenende selbst (27.–30. November): ausführen und beobachten

Wenn Sie die Arbeit oben erledigt haben, besteht das Wochenende vor allem aus Beobachtung. Ihre geplanten Angebote gehen von selbst live; Ihre Aufgabe ist es, Auffälligkeiten schnell zu erkennen.

• Bestätigen, dass die Angebote gestartet sind. Laden Sie am 27. als Erstes das Front Office wie ein Kunde und prüfen Sie, ob die reduzierten Preise tatsächlich angezeigt werden. Ein Zeitzonenfehler ist der klassische 6-Uhr-morgens-Panikmoment.
• Die richtigen Dashboards beobachten. Behalten Sie Serverlast, Fehlerraten und abgeschlossene Bestellungen im Blick. In Google Analytics 4 sollten Sie die Echtzeit-Conversions beobachten — ein plötzlicher Einbruch bedeutet meist, dass etwas kaputt ist, nicht dass die Nachfrage verschwunden ist.
• Antwortzeiten realistisch im Blick behalten. Wenn die Last steigt, nutzen Sie den Spielraum, den Sie im Oktober aufgebaut haben. Widerstehen Sie der Versuchung, mitten am Wochenende "schnell ein Caching-Modul zu installieren" — genau solche Änderungen sollte der Freeze verhindern.
• Zurückholen, was verloren geht. Selbst ein fehlerfreies Wochenende verliert einige Warenkörbe. Sequenzen für Warenkorbabbrecher und Follow-ups nach dem Kauf, mit denen Sie einen Teil zurückgewinnen, lohnen sich vorbereitet zu haben — sie sind jedoch eine Kampagne, kein Checklistenpunkt, und gehören deshalb in Ihren breiteren saisonalen Aktionskalender.

Nach dem Wochenende: festhalten, was Sie gelernt haben

Black Friday ist kein isoliertes Ereignis — er ist der laute Auftakt einer Saison, die über Weihnachten bis in die Neujahrsplanung reicht. Bevor sich der Staub legt, schreiben Sie die Zahlen auf, solange sie frisch sind: welche Produkte sich verkauft haben, welche Kanäle Umsatz gebracht haben, wo der Shop unter Druck geraten ist und welcher Rabattmechanismus tatsächlich Bestellungen bewegt hat. Dieses Dokument ist Ihr Vorsprung fürs nächste Jahr — und so wird aus einem chaotischen ersten Black Friday ein ruhiger, wiederholbarer Ablauf.

Das Muster darunter ist jedes Jahr dasselbe: Gewonnen wird in den Wochen davor, in Staging, unter Lasttest, hinter einem Code-Freeze. Das Datum für 2026 steht fest: der 27. November. Alles andere bedeutet nur, mit genügend Puffer von dort rückwärts zu arbeiten, damit Sie beheben können, was Sie finden.

Häufig gestellte Fragen

Auf welches Datum fällt der Black Friday 2026, und wann sollte ich anfangen?

Der Black Friday 2026 ist Freitag, der 27. November; der Cyber Monday ist der 30. November. Arbeiten Sie rückwärts: technische Grundlage und Lasttests etwa 8 Wochen vorher (Anfang Oktober), Updates bis 6 Wochen vorher, Rabatte bis 4 Wochen vorher in Staging aufgebaut und getestet, Code-Freeze am 1. November, Planung und Trockenläufe zwei Wochen vorher sowie operative Einsatzbereitschaft (Bestand, Backups, Monitoring) in der Woche um den 20. November.

Ein Angebot, das ich für "Mitternacht" geplant hatte, ging zur falschen Zeit live. Warum?

PrestaShop bewertet das "gültig von / bis" einer Warenkorbregel anhand der Zeitzone des Shops, eingestellt unter International → Lokalisierung → Lokalisierung — das ist Serverzeit und nicht zwingend die lokale Mitternacht Ihrer Kunden. Prüfen Sie diese Einstellung vor dem Wochenende und tragen Sie Ihre Daten mit dem Versatz im Kopf ein. Dieser Zeitzonenfehler ist der klassische 6-Uhr-morgens-Panikmoment am 27.

Soll ich Rabatte in der Produktion oder in einer Staging-Kopie anlegen?

Immer in Staging. Bauen Sie die Rabatte dort auf und weisen Sie nach, dass sie korrekt greifen — und nicht auf Ihre ausgeschlossenen Produkte angewendet werden —, bevor Sie die getestete Konfiguration in die Produktion übernehmen. Auch Lasttests sollten gegen Staging laufen, nicht gegen den Live-Shop, damit ein Test mit Hunderten gleichzeitigen Kassenläufen keinen echten Traffic lahmlegt.

Kann ich mitten am Wochenende ein Caching-Modul installieren, wenn die Website langsam wird?

Nein — genau dafür gibt es den Code-Freeze. Ein neues Modul während des Spitzen-Traffics ist die riskanteste Änderung, die Sie vornehmen können, und Sie haben die geringste Zeit, eine Regression in der Kasse zu entdecken. Bauen Sie Ihren Spielraum im Oktober auf. Wenn die Last am Aktionstag steigt, stützen Sie sich auf das Caching und die Kapazität, die Sie bereits getestet haben, beobachten Sie die abgeschlossenen Bestellungen und widerstehen Sie der "schnellen Lösung".

Brauche ich separaten Sitzungsspeicher, wenn ich Caching auf Redis umstelle?

Ja — das sind unterschiedliche Aufgaben. Wenn Sie PrestaShops Objekt-Cache auf Redis oder Memcached zeigen lassen (unter Erweiterte Einstellungen → Leistung → Caching), entlastet das die Datenbank bzw. den Datenträger, aber PHP-Sitzungen vom Dateisystem wegzuziehen, wird separat auf Server-/PHP-Ebene oder über ein Modul konfiguriert. Das eine erledigt nicht automatisch das andere; planen Sie beides, wenn Ihre Gleichzeitigkeit es rechtfertigt.