Ein Meinungsbeitrag von Christopher Perner.
Es gibt einen Moment, der sich bei uns in den letzten Jahren so oft wiederholt hat, dass er schon fast ein Ritual ist. Ein neuer Kunde sagt: "Übernimmst du unsere Website?" Wir sagen ja, bekommen die Zugangsdaten, loggen uns ein, und dann sitzt man da und schaut auf ein Dashboard, das aussieht wie ein Dachboden, den seit acht Jahren niemand mehr betreten hat.
Vierzehn Plugin-Updates offen. PHP-Version von vorgestern. Ein Cookie-Banner, das brav "Alle akzeptieren" anbietet und die Tracking-Skripte längst geladen hat, bevor überhaupt jemand geklickt hat. Kein Backup, das jemals getestet wurde. Und in einem erschreckend hohen Anteil der Fälle: eine Domain, die nicht dem Kunden gehört, sondern der Agentur, die die Seite gebaut hat.
Ich sag's, wie es ist: Ich hab' die Schnauze voll. Nicht von unseren Kunden, die können das alles nicht wissen. Sondern von einem Teil unserer Branche, der jahrelang Geld für "Betreuung" nimmt und dabei nicht einmal die Basics erledigt.
Vorweg, damit wir uns richtig verstehen
Das ist keine Abrechnung mit allen. Ich kenne in Kärnten mehrere Agenturen und Einzelkämpfer, die exzellente Arbeit machen, sauber dokumentieren, Wartung ernst nehmen und ihren Kunden Dinge auch dann sagen, wenn sie unangenehm sind. Die sind hier nicht gemeint, und sie ärgern sich über dieselben Fälle wie ich.
Und ehrlicherweise: Wir sind auch nicht heilig. Wir haben Projekte, bei denen wir das Monitoring später eingerichtet haben als wir sollten, und Seiten, bei denen ein Update länger gelegen hat als geplant. Der Unterschied liegt nicht darin, dass die einen perfekt sind und die anderen schlampig. Er liegt darin, ob man dem Kunden gegenüber offenlegt, was gerade Zustand ist, oder ob man eine monatliche Pauschale kassiert und hofft, dass niemand nachfragt.
Was ich hier beschreibe, ist auch kein Kärntner Sonderfall. Die Zahlen sind global, sie sind nur bei uns genauso schlimm, wie sie überall sind. Und weil so viele Kärntner Betriebe genau eine Website haben und die vor Jahren einmal beauftragt und dann nie wieder angeschaut haben, trifft es hier besonders viele.
Befund 1: PHP-Versionen aus einer anderen Zeit
Fangen wir mit dem an, was man von außen gar nicht sieht. Jede WordPress-Seite läuft auf PHP. Wenn diese PHP-Version keine Sicherheitsupdates mehr bekommt, ist die Seite offen wie ein Scheunentor, egal wie schön das Design ist.
Aktuell bekommen laut php.net nur die Zweige 8.2 bis 8.5 noch Sicherheitspatches, und 8.2 fällt Ende 2026 auch heraus. Alles ab 8.1 abwärts ist tot. Was man in der Praxis findet, ist etwas anderes: Eine Untersuchung von Censys aus Juli 2026 hat sich über 316.000 öffentlich sichtbare WordPress-Seiten angeschaut, bei denen die Versionen erkennbar waren. Ergebnis: Über 70 Prozent liefen auf veraltetem PHP, nur rund 30 Prozent auf einem aktuellen Patch. Die häufigste einzelne Version war PHP 7.4, mit über 20 Prozent aller Seiten. PHP 7.4 hat im November 2022 seinen letzten Patch gesehen.
Das ist fast vier Jahre ohne Sicherheitsupdates. Auf einer Seite, für die jemand monatlich zahlt.
Der Klassiker als Ausrede lautet: "Das Update bricht die Seite." Manchmal stimmt das sogar, weil irgendein uraltes Plugin oder ein selbstgebasteltes Theme-Konstrukt nicht mitkommt. Nur ist "es würde etwas kaputtgehen" kein Grund, nichts zu tun. Es ist die Diagnose. Der nächste Satz muss lauten, was es kostet, das zu reparieren, und nicht, dass man das Thema wieder ein Jahr liegen lässt.
Befund 2: Plugins, die seit Jahren keiner angeschaut hat
Die zweite Baustelle sind die Plugins. Und hier wird es unangenehm konkret.
Patchstack hat im Whitepaper "State of WordPress Security in 2026" für das Jahr 2025 insgesamt 11.334 neue Sicherheitslücken im WordPress-Ökosystem gezählt, ein Plus von 42 Prozent gegenüber dem Vorjahr. 91 Prozent davon steckten in Plugins, nur 9 Prozent in Themes, im WordPress-Kern selbst waren es sechs, alle unkritisch. 17 Prozent aller Lücken waren hochkritisch, also so gebaut, dass sie sich in automatisierten Massenangriffen ausnutzen lassen.
Der Wert, der mir am meisten zu denken gibt, ist ein anderer: Bei den am stärksten ausgenutzten Lücken lag die gewichtete Zeitspanne zwischen Veröffentlichung und erstem beobachteten Angriff bei fünf Stunden. Fünf. Etwa die Hälfte der hochkritischen Lücken wurde innerhalb von 24 Stunden angegriffen.
Fünf Stunden bedeutet: Ein Wartungsintervall von "wir schauen quartalsweise drauf" ist kein Schutz, das ist Dekoration. Und wer glaubt, das Hosting fange das schon auf, sollte den zweiten Teil der Studie lesen. Patchstack hat die Abwehr gängiger Hoster gegen WordPress-Exploits getestet: geblockt wurden 26 Prozent. Bei einem engeren Test mit bekannten, aktiv ausgenutzten Lücken waren es 12 Prozent.
Und noch ein Detail, das die Illusion vom "wir updaten halt regelmäßig" zerlegt: Bei 46 Prozent der Lücken gab es zum Zeitpunkt der Veröffentlichung noch gar keinen Patch vom Hersteller.
Wie schlecht gepatcht wird, zeigt sich schön an einem völlig unverdächtigen Beispiel. Censys hat sich in derselben Untersuchung die Yoast-SEO-Versionen angeschaut, ein Plugin, das seine Version freiwillig im Quelltext hinterlässt. Weniger als 22 Prozent der Seiten liefen auf der damals aktuellen Version. Wenn das schon bei einem gut gepflegten Standard-Plugin so aussieht, kann sich jeder ausrechnen, wie es bei dem Slider-Plugin steht, das 2019 einmal installiert wurde.
Was daraus folgt, sieht dann so aus wie die Kampagne, die Censys beschreibt: Über 900 Websites trugen im Juni 2026 die Aufschrift "Hacked by MR.GREEN", die meisten davon CMS-Installationen, überwiegend WordPress. Kein raffinierter Angriff, keine Zero-Day-Magie. Einfach offene Türen und ein Bot, der geduldig anklopft.
Befund 3: Cookie-Banner als Dekoration
Jetzt zu dem Teil, den man sieht, und der trotzdem falsch ist.
Bei einem erheblichen Teil der Seiten, die wir übernehmen, ist das Cookie-Banner ein reines Beruhigungsmittel. Zwei Varianten sind besonders beliebt. Erstens: Das Banner sieht gut aus, aber Google Analytics, Meta-Pixel und Consent-fremde Schriftarten laden schon beim Aufruf, bevor irgendwer irgendwo geklickt hat. Zweitens: Es gibt ein fettes, farbiges "Alle akzeptieren", und das Ablehnen ist ein grauer Textlink oder liegt hinter einem zweiten Klick in den "Einstellungen".
Genau die zweite Variante hat das österreichische Bundesverwaltungsgericht am 23. April 2026 in der Entscheidung zu orf.at kassiert (Geschäftszahl W171 2303402-1/7E, Aufbereitung bei dataprotect.at). Das Gericht bestätigte die Datenschutzbehörde: Wenn der Zustimmungsbutton optisch deutlich hervorsticht und die datenschutzfreundlichere Option weniger auffällig ist, lenkt das Design die Nutzer in Richtung Einwilligung, und dann ist diese Einwilligung nicht mehr sicher freiwillig im Sinne von Art. 4 Z 11 DSGVO. Farbe, Kontrast, Größe, Platzierung und Reihenfolge sind also nicht Geschmacksfrage, sondern Teil der Rechtmäßigkeit.
Das Gericht war dabei fair: Es gibt nicht den einen erlaubten Banner, Gestaltungsspielraum bleibt. Der Spielraum endet dort, wo die Nutzerführung Zustimmung faktisch bevorzugt. Und weil das Gericht die Revision an den Verwaltungsgerichtshof zugelassen hat, ist das Thema noch nicht endgültig abgeschlossen. Die Richtung ist aber ziemlich klar, und sie ist seit Jahren dieselbe.
Der Punkt, der mich hier ärgert, ist nicht die Rechtslage. Der Punkt ist, dass ein korrekt konfiguriertes Consent-Tool eine Arbeit von wenigen Stunden ist, wenn man weiß, was man tut. Es wird bloß niemandem gesagt, weil es niemand gerne aufmacht.
Befund 4: keine Firewall, kein Monitoring, kein getestetes Backup
Drei Dinge, die in jedem Wartungsvertrag stehen sollten und in den meisten übernommenen Projekten schlicht fehlen:
- Kein Schutz vor der Lücke, für die es noch keinen Patch gibt. Angesichts von 46 Prozent Lücken ohne Patch zum Zeitpunkt der Veröffentlichung ist eine anwendungsnahe Absicherung kein Luxus, sondern das, was die Zeit zwischen Bekanntwerden und Fix überbrückt.
- Kein Monitoring. Wenn niemand mitbekommt, dass die Seite eine Stunde weg war, dass plötzlich fremde Dateien im Upload-Ordner liegen oder dass Google die Domain als unsicher markiert hat, dann merkt es der Kunde als Letzter. Meist über einen Anruf eines Gasts, der eine Warnmeldung im Browser sieht.
- Kein getestetes Backup. "Wir haben ein Backup" ist keine Aussage. "Wir haben letzten Monat ein Backup zurückgespielt und es hat funktioniert" ist eine. Der Unterschied fällt genau dann auf, wenn er teuer ist.
Dazu kommt die Kategorie Kleinkram mit großen Folgen: offene xmlrpc.php, eine erreichbare wp-admin/install.php, Admin-Logins ohne Zwei-Faktor, fünf Benutzer mit Administratorrechten, von denen zwei seit 2021 nicht mehr in der Firma sind.
Befund 5: Und dann gehört auch noch die Domain der Agentur
Das ist für mich der übelste Punkt, weil er nichts mit Technik zu tun hat, sondern mit Anstand.
Bei .at-Domains ist der Domaininhaber die Person oder Firma, die im Register bei nic.at eingetragen ist. Nicht der, der zahlt, nicht der, dessen Firmenname in der Adresse steht. Der Eingetragene. Und wenn dort die Agentur steht, dann hat der Kunde nichts in der Hand.
Formal ist das reparierbar, ein Inhaberwechsel ist ein Standardvorgang, kostet laut nic.at einmalig 15 Euro exklusive Umsatzsteuer und dauert normalerweise einen bis drei Werktage. Praktisch braucht es aber die vollständigen Daten und die Unterschrift des bisherigen Inhabers. Wer zufällig genau in dem Moment wechseln will, in dem die Zusammenarbeit unschön endet, hat also ein Problem, das nicht technischer Natur ist.
Ich habe erlebt, wie das ausgeht. Ein Betrieb, der seine eigene Domain zurückwollte, hat wochenlang telefoniert. Kein Formular, keine Unterschrift, keine Reaktion. Am Ende steht dann die Wahl zwischen unangenehmen Gesprächen und einem neuen Domainnamen mit Verlust aller Verlinkungen und Suchmaschinen-Historie.
Es gibt keinen legitimen Grund, die Domain eines Kunden auf sich selbst zu registrieren. Keinen. Es ist "einfacher in der Verwaltung", ja. Es ist auch ein Faustpfand, und beides gleichzeitig zu sein, ist genau das Problem.
Warum das so ist, und warum es nicht besser wird von allein
Ich glaube nicht, dass hier Bosheit im Spiel ist. Das Muster entsteht aus einem Geschäftsmodell, das falsch aufgesetzt ist. Website bauen ist ein Projekt mit einem klaren Ende und einer klaren Rechnung. Wartung ist eine Verpflichtung ohne Ende und mit einer Rechnung, die sich schlecht argumentieren lässt, weil das gute Ergebnis aussieht wie: nichts passiert.
Also wird die Wartungspauschale niedrig kalkuliert, weil sie sonst niemand kauft. Und weil sie niedrig ist, deckt sie realistisch ein oberflächliches Update-Klicken ab, nicht das Aufräumen einer Seite, die technisch fünf Jahre hinterher ist. Der Kunde bekommt das Gefühl von Betreuung zum Preis von keiner Betreuung. Das funktioniert genau so lange, bis es nicht mehr funktioniert.
Der ehrlichere Weg wäre unbequemer und für alle besser: sagen, was Wartung wirklich kostet, sagen, was drin ist und was nicht, und sagen, wenn eine Seite an einem Punkt ist, an dem Flicken teurer wird als neu bauen.
Selbst-Check: was du in zehn Minuten selbst prüfen kannst
Man braucht dafür keinen Entwickler. Vier Dinge, die jeder selbst nachschauen kann.
1. Wer ist Inhaber deiner Domain?
Auf nic.at die eigene Domain in die WHOIS-Abfrage eingeben. Steht dort dein Firmenname und deine Adresse, ist alles gut. Steht dort eine Agentur, ein Hoster oder ein fremder Name, hast du deine erste Aufgabe für heute.
2. Lädt die Seite Tracking, bevor du klickst?
Website im privaten Fenster öffnen, das Cookie-Banner ignorieren, dann mit F12 die Entwicklertools öffnen, auf "Netzwerk" wechseln und die Seite neu laden. Wenn dort schon vor jedem Klick Anfragen an google-analytics.com, googletagmanager.com, facebook.net oder fonts.googleapis.com auftauchen, läuft Datenverarbeitung ohne Einwilligung.
3. Ist das Ablehnen genauso leicht wie das Zustimmen?
Nicht technisch, sondern schlicht anschauen. Sind beide Optionen auf der ersten Ebene? Sind sie optisch gleichwertig? Ist die Ablehnung ein grauer Link neben einem leuchtenden Button, ist das nach der BVwG-Linie heikel.
4. Steht in der Fußzeile deiner Seite eine sichtbare Plugin-Version?
Rechtsklick, "Seitenquelltext anzeigen", dann mit Strg+F nach "ver=" suchen. Die Zahlen dahinter sind Versionsnummern. Das ist kein Sicherheitsurteil, aber ein brauchbares Indiz: Wenn dort Versionen von 2021 stehen, wurde lange nichts angefasst.
Die Fragen, die du deiner Agentur stellen solltest
Und jetzt der Teil, den ich mir eigentlich für diesen Beitrag vorgenommen hatte. Schick das per Mail, wörtlich, und bitte um schriftliche Antwort.
- Auf welcher PHP-Version läuft meine Seite, und bekommt diese Version noch Sicherheitsupdates?
- Wann wurden zuletzt WordPress-Kern, Themes und Plugins aktualisiert, und wie oft passiert das?
- Wie sind wir geschützt, wenn eine Lücke bekannt wird, für die es noch keinen Patch gibt?
- Gibt es Backups, wo liegen die, wie lange werden sie aufbewahrt, und wann wurde zuletzt eine Wiederherstellung getestet?
- Werde ich informiert, wenn die Seite offline ist oder Auffälligkeiten hat? Wie schnell?
- Wer hat Administratorzugang zu meiner Website, und ist der mit Zwei-Faktor-Authentifizierung gesichert?
- Wer ist bei nic.at als Inhaber meiner Domain eingetragen? Falls nicht ich: Bitte um Inhaberwechsel auf mich, mit Termin.
- Welche Dienste laden vor der Einwilligung, und wie ist das Consent-Tool konfiguriert?
- Sind Zustimmen und Ablehnen im Banner auf der ersten Ebene gleichwertig gestaltet?
- Was genau ist in meiner Wartungspauschale enthalten, und was nicht?
Eine gute Antwort ist konkret, mit Versionsnummern, Datumsangaben und einem klaren "das haben wir nicht, das würde X kosten". Eine gute Agentur wird dabei auch Dinge zugeben. Das ist ein Qualitätsmerkmal, kein Alarmsignal.
Alarmsignale sind: Ausweichen, Fachchinesisch als Nebelwand, "das ist bei uns alles inkludiert" ohne jede Zahl, oder Verstimmung darüber, dass man überhaupt fragt. Es ist deine Website, dein Geld und dein Haftungsrisiko.
Fazit
Es geht mir nicht darum, eine Branche schlechtzureden, in der ich selbst arbeite. Es geht darum, dass Grundstandards Grundstandards sind. Eine aktuelle PHP-Version, gepflegte Plugins, ein Schutz für die Zeit vor dem Patch, ein Backup, das getestet wurde, ein Consent-Banner, das hält, was es behauptet, und eine Domain, die dem Kunden gehört. Das ist kein Premium-Paket. Das ist die Untergrenze.
Wenn du die zehn Fragen abschickst und saubere Antworten bekommst: perfekt, dann hast du eine gute Agentur, sei froh und behalte sie. Wenn nicht, weißt du jetzt, wonach du fragen musst.
Und wenn du nach dem Selbst-Check das Gefühl hast, dass jemand einmal nüchtern draufschauen sollte: Meld dich. Wir sagen dir, was wir sehen, auch wenn die Antwort lautet, dass alles in Ordnung ist.
Quellen
- php.net: Supported Versions (abgerufen am 7. September 2026)
- Censys: Why Are WordPress Sites Still Running EOL PHP? (1. Juli 2026)
- Patchstack: State of WordPress Security In 2026 (Datenstand 25. Februar 2026)
- dataprotect.at: ORF.AT Cookie-Banner, BVwG bestätigt die Unzulässigkeit des Nudging (25. Mai 2026, zur Entscheidung BVwG 23.04.2026, W171 2303402-1/7E)
- nic.at: FAQ Domain-Inhaber (abgerufen am 7. September 2026)
