Markus Steinacher

Wie sicher ist WordPress im Vergleich zu anderen CMS wie Joomla, Drupal und TYPO3?

Markus Steinacher — Mon, 31 Aug 2026 04:20:55 +0000

Wenn es um die Sicherheit von WordPress-Websites geht, taucht früher oder später eine interessante Frage auf: Ist WordPress eigentlich unsicherer als andere Content-Management-Systeme wie Joomla, Drupal oder TYPO3? Meiner Meinung nach ist diese Frage durchaus berechtigt. Schließlich lesen wir regelmäßig von WordPress-Sicherheitslücken, Sicherheitsupdates und kompromittierten Websites. Jedoch ist die Frage viel komplexer als man zunächst meinen könnte. Sehen wir uns das Thema hier etwas genauer an.

Aber bedeutet das tatsächlich, dass WordPress als CMS unsicherer ist als andere Systeme?

Meine kurze Antwort darauf lautet: Nein: WordPress ist nicht unsicherer als andere Systeme, zumindest lässt sich das nicht pauschal behaupten. Meine längere Antwort ist wesentlich interessanter, denn bei der Sicherheit einer Website spielt nicht nur das verwendete CMS eine Rolle. Entscheidend ist vielmehr der Umgang mit der jeweiligen Website und das Zusammenspiel zwischen dem Kernsystem, seinen Erweiterungen (Plugins), der Konfiguration, Hosting, Server, Benutzerkonten, Updates, Wartung, Backups und weiteren technischen Komponenten.

Bei der Sicherheitsfrage verhält es sich genauso, wie bei der Frage, welches CMS beispielsweise über die beste Performance (Ladezeit, …) verfügt. Das beste CMS hilft nichts, wenn man das gewählte System nicht optimal aufsetzt. Die Qualität der Sicherheit ist stark abhängig vom persönlichen Umgang und Nutzung der zur Verfügung stehenden Ressourcen. Allein durch diesen Aspekt stellt sich die Frage nicht, welches CMS am sichersten ist. Wobei es durchaus Kriterien gibt, die einem bei der Entscheidungsfindung – welches CMS für einen selbst wohl am besten ist – helfen können.

WordPress ist nicht das einzige CMS, das Sicherheitsupdates benötigt

Zunächst einmal ist es wichtig, mit einem verbreiteten Missverständnis aufzuräumen. Sicherheitslücken gibt es in praktisch jeder komplexeren Software. Das betrifft nicht nur WordPress, sondern auch Joomla, Drupal, TYPO3 und viele andere Content-Management-Systeme. Diese werden allesamt laufend weiterentwickelt und müssen bei bekannt gewordenen Sicherheitsproblemen aktualisiert werden.

Wie CMS mit dem Thema Sicherheit umgehen

Solche Systeme verfügen über eigene Security-Teams und Prozesse zur Meldung, Bewertung und Behebung von Sicherheitsproblemen. Ohne diese Sicherheitsmaßnahmen könnten diese Systeme nicht lange bestehen. Dies ist demnach eine Grundvoraussetzung und Qualitätskriterium für ein CMS, wenn man sich die Frage stellt ob ein CMS sicher ist.

Bei Joomla beispielsweise werden im offiziellen Security Centre laufend behobene Sicherheitsprobleme veröffentlicht. Auch im Jahr 2026 finden sich dort unter anderem Meldungen zu Authentifizierungsumgehungen, XSS, fehlerhaften Zugriffskontrollen und problematischen Datei-Uploads.

Drupal veröffentlicht ebenfalls regelmäßig Sicherheitsmeldungen für den Core und für Erweiterungen. Im Jahr 2026 wurden beispielsweise auch hochkritische Sicherheitsprobleme im Drupal-Core veröffentlicht.

Und auch TYPO3 veröffentlicht regelmäßig Sicherheitsupdates. Allein am 14. Januar 2025 wurden beispielsweise mehrere Sicherheitsprobleme mit neuen TYPO3-Versionen behoben.

Das bedeutet für unsere Frage, dass keines dieser Systeme frei von Sicherheitslücken ist. Das ist allerdings auch nicht der für mich entscheidende Maßstab. Vielmehr ist mir wichtig, wie mit Sicherheitslücken umgegangen wird und wie schnell Sicherheitskorrekturen auf die tatsächlich betriebenen Websites gelangen. Und genau hier beginnt für mich das Thema Service und Wartung.

WordPress ist im Vergleich zu anderen CMS besonders weit verbreitet

Ein wichtiger Unterschied zwischen WordPress und anderen CMS ist die enorme Verbreitung. Nach den aktuellen Zahlen von W3Techs vom August 2026 wird WordPress von rund 40,7 % aller Websites eingesetzt. Betrachtet man nur Websites, bei denen das verwendete CMS bekannt ist, kommt WordPress auf einen Marktanteil von 58,9 %.

Diese Zahlen stammen aus der aktuellen W3Techs-Auswertung vom August 2026. WordPress wird damit unter den hier betrachteten CMS ungefähr 35-mal häufiger eingesetzt als Joomla, 59-mal häufiger als Drupal und mehr als 100-mal häufiger als TYPO3. Diese Größenverhältnisse sollte man im Hinterkopf behalten, wenn man Sicherheitsstatistiken miteinander vergleicht.

Warum WordPress in Sicherheitsstatistiken besonders präsent ist

Die große Verbreitung macht WordPress für Angreifer äußerst interessant. Viele Cyberangriffe auf Websites werden heute automatisiert durchgeführt. Ein Angreifer muss nicht unbedingt persönlich wissen, wem eine bestimmte Website gehört oder welches Unternehmen dahintersteht. Das ist heute nicht mehr so interessant, wie es vielleicht früher einmal der Fall war.

Automatisierte Systeme können beispielsweise nach bestimmten technischen Merkmalen suchen und anschließend versuchen, bekannte Schwachstellen auszunutzen. Eine sehr große Zahl potenzieller WordPress-Installationen macht das System deshalb für automatisierte Angriffskampagnen so interessant. Das habe ich bereits ausführlicher in meinem Beitrag „Warum auch kleine WordPress-Websites für Cyberangriffe interessant sein können“ beschrieben.

Aber auch hier gilt, dass eine hohe Zahl von Angriffen auf WordPress nicht automatisch bedeutet, dass WordPress technisch unsicherer ist als andere CMS. Marktanteil und Sicherheitsrisiko müssen voneinander getrennt betrachtet werden, wobei diese Kennzahlen hinsichtlich Analyse durchaus in kausalem Zusammenhang erscheinen können. Demnach finde ich es richtig, dass wenn man sich für WordPress entscheidet, das Thema Sicherheit von Grund auf präventiv am Radar haben sollte, sich demnach damit auseinandersetzen sollte, was passieren kann, wenn man die Sicherheit der eigenen Website vernachlässigt.

Die Anzahl der Sicherheitslücken ist kein einfaches Sicherheitsranking

Hier wird es für mich besonders interessant. Immer wieder findet man Statistiken, die beispielsweise die Anzahl veröffentlichter Sicherheitslücken verschiedener Softwareprodukte vergleichen. Auf den ersten Blick könnte man daraus ein Ranking erstellen, wie zum Beispiel:

System A hat mehr Sicherheitslücken als System B – also ist System B sicherer.

So einfach funktioniert es jedoch nicht, denn die Zahl gemeldeter Sicherheitslücken hängt unter anderem davon ab, wie weit ein System verbreitet ist, wie intensiv es von Sicherheitsforschern untersucht wird, wie groß der Quellcode und das Ökosystem sind, wie viele Erweiterungen existieren, wie aktiv Sicherheitsprobleme gemeldet werden und welche Zählweise verwendet wird.

Eine hohe Zahl gemeldeter Sicherheitslücken kann deshalb auch bedeuten, dass dieses System sehr gründlich untersucht und überwacht wird und daher über einen sehr aktiven Sicherheitsprozess verfügt. Umgekehrt ist eine geringe Zahl von Meldungen nicht automatisch ein Beweis für ein besonders sicheres System.

Was passiert bei WordPress außerhalb des des Kernsystems?

Aktuelle Zahlen von Patchstack machen diesen Unterschied bei WordPress sehr deutlich. Nach dem „State of WordPress Security in 2026“ wurden im Jahr 2025 insgesamt 11.334 neue Schwachstellen im WordPress-Ökosystem erfasst. Das entspricht laut Patchstack einem Anstieg von 42 % gegenüber dem Jahr 2024. Auf den ersten Blick ist diese Zahl durchaus interessant. Noch interessanter wird sie jedoch, wenn man genauer hinsieht, denn 91 % der gemeldeten Schwachstellen haben WordPress-Plugins betroffen.

Nur 9 % der gemeldeten Schwachstellen betrafen Themes und lediglich 6 Schwachstellen wurden im WordPress-Core gemeldet. Darüber hinaus wurden laut Patchstack 1.966 Schwachstellen als hoch eingestuft, wobei Patchstack davon ausgeht, dass sie für automatisierte Angriffe besonders relevant sein können.

Die wichtigste Erkenntnis daraus ist für mich nicht diese hohe Zahl 11.334. Viel relevanter auf unsere Frage ist die prozentuelle Verteilung der gemeldeten Schwachstellen. Die große Mehrheit der von Patchstack erfassten Schwachstellen betrifft nicht den Core, sondern Erweiterungen von externen Entwicklern. Das ist ein entscheidender Unterschied und wir lernen daraus, dass es extrem wichtig ist, bei der Wahl von Plugins vorsichtig und gut überlegt damit umzugehen.

Mein Tipp im Umgang mit WordPress-Plugins

Je weniger unnötige Plugins eine WordPress-Website benötigt, desto geringer ist grundsätzlich auch die zusätzliche technische Angriffsfläche. Entscheidend ist aber nicht allein die Anzahl, sondern vor allem die Qualität und laufende Pflege der eingesetzten Plugins. Es macht auch durchaus Sinn, dass man deaktivierte Plugins (gilt im Prinzip auch für Themes, ein Standard-Theme sollte für den Notfall installiert sein) komplett entfernt, da auch weiterhin installierte Zusatzsoftware kompromittiert werden könnte.

Aber nicht nur die Anzahl der installierten Plugins ist von Bedeutung, sondern es kommt auch auf die Wahl der Plugins hinsichtlich Qualität an. Speziell WordPress verfügt über extrem viele Plugins, die man kostenfrei installieren kann. Bei der Wahl muss man unbedingt darauf achten, dass die jeweiligen Plugin-Entwickler sich laufend darum kümmern, damit ihre Plugins gewartet werden. Bevor man ein Plugin installiert, sollte man sich daher unbedingt vorher die Bewertungen und die Anzahl der Downloads dazu ansehen.

Und natürlich sollte man sich die Performance und Funktionalität der eigenen Website nach der Installation eines neuen Plugins ansehen. Ein neues Plugin kann den Zustand einer WordPress Website in mehrfacher Hinsicht beeinflussen. Beispielsweise könnten Darstellungsfehler auftreten, Formulare nicht mehr funktionieren oder der Bilder-Upload blockiert sein.

In meiner beruflichen Praxis habe ich es immer wieder erlebt, dass ich WordPress Websites repariert habe (Thema: Hilfe mit WordPress), welche eindeutig zu viele Plugins installiert hatten. In einigen dieser Fälle waren viele Plugins unnötig installiert. Wenn man clever vorgeht, kann man meiner Erfahrung nach mit dem nötigen Know How bis zu einem Drittel der Plugins einsparen. Das ist selbstverständlich keine allgemeingültige Kennzahl, sondern eine Erfahrung aus meiner eigenen Praxis.

WordPress-Core und WordPress-Website sind nicht dasselbe

Wenn jemand sagt: „WordPress hat 11.334 Sicherheitslücken.“, dann ist diese Aussage deshalb irreführend. Die für mich korrekte Aussage ist: „Im WordPress-Ökosystem wurden im Jahr 2025 laut Patchstack 11.334 neue Schwachstellen erfasst.“

Eine WordPress-Website besteht nicht nur aus dem WordPress-Core, sondern auch aus einer individuellen Komposition aus Plugins, Themes und individuellen Anpassungen, sowie Webserver, Hosting, Konfiguration, eventuell externen Diensten und der laufenden Wartung. Erst dieses gesamte Konzept ergibt die tatsächliche Angriffsfläche auf eine WordPress-Website.

Und genau dasselbe gilt für Joomla, Drupal und TYPO3

Das ist ein ganz wichtiger Punkt für einen fairen Vergleich, denn auch bei Joomla, Drupal und TYPO3 darf man nicht einfach nur den jeweiligen Core betrachten. Joomla verfügt beispielsweise ebenfalls über zahlreiche Erweiterungen und veröffentlicht Sicherheitsmeldungen sowohl für das CMS als auch für weitere Bestandteile des Joomla-Ökosystems. Drupal unterscheidet in seinem Security-System ausdrücklich zwischen Drupal Core und Contributed Projects, also zusätzlichen Erweiterungen. Und auch bei TYPO3 finden sich neben Core-Sicherheitsproblemen regelmäßig Meldungen zu Drittanbieter-Erweiterungen. Ein besonders anschauliches Beispiel war die TYPO3-Erweiterung „Backup Plus“. Dort wurden unter anderem Command Injection, vorhersehbare Speicherorte und Cross-Site-Scripting-Probleme festgestellt.

Damit zeigt sich, dass das Problem „Erweiterung“ kein ausschließliches WordPress-Problem ist. Jedes komplexe CMS erweitert seine Funktionalität über zusätzliche Komponenten, und jede zusätzliche Komponente muss ebenfalls gepflegt werden.

Was unterscheidet WordPress dann überhaupt von anderen CMS?

Natürlich gibt es Unterschiede zwischen den einzelnen Systemen, und – wie eingangs erwähnt – diese Unterschiede sind durchaus relevant. WordPress verfügt über ein außergewöhnlich großes Ökosystem und eine enorme Verbreitung. Das bedeutet, dass man hier auf eine sehr große Entwicklergemeinschaft zurückgreifen kann. Die Herausforderungen liegen bei der großen Angriffsfläche durch das riesige Ökosystem, bei den unzähligen unterschiedlichen Erweiterungen von Drittanbietern und damit einhergehenden Qualitätsunterschieden.

Joomla ist ebenfalls ein etabliertes Open-Source-CMS mit eigener Sicherheitsorganisation und einem umfangreichen Erweiterungsökosystem. Auch Joomla veröffentlicht regelmäßig Security Advisories, beispielsweise wurden im Jahr 2026 Sicherheitsprobleme in Bereichen wie 2FA, Zugriffskontrolle und Datei-Uploads behoben. Jedoch steht der Maßstab von Joomla im Vergleich zu WordPress in keiner Relation. Dies macht sich alleine schon beim Marktanteil bemerkbar.

