Technische Schulden bei kleinen Websites erkennen und bepreisen

Technische Schulden sind eine aus der Softwareentwicklung geliehene Idee: eine Abkürzung, die jetzt Zeit spart und später mehr kostet. In einem großen Produktteam kann das heißen, Tests auszulassen. Auf der Website eines kleinen Unternehmens ist es alltäglicher. Ein Plugin, das seit Jahren niemand aktualisiert hat. Ein Theme, das direkt statt über ein Child-Theme bearbeitet wurde. Ein Kontaktformular, das nur wegen eines Snippets funktioniert, das 2019 in eine Functions-Datei kopiert wurde. Ein Hosting-Tarif, der auf einer alten PHP-Version hängt, weil ein Upgrade „etwas kaputt machen könnte“.

Nichts davon ist am Tag der Entstehung eine Katastrophe. Die Kosten kommen in Raten: eine langsamere Website, ein unerwarteter Ausfall, ein Sicherheitsvorfall und ein Angebot für einen Relaunch, der in Wahrheit eine Rettung ist. Die nützliche Frage für Inhaber lautet nicht „Haben wir technische Schulden?“, denn jede Website hat welche, sondern „Wie viele, wo, und was würde es kosten, sie abzubauen?“

Dieser Leitfaden gibt Ihnen eine einfache Bewertungsliste, um das für eine kleine Website zu beantworten, auf Grundlage dessen, was Plattformanbieter und Sicherheitsorganisationen zur Wartung veröffentlichen. Sie brauchen dafür keinen Code-Zugriff: Die meisten Prüfungen lassen sich über die Admin-Bereiche, das Hosting-Panel und ein Gespräch mit dem Ersteller der Website erledigen. Wenn Sie einen professionellen Durchgang wünschen, ist er in unserer Leistung Website-Wartung enthalten.

Seien Sie bei der Definition streng, sonst füllt sich die Bewertungsliste mit Vorlieben. Technische Schulden sind alles, was die nächste Änderung langsamer, riskanter oder teurer macht, als nötig wäre. Auf einer kleinen Website decken sechs Gruppen fast alles ab:

• Veraltete Komponenten. Die Kernplattform, Plugins, Themes, Bibliotheken und Server-Software.
• Nicht gepflegte Komponenten. Erweiterungen, deren Entwickler aufgehört hat oder die aus dem Verzeichnis des Anbieters geschlossen oder entfernt wurden.
• Eigenbauten. Änderungen an Core- oder Drittanbieter-Dateien und Snippets ohne Dokumentation.
• Fragile Infrastruktur. Alte PHP-Version, keine Staging-Website, keine getesteten Backups, eine Person mit dem einzigen Passwort.
• Schulden bei Inhalt und Struktur. Doppelte Seiten, verwaiste Landingpages, verworrene Weiterleitungen.
• Wissensschulden. Niemand weiß, warum etwas so gemacht wurde.

Eine Website, die veraltet aussieht, hat nicht zwangsläufig Schulden: Eine schlichte, gut gepflegte Website kann günstig änderbar sein. Eine schöne Website auf einem Stack, den niemand versteht, kann sehr teuer sein. Lassen Sie das Aussehen aus der Bewertungsliste heraus.

Die OWASP Top 10, die bekannteste Sensibilisierungsliste für die Sicherheit von Webanwendungen, enthält eine Kategorie namens Vulnerable and Outdated Components. OWASP sagt, Sie sind wahrscheinlich verwundbar, wenn Sie die Versionen aller Komponenten, die Sie nutzen, nicht kennen, einschließlich verschachtelter Abhängigkeiten; wenn die Software verwundbar, nicht unterstützt oder veraltet ist, einschließlich Betriebssystem, Webserver, Datenbank, Anwendungen und Bibliotheken; wenn Sie nicht regelmäßig scannen und Sicherheitsmitteilungen abonnieren; wenn Sie nicht risikobasiert und zeitnah beheben oder aktualisieren, was laut OWASP häufig geschieht, wenn Patchen eine monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle ist; und wenn Entwickler die Kompatibilität aktualisierter Bibliotheken nicht testen. Lesen Sie den Eintrag: OWASP A06:2021.

Die Liste zur Vorbeugung ist ein verkleideter Wartungsplan: ungenutzte Abhängigkeiten, Funktionen und Dateien entfernen; ein laufendes Verzeichnis der Komponentenversionen führen; Quellen für Schwachstellendaten beobachten; und Benachrichtigungen zu den genutzten Komponenten abonnieren.

Für ein kleines Unternehmen ist die Übersetzung einfach. Sie müssen wissen, was installiert ist, in welcher Version, wer es pflegt und ob es noch unterstützt wird. Diese Bestandsaufnahme ist die erste Zeile der Bewertungsliste.

