Eine Kundin schreibt mir an einem Sonntagabend. Ihr Blog leitet seit zwei Stunden auf eine türkische Glücksspielseite weiter, kein Foodfoto mehr da, dafür blinkende Casino-Werbung. Wir loggen uns ein. Login war admin, Passwort Sommer2022, letztes Update vor acht Monaten, dazu drei Plugins, die seit Jahren nicht mehr gepflegt werden. Das war kein Genie am Werk — das war ein Bot, der morgens um drei eine Liste von 100.000 WordPress-Blogs durchprobiert hat und an einer einzigen Tür hängengeblieben ist.

Genau diese Sorte Hack reparieren wir in der Agentur regelmäßig. Und jedes Mal denke ich danach dasselbe: Die Maßnahmen, die so einen Fall verhindern, sind alle banal. Niemand braucht eine Web Application Firewall, niemand braucht ein 99-€-Sicherheitsplugin. Was man braucht, ist einen Abend Zeit und die richtige Reihenfolge.

Unten kommen 12 Punkte, sortiert nach Wirkung mal Aufwand. Wenn du nur die ersten fünf machst, hast du den Großteil der realen Bedrohungen abgedeckt. Was wir bewusst weggelassen haben — Zwei-Faktor-Authentifizierung, Cloudflare und ein paar weitere wirksame, aber nicht ganz triviale Sachen — kommt unten als Bonus-Block, damit du weißt, dass es sie gibt und warum sie nicht in der Hauptliste stehen.

Eine Sache vorweg: Wir sagen dir, was zu tun ist und warum. Wir nennen keine konkreten Klickwege, keine Plugin-Empfehlungen mit Namen und keine „Geh in Einstellungen → Allgemein → Speichern"-Anleitungen. Der Grund: WordPress-Backends ändern sich, jeder Hoster hat sein eigenes Layout, und eine Anleitung, die heute stimmt, ist in sechs Monaten verkehrt. Wer den Klickweg selbst nicht findet, ist mit dem Hoster-Support oder einer Agentur besser bedient als mit einem Tutorial, das veraltet, bevor du es zu Ende gelesen hast. Falls du grundsätzlich darüber nachdenkst, ob du eigentlich ein Sicherheitsplugin brauchst — wir haben dazu eine eigene, ausführliche Antwort: Wordfence, Ninja Firewall & Co. — warum Sicherheitsplugins deinen Foodblog ausbremsen. Lies das gerne parallel; dieser Post hier ist der praktische Teil, der andere ist die Architektur-Argumentation dahinter.

Falls dir das schon zu viel Text ist und du einfach loslegen willst — fang oben an, arbeite dich nach unten durch. Punkt 1 dauert zehn Minuten, Punkt 12 ist nur eine Gewohnheit. Und keine Sorge: Du wirst bei keinem der zwölf Punkte ein Plugin kaufen müssen.

Übersicht: 12 Sicherheitsmaßnahmen für deinen Foodblog, sortiert in vier Gruppen

1. Ein einzigartiges, starkes Passwort für den WordPress-Admin

Lang, zufällig, nirgends anders verwendet. Kein „Sommer2022", kein Vorname plus Geburtsjahr, kein Name deines Hundes plus Ausrufezeichen. Wer sich solche Passwörter selbst nicht merken kann, ist genau die Person, die einen Passwort-Manager braucht — und davon gibt es genügend gute, die nichts kosten oder im niedrigen Euro-Bereich pro Monat liegen. Welcher konkret, ist Geschmackssache.

Warum so wichtig: Das mit Abstand häufigste Einbruchsszenario bei den Blogs, die wir reparieren, sind nicht raffinierte Lücken, sondern wiederverwendete Passwörter aus anderen Diensten. Du warst 2018 in einem Forum angemeldet, das Forum wurde gehackt, dein Passwort steht seitdem in einer Datenbank, die im Darknet kursiert — und ein Bot probiert dieses Passwort jetzt automatisch auch auf jedem WordPress-Login mit deinem Namen aus. Der Angreifer braucht null Talent. Es ist Fließbandarbeit.