Drupal wird häufig bei technisch komplexeren Websites und größeren Organisationen eingesetzt. Insofern ist ein direkter Vergleich mit WordPress schwierig. Das System verfügt über einen organisierten Security-Prozess. Drupal wird häufig in technisch komplexeren Projekten eingesetzt und stellt dadurch in der Praxis teilweise höhere Anforderungen an Planung, technischem Verständnis, Entwicklung und laufende Administration. Drupal selbst beschreibt seinen Sicherheitsprozess als etabliert und weist ausdrücklich darauf hin, dass sowohl Core als auch zusätzliche Projekte (Module) auf jeden Fall berücksichtigt werden müssen. Und natürlich benötigt auch Drupal laufende Sicherheitsupdates. Im Jahr 2026 wurden beispielsweise mehrere Core-Sicherheitsprobleme veröffentlicht, darunter auch eine als „Highly critical“ eingestufte SQL-Injection-Schwachstelle.

TYPO3 ist insbesondere im deutschsprachigen Raum ein etabliertes CMS für professionelle und häufig komplexere Unternehmensprojekte. Auch hier gibt es einen professionellen Security-Prozess und regelmäßige Sicherheitsupdates. Bereits am 14. Januar 2025 veröffentlichte TYPO3 beispielsweise eine Security-Release mit mehreren behobenen Sicherheitsproblemen. Im weiteren Jahresverlauf folgten weitere Security-Releases. Auch bei TYPO3 betrifft die Sicherheit nicht nur den Core, sondern ebenfalls Drittanbieter-Erweiterungen.

Gibt es also ein „sicherstes“ CMS?

Ich würde diese Frage mit Nein beantworten. Zumindest nicht in dem Sinne, dass man WordPress, Joomla, Drupal und TYPO3 auf einer einfachen Skala von 1 bis 10 einordnen könnte. Ein CMS kann technisch hervorragend entwickelt sein und trotzdem eine unsichere Website ermöglichen. Umgekehrt kann eine sehr sorgfältig geplante und professionell gewartete Website auf einem anderen System ein sehr hohes Sicherheitsniveau erreichen.

Die tatsächliche Sicherheit einer Website entsteht auf mehreren Ebenen

Wenn ich die Sicherheit einer Website beurteile, würde ich daher wesentlich mehr betrachten als nur das CMS. Hosting und Server, sowie Benutzer und Zugriffsrechte finden im laienhaften Umgang mit Website oftmals viel zu wenig Beachtung. Diese Bereiche sind für Laien oft nicht greifbar oder sichtbar. Daher bleiben Defizite in diesen Bereichen oftmals über lange Zeiträume hinweg auch unerkannt. Das ist auch einer der Gründe, warum ich in meinen bisherigen Beiträgen immer wieder auf den Begriff „Gesamtsystem“ zurückkomme.

Ein Beispiel aus der Praxis

Stellen wir uns zwei Websites vor: Website A (WordPress) und Website B (TYPO3)

Website A

Eine WordPress-Website mit wenigen, sorgfältig ausgewählten Plugins, aktuellem WordPress-Core, aktuellen Erweiterungen, aktuellem PHP, abgesichertem Hosting, restriktiven Benutzerrechten und professioneller Waertung.

Website B

Eine TYPO3-Website mit veralteter TYPO3-Version, alten Erweiterungen, nicht mehr gepflegten Komponenten, schwachen Zugangsdaten und niemandem, der die Website regelmäßig kontrolliert.

Welche Website ist sicherer?

Natürlich lässt sich das nicht allein anhand des verwendeten CMS beantworten. Und genau deshalb halte ich pauschale Aussagen wie „TYPO3 ist sicherer als WordPress“ oder „WordPress ist unsicherer als Drupal“ für wenig hilfreich.

Die Kehrseite der großen WordPress-Verbreitung

Trotzdem möchte ich WordPress an dieser Stelle auch nicht schönreden. Die enorme Verbreitung bringt einen echten Nachteil mit sich: WordPress ist für automatisierte Angriffe ausgesprochen interessant, daher nochmals mein Tipp:

Wenn man sich für WordPress entscheidet, sollte man das Thema Sicherheit von Beginn an am Radar haben!

Wenn ein Angreifer eine Schwachstelle in einer weit verbreiteten WordPress-Erweiterung findet, kann sich ein Angriff theoretisch gegen sehr viele Websites gleichzeitig richten, speziell wenn es sich um einen automatisierten Angriff handelt. Das erklärt auch, warum die schnelle Durchführung von Sicherheitsupdates so wichtig ist. Patchstack berichtet für das Jahr 2025 nicht nur von einer steigenden Zahl an Schwachstellen, sondern auch von einer zunehmenden Geschwindigkeit, mit der Schwachstellen ausgenutzt werden. Das Unternehmen betont, dass Angreifer neue Schwachstellen teilweise innerhalb sehr kurzer Zeit „weaponisieren“. Das bedeutet, dass die Zeit zwischen „Sicherheitslücke bekannt“ und „Update installiert“ entscheidend sein kann. Und genau hier schließt sich der Kreis zu meinem ersten Beitrag dieser Serie. Ich befürchte, dass uns dieses Thema künftig noch mehr beschäftigen wird.

Ein Sicherheitsupdate ist nicht nur ein kleines Update

Wenn ein Entwickler eine Sicherheitslücke behebt, ist damit die konkrete Website noch nicht geschützt. Es gibt mehrere Schritte in diesem Sicherheitsprozess:

Sicherheitsproblem wird entdeckt
Problem wird analysiert
Entwickler erstellt eine Korrektur
Sicherheitsupdate wird veröffentlicht
Update muss auf der Website installiert werden
Website muss nach dem Update funktionieren
Weitere Komponenten müssen gegebenenfalls auf Kompatibilität geprüft werden

Erst dann ist die konkrete WordPress-Website tatsächlich auf dem neuen Stand. Genau deshalb bedeutet professionelle WordPress-Wartung für mich nicht einfach: „Auf den Update-Button klicken.“ Es steckt in der Praxis viel mehr dahinter.

Warum ich WordPress weiterhin für ein sehr gutes CMS halte

An dieser Stelle möchte ich ausdrücklich keine Angst vor WordPress erzeugen. Ganz im Gegenteil: Ich halte WordPress grundsätzlich für ein sehr leistungsfähiges und professionelles CMS. Die große Verbreitung ist neben der beschriebenen möglichen Angriffsfläche gleichzeitig auch eine seiner größten Stärken. Es gibt eine enorme Entwicklergemeinschaft, eine sehr große Sicherheits-Community und zahlreiche etablierte Werkzeuge und Dienstleister.

Die Tatsache, dass regelmäßig Sicherheitslücken entdeckt und behoben werden, ist für mich deshalb nicht automatisch ein Argument gegen WordPress, auch hier ganz im Gegenteil. Vielmehr ist entscheidend, wie professionell mit diesen Sicherheitsproblemen umgegangen wird. Das gilt übrigens genauso für Joomla, Drupal und TYPO3. Daher würde ich nie der Sicherheitsfrage wegen mich für eines der besagten CMS entscheiden. Andere Aspekte der Entscheidungsfindung spielen für mich eine größere Rolle (zB Benutzerfreundlichkeit).

Mein persönliches Fazit

Wenn mich ein Kunde fragt: „Wäre meine Website mit Joomla, Drupal oder TYPO3 sicherer als mit WordPress?“ würde ich nicht automatisch mit Ja oder Nein antworten. Ich würde zunächst fragen: „Warum soll das andere CMS eingesetzt werden?“ Wenn die Anforderungen einer Website mit WordPress sinnvoll erfüllt werden können, sehe ich grundsätzlich keinen Grund, WordPress aus Sicherheitsgründen auszuschließen.

Viel wichtiger ist für mich, wie die konkrete Website geplant, umgesetzt, gehostet, abgesichert, aktualisiert und betreut wird. Eine professionell gewartete WordPress-Website kann ein sehr hohes Sicherheitsniveau erreichen. Eine schlecht gewartete Website kann dagegen unabhängig vom verwendeten CMS zum Sicherheitsrisiko werden.

Häufige Fragen

Ist WordPress unsicherer als Joomla, Drupal oder TYPO3?

WordPress-Sicherheit beginnt nicht erst bei WordPress: Warum Hosting, Server und DSGVO-Konformität entscheidend sind

Markus Steinacher — Fri, 28 Aug 2026 13:29:19 +0000

Die gesamte Themenlandschaft rund um die Sicherheit von WordPress-Websites, bei gleichzeitiger DSGVO-Konformität am Server und der Website selbst, kann im Fall des Falles eine wirklich komplexe Angelegenheit darstellen. Website-Betreiber sehen sich nicht umsonst in gewisser Weise zwischen zwei Stühlen sitzend, zwischen Cyberangriffen auf der einen Seite und den rechtlichen Rahmenbedingungen in der EU auf der anderen Seite. Diese Situation macht es demnach auch für kleine Firmen-Websites mehr oder weniger kompliziert genug, um auf professionelle Website-Dienstleister zurückgreifen zu müssen. Ohne entsprechendes Fachwissen kann es schwierig werden, den aktuellen Anforderungen gerecht zu werden.

Warum auch Hosting und Server entscheidend sind um eine WordPress-Website sicher und DSGVO-konform zu betreiben

Das Thema WordPress-Sicherheit beginnt für mich bereits außerhalb der Website. Eine wichtige äußere Verteidigungslinie befindet sich in der Hosting- und Server-Infrastruktur (Sinnbild: stellen wir uns eine mittelalterliche Burgmauer vor). Viele Angriffsversuche auf WordPress-Websites erfolgen automatisiert durch Bots und spezialisierte Programme. Diese Programme verwenden kein klassisches WordPress-Login um sich Zutritt zu verschaffen. Vielmehr versuchen Angreifer, bekannte Sicherheitslücken im Code oder Schwachstellen und Fehlkonfigurationen in der technischen Infrastruktur auszunutzen, um eine Website zu kompromittieren.

Die Wirtschaftskammer Österreich hat bereits im Jahr 2025 über das sogenannte Website-Kidnapping berichtet und klärt darin auf wie Website-Kompromittierung passieren kann. Sich daher alleine auf die Sicherheitsvorkehrungen des Servers (Zustand der Burgmauer) zu verlassen, ist demnach keine Garantie für die Sicherheit der Website. Daher sind weitere Sicherheitsmaßnahmen für die Website selbst eine Notwendigkeit um die Chancen für Cyberangriffe zu verringern.

Zur Information: Wie bereits in anderen Beiträgen meines Blogs erwähnt gibt es keine 100%ige Sicherheit vor Cyberangriffen. Das liegt in der Natur der Sache. Aber es gibt Möglichkeiten und Strategien (unter anderem die rasche Durchführung anstehender Sicherheitsupdates), wie man die Chancen und die Wahrscheinlichkeit für erfolgreiche Angriffe drastisch minimiert.

WordPress Server-Sicherheit und EU DSGVO-Konformität, Stichwort: Managed WordPress Hosting

Die Server-Sicherheit in der EU ist mehrdimensional zu betrachten. Die Wahl eines sicheren Hosting-Anbieters ist nicht nur eine technische, sondern unter Umständen auch eine datenschutzrechtliche Entscheidung. Ein Serverstandort innerhalb der Europäischen Union kann bestimmte datenschutzrechtliche Fragen vereinfachen, ist jedoch für sich allein keine Garantie für eine vollständig DSGVO-konforme Datenverarbeitung.

Umgekehrt bedeutet ein Anbieter außerhalb der EU nicht automatisch, dass dessen Dienste nicht DSGVO-konform eingesetzt werden können. Entscheidend sind unter anderem die konkret verarbeiteten Daten, die vertraglichen Vereinbarungen, mögliche Unter-Auftragsverarbeiter und – bei Übermittlungen in Drittländer – die jeweils vorgesehenen rechtlichen Schutzmechanismen.

Auch innerhalb der EU sollte daher genau geprüft werden, welche Daten wo und durch wen verarbeitet werden. Das bedeutet: Wir müssen in der Tat bei der Wahl des Providers / Server-Standortes genau hinsehen und aufpassen, um das jeweils richtige Setting zu erhalten.

Zur Information: Dieser Beitrag soll nicht als Werbung für teures Managed WordPress Hosting wahrgenommen werden. DSGVO-konformes Managed WordPress Hosting hat mit Sicherheit in der Praxis seine Berechtigung, aber es ist auch nicht zwingend erforderlich, in Managed WordPress Hosting unnötig viel Geld zu investieren, wenn es nicht unbedingt sein muss. Eine kleine WordPress-Website kann auch mit einem klassischen Webhosting sicher und DSGVO-konform gut und schnell funktionieren. WordPress ist in der Tat ideal für kleine Unternehmen und Managed WordPress Hosting ist für die meisten KMU’s nicht zwingend notwendig.

DSGVO-konformes Managed WordPress Hosting mit hohem Sicherheitsstandard

Das klingt nun nach einer All-In-One-Lösung für alle technischen und rechtlichen Sicherheitsaspekte einer WordPress-Website. Hinsichtlich Hosting- und Server-Infrastruktur stimmt das bis zu einem gewissen Grad, jedoch sind die Leistungen solcher Angebote im Detail zu überprüfen. Denn auch diese sicheren Hosting-Infrastrukturen, die auf eine datenschutzgerechte Verarbeitung und hohe Sicherheitsstandards ausgerichtet sind, können keine 100%ige Sicherheit vor Cyberangriffen bieten. Die Website selbst, inklusive darin verwendeten Plugins und Themes, kann nach wie vor auf einem sicheren Server gewisse Sicherheitslücken für Cyberangriffe bieten.

Premium-Anbieter mit DSGVO-konformen Managed WordPress Hosting mit hohen Sicherheitsstandards

An dieser Stelle möchte ich zwei renommierte Premium-Anbieter nennen, deren Managed-WordPress-Angebote auf eine DSGVO-konforme bzw. datenschutzgerechte Hosting-Infrastruktur und hohe Sicherheitsstandards innerhalb der EU ausgerichtet sind und daher auch ihren Preis haben: Raidboxes und HostPress. Beim direkten Vergleich fällt auf, dass Raidboxes und HostPress im deutschsprachigen Raum zur Premium-Liga des Managed WordPress Hostings gehören. Beide Anbieter fokussieren sich stark auf hohe Server-Sicherheit und umfangreiche Sicherheitsmaßnahmen, bis hin zu Enterprise-Infrastrukturen. Dennoch gibt es wesentliche Unterschiede bei Sicherheitsphilosophie, Preismodell und dem, was Sie als tatsächlichen Gegenwert erhalten.

Managed WordPress Hosting von Raidboxes und HostPress im Vergleich