Da viele kleine Websites auf WordPress laufen, sind dessen veröffentlichte Aussagen eine bequeme Grundlage. WordPress sagt auf seiner Sicherheitsseite, dass nur die neueste Version von WordPress offiziell unterstützt wird, auch wenn das Security Team Korrekturen als Gefälligkeit auf ältere Versionen zurückportiert. Bei Plugins und Themes werden Schwachstellen dem Entwickler und dem Prüfteam für Plugins oder Themes gemeldet; wer den Patch ausliefert, sagt die Seite nicht. Quelle: WordPress-Sicherheit.

Die FAQ für Plugin-Entwickler erklärt, was passiert, wenn ein Plugin geschlossen wird: Es erzeugt keine Zip-Dateien mehr und niemand kann es über die Website herunterladen; Plugins werden wegen Verstößen gegen Richtlinien, Sicherheitsproblemen oder auf Wunsch des Autors geschlossen. Sie nennt außerdem, dass bestehende Plugins, die nicht mehr weiterentwickelt werden, übernommen werden können, ohne Garantie für eine Übergabe, und dass ein Plugin ohne neuen Eigentümer erhebliche Sicherheitsfolgen haben kann. Siehe die FAQ für Plugin-Entwickler.

Daraus folgen zwei praktische Prüfungen. Erstens: Suchen Sie in der Plugin-Liste im Admin-Bereich nach Plugins, deren Seite im Verzeichnis sagt, dass sie geschlossen wurden, oder die den Hinweis „nicht mit Ihrer Version getestet“ zeigen. Die FAQ erklärt, dass der Wert „tested up to“ vom Entwickler gesetzt wird und dass ein fehlender oder falscher Wert die Meldung „not been tested“ erzeugt. Zweitens: Prüfen Sie den Server. WordPress empfiehlt PHP 8.3 oder höher und MariaDB 10.11 oder höher oder MySQL 8.0 oder höher. Es sagt, dass es in Legacy-Umgebungen weiterhin mit PHP 7.4 und MySQL 5.5.5 funktioniert, diese Versionen aber das Ende ihrer Lebensdauer erreicht haben und Ihre Website Sicherheitslücken aussetzen können (WordPress-Anforderungen).

Das PHP-Projekt veröffentlicht den Support-Status jedes Zweigs. Zum Zeitpunkt des Schreibens (22. Oktober 2026) zeigt die Seite mit den unterstützten Versionen:

Die Seite definiert aktive Unterstützung so, dass eine Version Korrekturen für gemeldete Fehler und Sicherheitsprobleme erhält, und „nur Sicherheitskorrekturen“ so, dass nur kritische Sicherheitsprobleme behoben werden. Eine Website auf PHP 8.2 hat daher bis Ende 2026 Zeit für Sicherheitskorrekturen; jeder ältere Zweig ist nicht als unterstützt aufgeführt. Quelle: Unterstützte PHP-Versionen.

Tragen Sie das Enddatum Ihrer PHP-Version in den Kalender ein und behandeln Sie eine Version, die nicht auf der Seite steht, als Punkt mit roter Bewertung in der Bewertungsliste.

Bewerten Sie jede Zeile: 0 bedeutet in Ordnung, 1 geringfügig, 2 ein echtes Problem, 3 dringend. Die Zeilen sind unsere eigene Arbeitsmethode für kleine Websites; sie verbinden die obigen Hinweise von OWASP und Herstellern mit gängiger Agenturpraxis.

Summen: 0 bis 7 ist gesund; 8 bis 15 braucht einen Wartungsplan; 16 bis 22 braucht ein finanziertes Bereinigungsprojekt; 23 bis 30 bedeutet, dass die Website ein Kandidat für einen Neubau ist. Die Bereiche sind eine Faustregel, kein Branchenstandard.

Über Schulden spricht man am leichtesten, wenn man ihnen einen Preis geben kann. Bitten Sie einen Entwickler, die Stunden pro bewerteter Zeile zu schätzen, und multiplizieren Sie mit seinem Stundensatz. Unsere eigenen einfachen Websites beginnen ab EUR 300 zuzüglich Mehrwertsteuer (siehe Preise), aber Sanierungsarbeiten werden nach Stunden berechnet und hängen davon ab, was Sie finden. Als Orientierung für die Form der Schätzung gruppieren Sie die Zeilen in drei Pakete.

1. Pflege (Zeilen 1, 2, 4, 10). Updates, Entfernen ungenutzter Elemente, PHP-Wechsel. Überwiegend Routine, oft im Rahmen eines monatlichen Wartungsplans, mit einem Test auf der Staging-Website.
2. Ersatz (Zeilen 3, 5). Aufgegebene Plugins austauschen und Eigenbauten zurückbauen. Jeder Punkt ist ein kleines Projekt: eine Alternative finden, Einstellungen und Daten migrieren, testen.
3. Grundlagen (Zeilen 6 bis 9). Versionskontrolle, Staging, Backups, Zugang. Einmalige Einrichtung, die sich danach bei jeder weiteren Änderung auszahlt.