Aufwand: einmalig zehn Minuten. Genau zehn Minuten, mehr nicht.

2. Ein Login-Name, der nicht „admin" oder dein Vorname ist

WordPress lässt dich den Login-Namen nachträglich nicht über die Oberfläche ändern. Wer beim ersten Setup admin oder seinen Vornamen genommen hat, muss einmal kurz durch ein kleines Manöver: einen neuen Admin-User mit einem unauffälligen Login-Namen anlegen, dann den alten löschen und seine Inhalte beim Lösch-Vorgang dem neuen User zuweisen. Wenn du dir das nicht selbst zutraust, fragst du deinen Hoster oder eine Agentur — das ist eine 15-Minuten-Sache.

Der bequemere Weg, falls du die ganze Inhaltsübertragung scheust: Du musst den alten Admin-User gar nicht löschen. Du legst einen neuen User mit unauffälligem Login an, gibst ihm die Admin-Rechte — und stufst deinen alten User auf Editor oder Redakteur runter. Die Beiträge bleiben da, wo sie sind, du sparst dir den ganzen Übertragungs-Schritt. Der einzige Haken: Der alte Login-Name (zum Beispiel lisa oder admin) bleibt im System bestehen. Solange er nicht mehr Admin ist, kann ein Angreifer damit aber wenig anfangen — und mit Punkt 3 unten verschwindet er auch aus den öffentlichen URLs.

Was du dafür bekommst, ist viel: Ein Brute-Force-Versuch braucht zwei Informationen — Login-Name und Passwort. Wenn der Login-Name geraten werden muss, hat der Bot deutlich mehr Arbeit. Wenn er einfach admin ist, hat er die Hälfte schon gewonnen.

Aufwand: einmalig 15 Minuten.

3. Den Login-Namen vom Autoren-URL-Slug entkoppeln

Jetzt wird es spannend. Selbst wenn du einen unauffälligen Login-Namen hast, verrät WordPress ihn standardmäßig wieder — und zwar auf zwei Wegen, die kaum jemand kennt.

Weg eins, die Autoren-URL. Jeder User in WordPress hat eine Autoren-Seite mit einer URL wie /author/dein-login-name/. Diese URL wird automatisch aus deinem Login-Namen gebildet. Wenn dein Login kati2024 ist, ist die Autoren-URL /author/kati2024/. Damit hat jeder Bot, der deinen Blog 30 Sekunden anschaut, schon den Login-Namen.

Weg zwei, die WordPress-eigene Schnittstelle. WordPress hat eine offene API, die unter /wp-json/wp/v2/users per einfachem Browser-Aufruf eine Liste aller postenden User zurückgibt — ohne Login, ohne Token, einfach im Browser. In dieser Liste steht für jeden User der Anzeigename (unkritisch) und der Autoren-URL-Slug. Bei den meisten Blogs ist der Slug identisch mit dem Login-Namen.

Was du tun musst: Setze deinen Anzeigenamen auf etwas anderes als deinen Login. Setz den Autoren-URL-Slug (intern heißt das Feld user_nicename) auf etwas Generisches wie redaktion oder kueche — nicht auf deinen Login. Und schalte Autorenseiten ganz ab, wenn du Single-Author-Blog bist; sie bringen SEO-mäßig sowieso nichts.

Warum das so wichtig ist: Wenn der Slug nicht mehr identisch mit deinem Login ist, kann die WordPress-API ruhig eine User-Liste ausspucken — sie verrät dann zwar, dass es einen Admin-Account gibt, aber nicht, womit er sich einloggt. Das ist die wichtigste Tarnmaßnahme überhaupt, und sie kostet nichts.

Aufwand: einmalig rund 20 Minuten.

4. Der Admin-User sollte keine eigenen Beiträge veröffentlichen