Beide Anbieter sorgen grundsätzlich im Rahmen ihrer Dienstleitung dafür, dass Angriffe und Malware so weit wie möglich abgefangen werden, noch bevor sie die WordPress-Installation überhaupt erreichen (die besagte Burgmauer). Durch die umfangreichen serverseitigen Sicherheitsmechanismen von besagten Managed-WordPress-Hostern kann ein zusätzliches Sicherheits-Plugin wie Wordfence je nach Website und Sicherheitskonzept weniger notwendig sein oder einzelne Funktionen können bereits durch die Hosting-Infrastruktur abgedeckt werden. Ob ein zusätzliches Security-Plugin sinnvoll ist, hängt jedoch von den konkreten Anforderungen der jeweiligen Website und den bereits vorhandenen Schutzmaßnahmen ab.

Raidboxes setzt auf RB Security Shield. Raidboxes verfolgt damit ein stark integriertes Sicherheitskonzept. Dazu gehören unter anderem eine Web Application Firewall, DDoS-Schutz und ein Exploit Detector, der verdächtige Skripte und Dateien erkennen soll. Ergänzt wird die Infrastruktur durch isolierte Umgebungen für einzelne WordPress-Projekte, automatische Updates und weitere Sicherheitsfunktionen. Der Leistungsumfang in Bezug auf die Bereinigung und Wiederherstellung im Schadensfall variiert je nach Tarif-Modell.

HostPress geht beim Thema Bereinigung einen Schritt weiter. Dieser Anbieter ergänzt seine präventiven Sicherheitsmaßnahmen durch Malware-Scanning und Unterstützung bei der Bereinigung kompromittierter Websites. Der konkrete Umfang der Malware-Entfernung und mögliche inklusive Leistungen sollten jedoch abhängig vom gewählten Tarif geprüft werden. Nach der aktuell veröffentlichten Tarifübersicht ist beispielsweise eine kostenlose Malware-Entfernung pro Jahr vorgesehen, weitere Bereinigungen können demnach kostenpflichtig sein.

Raidboxes oder HostPress?

Mein persönliches Zwischenfazit: Sowohl Raidboxes als auch HostPress bieten ein spezialisiertes Managed WordPress Hosting mit umfangreichen Sicherheits- und Datenschutzfunktionen für unterschiedlichste WordPress-Websites an.

Welcher Anbieter besser passt, hängt jedoch vom jeweiligen Projekt ab. Bei Websites mit besonders hohem Schutzbedarf, komplexen Anforderungen oder dem Wunsch nach einem möglichst umfangreichen Managed-Service kann HostPress aufgrund seines breiten Leistungsspektrums eine interessante Wahl sein.

Für viele Unternehmens-Websites, die eine leistungsstarke, auf WordPress spezialisierte Hosting-Infrastruktur mit deutschem Serverstandort, integrierten Sicherheitsmechanismen und Managed-Funktionen suchen, bietet auch Raidboxes eine sehr umfangreiche Lösung.

Entscheidend ist daher weniger die Frage, welcher Anbieter pauschal „sicherer“ ist, sondern welches Sicherheits-, Service- und Leistungsniveau zur jeweiligen Website passt.

Ein sicherer und datenschutzorientierter Hosting-Anbieter macht die gesamte Website nicht automatisch DSGVO-konform

Ein Serverstandort in Deutschland oder innerhalb der EU, ein Auftragsverarbeitungsvertrag und hohe Sicherheitsstandards sind wichtige Bausteine. Die DSGVO-Konformität einer Website hängt jedoch von weiteren Faktoren ab. Dazu können beispielsweise externe Analyse- und Marketingdienste, eingebundene Videos, Karten (zB Google Maps), Schriftarten (Google Fonts), Captcha-Systeme, Newsletter-Dienste, CDNs oder andere Drittanbieter gehören.

Managed WordPress Hosting kann daher eine von mehreren wichtigen technischen und organisatorischen Grundlagen für Datenschutz und Sicherheit schaffen. Die rechtliche Bewertung der gesamten Website muss alle eingesetzten Dienste und Datenverarbeitungen berücksichtigen.

Ein letzter Gedanke

WordPress-Sicherheit ist kein einzelnes Produkt und keine einzelne Einstellung. Sie ist das Zusammenspiel aus sicherer Infrastruktur, aktuellen Systemen, geeigneten Schutzmaßnahmen, Überwachung, Backups und einer durchdachten Datenschutzarchitektur.

Häufige Fragen zu WordPress, Hosting und DSGVO

Ist WordPress unsicherer als andere Website-Programme?

Warum auch kleine WordPress-Websites für Cyberangriffe interessant sein können

Markus Steinacher — Fri, 28 Aug 2026 03:22:38 +0000

Auch eine kleine WordPress-Website muss nicht gezielt ausgewählt werden, um angegriffen zu werden. Automatisierte Systeme können das Internet großflächig nach bekannten Schwachstellen durchsuchen. Entscheidend ist daher oft weniger, wie groß oder bekannt eine Website ist, sondern ob sie verwundbar ist.

Der Bedarf nach WordPress-Sicherheit hat sich dramatisch verändert

Früher stellte man sich in Punkto WordPress-Sicherheit vielleicht noch die Frage: „Warum sollte jemand gerade meine kleine Website angreifen?“ Heute ist die wesentlich relevantere Frage: „Was passiert, wenn ein automatisiertes System Millionen Websites nach genau dieser Schwachstelle durchsucht, die auch vielleicht meine Website betrifft?“

Meine Website ist doch viel zu klein, um für Cyberkriminelle interessant zu sein

Diese Überlegung ist nachvollziehbar. Ein regionales Unternehmen, ein kleiner Dienstleister oder eine überschaubare Firmenwebsite scheint auf den ersten Blick kein besonders attraktives Ziel zu sein. Doch genau hier hat sich die Art vieler Angriffe verändert. Eine Website muss heute nicht mehr persönlich ausgewählt werden, um angegriffen zu werden.

Viele Angriffe funktionieren automatisiert. Dabei wird nicht zuerst entschieden, welches Unternehmen angegriffen werden soll. Stattdessen suchen automatisierte Systeme nach Websites, die bestimmte technische Merkmale oder bekannte Schwachstellen aufweisen und daher leicht anzugreifen sind.

Nicht der Mensch sucht – die Software sucht

Ich möchte an dieser Stelle die Gelegenheit nutzen das Prinzip so einfach wie nur möglich zu erklären, zum Beispiel mit einer Analogie: Ein Einbrecher sucht sich ein bestimmtes Haus aus. Stellen Sie sich stattdessen ein System vor, das automatisch eine ganze Stadt entlangfährt und bei jedem Haus überprüft, ob eine Tür offen steht. Übertragen auf Websites bedeutet das, dass eine bekannte Schwachstelle (offene Haustüre) öffentlich vom System wahrgenommen wird. Es wird klar, welche Software-Versionen betroffen sind. Automatisierte Systeme prüfen in kurzer Zeit große Mengen von Websites. Verwundbare Systeme können nach dieser Prüfung schnell und sehr gezielt angegriffen werden.

Patchstack berichtet darüber hinaus, dass im ersten Halbjahr 2025 mehr als die Hälfte der untersuchten WordPress-Schwachstellen ohne vorherige Anmeldung (WordPress-Login) ausnutzbar waren und sich deshalb grundsätzlich für automatisierte Angriffe eignen können.

WordPress-Sicherheitsdaten aus dem Jahr 2025 - 2026

Aktuelle WordPress-Sicherheitsdaten stützen diese Einordnung der Situation rund um WordPress-Websites und deren Sicherheit. Patchstack berichtete rückblickend auf das Jahr 2025 von 11.334 neu gefundenen Schwachstellen im WordPress-Ökosystem. 17 % dieser Schwachstellen (weitere Infos dazu siehe weiter unten im Beitrag) wurden als besonders relevant für automatisierte Angriffe im großen Maßstab eingestuft. In einem groß angelegten Test beliebter Webhosting-Unternehmen wurden nur 26 % aller Schwachstellenangriffe serverseitig (die erste Verteidigungslinie) blockiert.

Regelmäßige Updates sind eine wichtige Sicherheitsmaßnahme, aber sie sind nur ein Teil einer mehrschichtigen Sicherheitsstrategie. Da Angreifer innerhalb weniger Stunden neue Schwachstellen (gerne ausgelöst durch neue Updates) identifizieren und schnell ausnutzen, ist dies dauerhaft keine praktikable und verlässliche Verteidigung.

Es gibt allerdings reaktive Lösungen, wie zum Beispiel Malware-Erkennung und rasche Bereinigung. Das WordPress-Ökosystem war bislang viel zu sehr darauf angewiesen, Sicherheit als etwas zu behandeln, um „Post-Boom“ (erst nach dem Angriff zu handeln: reparieren, wiederherstellen, …) zu beheben, aber Angreifer entwickeln sich weiter, ebenso wie ihre Malware.

Was nun durch Patchstack und Monarx ermittelt wurde, ist die Erkenntnis, dass Angreifer in ihren Methoden strategischer und ausgefeilter werden. Malware wird immer schwieriger zu finden und noch schwieriger zu entfernen.

Im Jahr 2025 wurden insgesamt 11.334 neue Sicherheits-Schwachstellen im WordPress-Ökosystem gefunden

Das ist ein Anstieg von 42% im Vergleich zum Jahr 2024. Von allen gefundenen neuen Schwachstellen stellten 4.124 (36%) eine tatsächliche Bedrohung dar und waren schwerwiegend genug, um RapidMitigate-Schutzregeln erforderlich zu machen. 1.966 WordPress-Sicherheitslücken (17%) hatten einen hohen Schweregrad und wurden von Patchstack als besonders relevant für eine mögliche Ausnutzung in automatisierten Angriffen im großen Maßstab eingestuft.

Kleine Websites sind nicht unbedingt das Ziel, aber Teil der Masse

Eine kleine WordPress-Website wird nicht zwangsläufig gezielt ausgewählt, weil das Unternehmen selbst interessant ist. Die Website kann lediglich ein kleiner Teil einer großen Menge von Websites sein, die automatisiert auf bekannte Schwachstellen geprüft werden.

Für ein automatisiertes System spielt es keine Rolle, ob eine Website zu einem internationalen Konzern oder zu einem kleinen regionalen Unternehmen gehört. Entscheidend kann allein sein, ob eine bekannte Schwachstelle vorhanden ist. Das ist für ein automatisiertes System Grund genug um anzugreifen, nach dem Motto „alles erobern was möglich ist“.

Warum überhaupt eine kleine WordPress-Website angreifen?

Viele Menschen denken: „Aber was soll ein Angreifer denn mit meiner Website anfangen?“

Die Antwort kann beunruhigend sein. Die Website selbst muss erst gar nicht das eigentliche Ziel sein. Eine kompromittierte Website kann beispielsweise missbraucht werden für:

Spam und Versand unerwünschter Nachrichten
Manipulierte oder unerwünschte Inhalte
Weiterleitungen auf betrügerische Webseiten
Hosting von Phishing-Inhalten
Verbreitung von Schadsoftware
SEO-Spam und Manipulation von Suchergebnissen
oder als Teil einer größeren kriminellen (oftmals unentdeckten) Infrastruktur.

Fakt ist: Eine Website kann für Angreifer als technische Ressource sehr wertvoll sein, auch wenn das dahinterstehende Unternehmen selbst kein besonders attraktives Ziel darstellt.

Beispiele, die reale Bedrohungen auch für kleine Websites darstellen können

Website-Kidnapping

Unter dem Titel Website-Kidnapping hat die WKO bereits im Jahr 2025 einen interessanten Beitrag veröffentlicht, in welchem die Problematik speziell auch für KMUs erklärt wird. Seriöse Unternehmens-Websites werden angegriffen, um betrügerische Weiterleitungen auf Fake-Shops, pornografische Inhalte oder Ähnliches zu platzieren. Die dramatische Begleiterscheinung ist, dass Betreiber der eigenen Website oft gar nichts von einer Manipulation, die im Verborgenen stattfindet, mitbekommen. Daher bleibt der Missbrauch auch oft lange Zeit unbemerkt.

Nun kann es beispielsweise der Fall sein, dass die kompromittierte Firmen-Website, die auch eine Marke repräsentiert, in Suchmaschinen zu unerwünschten Suchbegriffen erscheint und damit in ein rufschädliches Licht gerückt wird. Mit dem Klick auf das jeweilige Sucherergebnis könnten Interessenten dann auf einen Fake-Shop umgeleitet werden. Was bleibt, ist die Schädigung des renommierten Firmen-Rufes. Denn neben „Anabole Steroide online kaufen“ steht in den Suchergebnissen der Name Ihrer Website.

Nun empfiehlt auch die WKO, dass Ihr CMS sowie alle installierten Plugins stets auf dem neuesten Stand sind. Regelmäßige Updates schließen Sicherheitslücken und verringern das Risiko eines Angriffs.

Missbrauch unter dem Deckmantel des Urheberrechts

Ein denkbares Missbrauchsszenario könnte auch darin bestehen, dass Angreifer ohne Wissen des Website-Betreibers Inhalte auf einer kompromittierten Website veröffentlichen. Sollte daraus anschließend ein rechtlicher oder finanzieller Konflikt entstehen, kann die technische Dokumentation einer möglichen Kompromittierung für die Aufklärung des Vorfalls von großer Bedeutung sein.

Unter dem Deckmantel des Urheberrechts könnte beispielsweise der Fall passieren, dass kriminelle Individuen vermeintlich urheberrechtliches Bildmaterial auf einer kleinen, gehackten Website hochladen und heimlich veröffentlichen, ohne dass es der unwissende Website-Betreiber mitbekommt. Nun könnte ein Komplize – der vermeintliche Urheber – den Betreiber der kleinen Website kontaktieren und einen erheblichen Geldbetrag für das Veröffentlichen des Bildmaterials unter dem Deckmantel des Urheberrechts verlangen.

Ohne entsprechende sicherheitsrelevante Vorkehrungen und Fachkenntnis fehlt dem kleinen Website-Betreiber eventuell jegliche Möglichkeit um seine Unschuld zu beweisen, da er keine Informationen dazu hat und auch nicht weiß wie das Bildmaterial überhaupt auf seine Website gelangt ist. Aus Angst vor noch härteren Androhungen und im Zweifelsfall bezahlen die Opfer oftmals ohne echte rechtliche Grundlage die Schadenersatzforderung. Das ist einerseits verständlich, aber auf der anderen Seite ein Signal für jene Straftäter, die sich damit nicht nur ein gutes Zusatzeinkommen verschaffen, sondern auch ungeschoren damit durchkommen.

Sind WordPress Sicherheitslücken tatsächlich häufiger geworden?

Die Entwicklung im WordPress-Ökosystem ist deutlich zu erkennen. Im Jahr 2024 wurden laut Patchstack rund 7.966 Schwachstellen erfasst. Im Jahr 2025 waren es 11.334 Schwachstellen, also rund 42 % mehr als im Jahr zuvor. Aber Vorsicht: mehr entdeckte Schwachstellen bedeutet nicht automatisch, dass WordPress plötzlich massiv unsicherer geworden ist. Auch die Sicherheitsforschung und Entwicklung zur Verteidigung ist professioneller geworden.

