Kurz und einfach erklärt
Manchmal verschwinden Seiten eines Shops aus Suchmaschinen. Oft liegt es an nur einer Einstellung. Sie kommt zum Beispiel aus einem Testsystem in den echten Shop.
Der Shop läuft dabei ganz normal. Darum fällt der Fehler oft spät auf.
Der Beitrag zeigt, wie man das prüfen kann. Für jede wichtige Seite legt man fest, wie sie aussehen soll. Eine Prüfung meldet jede Abweichung.
Wir richten diese Prüfung für Ihren Shop ein.
Ein Shop, der aus dem Index fällt, meldet keinen Fehler. Der Server antwortet mit 200, der Warenkorb funktioniert, die Ladezeit ist unauffällig – und trotzdem verschwinden Kategorie- und Produktseiten binnen Tagen aus den Suchergebnissen. Auslöser ist meist eine einzelne Zeile: eine Robots-Direktive, die aus einer Testumgebung in die Produktion gewandert ist. Solche Direktiven sind kein Randthema, sondern Alltag – 47,0 Prozent der Desktopseiten und 47,9 Prozent der Mobilseiten liefern eine aus (Web Almanac 2025). Genau deshalb fällt eine gekippte Direktive so selten auf. Dieser Beitrag beschreibt eine Prüfkette aus fünf Stationen, die den Zustand messbar macht, bevor die Suchkonsole ihn Wochen später bestätigt.
Das Wichtigste in Kürze
- Ein versehentliches noindex erzeugt keinen Fehlerstatus. Die Seite antwortet mit 200, der Checkout arbeitet – und trotzdem entfernt die Suchmaschine sie vollständig aus den Ergebnissen, unabhängig davon, wie viele Verweise auf sie zeigen (Google Search Central).
- Sperrende Direktiven sind selten: noindex steht auf 3,5 Prozent der Desktop- und 2,4 Prozent der Mobilseiten, nofollow auf 2,4 und 2,8 Prozent (Web Almanac 2025). Der Antwortkopf X-Robots-Tag kommt auf 0,6 Prozent und wird selten geöffnet.
- Die Prüfkette hat fünf Stationen: Abruf und Status, robots.txt, Meta-Robots, Canonical-Host, Sitemap-Status. Unterseiten tragen mit 50 Prozent häufiger eine Direktive als Startseiten mit 46 Prozent (Web Almanac 2025) – wer nur die Startseite abfragt, misst falsch.
- Die robots.txt ist kein Mittel zum Ausschluss aus dem Index: Eine gesperrte Adresse kann weiterhin in den Ergebnissen erscheinen, nur ohne Textausschnitt (Google Search Central). Wer gleichzeitig sperrt und noindex setzt, verhindert, dass die Direktive überhaupt gelesen wird.
- Die Suchkonsole ist ein Nachlaufindikator: Die Beispielliste ist auf 1.000 Zeilen gedeckelt, die Bestätigung einer Korrektur dauert bis zu etwa zwei Wochen (Google Search Console-Hilfe), und bis der Crawler wiederkommt, können Monate vergehen (Google Search Central).
- Der Rahmen ist bezifferbar: Der deutsche Onlinehandel setzte zuletzt 92,3 Mrd. Euro um (HDE), Unternehmen in der EU erzielen 19,49 Prozent ihres Gesamtumsatzes über Onlineverkäufe (Eurostat). Davon entfallen 8,39 Prozentpunkte auf Websites und Apps, der Rest auf EDI.
Wie ein noindex in die Produktion gerät
Der Weg ist fast in jedem Fall derselbe. Eine Testumgebung trägt die Direktive zu Recht, damit ihre Inhalte nicht in den Index geraten. Dann wird ein Klon in die Produktion gezogen, eine Umgebungsvariable bleibt gesetzt, ein Wartungsmodus wird nur halb abgeschaltet, oder eine Regel am vorgelagerten Proxy setzt den Antwortkopf für alle Anfragen. In Testumgebungen und Freigabewegen ist dieses Verhalten gewollt; der Fehler entsteht beim Übergang, nicht beim Setzen. Und weil der Übergang selten protokolliert wird, gibt es keinen Zeitstempel, an dem eine spätere Untersuchung ansetzen könnte.
Die zweite Gruppe von Ursachen liegt in den Erweiterungen. Ein SEO-Modul verliert nach einem Update seine Konfiguration und fällt auf einen Vorgabewert zurück; ein Kategoriefilter setzt für Parameterseiten pauschal noindex und erwischt dabei die Hauptkategorie; eine abgelaufene Lizenz schaltet ein Modul in einen eingeschränkten Betrieb. Dass Lizenzfristen von Erweiterungen den Funktionsumfang verändern, ist selbst ein Wartungsthema – und ein Auslöser, der in keinem Deployment-Protokoll steht, weil an dem Tag niemand etwas veröffentlicht hat.
Ein Status 200 ist kein Nachweis von Sichtbarkeit
Was die Bestandszahlen über Robots-Direktiven sagen
Robots-Direktiven sind der Normalfall, nicht die Ausnahme: 47,0 Prozent der Desktopseiten und 47,9 Prozent der Mobilseiten liefern überhaupt eine aus (Web Almanac 2025). Sperrend ist davon nur ein kleiner Teil, und die Quelle beziffert die beiden Regeln getrennt: noindex steht auf 3,5 Prozent der Desktopseiten und 2,4 Prozent der Mobilseiten, nofollow auf 2,4 Prozent der Desktopseiten und 2,8 Prozent der Mobilseiten (Web Almanac 2025, Abbildung 5.8). Der Fließtext derselben Quelle fasst beide Regeln zu 2,8 Prozent Desktop und 2,4 Prozent Mobil zusammen; dieser Sammelwert liegt unter dem dort ausgewiesenen noindex-Anteil und wird hier deshalb nicht als Leitzahl geführt. Für die Überwachung folgt daraus eine unbequeme Eigenschaft: Die Zeile steht auf fast jeder zweiten Seite, ihr Inhalt kippt selten, und deshalb sucht sie niemand.
Zwei weitere Werte erklären, warum die Fehlersuche oft an der falschen Stelle ansetzt. Der Antwortkopf X-Robots-Tag kommt auf 0,6 Prozent der Desktopseiten und 0,7 Prozent der Mobilseiten (Web Almanac 2025) – er ist so selten, dass er beim Blick in den Quelltext gar nicht auffällt, obwohl er dieselbe Wirkung hat. Und 10,1 Prozent der Desktopseiten sowie 10,3 Prozent der Mobilseiten enthalten ungültige Elemente im Kopfbereich des Dokuments (Web Almanac 2025); ein vorzeitig beendeter Kopfbereich kann die Meta-Robots-Zeile aus dem gerenderten Dokument werfen, obwohl sie im Quelltext steht.
| Station | Was gemessen wird | Bestandswert | Typischer Fehlerfall |
|---|---|---|---|
| Abruf und Status | HTTP-Status je Zieladresse | alle 4xx außer 429 werden gleich behandelt (Google Search Central) | Produktseite fällt nach Sortimentspflege still auf 404 |
| robots.txt | Statuscode, Größe, Inhalt | 85 Prozent der Abrufe liefern einen gültigen 200 (Web Almanac 2025) | Disallow aus der Testumgebung bleibt stehen |
| Meta-Robots | Direktive im gerenderten Dokument | 3,5 Prozent tragen noindex, 2,4 Prozent nofollow (Desktop, Web Almanac 2025) | Vorgabewert nach einem Modul-Update |
| X-Robots-Tag | Direktive im Antwortkopf | 0,6 Prozent nutzen den Antwortkopf (Web Almanac 2025) | Regel am vorgelagerten Proxy trifft alle Antworten |
| Canonical-Host | Ziel der Canonical-Angabe | 68 Prozent der Desktopseiten setzen ein Canonical (Web Almanac 2025) | Canonical zeigt nach dem Umzug auf den Testhost |
| Sitemap-Status | Erreichbarkeit, Umfang, Grenzen | 50.000 Adressen je Datei (sitemaps.org) | Die Datei reißt die Grenze und wird nicht vollständig verarbeitet |
Die Tabelle zeigt zugleich, warum eine einzelne Messung nicht reicht. Jede Station kann für sich unauffällig sein, während die Kombination die Seite unsichtbar macht: Eine Adresse mit sauberem 200 und korrekter Meta-Zeile bleibt wirkungslos, wenn die robots.txt den Abruf sperrt – dann wird die Meta-Zeile gar nicht gelesen (Google Search Central). Wer nur eine Station misst, bekommt ein grünes Ergebnis mit falscher Bedeutung.
Die fünf Stationen der Prüfkette
Eine belastbare Kette läuft je Stichprobe über dieselben fünf Stationen und speichert das Ergebnis je Station getrennt. Wichtig ist die Auswahl der Adressen: nicht die Startseite, sondern ein fester Satz aus Kategorien, Produktseiten, Filterseiten und Inhaltsseiten. Unterseiten tragen mit 50 Prozent häufiger eine Robots-Direktive als Startseiten mit 46 Prozent (Web Almanac 2025) – wer nur die Startseite abfragt, misst genau die Adressen nicht, die kippen. Technisch steht eine solche Kette neben der übrigen Betriebsüberwachung und unterscheidet sich kaum von einer Verfügbarkeitsprüfung; nur der Prüfinhalt ist ein anderer.
Station 1: Abruf und Status
Je Zieladresse werden Statuscode, Weiterleitungskette und Antwortgröße festgehalten. Die Crawler folgen standardmäßig 10 Weiterleitungen (Google Search Central); alles darüber endet ohne Ergebnis.
Station 2: robots.txt
Statuscode, Dateigröße und Inhalt werden gegen den letzten bestätigten Stand verglichen. Google liest die Datei bis 500 KiB und ignoriert alles danach (Google Search Central).
Station 3: Meta-Robots
Die Direktive wird im gerenderten Dokument gelesen, nicht im Rohtext. Widersprechen sich zwei Angaben, gilt die restriktivste Regel (Google Search Central).
Station 4: Canonical-Host
Geprüft wird, ob die Canonical-Angabe auf denselben Host und dasselbe Schema zeigt. 68 Prozent der Desktopseiten setzen inzwischen eine (Web Almanac 2025).
Station 5: Sitemap-Status
Erreichbarkeit, Adressanzahl und Dateigröße werden gegen die Grenzen des Protokolls gehalten: 50.000 Adressen und 52.428.800 Bytes je Datei (sitemaps.org).
Zusatzspur: X-Robots-Tag
Der Antwortkopf wird getrennt ausgewertet, weil er dieselbe Wirkung hat und im Quelltext unsichtbar bleibt. Nur 0,7 Prozent der Mobilseiten nutzen ihn (Web Almanac 2025).
Zu jeder Station gehört ein erwarteter Zustand, der versioniert abgelegt wird: Diese Adresse ist indexierbar, jene bewusst gesperrt. Ohne diesen Sollstand meldet die Kette jede beabsichtigte Sperre als Fehler und wird nach zwei Wochen abgeschaltet, weil die Bereitschaft das Rauschen nicht mehr trennt. Der Sollstand gehört in dieselbe Verwaltung wie die übrigen Wartungsvereinbarungen, damit Änderungen daran nachvollziehbar bleiben und nicht als Zufallsbefund enden.
Station 1 und 2: Abruf, Status und robots.txt
Der Abruf ist die billigste Station und findet die gröbsten Fehler. Ein 4xx auf einer Produktseite entfernt sie aus dem Index, ohne dass irgendwo eine Warnung erscheint: Alle 4xx außer 429 werden gleich behandelt und dem nachgelagerten System als nicht vorhandener Inhalt gemeldet (Google Search Central). Deshalb gehört zu jeder Stichprobe der Statuscode am Ende der Weiterleitungskette, nicht der erste Wert. Wie sich fehlerhafte Adressen systematisch aufspüren lassen, beschreibt der Beitrag zur Pflege von 404-Seiten und Weiterleitungen.
Bei der robots.txt ist der Statuscode selbst schon eine Aussage. 85 Prozent aller Abrufe im Bestandscrawl endeten mit einem gültigen 200 (Web Almanac 2025), 13 Prozent mit einem 404 nach 14 Prozent im Vorjahr (Web Almanac 2025). Beides ist unkritisch. Kritisch ist der dritte Fall: Antwortet der Server mit einem Serverfehler, stoppt Google das Crawling der Website für die ersten 12 Stunden und arbeitet anschließend bis zu 30 Tage mit der letzten funktionierenden Fassung weiter (Google Search Central). Ein Fehler an dieser Stelle läuft also lange mit, bevor er sichtbar wird.
# Station 1: Status am Ende der Weiterleitungskette
curl -sS -o /dev/null -L -w '%{http_code} %{url_effective} %{num_redirects}\n' "$URL"
# Station 2: robots.txt mit Statuscode und Größe
curl -sS -o /tmp/robots.txt -w '%{http_code} %{size_download}\n' "$HOST/robots.txt"
grep -n -i -E '^(disallow|allow|sitemap):' /tmp/robots.txt
# Station 3: Meta-Robots und X-Robots-Tag getrennt lesen
curl -sS -L "$URL" | grep -o -i '<meta[^>]*name="robots"[^>]*>'
curl -sS -I -L "$URL" | grep -i '^x-robots-tag:'
# Station 4: Canonical gegen den Sollwert halten
curl -sS -L "$URL" | grep -o -i '<link[^>]*rel="canonical"[^>]*>'
Zwei Grenzwerte gehören in die Auswertung. Google liest die robots.txt bis 500 KiB; Inhalt jenseits dieser Größe wird ignoriert (Google Search Central), und der Standard verlangt von Crawlern mindestens 500 Kibibyte (IETF, RFC 9309). In der Praxis ist die Größe selten das Problem: 98 Prozent der Dateien blieben unter 100 KB (Web Almanac 2025). Häufiger ist der stille Fall – 1,8 Prozent der Desktopabrufe und 1,7 Prozent der Mobilabrufe lieferten eine leere Datei (Web Almanac 2025), die in jeder oberflächlichen Sichtprüfung gesund aussieht. Automatisierte Prüfungen finden das durchaus: In der Vorjahresausgabe fielen 8,43 Prozent der Desktopseiten und 7,40 Prozent der Mobilseiten bei der Prüfung auf eine gültige robots.txt durch (Web Almanac 2024).
Auch die Trägheit gehört gemessen. Eine korrigierte robots.txt wirkt nicht sofort: Google hält die Datei in der Regel bis zu 24 Stunden im Zwischenspeicher (Google Search Central), und der Standard sieht dieselbe Obergrenze vor (IETF, RFC 9309). Liegt die Datei hinter einer Weiterleitungskette, sollen Crawler mindestens fünf aufeinanderfolgenden Weiterleitungen folgen (IETF, RFC 9309) – danach ist die Erreichbarkeit nicht mehr gesichert. Wer nach einer Korrektur sofort Entwarnung gibt, misst den Zwischenspeicher, nicht die Wirkung.
Station 3: Meta-Robots und der Vorrang der strengsten Regel
Die dritte Station liest die Direktive dort, wo sie wirkt. Zwei Auslieferungswege sind gleichwertig: die Meta-Zeile im Dokument und der Antwortkopf X-Robots-Tag. Widersprechen sie sich, gewinnt die restriktivste Regel (Google Search Central). Ein vergessener Testschalter im Antwortkopf schlägt damit die korrekte Meta-Zeile, und weil der Kopf im Quelltext unsichtbar bleibt, sucht die Fehlersuche an der falschen Stelle. Genau deshalb liest die Kette beide Wege getrennt und protokolliert beide Ergebnisse nebeneinander.
Die Folgen sind unangenehm asymmetrisch. Wird die Direktive einmal gelesen, entfernt die Suchmaschine die Seite vollständig aus den Ergebnissen, unabhängig davon, wie viele Verweise auf sie zeigen (Google Search Central). Die Rückkehr dauert dagegen: Bis der Crawler eine Seite erneut besucht, können Monate vergehen (Google Search Central). Ein Deployment, das die Zeile entfernt, stellt den alten Zustand also nicht wieder her – es beendet nur das weitere Absinken.
Sperren und ausschließen sind zwei verschiedene Dinge
Station 4 und 5: Canonical-Host und Sitemap-Status
Canonical-Angaben sind inzwischen Standard: 68 Prozent der Desktopseiten und 67 Prozent der Mobilseiten tragen eine, nach jeweils 65 Prozent im Vorjahr (Web Almanac 2025). Damit wird der Canonical-Host zu einer eigenen Fehlerquelle. Zeigt die Angabe nach einem Umzug auf den Testhost oder auf eine Adresse ohne TLS, verweist die Seite selbst auf ein Dokument, das gar nicht ausgeliefert werden soll. Die Prüfkette vergleicht darum nicht nur, ob eine Canonical-Angabe existiert, sondern ob Schema, Host und Pfad dem Sollstand entsprechen.
Die Sitemap ist die fünfte Station und die einzige mit harten Zahlen. Eine Datei fasst 50.000 Adressen oder 50 MB unkomprimiert (Google Search Central); das Protokoll nennt dieselbe Grenze bytegenau mit 52.428.800 Bytes (sitemaps.org). Wird eine davon gerissen, verarbeitet der Crawler die Datei nicht mehr vollständig – und weil ein Shop mit wachsendem Sortiment langsam auf diese Grenze zuläuft, fällt der Moment ohne Messung niemandem auf. Zwei viel gepflegte Felder sind dabei wirkungslos: priority und changefreq werden ignoriert (Google Search Central).
- Feste Stichprobe aus Startseite, Kategorien, Produktseiten, Filterseiten und Inhaltsseiten festlegen und versionieren
- Je Adresse Statuscode am Ende der Weiterleitungskette, robots.txt-Zustand, Meta-Robots, X-Robots-Tag, Canonical-Ziel und Sitemap-Eintrag erfassen
- Sollstand je Adresse hinterlegen: indexierbar oder bewusst gesperrt, mit Begründung und Datum
- Die Kette bei jedem Deployment und zusätzlich zeitgesteuert laufen lassen, nicht nur nach größeren Releases
- Abweichungen als eigene Alarmklasse führen, getrennt von Erreichbarkeits- und Antwortzeitmeldungen
- Ergebnisse mindestens ein Jahr aufbewahren, damit der Zeitpunkt einer Änderung später bestimmbar bleibt
Warum die Suchkonsole allein zu spät kommt
Der Indexierungsbericht der Search Console ist ein gutes Werkzeug und ein schlechter Alarmgeber. Er zeigt je Problem nur eine gedeckelte Beispielliste: Die Liste ist auf 1.000 Zeilen begrenzt und enthält nicht zwangsläufig alle betroffenen Adressen (Google Search Console-Hilfe). Die Zahl im Diagramm ist vollständig, die Liste darunter nicht – wer den Umfang eines Vorfalls aus der Liste ableitet, unterschätzt ihn bei jedem größeren Shop erheblich.
Dazu kommt die Trägheit. Bis eine neue Seite überhaupt gecrawlt und indexiert ist, vergeht etwa eine Woche (Google Search Console-Hilfe). Die Bestätigung einer gemeldeten Korrektur dauert typischerweise bis zu etwa zwei Wochen, in Einzelfällen deutlich länger (Google Search Console-Hilfe). Und ein Vorgang bleibt derselbe Fall, bis 90 Tage nach dem letzten beobachteten Auftreten vergangen sind (Google Search Console-Hilfe). Für die Nachbereitung ist das brauchbar; als Frühwarnung ist es zu langsam.
Auch das Entfernen-Werkzeug ist keine Reparatur, sondern ein Zeitfenster. Eine erfolgreiche Anfrage wirkt nur etwa sechs Monate (Google Search Console-Hilfe), und selbst der schnelle Weg braucht in der Regel bis zu einen Tag, wobei die Annahme im Einzelfall offen bleibt (Google Search Console-Hilfe). Das Werkzeug verschafft Zeit, wenn versehentlich vertrauliche Adressen im Index stehen; die Ursache beseitigt es nicht. Wer es als Notbremse einplant, sollte den Ablauf zusammen mit dem übrigen Notfallweg dokumentieren.
Alarmierung: Schwellen, Ruhephasen, Eskalation
Eine Prüfkette ohne Alarmweg ist ein Protokoll, das niemand liest. Sinnvoll sind drei Stufen. Eine einzelne Adresse mit unerwartetem noindex ist ein Hinweis und wird gesammelt. Zwei oder mehr Adressen derselben Seitenvorlage sind ein Vorfall und lösen sofort aus. Eine Abweichung an der robots.txt oder am Canonical-Host betrifft grundsätzlich den ganzen Bestand und geht ohne Sammelfenster direkt an die Bereitschaft – dieselbe Logik, die auch für stille Fehler in Hintergrundjobs gilt.
Wichtig ist die Trennung von der übrigen Meldungsflut. Indexierbarkeit erzeugt selten Alarme, aber jeder davon ist teuer; Erreichbarkeitsmeldungen sind häufig und meist harmlos. Landen beide im selben Kanal, gewöhnt sich die Bereitschaft an das Rauschen und quittiert beides gleich schnell weg. Wie sich Kanäle, Schwellen und Ruhephasen sauber trennen lassen, beschreibt der Beitrag zu Log-Monitoring und Alarmierung; die Prüfkette bekommt dort einen eigenen Kanal mit eigener Eskalationsstufe.
Die Ausgabe zeigt, was eine gute Meldung leisten muss: Sie nennt die Station, die betroffene Adresse, den Soll- und den Istwert und den Zeitpunkt der letzten unauffälligen Messung. Ohne diesen letzten Wert beginnt jede Untersuchung mit der Frage, seit wann der Zustand besteht – und die ist ohne gespeicherten Verlauf nicht zu beantworten.
Was ein unbemerkter Sichtbarkeitsverlust kostet
Die Größenordnung lässt sich aus dem Markt ableiten. Der deutsche Onlinehandel wuchs zuletzt um 3,9 Prozent auf 92,3 Mrd. Euro (HDE), und der Onlineanteil am gesamten Einzelhandel liegt bei 13,5 Prozent nach 13,4 Prozent im Vorjahr (HDE). Auf Unternehmensebene ist der Anteil noch deutlicher: Unternehmen in der EU erzielten 19,49 Prozent ihres Gesamtumsatzes über Onlineverkäufe (Eurostat), davon 8,39 Prozentpunkte über Websites oder Apps und 11,07 Prozentpunkte über EDI-Nachrichten, und der Anteil der Unternehmen mit Onlineverkauf stieg von 18,93 Prozent im Jahr 2014 auf 23,59 Prozent im Jahr 2024 (Eurostat).
Diese Zahlen belegen keinen konkreten Schaden im Einzelfall – sie ordnen ein, worum es geht. Ein Shop, dessen Kategorieseiten drei Wochen lang nicht auffindbar sind, verliert den Anteil seines Umsatzes, der über die organische Suche kommt, und gewinnt ihn nicht automatisch zurück: Der Wiederaufbau hängt am Crawl-Rhythmus, nicht am Deployment. Die Einordnung zum Crawl-Budget nennt 1 Million eindeutige Seiten als Schwelle für große Websites und 10.000 eindeutige Seiten bei sehr schnell wechselnden Inhalten (Google Search Central) – unterhalb davon ist ein Indexierungsproblem fast in jedem Fall ein Konfigurationsproblem, kein Kapazitätsproblem.
Erreichbarkeit und Auffindbarkeit sind zwei verschiedene Messgrößen. Wer nur die erste überwacht, erfährt vom Verlust der zweiten aus dem Umsatzbericht.
Die Prüfkette in den Wartungsrhythmus einbauen
Technisch ist die Kette überschaubar: ein Skript, ein Sollstand, ein Verlauf, ein Alarmkanal. Der Aufwand liegt in der Pflege. Jede neue Seitenvorlage gehört in die Stichprobe, jede beabsichtigte Sperre in den Sollstand, jede Änderung an der robots.txt in den Verlauf. Deshalb gehört die Kette in denselben Rhythmus wie Sicherheitsupdates, die laufende Shop-Wartung und inhaltliche Pflichten wie das Gewährleistungslabel auf Produktseiten – als fester Punkt, nicht als Projekt.
Zwei Erweiterungen lohnen sich. Erstens ein Abgleich zwischen Sitemap und Stichprobe: Adressen, die in der Sitemap stehen, aber ein noindex tragen, sind ein sicheres Zeichen für einen Konfigurationsfehler. Zweitens eine Verknüpfung mit den Kennzahlen des laufenden Betriebs, damit ein Einbruch der Sichtbarkeit im selben Bericht steht wie Antwortzeiten und Verfügbarkeit – so, wie es beim Performance-Monitoring im Wartungsvertrag ohnehin üblich ist.
Ein Anfang, der an einem Tag steht
Quellen und Studien
Verwandte Artikel
Wenn die Platte voll läuft: Shop-Speicher überwachen
Eine volle Datenpartition erzeugt keinen Ausfall, sondern hängende Bestellungen. Welche Verzeichnisse wachsen, welche Schwelle greift, welcher Turnus hilft.
WordPress-Sicherheitsupdates: Was alte Zweige noch bekommen
WordPress 7.1.2 schloss eine kritische Lücke, der Fix kam als Gefälligkeit bis 4.7 zurück. Was ältere Zweige erhalten, was nicht und wann der Sprung fällig ist.
Rabattcodes in der Black Week: Missbrauch früh erkennen
Rabattcodes in der Black Week schützen: Codelänge, Rate-Limit am Gutscheinfeld, Alarm bei Fehlversuchen und ein Neukundenrabatt, der Mehrfachkonten standhält.