Diese gerade erwähnte API-Schnittstelle hat eine Eigenheit, die du dir zunutze machen kannst: Seit WordPress 4.7.1 zeigt sie für nicht eingeloggte Anfragen nur User an, die mindestens einen veröffentlichten Beitrag haben. Heißt: Wenn dein Admin-Account selbst nichts postet, taucht er in der öffentlichen API-Liste gar nicht erst auf.

Das saubere Pattern dafür: Du legst zwei User an. Einer ist Administrator und macht ausschließlich Admin-Sachen — Plugin-Updates, Einstellungen, Theme-Pflege. Der andere ist Redakteur (oder Autor) und schreibt die Beiträge. Wer aktuell als Admin postet, hat zwei bequeme Wege: Entweder den bestehenden Admin-User auf Redakteur runterstufen und parallel einen neuen Admin daneben anlegen — dann bleiben alle Beiträge dort, wo sie sind. Oder einen frischen Redakteur-User anlegen und die bestehenden Beiträge in der WordPress-Beitragsübersicht per Massen-Aktion auf ihn übertragen. Welcher Weg besser passt, hängt davon ab, ob dir der bisherige Login-Name gefällt — wenn ja, einfach degradieren; wenn nein, lieber neu anlegen.

Achtung — und das ist eine Falle, die fast alle übersehen: „Posten" meint hier nicht nur Blog-Beiträge. Bei manchen Themes und Block-Editoren legst du auch Header, Footer, Popups oder Layout-Bausteine als kleine eigene Inhaltstypen an. Sobald dein Admin-User einmal so ein Element erstellt hat, ist er wieder in der API-Liste sichtbar. Wer den Trick wirklich konsequent durchzieht, baut also auch Theme- und Layout-Bausteine als Editor-User, nicht als Admin. In der Praxis ist das nicht immer durchhaltbar — Header und Footer baut man typischerweise einmal, aber wenn man später Popups, Banner oder neue Kadence-Elemente nachschiebt, vergisst man's. Genau deshalb ist Punkt 3 (Slug entkoppeln) der wichtigere Schutz und Punkt 4 hier die zusätzliche Härtung obendrauf. Wer Punkt 3 sauber gemacht hat, kommt notfalls auch ohne Punkt 4 aus.

Aufwand: einmalig 30 bis 45 Minuten. Der Brocken ist das Umzeichnen bestehender Beiträge.

5. Die WordPress-Admin-E-Mail vom Impressum trennen

In Deutschland brauchst du im Impressum eine erreichbare E-Mail-Adresse — Pflicht. Bei den meisten Bloggern ist genau diese Mailadresse auch die WordPress-Admin-E-Mail. Damit hast du eine Lücke, die du nicht siehst: WordPress erlaubt das Zurücksetzen des Passworts per Login-Name oder per E-Mail. Heißt: Selbst wenn dein Login-Name perfekt versteckt ist, kann jeder, der dein Impressum liest, den Reset-Flow auf deine Mailadresse anstoßen. Das eigentliche Passwort kommt damit zwar nicht raus, aber zwei Dinge passieren: Phishing wird gezielter (der Angreifer weiß, an welche Adresse echte Reset-Mails gehen, und kann perfekt gefälschte schicken), und falls dein Mailaccount selbst kompromittiert wird, ist der WordPress-Login mit dabei.

Die Lösung ist simpel: zwei verschiedene E-Mail-Adressen. Eine öffentliche, die im Impressum steht, im Kontaktformular landet und im Newsletter-Footer auftaucht — z. B. hallo@deinblog.de. Und eine separate, die ausschließlich die WordPress-Admin-Mail ist und nirgends im Internet sichtbar wird. Beide Postfächer können bei demselben Hoster liegen, das kostet nichts. Entscheidend ist, dass sie öffentlich nichts miteinander zu tun haben.

Vergleich: Welche zwei E-Mail-Adressen brauchst du? Impressum-Mail öffentlich, WordPress-Admin-Mail privat

Aufwand: einmalig 15 Minuten — zweite Mailadresse beim Hoster anlegen, in WordPress umstellen, Bestätigungslink anklicken.