Wordfence weist beispielsweise darauf hin, dass die höhere Zahl veröffentlichter Schwachstellen auch mit verstärkter Sicherheitsforschung und Bug-Bounty-Programmen zusammenhängt. Im Jahr 2024 wurden dort 8.223 Schwachstellen dokumentiert, rund 68 % mehr als im Jahr 2023.

Wir sehen heute mehr Software Sicherheitsprobleme, weil es teilweise mehr komplexe Software gibt und weil teilweise besser und intensiver danach gesucht werden kann.

Die eigentliche Herausforderung für Website-Betreiber: Zeit

Nicht nur ob ein Update kommt, ist entscheidend, sondern wie schnell reagiert werden kann. Denn sobald eine Schwachstelle bekannt wird, beginnt ein Wettlauf zwischen dem Entwickler (der für das Sicherheitsupdate zuständig ist), dem Website-Betreiber (der das Update auf seiner Website installieren „lassen“ muss) und möglicherweise dem Angreifer (automatisierte Suche nach verwundbaren Websites).

Wer macht das Rennen?

Wenn Angreifer eine bekannte Schwachstelle ausnutzen können, bevor ein Sicherheitsupdate installiert oder andere Schutzmaßnahmen wirksam werden, kann sich das Risiko einer Kompromittierung deutlich erhöhen. Wird eine Website tatsächlich infiziert, kann die anschließende Analyse, Bereinigung und Wiederherstellung je nach Art und Umfang des Angriffs erheblichen Aufwand verursachen. Bis eine infizierte Website wieder sauber ist (falls das überhaupt dann noch möglich ist) können Wochen vergehen. Die Rettung von WordPress-Websites ist ein Thema für sich, bei welchem sich oft die Frage stellt ob ein kompletter Relaunch die bessere Option darstellt.

Ein Update ist nicht einfach eine lästige technische Meldung und Updates sind keine 100%ige Sicherheitsgarantie

Ich persönlich nehme das Thema „WordPress Updates“ sehr ernst und bin grundsätzlich der Meinung, dass automatisierte Update-Prozesse immer wieder zu Problemen führen können, die man als Website-Bertreiber lieber nicht haben will. Automatisierte Updates können in vielen Fällen durchaus sinnvoll sein und helfen, bekannte Sicherheitslücken schneller zu schließen. Bei individuell aufgebauten oder komplexeren Websites können Updates jedoch auch Auswirkungen auf Plugins, Themes und andere technische Komponenten haben. Deshalb ist es wichtig, für jede Website eine passende Update-Strategie zu wählen und die Funktionsfähigkeit des Gesamtsystems im Blick zu behalten.

Genauso bin ich der Meinung, dass schnelles Updaten (One-Klick-Update) im WordPress-Backend auch nicht unbedingt der richtige Weg ist, um die eigene Website sicher und up2date zu halten. Viel wichtiger ist eine solide Strategie, wie man mit WordPress Updates im Allgemeinen umgeht. Hier kommt mein WordPress Website Service zum Einsatz. Mit diesem Service biete ich Unternehmen und ihren WordPress Websites einen soliden und schnellen Update-Service, der so rasch wie möglich Sicherheitslücken durch verfügbare Sicherheitsupdates schließt.

Manchmal verkürzt ein Sicherheitsupdate schlicht aber auch nur das Zeitfenster, in dem eine bekannte Schwachstelle auf einer Website offen bleibt. Daher ist auch mein Service keine 100%ige Sicherheitsgarantie, jedoch reduziere ich die Gefahr erheblich.

Aktuelle Wordfence-Daten zeigen die Dimension automatisierter Aktivitäten sehr deutlich. Allein im 4. Quartal 2025 wurden in dem von Wordfence beobachteten Netzwerk 9,1 Milliarden verdächtige Anfragen durch Web Application Firewalls blockiert und 13,8 Milliarden Brute-Force-Angriffe abgewehrt. Das sind keine Zahlen für „kleine Websites allein“, aber sie zeigen, wie stark automatisiert Angriffe im WordPress-Ökosystem stattfinden können.

Die meisten Schwachstellen liegen nicht im WordPress-Core

An dieser Stelle möchte ich unbedingt vermeiden, dass der Eindruck erweckt wird, WordPress als System sei unsicher. Das stimmt so nicht, denn mit diesem Thema haben alle Software-Systeme, die vom Internet abhängig sind, zu kämpfen. WordPress ist grundsätzlich ein sehr sicheres CMS-System und es wird ständig an der Sicherheit gearbeitet. Der steigende Sicherheitsaufwand lässt sich nicht auf WordPress oder ein einzelnes Software-System reduzieren. Er hängt vielmehr mit der zunehmenden Komplexität moderner Software, der großen Zahl an Drittanbieter-Komponenten, intensiverer Sicherheitsforschung und der zunehmenden Automatisierung von Angriffen zusammen.

Patchstack ordnete beispielsweise im Jahr 2025 rund 91 % der dort erfassten WordPress-Schwachstellen Plugins zu, etwa 9 % Themes und nur einen sehr kleinen Anteil dem WordPress-Core selbst. Die Sicherheit von WordPress ist heute nicht nur eine Frage des WordPress-Grundsystems. Entscheidend ist das gesamte Ökosystem aus Plugins, Themes und weiteren technischen Komponenten, sowie dem persönlichen Umgang mit der eigenen Website. Die menschliche Komponente (meistens wegen fachlicher Mängel, Unwissen) trägt leider auch einen nicht unwesentlichen Beitrag dazu bei. Daher zahlt es sich aus, im Bedarfsfall eine WordPress Schulung in Anspruch zu nehmen.

Sicherheitslücken und automatisierte Angriffe existieren

Die Tatsache, dass Sicherheitslücken und automatisierte Angriffe existieren, bedeutet nicht, dass jede Website zwangsläufig kompromittiert wird. Sie zeigt aber, warum eine Website nicht über Jahre hinweg unverändert bleiben sollte. Regelmäßige Updates, Sicherheitsmaßnahmen und eine laufende technische Betreuung reduzieren bekannte Risiken und sorgen dafür, dass notwendige Maßnahmen möglichst zeitnah umgesetzt werden können. Genau deshalb gehört die laufende Aktualisierung und technische Betreuung bei meinen betreuten WordPress-Websites zum festen Bestandteil des Website-Betriebs.

Häufige Fragen zur Sicherheit von WordPress

Warum sollte jemand eine kleine WordPress-Website angreifen?

Warum WordPress-Websites heute immer häufiger aktualisiert werden müssen – und was hinter den laufenden Updates wirklich steckt

Markus Steinacher — Thu, 27 Aug 2026 09:44:58 +0000

Eine WordPress-Website wirkt für Besucher meist erstaunlich unkompliziert: Man ruft die Seite auf, liest Inhalte, sendet eine Anfrage oder bestellt ein Produkt. Wenn alles funktioniert, gibt es keinen Grund, über die Technik im Hintergrund nachzudenken. Genau so soll es auch sein!

Eine moderne Website ist heute kein fertiges Produkt, das nach der Erstellung unverändert bestehen bleibt. Sie ist ein laufend weiterentwickeltes Software-Ökosystem. Das Kernsystem von WordPress selbst wird jährlich ein paar Mal aktualisiert, Plugins ziehen nach und werden entsprechend weiterentwickelt, genauso wie Themes und auch die technische Umgebung auf den jeweiligen Servern verändert sich stetig.

Wer meinen laufenden WordPress Website Service nutzt, bekommt von vielen dieser Arbeiten im Idealfall gar nichts mit. Die Website funktioniert einfach weiter. Aber gerade hinter diesem „einfach weiter“ steckt heute deutlich mehr laufende Arbeit als noch vor einigen Jahren.

Eine WordPress-Website ist heute ein kleines dynamisches Software-Ökosystem

Als WordPress vor vielen Jahren populär wurde, war eine typische Website technisch meist überschaubar aufgebaut. Es gab das WordPress-Grundsystem, ein Theme und einige wenige Plugins. Heute sieht das bei vielen Websites anders aus.

Eine moderne WordPress-Website besteht häufig aus einer Vielzahl eigenständiger Komponenten:

WordPress-Kernsystem
Theme, gegebenenfalls einem Child Theme (Design-Paket, Design-Vorlage)
einer Reihe von Plugins (Funktionserweiterungen)
Sicherheits- und Backup-Lösungen
Formular- und Newsletter-Systemen
SEO- und Analyse-Werkzeugen
Cookie- und Datenschutz-Lösungen
Schnittstellen zu externen Diensten
bei Onlineshops zusätzlich Shop-, Zahlungs- und Versand-Erweiterungen
Technische Serverumgebung mit PHP, Datenbank und weiteren Komponenten

All diese Bausteine werden von zahlreichen unterschiedlichen Entwicklern und Unternehmen auf der ganzen Welt weiterentwickelt. Und genau darin liegt ein wesentlicher Unterschied zu früher. Eine Website besteht heute nicht mehr nur aus einer Software. Sie besteht aus einem Zusammenspiel vieler einzelner Software-Komponenten, die allesamt miteinander harmonieren müssen, damit die Website einfach nur funktionieren kann. Das ist die Mindestanforderung, die sich ein Kunde / Website-Betreiber von seiner Website erwarten kann. Der Aufwand dahinter ist enorm und ist im Begriff stetig weiter zu steigen.

Werden WordPress-Websites heute tatsächlich häufiger aktualisiert?

Mein Eindruck aus der laufenden Betreuung von zahlreichen WordPress-Websites war in den vergangenen Jahren eindeutig: Die Zahl der verfügbaren Aktualisierungen scheint deutlich zugenommen zu haben. Ein Blick auf die offizielle WordPress-Release-Historie bestätigt zumindest einen wesentlichen Teil dieses Eindrucks.

Bei Aufwand und Häufigkeit von WordPress-Updates muss man unterscheiden

Die Anzahl der großen WordPress-Versionen ist nicht einfach von Jahr zu Jahr explodiert. WordPress verfolgt seit Langem einen relativ regelmäßigen Entwicklungsrhythmus. Ein Release-Zyklus dauert typischerweise rund vier Monate. Als Orientierung werden häufig größere Veröffentlichungen im Abstand von etwa vier Monaten genannt.

Zusätzlich zu diesen großen Versionen gibt es jedoch sogenannte Minor- oder Wartungs-Releases. Diese dienen unter anderem dazu, Fehler zu beheben, Verbesserungen einzuspielen oder Sicherheitsprobleme zu korrigieren. Solche Updates erscheinen nicht nach einem starren Kalender, sondern dann, wenn sie tatsächlich erforderlich sind.

Das wiederum führt zu einer wichtigen Erkenntnis

Nicht unbedingt die Zahl der großen WordPress-Versionen ist der Grund für die zunehmende Update-Wahrnehmung. Entscheidend ist vielmehr die Summe aller technischen Aktualisierungen, die im Zusammenhang mit modernen WordPress-Websites stehen, denn dazu gehören nicht nur WordPress-Updates selbst, sondern vor allem auch Plugin-, Theme- und weitere technische Updates am Server.

Ein aktuelles Beispiel: Wie schnell sich WordPress-Updates hintereinander folgen können

Wie dynamisch ein Release-Zyklus sein kann, zeigt ein Blick auf die aktuelle WordPress-Entwicklung im Jahr 2026. WordPress 7.0 wurde am 20. Mai 2026 veröffentlicht. Danach folgten innerhalb weniger Monate mehrere Wartungs- und Sicherheitsupdates. Im offiziellen Release-Archiv sind für den 7.0-Zweig unter anderem die Versionen 7.0.2, 7.0.3 und 7.0.4 dokumentiert. WordPress 7.1 erschien am 19. August 2026.

Das bedeutet nicht, dass jede Website jede einzelne dieser Versionen manuell installieren muss. Moderne WordPress-Systeme können bestimmte Updates auch automatisch erhalten. Allerdings sollte man sehr vorsichtig und mit Bedacht mit automatisierten Update-Vorgängen in Bezug auf WordPress umgehen.

Für die technische Betreuung zeigt dieses Beispiel aber sehr deutlich, wie schnell sich die Softwarelandschaft verändern kann. Hinzu kommt, dass ein aktuelles WordPress-System nicht isoliert betrachtet werden kann. Nach einem WordPress-Update können auch Plugin-Entwickler Anpassungen veröffentlichen, weil diese naturgemäß nachziehen müssen, damit ihr Plugin kompatibel bleibt. Ein Update eines Plugins kann wiederum eine Änderung an einer anderen Komponente erforderlich machen. Aus einem einzelnen Update können somit mehrere weitere Aktualisierungen erforderlich werden.

Warum Plugins bei der Update-Häufigkeit eine besonders große Rolle spielen

Im Alltag ist das oft der wichtigste Punkt, der hier berücksichtigt werden muss. Eine WordPress-Website mit einem Theme und 15 Plugins besteht bereits aus mindestens 17 separat entwickelten Software-Komponenten. Wenn einzelne Plugins nur wenige Male pro Jahr aktualisiert werden, kann sich trotzdem eine beträchtliche Anzahl von erforderlichen Updates daraus ergeben.

Wenn 15 Plugins durchschnittlich vier Updates pro Jahr erhalten, entstehen allein dadurch bereits 60 Plugin-Updates pro Jahr. Das entspricht rein rechnerisch durchschnittlich mehr als einem verfügbaren Update pro Woche.

Natürlich erscheinen diese Updates nicht gleichmäßig verteilt. Manchmal passiert ein oder zwei Wochen lang nichts und dann stehen plötzlich mehrere Aktualisierungen gleichzeitig bereit. Bei aktiv entwickelten Erweiterungen kann die tatsächliche Update-Frequenz deutlich höher sein.

Gerade bei komplexeren Websites, etwa mit WooCommerce, Buchungssystemen, Mitgliederbereichen oder zahlreichen externen Schnittstellen, steigt die Zahl der voneinander abhängigen Komponenten zusätzlich an.

Ein Update ist nicht einfach nur ein Klick auf „Aktualisieren“

Genau hier entsteht sehr häufig ein großes Missverständnis. Ja, rein technisch kann ein Update oft mit einem Klick gestartet werden. Aber ein professioneller Website-Service besteht nicht einfach darin, möglichst schnell auf den Update-Button zu drücken. Deshalb lautet die eigentliche Frage:

Funktioniert die Website nach dem Update noch genauso zuverlässig wie davor?

Bei jedem Update können theoretisch neue Wechselwirkungen im System entstehen. Ein Plugin kann beispielsweise mit einer neuen WordPress-Version anders reagieren, als zuvor. Ein Theme benötigt ein Update, damit es ordnungsgemäß mit der neuen WordPress-Version funktionieren kann. Eine Erweiterung kann eine bestimmte neue PHP-Version voraussetzen. Zwei Plugins können nach einem Update plötzlich miteinander in Konflikt geraten, usw … die durchaus realistischen Szenarien können mannigfaltig ausfallen. Deshalb gehört zu einem professionellen Website Service mehr als nur die One-Klick-Installation einer neuen Version.

