Website-Neuentwicklung oder Patchen? Entscheidungsleitfaden für österreichische Unternehmen bei anhaltenden Sicherheitsproblemen

Kurzantwort
Eine Neuentwicklung ist dann gerechtfertigt, wenn wiederholte, systemische Probleme (z. B. anhaltende Sicherheitslücken, schlechte Core‑Web‑Vitals für zentrale Conversion‑Seiten, oder eine veraltete Architektur ohne Upgrade‑Pfad) den Geschäftsbetrieb, die Conversion‑Rates oder regulatorische Anforderungen gefährden. Falls dagegen technische Schulden lokal begrenzt sind und Kernfunktionen sowie Sicherheitsprozesse nachhaltig wiederherstellbar sind, ist gezieltes Patchen und Refactoring oft günstiger und schneller. (Siehe Entscheidungsleitfaden weiter unten.)

Verifizierte Fakten (kurz)

• Core Web Vitals = LCP, INP, CLS; Zielwerte: LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1. Diese Kennzahlen sind Teil der Page‑Experience‑Signale von Google. (developers.google.com)
• Google verwendet für das Ranking Feld‑Messwerte (Chrome user experience Report / CrUX) und stellt Berichte in der Search Console bereit. (support.google.com)
• Google bietet seit Juni 2026 dedizierte Performance‑Reports für generative‑AI‑Ergebnisse (Sichtbarkeit in AI‑Overviews / AI Mode) in der Search Console. Das beeinflusst, wie Inhalte in AI‑basierten Antworten auftauchen. (developers.google.com)
• OWASP veröffentlicht gängige Schwachstellen (Top‑10) und gilt als Referenz für Web‑Sicherheitsrisiken. (top10.owasp.org)
• Die EU‑Richtlinie NIS‑2 (in Kraft seit 16.1.2023) erweitert Pflichten für IT‑Sicherheit; kleine Unternehmen sind grundsätzlich ausgenommen, können aber in bestimmten Fällen oder über Lieferketten betroffen sein. Österreich informiert dazu zentral. (nis.gv.at)

Problem und Symptome

• Sicherheitssymptome: wiederkehrende oder ungepatchte CVE‑Warnungen, fremde Dateien/Backdoors, erzwungene Passwort‑Resets, verdächtige Logins oder Ausfälle nach Sicherheitsvorfällen. (Verhaltens‑ und Logdaten prüfen.)
• Performance/UX‑Symptome: hohe Absprungraten auf Produkt‑ oder Checkout‑Seiten, lange Ladezeiten (sichtbar in PageSpeed / Search Console), spürbar schlechte Core‑Web‑Vitals auf Seiten mit Umsatzwirkung. Beispiel: Hero‑Bild oder Dritt‑Script verzögert LCP > 4 s auf Produktseiten. (developers.google.com)
• SEO/AI‑Sichtbarkeit: plötzlicher Traffic‑Verlust in organischer Suche; seit 2026 zusätzlich Fälle, in denen Inhalte in Google‑AI‑Antworten wenig oder gar nicht angezeigt werden (mögliche neue Metrik in Search Console). (developers.google.com)
• Wartungs‑Symptome: Plugin‑Ecosystem mit abgekündigten Versionen, fehlende Sicherheitsupdates vom Hersteller, hohe Time‑to‑Fix bei kritischen Bugs.

Was messen — und wie genau

• Core Web Vitals (Felddaten): Search Console → Core Web Vitals Report (CrUX‑basiert, 28‑Tage‑Rollfenster, p75). PageSpeed Insights zeigt Feld‑ und Laborwerte; Lighthouse liefert Labordaten für einzelne Audits. Nutzen Sie die web‑vitals JavaScript‑Bibliothek für eigenes RUM‑Tracking. (support.google.com)
  Vorgehen: identifizieren Sie die Top‑10 umsatzrelevanten URLs (Produkt, Kategorie, Checkout) und prüfen deren p75‑Werte in Search Console.