Faustregel über die Punkte 3, 4 und 5: Wer 30 Sekunden auf dein Impressum, deinen Quelltext und /wp-json/wp/v2/users schaut, soll weder deinen Login-Namen noch die E-Mail-Adresse rausfinden, mit der er einen Passwort-Reset starten könnte.

6. Automatische Updates für Core, Theme und Plugins

WordPress kann seit Jahren alles selbst aktualisieren — Core, Theme, Plugins. Standardmäßig ist nur der Core auf „kleine Updates automatisch" eingestellt. Den Rest musst du einmal kurz freischalten, dann läuft es.

Warum so wichtig: Die meisten erfolgreichen Hacks, die wir in der Agentur sehen, treffen veraltete Plugins — nicht Zero-Day-Lücken, die niemand kennt. Eine Lücke wird typischerweise erst Wochen nach der Veröffentlichung des Patches massenhaft ausgenutzt, weil dann genug Bots existieren, die die alte Version automatisiert durchsuchen. Wer aktualisiert hat, ist raus aus der Schusslinie. Wer manuell einmal pro Quartal auf „Updates" klickt, ist drin.

Aufwand: einmalig zehn Minuten, dann automatisch.

Ehrlicher Hinweis: Automatische Updates können selten ein Plugin zerschießen. Genau deshalb ist Punkt 7 — Backups — der nächste Punkt direkt darunter, und nicht umgekehrt.

7. Backups, die du im Ernstfall wirklich zurückspielen kannst

Täglich, automatisch, nicht nur beim Hoster. Mindestens eine Kopie an einem zweiten Ort — Cloud-Speicher, externe Festplatte, zweite Mailadresse, irgendwas außerhalb des Servers, auf dem dein Blog läuft.

Warum nicht nur beim Hoster: Wenn dein Hoster-Account selbst gekapert wird (Stichwort: schwaches Hoster-Login-Passwort), sind die Hoster-Backups mit weg. Außerdem — und das ist ein Punkt, den ich hier wirklich betonen will: Wer noch nie ein Backup zurückgespielt hat, hat kein Backup, sondern eine Hoffnung. Mach einmal im Jahr einen Probelauf. Lade dir ein Backup runter, öffne es, schau, ob du wirklich an die Datenbank rankommst und ob die Mediendateien drin sind. Wenn nicht — jetzt ist der Moment, an dem du es merkst, nicht in der Krise.

Aufwand: einmalig 30 bis 60 Minuten Setup, dann automatisch. Plus einmal jährlich der Probelauf.

8. Hosting-Hygiene — aktuelles PHP, HTTPS, SFTP statt FTP

Drei Klick-Sachen im Hoster-Backend, die zusammen 15 Minuten kosten und in Summe einen guten Effekt haben.

PHP-Version: Aktuell empfohlen ist PHP 8.2 oder 8.3 (Stand 2026). Wenn dein Blog noch auf PHP 7.4 läuft — und das tun erstaunlich viele —, bekommst du keine Sicherheits-Patches mehr und bist langfristig angreifbar. Wechseln, kurz testen, fertig.

HTTPS für die ganze Seite erzwingen. Nicht nur für den Login. Wenn du irgendwo noch http-Inhalte hast, geht alles drumherum auch unverschlüsselt — und dein Login-Passwort kann theoretisch im offenen WLAN abgefangen werden.

SFTP statt FTP für Datei-Uploads. Klassisches FTP überträgt Passwörter im Klartext. SFTP nicht. Bei jedem halbwegs aktuellen Hoster ist SFTP standardmäßig verfügbar — wenn deine FTP-Software gerade noch FTP spricht, einmal kurz auf SFTP umstellen.

Hinweis: Bei Managed-Hosting (IONOS, Raidboxes, ähnliche) ist all das oft schon richtig konfiguriert. Trotzdem einmal nachsehen schadet nicht — nichts ist ärgerlicher, als zu glauben, der Hoster macht's, und dann auf PHP 7.2 zu hängen.

9. Plugin-Diät — alles, was du nicht aktiv nutzt, runter vom Server