Ein Update zu installieren ist einfach. Die Verantwortung dafür zu übernehmen, dass eine Website danach weiterhin funktioniert, ist der eigentliche Teil der Arbeit.

Je nach Website und Art der Updates können beispielsweise folgende Schritte erforderlich sein:

Prüfen, welche Aktualisierungen verfügbar sind
Einschätzen, ob es sich um ein Sicherheits-, Wartungs- oder Funktionsupdate handelt
Sicherstellen, dass eine aktuelle Sicherung vorhanden ist
Updates in einer sinnvollen Reihenfolge durchführen
Besonderheiten und Abhängigkeiten der jeweiligen Website berücksichtigen
Nach Aktualisierungen wichtige Funktionen kontrollieren
Auffälligkeiten oder Fehlermeldungen prüfen
Bei Problemen reagieren und gegebenenfalls Maßnahmen zur Wiederherstellung oder Fehlerbehebung einleiten
Änderungen an der Serverumgebung und an unterstützten Software-Versionen berücksichtigen

Die Installation eines Updates ist daher nur ein einzelner Schritt innerhalb eines viel größeren Prozesses.

Warum werden Software-Systeme heute überhaupt so häufig aktualisiert?

Diese Entwicklung beschränkt sich bei Weitem nicht nur auf WordPress. Grundsätzlich hat sich die Art, wie moderne Software entwickelt und betrieben wird, in den vergangenen Jahren extrem stark verändert. Früher erschienen neue Software-Versionen häufig in größeren Zeitabständen. Zwischen zwei Hauptversionen konnten Monate oder sogar Jahre liegen. Heute werden Änderungen wesentlich häufiger veröffentlicht. Die Gründe dafür sind unter anderem: Sicherheit, Fehlerbehebungen, neue technische Anforderungen, neue Funktionen und Verbesserungen.

Sicherheit für Software-Systeme

Sicherheitslücken müssen möglichst rasch geschlossen werden. Je komplexer ein Software-System ist und je mehr Komponenten und externe Bibliotheken darin verwendet werden, desto größer wird auch die Zahl möglicher Angriffspunkte.

WordPress unterscheidet bei seinen kleineren Releases ausdrücklich zwischen Wartungs- und Sicherheitsaspekten. Für Sicherheitsupdates existieren eigene Prozesse, Tests und Vorbereitungen. WordPress-Entwickler bemühen sich zudem, geeignete Sicherheitskorrekturen auf verschiedene Versionszweige zurück zu portieren. Was die Sicherheit von WordPress Websites betrifft, so können auch kleine WordPress-Websites für automatisierte Cyberangriffe interessant sein.

Fehlerbehebungen

Keine komplexe Software ist vollständig fehlerfrei. Nach einer größeren Veröffentlichung werden oft Probleme entdeckt, die erst unter realen Bedingungen sichtbar werden. Deshalb können auf ein größeres Release relativ rasch kleinere Korrekturversionen folgen. Auch der offizielle WordPress-Release-Prozess beschreibt, dass auf eine Veröffentlichung häufig weitere Minor-Releases folgen, um gemeldete Fehler zu beheben.

Neue technische Anforderungen

Auch die Umgebung einer Website bleibt nicht stehen. PHP-Versionen entwickeln sich weiter. Browser ändern sich. Sicherheitsstandards werden angepasst. Externe Dienste verändern ihre Schnittstellen. Eine Website muss deshalb nicht nur mit WordPress selbst kompatibel bleiben, sondern mit ihrem gesamten technischen Umfeld.

Neue Funktionen und Verbesserungen

Software wird heute laufend weiterentwickelt. Was früher vielleicht in einer großen neuen Version gesammelt wurde, kann heute in kleineren Schritten veröffentlicht werden. Für Website-Betreiber ist das grundsätzlich positiv. Verbesserungen und Fehlerkorrekturen müssen nicht erst auf die nächste große Version warten.

Die Folge ist allerdings eine höhere Dynamik. Die besondere Herausforderung dabei ist, dass alle Komponenten zusammenarbeiten müssen.

Stellen wir uns eine Website vereinfacht als Team vor

WordPress ist die Grundlage. Das Theme bestimmt die Darstellung. Plugins übernehmen zusätzliche Aufgaben. Der Server stellt die technische Umgebung bereit. Wenn sich eine dieser Komponenten verändert, müssen die anderen weiterhin damit zusammenarbeiten. Das ist vergleichbar mit einem modernen Fahrzeug. Es reicht nicht aus, dass ein einzelnes Bauteil für sich genommen funktioniert. Entscheidend ist, dass das gesamte System weiterhin zuverlässig zusammenspielt und in seiner Gesamtheit funktioniert.

Jedes Update kann sinnvoll und notwendig sein, entscheidend ist aber immer die Stabilität des Gesamtsystems

Genau deshalb ist die laufende technische Betreuung bei individuell aufgebauten oder über Jahre gewachsenen Websites besonders wichtig.

Warum Kundinnen und Kunden von den meisten Updates nichts bemerken

Im Idealfall bemerkt man meinen Website-Service kaum. Die Website ist erreichbar und Inhalte werden korrekt angezeigt. Dass im Hintergrund WordPress, Plugins oder andere Komponenten aktualisiert und geprüft werden, muss für die tägliche Arbeit nicht sichtbar sein.

Das ist auch der Sinn einer laufenden Betreuung

Man kann es mit der Wartung anderer technischer Systeme vergleichen. Niemand möchte sich regelmäßig mit der Frage beschäftigen müssen, welche Software-Version gerade installiert ist oder ob zwei technische Komponenten nach einem Update noch kompatibel sind. Vielmehr besteht das Ziel darin, mögliche Probleme frühzeitig zu erkennen und die laufende Funktionsfähigkeit der Website sicherzustellen.

Die beste technische Wartung ist oft jene, die man gar nicht bemerkt

Eine Website kann heute einwandfrei funktionieren und morgen trotzdem technische Aktualisierungen benötigen, damit dieser Zustand auch so bleibt. Denn ein Update wird nicht erst dann relevant, wenn bereits ein sichtbares Problem besteht.

Prävention statt Troubleshooting

Oft geht es darum bekannte Sicherheitsrisiken zu reduzieren, mögliche Fehlerquellen zu beheben bevor diese offensichtlich auftreten, die Kompatibilität mit aktuellen WordPress-Versionen zu erhalten und die Grundlage für spätere Weiterentwicklungen zu sichern.

Wer eine Website über einen längeren Zeitraum im technischen Kontext unverändert lässt, kann irgendwann vor einem wesentlich größeren Problem stehen. Wenn es soweit ist, dann müssen möglicherweise viele WordPress-Versionen, Plugins oder Server-Komponenten auf einmal aktualisiert werden. Gleichzeitig steigt das Risiko, dass ältere Komponenten überhaupt nicht mehr miteinander kompatibel sind.

Regelmäßige Wartung, wie im Rahmen meines WordPress Website Service ist daher in vielen Fällen wesentlich sinnvoller als eine große technische „Aufholaktion“ nach mehreren Jahren. Im schlimmsten Fall muss darüber auch immer wieder einmal entschieden werden, ob eine veraltete WordPress-Website gerettet werden kann oder doch ein kompletter Neubau die bessere Möglichkeit darstellt.

Mein Website Service ist Teil des laufenden Betriebs

Der Begriff „Website“ führt meiner Erfahrung nach manchmal noch zu einer falschen Vorstellung. Man denkt an ein Projekt, das einmal erstellt und anschließend abgeschlossen wird. Technisch betrachtet ist das bei modernen WordPress-Websites jedoch nur der Anfang, denn nach der Veröffentlichung beginnt der laufende Betrieb. Und dieser laufende Betrieb umfasst heute unter anderem:

Aktualisierungen
Sicherheitsmaßnahmen
technische Kontrollen
Sicherung und Überwachung
Fehlerbehebungen im Fall der Fälle
Anpassungen an neue technische Anforderungen
Bei Bedarf die Weiterentwicklung hinsichtlich Funktionalität
Im Idealfall der inhaltliche Ausbau

Wie viel Aufwand im laufenden Betrieb tatsächlich entsteht, das hängt natürlich stark von der jeweiligen Website ab. Eine kleine Unternehmenswebsite mit wenigen Erweiterungen ist etwas völlig anderes als ein komplexer Onlineshop mit zahlreichen Schnittstellen.

Aber die grundsätzliche Entwicklung ist eindeutig: Moderne Websites sind dynamische Software-Systeme. Und Software-Systeme müssen an allen Ecken und Enden gepflegt werden.

Erkenntnis daraus: Im Hintergrund passiert mehr, als man sieht

Der Eindruck, dass WordPress und die dazugehörigen Komponenten heute häufiger aktualisiert werden als früher, ist nicht unbegründet. Bei den großen WordPress-Versionen selbst zeigt sich vor allem ein regelmäßiger Release-Rhythmus. Die eigentliche Dynamik entsteht jedoch durch die Kombination aus:

großen WordPress-Releases
kleineren Wartungs- und Sicherheitsupdates
laufend aktualisierten Plugins
Theme-Aktualisierungen
technischen Änderungen auf Server-Ebene
und den zahlreichen Abhängigkeiten zwischen diesen Komponenten.

Für Website-Betreiber sollte das allerdings nicht bedeuten, dass sie ständig selbst Update-Meldungen beobachten und technische Entscheidungen treffen müssen. Genau dafür gibt es meine laufende technische Betreuung.

Während im Hintergrund WordPress, Plugins und weitere Komponenten weiterentwickelt werden, bleibt das Ziel im Vordergrund unverändert. Ihre Website soll zuverlässig funktionieren, sicher bleiben und technisch möglichst aktuell sein.

Und wenn Sie von den vielen einzelnen Aktualisierungen gar nichts bemerken, dann ist das im besten Fall kein Zeichen dafür, dass nichts passiert. Sondern dafür, dass die laufende Wartung genau das tut, was sie soll.

Fragen zu diesem Thema?

Wenn Sie Fragen zu diesem Beitrag haben, dann stehe ich Ihnen gerne zur Verfügung. Senden Sie mir bitte einfach Ihre unverbindliche und kostenfreie Anfrage.

Kleines Fazit

Dass Sie von den vielen Updates im Hintergrund möglichst wenig bemerken, bedeutet nicht, dass nichts passiert. Im Gegenteil: Eine gut betreute Website soll im Alltag einfach funktionieren – gerade weil WordPress, Plugins und die technische Umgebung laufend gepflegt werden.

The post Warum WordPress-Websites heute immer häufiger aktualisiert werden müssen – und was hinter den laufenden Updates wirklich steckt first appeared on Markus Steinacher.

Google Takeout: YouTube Video sichern mit der Google Datensicherung

Markus Steinacher — Tue, 25 Aug 2026 12:06:55 +0000

Ist es Ihnen schon einmal passiert, dass Sie versehentlich einen – oder sogar Ihren eigenen – YouTube-Kanal gelöscht haben? Ein Klick (vielleicht nicht einmal auf YouTube selbst) und plötzlich waren alle Videos weg, und nun? Aber kann so etwas passieren? Ja, es kann passieren, zum Beispiel wenn man versehentlich ein altes, beziehungsweise verknüpftes Google-Konto (Stichwort: Brand-Konto) entfernen / umorganisieren will. Die möglichen Szenarien sind mannigfaltig, jedenfalls möglich ist es, ungeachtet auf welchem Weg es passiert. In diesem Beitrag geht es lediglich darum, dass wenn einmal ein Google-Konto mit YouTube-Kanal bereits gelöscht worden ist, dass auch gleichzeitig ohne Vorwarnung auch damit der gesamte YouTube-Kanal samt aller darin enthaltener Videos von YouTube ohne Aussicht auf Reaktivierung entfernt werden. Was man in so einem Fall tun kann? Gar nichts! Und doch gibt es eine präventive Möglichkeit um bereits online verfügbare YouTube Videos des eigenen Kanals zu exportieren, um diese am eigenen PC oder des eigenen Dropbox-Accounts zu sichern. Wie das funktioniert, das erkläre ich kurz in diesem Beitrag.

Mit Google Takeout eigene YouTube-Videos exportieren und sichern

Mit dem Google Datenexport-Feature „Google Takeout“ kann man YouTube Videos ganz einfach exportieren und extern sichern, zum Beispiel am eigenen PC oder im eigenen Dropbox-, Drive- oder Microsoft OneDrive-Account (es gibt mehrere Export-Möglichkeiten). Mit Google Takeout ist es sogar möglich, dass man den eigenen kompletten YouTube-Kanal mit einem Arbeitsschritt exportiert und zum Beispiel direkt in der eigenen Dropbox speichert.

Google Takeout Export-Typen

Zudem gibt es zwei verschiedene Export-Typen: Einmaliges Archiv oder mehrere geplante Exporte. Bei den geplanten Exporten wird ein Jahr lang alle zwei Monate automatisch ein Archiv Ihrer ausgewählten Daten erstellt und beispielsweise direkt in Ihre Dropbox gespeichert (je nachdem welches Medium Sie zur Sicherung gewählt haben). Das erste Archiv wird sofort erstellt. Wahlweise kann man auch noch zwischen den Export-Dateitypen ZIP- und TGZ-Dateien wählen.

YouTube-Kanal vorübergehend ausblenden oder endgültig löschen

Sie haben bei YouTube die Möglichkeit, Videos auf Ihrem eigenen Kanal vorübergehend auszublenden oder den Kanal komplett und endgültig zu löschen. Sie können Videos am eigenen YouTube-Kanal sehr einfach ausblenden und später ebenso leicht wieder einblenden. Wenn Sie Ihren Kanal ausblenden, erhalten Ihr Kanalname sowie Videos, Likes, Abos und Abonnenten den Status „Privat“. Außerdem sind die Aufrufzahlen möglicherweise fehlerhaft. Nachdem Sie Ihren Kanal wieder aktiviert haben, kann es bis zu einer Woche dauern, bis die Werte aktualisiert werden.

Vorübergehend ausgeblendeten YouTube-Kanal wieder einblenden

Wenn Sie einen ausgeblendeten YouTube-Kanal wieder einblenden – also für alle sichtbar machen – wollen, dann können Sie dies mit Hilfe dieser Beschreibung tun.

YouTube-Kanal endgültig löschen