• Sicherheitslage: Asset‑Inventar, aktuelle Patch‑Liste (OS, CMS, Plugins, Libraries), offene/geschlossene CVEs mit Datum der ersten Meldung, und Incident‑Logs (Anzahl und Impact). Als Referenz nutzen Sie OWASP‑Checklisten für Web‑Apps. (top10.owasp.org)
• SEO‑/AI‑Sichtbarkeit: Search Console Performance + seit 2026 das Generative‑AI‑Performance‑Report (zeigt Impressions/URLs in AI‑Features). Prüfen Sie Ranking‑Veränderungen, organische Impressions und Klicks für Schlüsseltermine vor/nach Problemen. (developers.google.com)
• Betriebskosten & Time‑to‑Market: Ermitteln Sie Stundenaufwand und Kosten für: (a) kurzfristige Patches; (b) umfassendes Refactoring; (c) kompletten Relaunch (Design + Migration). Diese Zahlen sind entscheidend für ROI‑Vergleiche.

Business‑Impact (konkret)

• Conversion/Revenue: Jede Sekunde Ladezeit kann die Conversion verschlechtern; besonders Checkout‑/Produktseiten haben hohe Sensitivität. (Konkrete %-Zahlen variieren; messen Sie an eigenen Funnels.) (developers.google.com)
• Reputation & rechtliche Risiken: Sicherheitsvorfälle können bei betroffenen EU‑Pflichtfällen zu Meldepflichten und Bußgeldern führen (NIS‑2: Meldefristen und mögliche Sanktionen für betroffene Unternehmen). Für kleine KMU gilt in der Regel Erleichterung, Ausnahmen bestehen aber. (nis.gv.at)
• Sichtbarkeit 2026+: AI‑Gestützte Suchfeatures können Traffic‑Verteilung und Click‑Through verändern; fehlende Sichtbarkeit in AI‑Antworten ist neuer Wettbewerbsfaktor. Nutzen Sie Search Console‑Reports, um Veränderungen zu quantifizieren. (developers.google.com)

Prioritäten: Jetzt / Nächste Schritte / Später

• Jetzt (sofort, 0–2 Wochen)

  • Sicherheits‑Schnellcheck: Backups, Zugangssperre (MFA), Passwortrotation für Admins, Notfall‑Patching für kritische CVEs. (Sofortmaßnahmen, minimaler Aufwand.) (top10.owasp.org)
  • Schnelle Messung: Search Console Core Web Vitals + PageSpeed Insights für Ihre wichtigsten Seiten; erstellen Sie eine Prioritätenliste der Seiten nach Umsatzwirkung. (developers.google.com)

• Nächste Schritte (2–8 Wochen)

  • Kurzfristiges Refactoring: Entfernen oder deferen render‑blockierender Scripts auf Top‑Pages, Bildoptimierung, CDN‑Konfiguration. Messen Sie Effekte mit RUM und PageSpeed. (web.dev)
  • Sicherheits‑Härtung: Plugin‑Audit, Entfernen veralteter Plugins/Extensions, Einsatz einer WAF, regelmäßige Vulnerability‑Scans. (top10.owasp.org)
  • Reporting einrichten: Search Console Property + Zugriff auf AI‑Performance‑Report aktivieren; RUM‑Scripts (web‑vitals) implementieren. (support.google.com)

• Später (2–6 Monate)

  • Architekturentscheidung: Wenn Probleme wiederkehren, planen Sie Refactor vs. Rebuild basierend auf Kosten, Time‑to‑Market und Sicherheitsanforderungen (siehe Entscheidungs‑Kriterien).
  • Test & Launch: Staging‑Tests, Lasttests, Migrationsplan mit Rollback und Monitoring.

Entscheidungskriterien: Patchen/Refactor vs. Neuentwicklung
Bewerten Sie systematisch anhand dieser Fragen (je “Ja” → stärkerer Fall für Neuentwicklung)