Inaktive Plugins liegen trotzdem auf dem Server. Code, der nicht aktiv genutzt wird, ist Code, der nicht aktiv gepflegt wird — und damit ein Risiko. Wir hatten in der Agentur mehrere Fälle, in denen die Einbruchsstelle ein Plugin war, das die Bloggerin schon vor zwei Jahren deaktiviert, aber nicht gelöscht hatte.

„Deaktiviert" heißt nicht „weg". Eine Sicherheitslücke in einem deaktivierten Plugin kann immer noch ausgenutzt werden, wenn der Angreifer die Plugin-Datei direkt aufruft — und genau das tun automatisierte Scanner.

Geh einmal kurz durch deine Plugin-Liste. Alles, was du in den letzten sechs Monaten nicht wirklich gebraucht hast, fliegt raus. Nicht deaktiviert, gelöscht.

Warum das gerade jetzt besonders dringend ist: Die Plugin-Welt von WordPress ist im Moment in einer schlechten Verfassung. Viele Plugins, die jahrelang gut funktioniert haben, geben gerade reihenweise den Geist auf — weil ihre Entwickler nicht mehr hinterherkommen mit den WordPress-Änderungen, weil die Wirtschaftlichkeit fehlt, weil Übernahmen schief gehen, weil neue PHP- und WordPress-Versionen alte Annahmen brechen. Ich habe das in einem eigenen Beitrag länger ausgeführt: Warum es ein eigenes Foodblog-WordPress-Angebot von Foodblogliebe gibt — dort gehe ich konkret auf die strukturellen Probleme der Plugin-Landschaft ein und warum dadurch derzeit überproportional viele Sicherheitslücken entstehen. Wer das einmal gelesen hat, versteht, warum Plugin-Diät 2026 keine Schönheitsmaßnahme ist, sondern Pflicht.

Aufwand: einmalig 20 Minuten Aufräumen.

10. Bei der Plugin-Auswahl auf Pflege achten

Vor jeder Neuinstallation eines Plugins drei Minuten investieren und nachschauen: Wann wurde das Plugin zuletzt aktualisiert? Wie viele aktive Installationen hat es? Gibt es Bewertungen aus den letzten Monaten?

Faustregel: „Letztes Update vor zwei Jahren" → Finger weg, egal wie schick die Funktionsbeschreibung klingt. Vergessene Plugins sind die häufigste Einbruchsstelle in WordPress, die wir sehen. Ein gut bewertetes, aber seit drei Jahren ungepflegtes Plugin ist gefährlicher als ein neues Plugin mit fünf Bewertungen, das aktiv weiterentwickelt wird.

Aufwand: zwei Minuten pro Plugin, jedes Mal, wenn du eines installierst. Diese zwei Minuten ersparen dir später fünf Stunden Wiederherstellung.

11. Login-Versuche limitieren

WordPress lässt im Standard unbegrenzt viele Login-Versuche zu. Das ist die offene Einladung für Brute-Force-Bots, die einfach durchprobieren, bis irgendwas matcht.

Was du brauchst, ist eine Lösung, die nach einer Handvoll Fehlversuchen die IP-Adresse für eine Weile sperrt. Manche Hoster machen das bereits server-seitig — kurz beim Hoster-Support nachfragen oder im Hoster-Backend nachsehen. Wenn nicht: Das ist eine der wenigen Stellen, an denen ein kleines, leichtes Plugin sinnvoll ist. Oder dein Theme bringt es mit.

Warum das so wirksam ist: Ein Bot, der nach fünf Fehlversuchen 30 Minuten warten muss, kommt in vier Wochen nicht durch dein Passwort, selbst wenn er es theoretisch knacken könnte. Du hast also ohne weiteren Aufwand die Geschwindigkeit, mit der Brute Force funktioniert, in den Boden gerammt.

Aufwand: einmalig zehn Minuten Konfiguration.

12. Phishing-Bewusstsein — WordPress schreibt dich nicht zum Einloggen an