Durch das Löschen eines YouTube-Kanals werden alle Inhalte des Kanals endgültig und unwiderruflich entfernt. Dies schließt alle Videos, Kommentare, Nachrichten, Playlists und den gesamten Verlauf des Kanals ein. Aktuell (Stand: August 2026) können YouTube-Kanäle nicht über Mobilgeräte gelöscht werden. Der Grund liegt in der Unübersichtlichkeit und damit verbundenen höheren Fehlerquote bei der Bedienung von Smartphones (zB Vertippen, was zum unabsichtlichen Löschen führen könnte). Nachdem ein YouTube-Kanal gelöscht worden ist, werden die Kanal-URL und der Kanalname nicht mehr in YouTube Analytics angezeigt und man kann auch nicht mehr danach suchen. Mit dem Kanal verknüpfte Daten, wie zB die Wiedergabezeit, werden weiterhin in den zusammengefassten Berichten aufgeführt, allerdings nicht dem gelöschten Kanal zugeordnet.

The post Google Takeout: YouTube Video sichern mit der Google Datensicherung first appeared on Markus Steinacher.

WordPress-Problematik mit Elementor Google Maps Widget und der DSGVO

Markus Steinacher — Fri, 21 Aug 2026 10:45:56 +0000

Alle Website-Betreiber die schon einmal in den Genuss von DSGVO-relevanten Cookies gekommen sind, wissen wahrscheinlich nur zu gut, dass diese Art von Cookies nicht besonders gut schmecken. Speziell bei der Verwendung von Drittanbieter-Widgets kann es damit zu technischen Reibungspunkten kommen, die man zu Beginn oftmals noch nicht am Radar hatte. Dieses Beispiel ist wieder einmal ein Beleg dafür, dass Widgets und Anwendungen von Drittanbietern zu technischen Problemen führen können, und dass es klug sein kann, nicht auf Applikationen von Drittanbietern zurück zu greifen. In diesem Beispiel geht es um den mächtigen WordPress Elementor Editor, der eine Vielzahl von Widgets (beziehungsweise Elementen) anbietet und damit quasi auch als Drittanbieter-Zwischenstelle fungiert. Im Konkreten geht es in diesem Beitrag um das Google Maps Widget des Elementors. Hier möchte ich aus Datenschutzgründen davor warnen dieses Widget zu verwenden. Warum ich davor warnen will und welche Alternative man hat, das erkläre ich in diesem kurzen Beitrag.

Warum die Verwendung des Elementor Google Maps Widgets nicht DSGVO-konform ist

Gleich vorweg: In diesem Beitrag geht es mir um das kostenfreie Standard-Google Maps Widget des Elementors (Stand: August 2026), nicht um eine Erweiterung eines anderen Entwicklers. Das native Elementor Google Maps Widget bietet keine integrierte Möglichkeit, die Google-Maps-Darstellung bis zur Zustimmung des Website-Besuchers zu unterbinden. Dadurch kann es in Kombination mit einem Consentmanagement-System zu technischen Problemen kommen, wenn die Einbindung nicht zuverlässig vor dem Consent blockiert werden kann.

Grundsätzlich können Google Maps-Landkarten nicht ohne Weiteres DSGVO-konform in Websites eingebunden werden

Eine eingebundene Google Maps-Landkarte kann datenschutzrechtlich relevant sein, weil bereits beim Laden der Karte personenbezogene Daten an Google übertragen und Google-Technologien bzw. Cookies eingesetzt werden können. Deshalb muss die konkrete Einbindung datenschutzrechtlich und technisch entsprechend umgesetzt werden. Daher sollte die Verwendung für Website-Besucher über ein Consentmanagement-System abgewickelt werden können. Mit WPConsent beispielsweise kann man in der kostenfreien Variante bereits die technsichen Anforderungen für die DSGVO-konforme Verwendung von Google Maps auf der Website gewährleisten.

Google Maps Cookies werden beim Erscheinen der Landkarte geladen

Google Maps ladet zum Beispiel Cookies wie OGP (dieses Cookie wird von Google verwendet, um die Google-Maps-Funktionalität zu aktivieren und nachzuverfolgen) und OGPC (Nutzereinstellungen und Informationen werden gespeichert, während Seiten mit Google Maps aufgerufen werden). Die Website sollte über das Consentmanagement-System in der Lage sein, dass die Google Maps-Landkarte erst geladen wird, wenn der jeweilige Website-Besucher vor dem Laden / Erscheinen der Google Map informiert wird und die Verwendung der Cookies mit einem Klick bestätigt.

Das technische Problem mit dem Elementor Google Maps Widget

Eigentlich sollte es über das Consentmanagement-System kein Problem damit geben das Laden der Google Map (und der Cookies) solange zu verhindern, bis der Website-Besucher seine Zustimmung erteilt. Allerdings verhindert Elementor, beziehungsweise das Elementor Google Maps Widget, dass das Consentmanagement-System der Website diese technische Anforderung umsetzen kann.

Mit anderen Worten: Nach aktuellem Wissensstand (August 2026) ist es technisch nicht möglich, dass man mit dem eigenen Consentmanagement-System das Laden von Google Maps Cookies, die mit dem Elementor Google Maps Widget integriert worden sind, verhindern kann bevor der Website-Besucher die Chance hat, dies auf seinem Endgerät zu verhindern.

Die Lösung und Alternative zum Elementor Google Maps Widget

Die Lösung ist ganz einfach: Wenn man die gewünschte Google Map-Landkarte (den iframe-Code der gewünschten Landkarte) einfach mit dem Elementor HTML-Element einbaut (anstelle des Google Map Widgets), dann lässt sich das Google Maps-iframe ganz sauber und DSGVO-konform über das Consentmanagement-System abwickeln.

Mein Fazit

Aus technischer und datenschutzpraktischer Sicht würde ich das native Elementor Google Maps Widget nicht empfehlen, wenn eine zuverlässige Consent-gesteuerte Blockierung der Google-Maps-Einbindung erforderlich ist. Stattdessen ist ein kontrollierbarer iframe über das Elementor HTML Widget die transparentere und besser steuerbare Lösung.

Weitere Fragen zum Elementor?

Wenn Sie Fragen zu einem speziellen WordPress- oder Elementor-Thema haben, dann stehe ich Ihnen gerne beratend zur Verfügung. Senden Sie mir bitte einfach Ihre unverbindliche Anfrage.

The post WordPress-Problematik mit Elementor Google Maps Widget und der DSGVO first appeared on Markus Steinacher.

Google Pagespeed: der Website Speed Test

Markus Steinacher — Mon, 17 Aug 2026 16:42:52 +0000

Mit dem Onlinedienst Google PageSpeed Insights kann man die Ladezeit einer Website untersuchen und Aufgrund der Speed Test-Empfehlungen Optimierungen an der Website vornehmen die dafür sorgen, dass die Website durch schnellere Ladezeiten eine höhere Usability (Gebrauchstauglichkeit oder Benutzerfreundlichkeit) erfährt. Dabei ist die Usability nicht mit der User Experience zu verwechseln. Während es sich bei der Usability rein um die funktionale Bedienbarkeit und Mechanik handelt, beschäftigt sich die User Experience mit den Gefühlen und Erlebnissen vor, während und nach der Nutzung einer Website. Im Falle des Page Speeds sind beide Begriffe von Relevanz, da sich lange Ladezeiten natürlich auch auf die User Experience negativ auswirken.

Über die Core Web Vitals-Bewertung

Die Core Web Vitals-Bewertung in Google PageSpeed Insights ist sinnvoll, aber man sollte sie nicht mit dem PageSpeed-Score von 0-100 verwechseln. Für die Beurteilung einer Website ist die eigentliche Aussagekraft der realen Nutzerdaten deutlich höher als die Frage, ob Google Lighthouse gerade 87 oder 96 Punkte ausgibt.

Was wird bei den Core Web Vitals eigentlich bewertet?

Aktuell sind es drei Kennzahlen, die hier besondere Aufmerksamkeit verdienen (siehe auch die Abbildung):

LCP (Largest Contentful Paint): Wie schnell der wesentliche Inhalt der Seite sichtbar wird. „Gut“ ist ≤ 2,5 Sekunden.
INP (Interaction to Next Paint): Wie schnell die Seite auf Benutzerinteraktionen reagiert. „Gut“ ist ≤ 200 ms.
CLS (Cumulative Layout Shift): Wie stark sich Inhalte während des Ladens unerwartet verschieben. „Gut“ ist ≤ 0,1.

Das sind durchaus vernünftige Messwerte, weil sie nicht einfach technische Eigenschaften eines Servers messen, sondern Aspekte, die ein Besucher tatsächlich erlebt. Und hier liegt eine der größten Stärken von Google PageSpeed Insights. Das Tool zeigt neben den Lighthouse-Labordaten auch Felddaten aus dem Chrome User Experience Report (CrUX). Diese stammen von echten Nutzern und unterschiedlichen Geräten, Netzwerken und Nutzungssituationen. Betrachtet wird dabei stets ein Zeitraum von 28 Tagen.

Dieser Page Speed Test greift somit auf Nutzungswerten einer möglichst breiten Bevölkerungsschicht zu. Eine Website kann auf einem leistungsfähigen Desktop-PC hervorragend funktionieren und bei eigenen Tests einen PageSpeed-Score von 98 erreichen – während ein erheblicher Teil der mobilen Besucher trotzdem eine schlechte Erfahrung hat. Dem soll mit den Felddaten aus dem Chrome User Experience Report entgegen gewirkt werden. Die CrUX-Daten können genau diesen Unterschied sichtbar machen.

Besonders interessant ist dabei das 75. Perzentil. Vereinfacht gesagt bedeutet das, dass Google nicht nur wissen will, wie schnell die Websites bei den schnellsten Nutzern läuft, sondern ob die Website auch unter weniger günstigen Bedingungen für die große Mehrheit akzeptabel funktioniert.

Wie wichtig ist dieser Website Speed Test für SEO?

Die Geschwindigkeit einer Website ist für SEO durchaus wichtig, aber deutlich weniger wichtig, als es manche SEO-Darstellungen suggerieren. Google bestätigt durchaus, dass Core Web Vitals von seinen Rankingsystemen verwendet werden. Gleichzeitig teilt Google ebenso mit, dass gute Core Web Vitals keine Garantie für gute Rankings sind. Es gibt kein einzelnes „Page Experience“-Ranking-Signal, das aus einem PageSpeed-Wert besteht.

Meiner Meinung nach stellt Google die Relevanz und Qualität nicht hinter einen technischen Performance-Score. Core Web Vitals können demnach eher als eine Art von Qualitätsfaktor innerhalb eines wesentlich größeren Ranking-Systems verstanden werden.

Nicht für Google auf 100 Punkte optimieren sondern für die Nutzer auf gute Core Web Vitals optimieren

Wenn die realen Felddaten bei LCP, INP und CLS grün sind, würde ich eine Website normalerweise nicht weiter optimieren, nur um einen höheren Lighthouse-Score zu erreichen. Wenn die Felddaten schlecht sind, sind die Core Web Vitals dagegen ein sehr guter Hinweis darauf, dass es ein echtes UX-Problem gibt – und damit lohnt sich die technische Optimierung unabhängig von SEO.

Google behauptet immerhin auch selbst inzwischen ausdrücklich, dass man keinen perfekten Wert nur aus SEO-Gründen anstreben sollte, wenn andere Verbesserungen für Nutzer wichtiger sind.

Häufige Fragen zu Google Pagespeed Insights

Was bedeutet LCP (Largest Contentful Paint)?

WordPress-Sicherheit: Tipps, um WordPress sicher zu machen

Markus Steinacher — Thu, 13 Aug 2026 05:41:43 +0000

Mit der zunehmenden Bedeutung der Sicherheit im Internet wächst auch der Sicherheitsbedarf für Websites, Onlineshops und Firmennetzwerke. Eine WordPress-Website kann kompromittiert werden, ohne dass der Betreiber dies unmittelbar bemerkt – und die Folgen können erheblich sein. Die technischen Möglichkeiten für die illegale Ausnutzung des Internets sind äußerst mannigfaltig, die Kreativität von Hackern scheinbar grenzenlos. Und unser Rechtssystem? Die internationale und technisch komplexe Natur vieler Cybercrime-Fälle stellt auch die Strafverfolgungsbehörden vor erhebliche Herausforderungen. Die Aufklärungsquote bei Cybercrime-Straftaten ist in Österreich vergleichsweise niedrig. Im Jahr 2024 lag sie bei 31,7 Prozent – damit wurde nur etwa ein Drittel der angezeigten Fälle aufgeklärt.

WordPress-Websites sind für Angreifer aus verschiedenen Gründen interessant

Typische Unternehmens-Websites sind als Ziel gezielter Erpressungsangriffe häufig weniger lukrativ als beispielsweise große Onlineshops oder Systeme mit besonders wertvollen Daten. Dennoch sind WordPress-Websites aus verschiedenen Gründen ein interessantes Ziel für Angreifer und können – oftmals im Verborgenen – mit Malware oder anderem Schadcode kompromittiert werden. Website-Betreiber merken oft gar nicht, dass ihre Website kompromittiert worden ist.

Es kann beispielsweise vorkommen, dass ohne offensichtlichen Grund plötzlich neue WordPress-Benutzer mit Administrator-Berechtigung im Backend erscheinen. Diese Benutzer könnten beispielsweise neuen Content auf der Website veröffentlichen, und unberechtigterweise Backlinks erstellen. Es könnten auch Benutzerdaten von WooCommerce-Onlineshop-Kunden ausgelesen (exportiert) werden. Oder es könnte der unbefugte und geheime Zugriff auf eine WordPress-Website dazu führen, dass jemand unter dem Deckmantel des Urheberrechts und Datenschutzes gewisse Ansprüche an den Websitebetreiber rechtlich geltend macht.

Dies soll nur verdeutlichen, was passieren kann, wenn die Sicherheit Ihrer WordPress-Website nicht ausreichend gewährleistet ist. WordPress ist als Open-Source-CMS öffentlich einsehbar und wird von einer großen Entwickler- und Community-Basis weiterentwickelt. Wie bei jeder komplexen Software können dabei Sicherheitslücken entdeckt werden. Entscheidend ist daher, dass bekannt gewordene Schwachstellen zeitnah behoben und Sicherheitsupdates installiert werden. Die starke WordPress-Community ist stets bemüht, neue Sicherheitslücken so rasch wie möglich zu schließen, daher gibt es so viele Sicherheits-Updates, immer wieder in sehr dicht aufeinanderfolgenden Zeitabständen.

Beispiel für Missbrauchsszenario einer WordPress Website die über zu wenig Sicherheit verfügt

Nehmen wir an, dass ein kleines Unternehmen eine relativ einfache WordPress-Website als Unternehmenswebsite betreibt. Diese WordPress-Website verfügt über keine technischen Maßnahmen um Malware- oder gewisse Angriffe von außen verhindern oder zumindest erkennen zu können. Dieses fiktive Szenario beschreibt nun den Fall, dass sich jemand von außen Zugriff auf das Backend der Website verschafft und sich ein Benutzerkonto mit Administratorrechten anlegt.

Wie eine kompromittierte WordPress-Website missbraucht werden kann