Bitten Sie darum, jedes Paket getrennt zu kalkulieren, mit den Punkten des höchsten Risikos zuerst. Übersteigt das Ersatzpaket den Preis eines sauberen Neubaus, vergleichen Sie die Optionen in unserem Leitfaden zum Website-Relaunch. Ein Neubau ist nicht immer sauberer: Er trägt eigene Schulden, wenn Dokumentation und Zuständigkeit nicht Teil des Briefings sind.

Sie können viel lernen, ohne Code zu lesen.

• Admin-Bereiche. Zählen Sie ausstehende Updates. Notieren Sie jedes Plugin, das lange kein Update erhalten hat.
• Hosting-Panel. Lesen Sie PHP-Version und Datenbankversion ab und prüfen Sie das Alter des letzten Backups.
• Stellen Sie dem Ersteller drei Fragen. Was wurde außerhalb der normalen Einstellungen geändert? Wo liegt der Code? Wie würde sich ein neuer Entwickler in die Website einarbeiten?
• Messen Sie die Zeit für eine Änderung. Eine triviale Änderung, etwa eine Telefonnummer auf der ganzen Website zu ändern, zeigt, wie brüchig die Website ist. Dauert es einen Tag, gibt es Schulden.
• Prüfen Sie die Zugangsliste. Ehemalige Mitarbeiter und Agenturen mit aktiven Admin-Konten sind ein eigenes Risiko.

Schreiben Sie die Ergebnisse auf einer Seite auf, mit dem Score neben jeder Zeile, damit die nächste Person dort weitermachen kann, wo Sie aufgehört haben.

Hüten Sie sich vor zwei verbreiteten falschen Beruhigungen. Die erste ist „es läuft seit Jahren gut“: Eine Website, die nicht angegriffen wurde, ist nicht dasselbe wie eine Website, die nicht angegriffen werden kann. Die zweite ist ein grüner Haken von einem Plugin, das behauptet, alles zu scannen. Solche Werkzeuge können helfen, aber OWASP rät, ein Verzeichnis zu führen und Schwachstellenquellen für die tatsächlich genutzten Komponenten zu beobachten, was kein einzelner Haken ersetzt. Behandeln Sie die Ausgabe von Werkzeugen als eine Eingabe für die Bewertungsliste, nie als den Score.

Sie brauchen selten eine einzige große Bereinigung. Ein ruhiger Ansatz ist, regelmäßig ein kleines Stück Arbeit einzuplanen.

1. Beginnen Sie mit einem Backup, das Sie tatsächlich auf einer Kopie wiederhergestellt haben.
2. Legen Sie eine Staging-Kopie an und spielen Sie Updates zuerst dort ein.
3. Entfernen Sie, was ungenutzt ist: Plugins, Themes, alte Medien, Testseiten.
4. Ersetzen Sie zuerst die gefährlichste aufgegebene Komponente.
5. Dokumentieren Sie eigenen Code in einer kurzen Readme und halten Sie ihn in der Versionskontrolle.
6. Stellen Sie PHP auf einen unterstützten Zweig um, wenn der Staging-Test bestanden ist.
7. Legen Sie einen monatlichen Wartungstermin und eine vierteljährliche Neubewertung fest.

Der Hinweis von OWASP, dass Patchen als monatliche oder vierteljährliche Aufgabe unter Änderungskontrolle „Tage oder Monate unnötiger Angriffsfläche“ lässt, ist ernst zu nehmen: Vereinbaren Sie eine Schnellspur für Sicherheitsupdates und eine langsame Spur für alles andere.

Ein Neubau ist gerechtfertigt, wenn die Plattform selbst das Problem ist: Der Core lässt sich nicht aktualisieren, das Theme hängt von aufgegebenen Frameworks ab oder die Kosten des Ersatzpakets nähern sich dem Preis einer Neuentwicklung. Er ist nicht gerechtfertigt, wenn die eigentlichen Probleme fehlende Dokumentation und fehlende Wartung sind, denn eine neue Website ohne beides driftet in zwei Jahren in denselben Zustand.

Führen Sie vor jeder Entscheidung die Bewertungsliste durch, fragen Sie die Preise der drei Pakete ab und legen Sie ein Datum für die Neubewertung nach der Arbeit fest. Wenn wir die Bewertungsliste für Ihre Website durchführen sollen, nehmen Sie Kontakt auf oder fordern Sie ein Angebot an, und sehen Sie sich die Seite WordPress-Entwicklung für Arbeiten an der Plattform an.

• OWASP Top 10:2021 A06 Vulnerable and Outdated Components
• WordPress.org: security
• WordPress Plugin Handbook: plugin developer FAQ
• WordPress.org: requirements
• PHP: supported versions