WordPress versendet keine „Bitte hier einloggen, sonst wird Ihr Account gesperrt"-Mails. Hoster auch nicht. Plugin-Anbieter auch nicht. Wenn du so eine Mail bekommst, ist es Phishing.

Was du tust: nicht auf den Link in der Mail klicken. Nie. Stattdessen direkt im Browser zur eigenen Domain gehen, dort einloggen und schauen, ob es wirklich was zu tun gibt.

Phishing ist 2026 nicht mehr die schlecht übersetzte Mail von 2010 mit nigerianischem Prinzen. Aktuelle Versuche sehen aus wie echte WordPress-Update-Benachrichtigungen, mit korrektem Logo, plausibler Absenderadresse, sauberem Deutsch. Der Unterschied ist nur die Domain im Link, und die siehst du erst, wenn du draufklickst — wo es dann zu spät ist.

Aufwand: dauerhafte Gewohnheit, keine Setup-Zeit.

Wirksam, aber nicht einfach — was wir bewusst weggelassen haben

Vier Maßnahmen, die in vielen anderen Sicherheits-Checklisten ganz oben stehen, fehlen in unserer Hauptliste. Sie sind alle wirksam — und genau deshalb wollen wir sie hier offen nennen, damit du weißt, dass es sie gibt. Aus den 12 Punkten oben raus sind sie geflogen, weil sie für nicht-technische Blogger entweder zu viel Disziplin, zu viel Setup-Wissen oder ein zu hohes Lockout-Risiko mit sich bringen. Wer technisch fitter ist oder einen Hoster bzw. eine Agentur an der Hand hat, sollte trotzdem mal prüfen, ob eine davon zu seinem Setup passt.

Zwei-Faktor-Authentifizierung

Sicherheitstechnisch fast Pflicht. In der Praxis trotzdem oft die Hürde, an der sich Blogger selbst aussperren oder den Zugang verlieren — Backup-Codes verlegt, App auf nur einem Gerät, Notfallplan fehlt. Wer sich den Aufwand und die Disziplin zutraut, sollte es machen, ohne Frage. Wer nicht, ist mit Punkt 1 (starkes Passwort), den Punkten 3 bis 5 (Login-Name und Mail unsichtbar) und Punkt 11 (Login-Versuche limitieren) gegen die häufigsten Angriffsmuster auch ohne 2FA gut abgedeckt. Das ist kein Freifahrtschein, sondern eine ehrliche Risiko-Abwägung.

Verzeichnisschutz für /wp-admin/

Eine zusätzliche Passwort-Abfrage des Webservers, bevor WordPress überhaupt geladen wird. Bei IONOS, Webgo, Raidboxes und vielen weiteren Hostern per Klick im Kundencenter einrichtbar — heißt dort meist „Verzeichnisschutz". Wirksam wie wenig anderes: Brute-Force-Bots kommen gar nicht erst an die WordPress-Login-Maske, und PHP startet für blockierte Anfragen nicht.

Der Haken: Der Schutz darf nicht pauschal über das ganze wp-admin-Verzeichnis gelegt werden. Sonst brechen Frontend-Funktionen wie Sterne-Ratings oder Like-Buttons, die intern eine Datei namens admin-ajax.php aufrufen. Die Ausnahme für admin-ajax.php muss explizit konfiguriert werden — und das ist über die Klick-Lösungen mancher Hoster nicht ohne Weiteres möglich. Wer das selbst nicht überblickt, fragt den Hoster-Support oder lässt es weg.

Cloudflare oder eine andere Web Application Firewall vor dem Hoster

Cloudflare hat einen kostenlosen Tarif mit echter Schutzwirkung (Stand Mai 2026): DDoS-Abwehr, eine Basis-Firewall gegen die häufigsten Angriffsmuster, Bot-Filter — und das alles als Edge-Service vor deinem Hosting. Heißt: Schädlicher Traffic wird abgefangen, bevor er deinen Server erreicht. Ein gutes Setup blockt einen sehr großen Teil der Bot-Angriffe an der Edge ab, ohne dass dein Blog dadurch langsamer wird.