Nun könnte diese Person eine urheberrechtlich geschützte Bilddatei (ein digitales Foto) in der WordPress-Mediathek hochladen und dieses Foto öffentlich in einem Blog-Beitrag auf der Website veröffentlichen. Der Blogbeitrag könnte so platziert werden, dass er nicht gleich in den Archivseiten oben erscheint. So könnte dieser Blogartikel möglichst unerkannt bleiben. Ein Angreifer mit entsprechenden Berechtigungen kann nachträglich Inhalte verändern oder hinzufügen und dadurch die Rekonstruktion des tatsächlichen Geschehens erschweren.

Dieses Beispiel zeigt, wie eine kompromittierte WordPress-Website zur Manipulation von Inhalten und damit zur Erschwerung der späteren Rekonstruktion eines Sachverhalts missbraucht werden kann. Beispielsweise könnten Logfiles am Webserver wichtige Hinweise bei der Nachverfolgung und Rekonstruktion eines solchen Vorgehens liefern. Auch die vorhandenen Logdaten sind jedoch nicht immer ausreichend, um einen Angriff nachträglich eindeutig zu rekonstruieren. Welche Informationen protokolliert und wie lange sie gespeichert werden, hängt unter anderem von der technischen Konfiguration, dem Hosting und den geltenden datenschutzrechtlichen Rahmenbedingungen ab.

In diesem fiktiven Beispiel wäre es demnach möglich, dass sich der Täter oder ein Komplize als vermeintlicher Urheber des auf der Website veröffentlichten Fotos ausgibt und einen unverhältnismäßig hohen Schadensersatz für die Verletzung seines Urheberrechts einfordert. Aus Unsicherheit und Angst vor rechtlichen Konsequenzen sind die Opfer (Website-Betreiber) oftmals bereit den Geldforderungen nachzukommen – insbesondere dann, wenn das nötige Fachwissen für eigene Nachforschungen fehlt, oder zu wenige Daten für die Nachforschung vorhanden sind (Stichwort: Logfiles am Server).

Der Angreifer einer WordPress-Website muss nicht zwingend ins Backend

Eine mögliche Kompromittierung der WordPress-Website muss nicht zwingend über das WordPress-Backend, beziehungsweise über einen gestohlenen Administrator-Account erfolgen. Ein Angreifer kann sich beispielsweise auch über einen kompromittierten oder unzureichend abgesicherten Serverzugang Zugriff (zB via SSH) auf das System verschaffen. Mögliche Angriffsvektoren können beispielsweise sein:

veraltete WordPress-Version
verwundbare Plugins
verwundbare Themes
kompromittierte Zugangsdaten
unsichere Hosting-/Serverkonfiguration
Schwachstellen in individuell entwickeltem Code
fehlende Zugriffsbeschränkungen
kompromittierte Drittanbieter-Dienste

Fazit: WordPress-Sicherheit ist viel mehr als nur ein starkes Administrator-Passwort.

10 Sicherheitstipps um die eigene WordPress Website möglichst sicher zu machen

WordPress, Plugins und Themes konsequent aktuell halten

Bilder kostenfrei online in WebP und AVIF-Format konvertieren um diese auf Websites zu verwenden

Markus Steinacher — Tue, 11 Aug 2026 08:48:26 +0000

In diesem Beitrag wird erklärt wie man Bilder (zum Beispiel in den Formaten .jpg oder .png) kostenfrei und online im Browser (ohne Verpflichtung und etwas installieren zu müssen) in das WebP und AVIF-Format konvertieren lassen kann, um diese Bilder im Anschluss beispielsweise auf der eigenen Website – sozusagen ladezeitoptimiert – zu verwenden. Es gibt natürlich auch Möglichkeiten mit Photoshop und ähnlichen Programmen, allerdings wäre das nicht kostenfrei.

Zusätzlich beschäftigt sich dieser Artikel mit der Frage, welches der beiden Bildformate die bessere Wahl ist. Dies Frage ist nicht so einfach pauschal zu beantworten, jedoch allgemein gilt: Das AVIF-Bildformat bietet häufig die bessere Kompression, WebP punktet jedoch mit breiter Unterstützung und einem unkomplizierten Workflow. Welches Format sinnvoller ist, hängt vom konkreten Einsatz und der technischen Umgebung ab.

Bilder online kostenfrei in WebP und AVIF konvertieren

Eine Möglichkeit besteht darin, eigene Bilder online und kostenfrei in das WebP-Format oder in das AVIF-Format konvertieren zu lassen, in dem man dies über die Website squoosh.app macht. Der einzige Nachteil daran ist, dass man nur einzelne Bilder in einem Arbeitsschritt konvertieren lassen kann. Es ist demnach nicht möglich, gleich mehrere Bilder in einem Vorgang zu konvertieren. Zudem wird das Konvertieren direkt über den Browser ausgeführt. Die Konvertierung erfolgt also direkt im Browser und auf dem eigenen Gerät. Das Ausgangsbild muss daher für die Konvertierung nicht auf einen externen Server hochgeladen werden.

Man kann damit also nicht bereits auf der eigenen Website hochgeladene Bilder (zum Beispiel in WordPress oder ähnlichen CMS-Systemen) konvertieren. Insofern zahlt sich diese Variante eigentlich nur für alle neuen Bilder aus, die zuvor noch nicht online hochgeladen worden sind. Die beste Arbeitsweise wäre dann:

Eigenes JPG- / PNG-Bild in squoosh.app hochladen
Das Bild in gewünschtes Format konvertieren und lokal speichern
Das neue WebP- / AVIF-Bild in WordPress hochladen und verwenden

Die Dateigrößen beziehen sich auf dieses konkrete Beispielbild und können je nach Motiv, Bildgröße und Qualitätseinstellungen deutlich abweichen.

WebP und AVIF bei der Anwendung für Websites im Vergleich

Wie man hier in diesem Beitrag sieht, kann WordPress grundsätzlich mit diesen beiden Bildformaten (WebP und AVIF) umgehen. Wie gut WordPress mit WebP und AVIF umgehen kann, hängt neben der WordPress-Version auch von der verwendeten Bildverarbeitung und der Konfiguration des Hostings ab. Folgende Fragen sind an dieser Stelle zu stellen:

Kann WordPress das Format beim Upload akzeptieren?
Kann WordPress daraus die benötigten Bildgrößen/Thumbnails erzeugen?
Unterstützt die verwendete Bildbibliothek (z. B. Imagick/GD) das Format?
Kann der Server das Bild korrekt ausliefern?
Unterstützt der Browser des Besuchers das Format?

Wenn man mit diesen Fragen und dessen Antworten nichts anzufangen weiß, dann sollte man auf jeden Fall vor dem ersten Upload vorsichtig sein.

Achtung bei Bildupload-Problemen in WordPress

Ist die Website und / oder der Server nicht richtig aufgesetzt, kann es unter Umständen bei einem versuchten Bilderupload in WordPress selbst zu einem Error (Fehlermeldung) kommen und eventuell dadurch Upload- oder Verarbeitungsfehler verursachen. Die Ursachen und Möglichkeiten eines Errors können vielfältig sein, daher ist es empfehlenswert, dass man vor dem ersten Bilderupload ein Backup macht, auf welches man im Notfall zurückgreifen kann. Insbesondere wenn man ein Bild im AVIF-Format hochladen will, sollte man zunächst vorsichtig damit umgehen, da es zB im Jahr 2026 noch durchaus der Fall sein kann, dass einige Server noch nicht so ganz gut damit umgehen können. Der Vorteil des WebP-Formates dahingehend ist, dass WebP durchaus (Stand: Jahr 2026) weit verbreiteter ist als das AVIF-Format.

Wenn man demnach das WebP-Format mit dem AVIF-Format vergleichen will, dann ist meine Empfehlung aus dem Jahr 2026 das WebP-Format, da eine weit verbreitete Nutzung in vielen Systemen bereits ohne Probleme erfolgen kann. Damit entscheidet man sich für die derzeit unkompliziertere und breiter unterstützte Variante.

Ich möchte an dieser Stelle ausdrücklich darauf hinweisen, dass ich das AVIF-Bildformat nicht als besonders gefährliches Upload-Format darstellen will, sondern aufzeigen, dass Website-Betreiber ohne spezifisches Fachwissen mit dieser Information gewisse technische Probleme vermeiden können.

WordPress-Support bei technischen Problemen mit dem Bilderupload

Wenn Sie Fragen zu diesem speziellen Thema haben, oder Support benötigen, dann stehe ich Ihnen gerne zur Verfügung. Senden Sie mir bitte einfach Ihre unverbindliche Anfrage.

Bilder für Ihre Website mit WebP optimieren und Ladezeit verbessern

Da ich grundsätzlich nach wie vor der Einfachheit halber (im Jahr 2026) „noch“ das WebP-Bildformat bevorzugt für Websites benutze, habe ich nur zum Thema „Bilder für Ihre Website optimieren und Ladezeit verbessern“ einen interessanten Fachartikel geschrieben. In diesem Artikel wird beschrieben, wie speziell das WebP-Format auf Websites am besten zum Einsatz kommen kann. Doch nun kommen wir zum interessanten Teil dieses Fachartikels, der die Unterschiede zwischen dem WebP-Bildformat und dem AVIF-Bildformat aufzeigt.

WebP und AVIF im Vergleich

Der offensichtlichste Unterschied zwischen diesen beiden modernen Bildformaten ist die Komprimierung und damit verbundene Dateigröße. Wenn man augenscheinlich zwei völlig identische Bilder (gleiche Abmessungen, gleiches Motiv, …), die eigentlich nur den Unterschied haben, dass das eine Bild im WebP-Format ist, und das andere Bild aus dem AVIF-Format besteht, dann wird man bei der Dateigröße feststellen, dass das AVIF-Bild höchstwahrscheinlich viel kleiner ist (also Ladezeit spart, wenn man dieses Bild auf einer Website verwendet), als das WebP-Bild. Das WebP-Bild ist in Bezug auf die Dateigröße schon viel kleiner als ein „gleichwertiges“ JPG-Bild / PNG-Bild, aber das AVIF-Bild ist nochmals um ein deutliches Stück kleiner. Dieser Punkt geht im Direktvergleich eindeutig an das AVIF-Bildformat, wobei die tatsächliche Dateigröße unter anderem abhängt von:

Bildmotiv
Auflösung
Farbraum
Transparenz
Qualitätsparameter
Encoder
verwendeten Einstellungen

Die Dateigröße allein ist nicht unbedingt ein sinnvoller Qualitätsvergleich, auch wenn es sich primär um schnelle Ladezeiten auf Websites handelt. Wenn man eine möglichst allgemein gültige Antwort haben will, dann könnte diese so lauten: „Bei vergleichbarer visueller Qualität kann AVIF häufig eine kleinere Datei erzeugen. Die tatsächlich erzielbare Einsparung hängt jedoch stark vom Bild und den Encoder-Einstellungen ab.“

WebP und AVIF für Website-Optimierung: Das Bildformat allein macht noch keine optimale Website

Die Wahl des richtigen Bildformats ist nur ein Teil der Bildoptimierung. Auch ein modernes AVIF-Bild kann unnötig groß sein, wenn beispielsweise die Bildabmessungen nicht zum tatsächlichen Darstellungsbereich passen. Für eine gute Performance sollten Bilder daher in der passenden Auflösung bereitgestellt und über responsive Techniken je nach Bildschirmgröße passend ausgeliefert werden.

Zusätzlich spielen eine sinnvolle Kompression und Qualitätsstufe eine wichtige Rolle. Bilder, die erst weiter unten auf der Seite erscheinen, können per Lazy Loading verzögert geladen werden. Bei besonders wichtigen Bildern im sichtbaren Bereich – insbesondere beim Largest Contentful Paint (LCP) – sollte hingegen darauf geachtet werden, dass sie möglichst schnell geladen werden. Je nach Website können außerdem CDN und Caching die Ladezeiten weiter verbessern.

Wer unterschiedliche Bildformate wie WebP und AVIF parallel anbieten möchte, kann dafür beispielsweise das HTML-Element verwenden. Entscheidend ist also nicht nur die Frage „WebP oder AVIF?“, sondern das Zusammenspiel aus Bildgröße, Abmessungen, Qualität, Auslieferung und Ladeverhalten. Ein 3-MB-Foto bleibt schließlich auch als AVIF ein unnötig großes Bild.

Häufige Fragen zu Bildformaten für Websites

Wann und warum sollte ich WebP statt AVIF verwenden?

WordPress feiert heute seinen 23. Geburtstag – Happy Birthday WordPress!

Markus Steinacher — Wed, 27 May 2026 09:27:02 +0000

Heute, am 27. Mai 2026, feiert das weltweit bekannteste Open Source CMS WordPress seinen Geburtstag. An diesem Datum erschien im Jahr 2003 die erste öffentliche Version von WordPress. Damit wird WordPress heute bereits 23 Jahre alt – Happy Birthday WordPress!

Wie alles mit WordPress im Jahr 2003 begonnen hat

Wenn man sich erinnert, wie das Internet im Jahr 2003 aussah, wirkt das aus heutiger Sicht fast unwirklich. Damals waren persönliche Websites oft bloß statische HTML-Dateien. Blogs galten als etwas für technikbegeisterte Freaks und sogenannte Nerds, und Inhalte ins Netz zu stellen bedeutete häufig: Dateien per FTP-Servertransfer hochzuladen, Menüs per Hardcoding zu ändern und zu hoffen, nichts dabei kaputt zu machen. In diese Welt wurde WordPress quasi hinein geboren, ursprünglich gar nicht mit dem Anspruch, das Internet zu verändern, sondern schlichtweg als bessere Blog-Software mit damals neuartigem Ansatz. WordPress entstand aus einem bestehenden Open-Source-Projekt namens b2/cafelog (siehe auch b2evolution) und wurde von Matt Mullenweg und Mike Little weiterentwickelt.

Das Open Source WordPress-Konzept begeisterte die Welt

Interessant daran ist, dass WordPress nie nur einfach ein Programm war. Es hat sich zu einer Art Infrastruktur des Internets entwickelt und international etabliert. Ein Hauptgrund dafür war die Benutzerfreundlichkeit und die starke Community dahinter. Millionen Menschen haben ihre ersten Texte, Fotos, Unternehmensseiten, und sogar Onlineshops damit veröffentlicht. Für viele war WordPress nicht einfach ein Werkzeug, sondern fast schon der Moment, in dem das Internet vom Anschauen zum Mitmachen wurde. WordPress lud richtiggehend zum Mitgestalten ein, und das tut es auch heute noch in gewisser Art und Weise.

WordPress ist nach wie vor Open Source

Eine der bemerkenswertesten Entscheidungen war, WordPress als Open Source zu belassen. Das bedeutete: Jeder durfte den Code ansehen, verändern, erweitern und entsprechend weitergeben. Daraus entstand eine weltweite Community aus Entwicklern, Designern, Übersetzern, Bloggern und Agenturen, die tagtäglich mit und an WordPress arbeiten. Heute erscheinen neue Funktionen nicht nur aus einem Unternehmen heraus, sondern oft aus tausenden kleinen Beiträgen von Menschen auf der ganzen Welt.