1. Sind Kernabhängigkeiten (Framework, CMS, PHP/Node‑Versionen) nicht mehr updatebar oder end‑of‑life?
2. Sind Sicherheitslücken strukturell (Architektur, schlechte Authentifizierungslogik) statt lokal (ein Plugin)?
3. Liegen die wichtigsten KPI‑Probleme (Conversion, Umsatz, SEO‑Traffic) an vielen Seitentypen, nicht nur an Einzelseiten?
4. Erfordert die geplante Produktstrategie (z. B. Omnichannel, Headless, umfangreiche Personalisierung, Integration mit externen Systemen) technische Voraussetzungen, die das bestehende System nicht tragen kann?
5. Übersteigen die wiederkehrenden Wartungs‑ und Patchkosten (Total Cost of Ownership) auf 2–3 Jahre gerechnet die geschätzten Kosten für einen sauberen Relaunch?

Wenn die Antworten überwiegend mit „Nein“ ausfallen, ist gezieltes Patchen/Refactoring meist wirtschaftlicher. Bei überwiegend „Ja“ ist eine Neuentwicklung zu prüfen.

Konkrete Beispiele (Illustrativ)

• Beispiel A (Patchen sinnvoll): WordPress‑Shop mit einem einzigen veralteten Plugin, das Lücken enthält, ansonsten aktuelle PHP‑Version und moderater Traffic. Lösung: Plugin ersetzen, Caching + Bildoptimierung.
• Beispiel B (Neuentwicklung sinnvoll): Eigenentwickelte Shop‑Plattform mit monolithischer, veralteter Codebasis, keine Test‑Coverage, wiederholten Sicherheitsvorfällen und trotz Patches anhaltend schlechter Performance auf allen Produktseiten. Lösung: Planbarer Rebuild (z. B. modulare, cloud‑hosted Architektur, automatisierte Tests, CI/CD).

Konkrete Mess‑ und Prüf‑Tools (zum Start)

• Google Search Console (Core Web Vitals, Performance, Index‑Status). (support.google.com)
• PageSpeed Insights / Lighthouse (Lab + Feld). (developers.google.com)
• Chrome UX Report (CrUX) für p75‑Werte; BigQuery/Tools für tiefergehende Analysen. (developer.chrome.google.cn)
• web‑vitals JS‑Library für eigenes RUM. (app.unpkg.com)
• OWASP‑Checklisten & WAF für Security‑Review. (top10.owasp.org)

Entscheidungs‑Checkliste (knapp)

• Haben Sie ein Inventar aller Tech‑Komponenten und deren End‑of‑Life‑Datum? (ja/nein)
• Kern‑Umsatzseiten: p75 LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1? (ja/nein) — prüfen per Search Console. (developers.google.com)
• Liegen offene kritische CVEs vor, die nicht binnen 72 Std. patchbar sind? (ja/nein)
• Führt die aktuelle Plattform zu monatlichen Betriebs‑ und Supportkosten, die eine Neuentwicklung rechtfertigen? (ja/nein)
• Bedarf an Compliance/Reporting (NIS‑2 oder Lieferketten‑Vorgaben)? (ja/nein) — prüfen Sie Österreich‑Infos. (nis.gv.at)
• Ist Ihre Sichtbarkeit in AI‑Suchformaten messbar / rückläufig? (ja/nein) — Search Console AI‑Report prüfen. (developers.google.com)

Abschlusshinweis
Beginnen Sie mit Messdaten: ohne valide Search‑Console‑/CrUX‑Daten und ein aktuelles Sicherheitsinventar ist jede Entscheidungsrechnung spekulativ. Sammeln Sie die genannten Messdaten (Top‑URLs, Sicherheitsliste, Wartungskosten) und nutzen Sie die obige Checkliste, um in eine sachliche Patch‑vs‑Rebuild‑Entscheidung zu kommen.