Die Hürden: Du musst die Nameserver deiner Domain auf Cloudflare umstellen — eine Stelle, an der bei falscher Konfiguration die ganze Seite kurzzeitig wegfliegt. DSGVO-mäßig leitest du ab dem Moment den kompletten Traffic über einen US-amerikanischen Anbieter; das gehört in deine Datenschutzerklärung. Und falsch eingestellte Sicherheitsregeln blockieren regelmäßig echte Leser oder dich selbst aus deinem eigenen Backend. Für einen ernsthaft betriebenen Foodblog auf Dauer trotzdem eine Überlegung wert — wenn man es einmal sauber einrichtet oder einrichten lässt.

REST-API-Enumeration blockieren, Versionsnummer entfernen, XML-RPC abschalten

Drei Stellen, die alle technisch wirksam sind und an denen wir mit unserem Foodblogliebe-Sicherheitspaket entsprechend ansetzen — die aber kein nicht-technischer Blogger in fünf Minuten selbst lösen kann. Wer ein Bundle nutzt, das diese Punkte mitbringt, hat sie ohnehin abgedeckt. Wer nicht, kann eine Agentur fragen oder den Schwesterpost lesen, in dem wir die Architektur ausführlicher beschreiben: Wordfence, Ninja Firewall & Co. — warum Sicherheitsplugins deinen Foodblog ausbremsen.

Eine Sache vorweg, bevor du dich in eine dieser vier Maßnahmen stürzt: erst die 12 Punkte oben. Diese vier hier sind das Sahnehäubchen, sie wirken — aber sie wirken auf dem Fundament der Hauptliste. Wer 2FA aktiviert, aber sein Passwort kueche2019 lässt, hat nichts gewonnen. Wer Cloudflare davorschaltet, aber sein Theme seit 18 Monaten nicht aktualisiert hat, schiebt das Problem nur eine Ebene weiter. Erst die zwölf sauber durchziehen, dann darüber nachdenken, ob du eine dieser vier hier zusätzlich willst.

Fazit

Wer die ersten sieben Punkte macht — Passwort, Login-Name nicht „admin", Slug entkoppeln, Admin postet keine Inhalte, Mail trennen, Updates, Backups —, hat in einem Abend mehr für die Sicherheit seines Foodblogs getan als die meisten Bezahl-Plugins in einem Jahr leisten. Und das ohne, dass die Rezeptseiten dadurch ein Millisekunde langsamer werden.

Wenn dich interessiert, wie wir das alles im Foodblogliebe-Sicherheitspaket technisch lösen — also wie der Login-Schutz konkret implementiert ist, wie die REST-API gehärtet wird, wie das Audit-Log mit IP-Hashes funktioniert —, schau in den passenden Kurs: Sicherheitsfeatures im Foodblogliebe-Paket. Wer noch grundsätzlicher anfangen will, was WordPress-Sicherheit überhaupt heißt: WordPress-Sicherheit für Foodblogs. Und wer wissen will, warum wir bei Foodblogliebe trotz alledem keine WAF und kein Wordfence einsetzen — auch nicht hinter den Kulissen —, hier entlang: Wordfence, Ninja Firewall & Co. — warum Sicherheitsplugins deinen Foodblog ausbremsen.

Wer einfach nur seinen Blog besser absichern will, ist mit den 12 Punkten oben fertig. Pro Punkt ein Häkchen, einen Abend Zeit — und der Sonntagabend mit der türkischen Glücksspielseite passiert dir nicht.

Transparenz: Wir verkaufen das Foodblogliebe-Theme, das mit einem eigenen Sicherheitspaket ausgeliefert wird, in dem ein Teil dieser Punkte schon umgesetzt ist (Slug-Entkopplung, REST-API-Härtung, Audit-Log mit gehashten IPs, Login-Throttling). Das ist offen — und es ändert nichts daran, dass du diese 12 Maßnahmen unabhängig von unserem Bundle umsetzen kannst und solltest. Genau deshalb haben wir den Post so geschrieben, dass du keinen einzigen Tool-Namen brauchst, um durchzukommen.