Zu einem Teil gehört auch meine Arbeit zum Erhalt und Fortbestand von WordPress, da ich mich bei der Entwicklung meiner Webprojekte an gewisse Standards halte und versuche, das Optimum aus WordPress dabei herauszuholen. Und ich stelle viele meiner persönlichen Expertisen und Erfahrungen rund um WordPress hier auf meiner Website kostenfrei für die Allgemeinheit zur Verfügung. Das ist meiner Meinung nach gelebter Open Source Community-Spirit, den ich bei WordPress immer wieder verspüre. Daher funktioniert das Konzept nach wie vor gut.

Und obwohl WordPress in der Gegenwart oft mit großen Themen wie Block-Editoren, Headless-Architekturen (APIs, Schnittstellen, .. ) oder anderen externen Plattformen verbunden wird, steckt noch immer dieselbe Idee dahinter wie ursprünglich im Jahr 2003: Menschen sollen ohne große Hürden Websites erstellen und Blogbeiträge veröffentlichen können. Die Welt des Internets hat sich in den vergangenen 20 Jahren extrem verändert und WordPress ist diesen Weg mitgegangen, ohne dabei seine Wurzeln ganz zu vergessen – Chapeau!

Es gibt zudem eine schöne Ironie dazu

Viele neue / moderne Plattformen, die heute als „die Zukunft des Webs“ gelten, verfolgen eigentlich letztlich nur etwas, das WordPress schon viel früher populär gemacht hat: Inhalte möglichst ohne technische Barrieren ins Internet zu bringen. Ein Geburtstag also nicht nur für eine Software, sondern für eine geniale Idee, die das offene Internet über mehr als zwei Jahrzehnte geprägt hat .. und hoffentlich auch weiterhin prägen wird.

Spannend finde ich auch den Aspekt, dass die meisten Menschen irgendwann einmal eine Website besucht haben, die mit WordPress gebaut wurde, ohne es zu merken. Nachrichtenportale, kleine Familienblogs, Vereinsseiten, Magazine und Unternehmens-Websites: Vieles davon läuft im Hintergrund mit der gleichen Idee, die im Jahr 2003 als reines Blogsystem begonnen hat. Und vielleicht ist das der eigentliche Erfolg von WordPress: Nicht, dass WordPress besonders laut (bekannt) geworden ist, sondern dass es für viele einfach zur Selbstverständlichkeit wurde.

Häufige Fragen zur Entstehung von WordPress

Wann wurde WordPress erstmals veröffentlicht?

WordPress 7.0 – Opcode-Cache und persistenter Objekt-Cache

Markus Steinacher — Fri, 22 May 2026 09:40:07 +0000

Seit dem neuen WordPress Update auf Version 7.0 erscheint in einigen WordPress-Installationen eine neue Fehlermeldung, bzw. eine empfohlene Verbesserung: Der Opcode-Cache ist nicht aktiviert. Nun fragen sich bestimmt einige WordPress-Seitenbetreiber, was es damit auf sich hat. Hier gibt es eine Erklärung dazu.

Beim Opcode-Cache (auch OPcache genannt) handelt es sich um nichts, was man direkt innerhalb einer WordPress-Installation aktivieren kann, sondern um etwas Server-spezifisches. Wenn Sie demnach das dringende Bedürfnis nach einem Opcode-Cache haben – warum auch immer – dann wenden Sie sich am besten an Ihren Provider und fragen, ob dieser so etwas auf seinem Server anbietet.

Ist ein Opcode-Cache für den Betrieb einer WordPress-Website notwendig?

Nein, ein Opcode-Cache ist nicht zwingend erforderlich, damit Ihre Website gut funktioniert. Aber es ist natürlich hinsichtlich der Website-Performance durchaus vorteilhaft, wenn der Server einen OPcache verwendet, da PHP-Code nicht bei jedem Seitenaufruf neu übersetzt werden muss. Das reduziert insbesondere bei einem System wie WordPress die Serverlast, speziell wenn viel Traffic auf der Website gleichzeitig passiert.

Ab WordPress 7.0 können folgende Verbesserungen angezeigt werden

Bereits lange vor WordPress 7.0 wurde der persistente Objekt-Cache empfohlen. Nun folgt zusätzlich der Opcode-Cache. Dies zeigt deutlich, wie sehr WordPress-Entwickler bemüht sind, WordPress hinsichtlich Performance mit Hilfe von serverseitigen Ressourcen zu pushen:

Der Opcode-Cache kurz erklärt

WordPress-Websites ohne Opcode-Cache funktionieren vereinfacht so:

Server empfängt Anfrage von Website
PHP lädt die entsprechenden WordPress-Dateien
PHP parst und kompiliert den PHP-Code in sogenannten den sogenannten Opcode
PHP führt diese Opcodes aus
HTML und CSS wird an den Browser gesendet und somit die Website dargestellt

Speziell das Parsen und Kompilieren (übersetzen) im Schritt 3 kosten viel Zeit. Ohne den Opcode-Cache muss bei jedem Aufruf neu übersetzt werden.

WordPress-Websites mit Opcode-Cache funktionieren im Vergleich dazu so:

Server empfängt die erste Anfrage von Website
PHP „kompiliert“ den Code einmal
Die erzeugten Opcodes werden im Cache (Speicher) abgelegt und zur Wiederverwendung aufbewahrt
Bei weiteren Anfragen / Aufrufen nutzt PHP direkt den gespeicherten Opcode (kein erneutes Übersetzen notwendig)

Der unmittelbare Vorteil daraus:

Die aufgerufenen Seiten der WordPress-Website laden schneller
Dadurch entsteht auch eine geringere CPU-Last
.. und es sind im Bedarfsfall auch mehr gleichzeitige Besucher möglich

Noch nicht alle Provider bieten den Opcode-Cache an

Moderne und „hochwertigere“ (meistens auch teurere) Provider bieten jetzt bereits standardmäßig den Opcode-Cache an. In diesem Fall erscheint mit WordPress 7.0 keine Fehlermeldung in der Website-Zustand-Analyse. Bei gängigen österreichischen Providern, wie zum Beispiel bei World4You (dieser Provider bietet aktuell – Stand: Mai 2026 – anstelle dessen Serverseitiges Caching mit FPM an) wird der nun von WordPress propagierte OPcache (noch) nicht angeboten.

Serverseitiges Caching und PHP-FPM sind nicht dasselbe

Serverseitiges Caching, wie der Opcode-Cache, und PHP-FPM (wie es World4You standardmäßig verwendet) sind nicht dasselbe und funktionieren auch ganz unterschiedlich, wenngleich beide Varianten die Website-Performance erhöhen können.

Um es einfach zu erklären, möchte ich folgendes Beispiel nennen:

FPM ist der Teil des Servers, der WordPress (bzw. PHP) ausführt. Wenn jemand eine WordPress-Website besucht, nimmt FPM die Anfrage an und lässt den PHP-Code ausführen. Serverseitiges Caching versucht dagegen, diese Arbeit zu vermeiden und damit Ressourcen zu sparen. Der Cache merkt sich bereits erzeugte Ergebnisse und liefert sie ohne erneute Kompilierung aus. Wenn sich die zu ladende Webseite bereits im serverseitigen Cache befindet, muss FPM oft nichts mehr tun. Wenn sich allerdings nichts im Cache befindet (oder es keinen Cache gibt), übernimmt FPM die volle Arbeit und erzeugt die Seite immer wieder komplett neu.

Was den persistenten Objekt-Cache betrifft, so habe ich darüber bereits berichtet: Objekt-Caching bei WordPress-Websites. Dies ist meiner Meinung nach nur bei den wenigsten WordPress-Websites sinnvoll und wirklich empfehlenswert.

Fazit aus dieser Erkenntnis

Ja, die WordPress-Website funktioniert ohne Opcode-Cache durchaus – und auch schnell, wenn sie richtig aufgesetzt ist (es gibt tolle Möglichkeiten, mehr dazu hier: WordPress Caching für bessere Performance) – aber es könnte natürlich mit dem richtigen serverseitigen Caching auch noch besser gehen. Dabei ist es wichtig zu beachten, dass man sich nicht auf das schnellste Hosting und den besten Provider (und einen Opcode-Cache) verlässt, sondern am besten dafür sorgt, dass die eigene WordPress-Website solide erstellt ist. Die Performance einer Website lässt sich am besten durch die richtigen Bildformate, möglichst kleine Dateien, die Wahl der richtigen Plugins und der Struktur steuern. Erst wenn diese Hausaufgaben erfüllt sind, sollte man sich über den Opcode-Cache seine Gedanken machen.

Fachliche Hilfe mit WordPress Caching benötigt?

Wenn Sie Fragen zu diesem speziellen Thema haben, dann stehe ich Ihnen gerne beratend zur Verfügung. Senden Sie mir bitte einfach Ihre unverbindliche Anfrage.

The post WordPress 7.0 – Opcode-Cache und persistenter Objekt-Cache first appeared on Markus Steinacher.

WordPress Barrierefreiheit: Elementor Ally – Benutzerfreundlichkeit mit dem Elementor

Markus Steinacher — Fri, 17 Apr 2026 09:34:21 +0000

Ich habe in meinem Blog in der Vergangenheit schon mehrmals über die Barrierefreiheit im Internet berichtet, wie zum Beispiel auch über die Möglichkeiten einer barrierefreien Navigation via Tabindex und WAI-ARIA. Die Erleichterungen für Kleinstunternehmen laut Barrierefreiheitsgesetz räumen den EPUs zwar ein, nicht alle Anforderungen daran erfüllen zu müssen, aber es gibt dennoch Leitlinien für Kleinstunternehmen zur Anwendung des Barrierefreiheitsgesetzes, die beachtet werden sollten. Demnach sind Kleinstunternehmen nur im Bereich der Produkte betroffen, nicht jedoch im Bereich der Dienstleistungen. Kleinstunternehmen sind Unternehmen, die weniger als zehn Personen beschäftigen und die entweder einen Jahresumsatz von höchstens 2 Millionen Euro erzielen oder deren Jahresbilanzsumme sich auf höchstens 2 Millionen Euro beläuft. Wie dem auch sei, es schadet auf keinen Fall, wenn man sich als Webseiten-Betreiber im Sinne seiner Kundschaft und Leserschaft mit dem Thema Barrierefreiheit gewissenhaft auseinandersetzt.

Barrierefreiheit mit WordPress

Grundsätzlich hat WordPress selbst in der jüngeren Vergangenheit im Rahmen von Updates einiges hinsichtlich Barrierefreiheit vorangetrieben. Dies betrifft allerdings die Benutzung des Backends selbst und hat eigentlich weniger mit der Benutzerfreundlichkeit des Frontends für Website-Besucher zu tun. Insofern ist man als Website-Betreiber selbst dafür verantwortlich, dass man seine eigene WordPress-Website für die Besucher barrierefrei und benutzerfreundlich gestaltet. WordPress als System ansich trägt nur wenig dazu bei. Dies nur zum Verständnis.

Barrierefreiheit mit Hilfe von Elementor Ally

Der Elementor ist ein sehr weit verbreiteter und zugleich mächtiger und funktionsreicher WordPress-Editor. Allerdings hat der Elementor auch seine Schwachstellen und Stolperfallen, wie zum Beispiel hinsichtlich Performance und Ladezeit. Wir müssen uns bewusst sein, dass je mehr Funktionen und Features unsere Website zur Verfügung stellt, umso mehr kann die Ladezeit und generelle Performance der Website darunter leiden. Daher stellt sich auch bei Elementor Ally die berechtigte Frage, ob es für die eigene Website wirklich gut ist, wenn man dieses zusätzliche Plugin / Feature installiert – speziell wenn man von Gesetzes wegen dies eigentlich nicht braucht. Echte Barrierefreiheit und Benutzerfreundlichkeit auf Websites kann durch Elementor Ally nur bedingt bereit gestellt werden. Der Vorteil ist zwar, dass Elementor Ally sehr leicht zu installieren ist und auch schon in der kostenfreien Version einiges abdeckt, aber die Performance / Ladezeit der Website leidet und es werden auch Cookies damit aktiviert, die wiederum ein neues Thema öffnen: Datenschutz und Consent.

Wenn man also mit Elementor Ally die Barrierefreiheit und Benutzerfreundlichkeit auf der eigenen Website verbessern will, so muss einem bewusst sein, dass man damit folgende Aspekte akzeptiert und in Kauf nimmt:

Zusätzliche Cookies werden geladen
Ladezeit erhöht sich

Cookies durch Elementor Ally

Sobald man Elementor Ally aktiviert, werden beim nächsten Laden der Website folgende Cookies am jeweiligen Endgerät geladen. Insofern sollte man dies entsprechend in seinem eigenen Consentmanagement-System berücksichtigen. Demnach sollte ein Website-Besucher, der die barrierefreien Funktionen von Elementor Ally auf der Website nutzen will, diese Cookies zuvor via Consent bestätigen. Nur dann – nach Einwilligung (zB via Cookie-Banner) – sollte Elementor Ally erst für den Besucher zur Verfügung stehen .. so viel zur Theorie. In der Praxis ist dieser Aspekt mit diesem Plugin technisch nicht vorgesehen.

Grundsätzlich kann das als klassische Stolperfalle von Elementor betrachtet werden. Unwissende Webseiten-Betreiber verwenden solche Features, um eine vermeintlich erforderliche Anforderung zu erfüllen und eröffnen damit gleichzeitig ein anderes rechtliches Thema durch die Nutzung weiterer Cookies. Ich empfehle daher stets vorsichtig mit der Installation und Aktivierung von zusätzlichen Features zu sein.

Erhöhte Ladezeit durch Elementor Ally

Mit dem Google Pagespeed-Test habe ich meine eigene Website zweimal unter folgenden Voraussetzungen getestet:

Pagespeed-Test ohne die Verwendung von Elementor Ally
Pagespeed-Test mit der Verwendung von Elementor Ally

Hier das Ergebnis:

Es ist sehr deutlich zu sehen, dass die Website durch die Verwendung des Plugins an Leistung einbüßt. Bei meiner Website gibt es bei diesem Google-Test im Bereich „Barrierefreiheit“ überhaupt keinen Unterschied, egal ob ich Elementor Ally verwende oder nicht. Das liegt darain, dass ich von Grundauf gewisse Aspekte der Barrierefreiheit ohne zusätzliches Plugin abdecke. Insofern macht es für mich persönlich als Kleinstunternehmer (weniger als 10 Mitarbeiter und weniger als 2 Mio Jahresumsatz) keinen Sinn, dieses Plugin – und somit diese Last – in Kauf zu nehmen.

The post WordPress Barrierefreiheit: Elementor Ally – Benutzerfreundlichkeit mit dem Elementor first appeared on Markus Steinacher.