Häufig lohnt sich erst eine Audit‑gestützte Optimierung — ein fokussierter Fix an Performance, UX, SEO und Sicherheit — bevor ein teurer Neuaufbau angeordnet wird. Wenn jedoch die Codebasis veraltet, Wartung unmöglich oder die Seite technisch so fragmentiert ist, dass schnelle Verbesserungen nicht möglich sind, spricht vieles für ein Redesign/Neubau. Unten finden Sie einen Entscheidungscheck, was Sie messen müssen, wie Sie die Auswirkungen bewerten und welche Kriterien für «optimieren» vs. «neu aufbauen» gelten.
Problem und Symptome
-
- Langsame Ladezeiten, spürbare Verzögerungen bei Klicks oder Formularen, sichtbare Layout‑Verschiebungen (inhalte springen), stark fallende Mobile‑Klick‑Raten: typische Symptome technischer Defizite.
-
- SEO‑Signale: Rückgang organischer Sichtbarkeit, Fehlermeldungen in der Search Console (Indexierungsfehler, Core Web Vitals Warnungen).
-
- Betrieb/Support: teure Hotfixes, hoher Aufwand für kleine Änderungen, fehlende Tests/CI — Hinweise auf schlechte Codequalität.
Verifizierte Fakten: Core Web Vitals (LCP, INP, CLS) sind von Google definierte Kennzahlen zur Bewertung von Ladezeit, Interaktivität und visueller Stabilität. Diese Metriken werden u. a. in Search Console und PageSpeed Insights dargestellt.(web.dev)
- Betrieb/Support: teure Hotfixes, hoher Aufwand für kleine Änderungen, fehlende Tests/CI — Hinweise auf schlechte Codequalität.
Was messen — und wie
Verifizierte Kennzahlen (Wichtigste, direkt messbar)
-
- LCP (Largest Contentful Paint): misst, wann das größte sichtbare Element geladen ist. Ziel: Good ≤ 2,5 s (75. Perzentil).(web.dev)
-
- INP (Interaction to Next Paint): misst Reaktionszeit für Benutzerinteraktionen; ersetzt FID. Good ≤ 200 ms, Poor > 500 ms; zur Beurteilung am 75. Perzentil.(developers.google.com)
-
- CLS (Cumulative Layout Shift): misst visuelle Verschiebungen. Good ≤ 0,1; Poor > 0,25.(web.dev)
Werkzeuge (Lab & Field)
-
- Felddaten (RUM): Google Search Console – Core Web Vitals Report; Chrome user experience Report (CrUX) / PageSpeed Insights (Origin/Page‑Level). Diese zeigen reale Nutzerdaten.(support.google.com)
-
- Lab‑Tools: Lighthouse (DevTools/CI), PageSpeed Insights, WebPageTest — für reproduzierbare Diagnosen.(github.com)
-
- Messbibliotheken: web‑vitals (für eigene RUM‑Erfassung) oder kommerzielle RUM‑Provider (New Relic, Datadog etc.) für detaillierte Interaktions‑Traces.(github.com)
Konkretes Vorgehen
-
- Start‑Audit (1–2 Tage): Search Console prüfen (Index, CWV‑Report), PSI/Lighthouse für 5–10 repräsentative Seiten, Server‑ und CDN‑Konfiguration prüfen.
-
- RUM‑Messung (2–4 Wochen): web‑vitals oder RUM‑Tool implementieren, 75. Perzentil für LCP/INP/CLS getrennt nach Mobile/Desktop erheben.
-
- Lab‑Diagnose: Ressourcen‑Priorisierung (render‑blocking JS/CSS, große Bilder, schlecht konfigurierte Fonts), Third‑party Audit (Ads, Tracker).
Verifizierte Fakten: INP wurde offiziell als Core Web Vital eingeführt und hat FID ersetzt; Google empfiehlt die 75. Perzentil‑Betrachtung als Bewertungsgrundlage.(developers.google.com)
- Lab‑Diagnose: Ressourcen‑Priorisierung (render‑blocking JS/CSS, große Bilder, schlecht konfigurierte Fonts), Third‑party Audit (Ads, Tracker).
Business‑Impact (wie technische Probleme Umsätze und Sichtbarkeit beeinflussen)
-
- Sichtbarkeit: Page Experience‑Signale fließen in Googles Bewertungsrahmen ein; Core Web Vitals sind Teil dieses Page‑Experience‑Ansatzes. Allerdings gilt: Relevanz/Inhalte bleiben zentrale Rankingfaktoren — gute CWV garantieren kein Top‑Ranking.(developers.google.com)
-
- Conversion & UX: langsame oder unzuverlässige Interaktion reduziert Nutzerzufriedenheit und kann direkte Buchungen/Käufe hemmen; technische Barrieren erhöhen Support‑Aufwand und Kosten für Nachbesserungen.
-
- Betriebskosten: eine schwer wartbare Site verursacht langfristig höhere Entwicklungs‑ und Sicherheitskosten (z. B. bei fehlender Modularität oder veralteten Libraries).
Kontext für österreichische KMU
Verifizierte Fakten: In Österreich sind fast alle Unternehmen KMU: nach aktuellen Angaben machen KMU über 99 % der österreichischen Unternehmen aus (konkrete nationale Berichte/Monitoring‑Publikationen). Die EU‑Definition für KMU: <250 Beschäftigte und entweder Jahresumsatz ≤ €50 Mio. oder Bilanzsumme ≤ €43 Mio. (relevant für Förderkriterien und Förderprogramme).(bmwet.gv.at)
Prioritäten — Jetzt / Nächste Schritte / Später
Empfehlungen (Praxispriorität)
-
- Jetzt (0–4 Wochen)
-
- Notfallfixes: kritische JavaScript‑Blocks entfernen, Bilder nachladen (lazy loading), Browser‑Caching konfigurieren, HTTPS erzwingen.
-
- Search Console: Fehler beheben (Indexierungs‑ und Mobile‑Usability‑Warnungen); CWV‑Report ansehen.
-
- Backup & Security: TLS/HTTPS, regelmäßige Backups, aktive Firewall/Rate‑Limits. (Security‑Standards: OWASP‑Richtlinien als Orientierung).(support.google.com)
-
- Jetzt (0–4 Wochen)
-
- Nächste Schritte (1–3 Monate)
-
- RUM‑Messung vollständig einführen; steigende Testabdeckung per Lighthouse CI; kritische Templates/Seiten (Produktseiten, Buchung) optimieren.
-
- Content‑Audit: Inhalte auf Suchintention und E‑E‑A‑T‑Signale prüfen; strukturierte Daten dort einsetzen, wo sinnvoll.
-
- Third‑party: Tags und Drittanbieter prüfen (Analytics, Ads) — oft große Performance‑ und Datenschutz‑Risiken.
-
- Nächste Schritte (1–3 Monate)
-
- Später (3–12 Monate)
-
- Architektur‑Review: CMS‑Updates, CI/CD, Komponententests.
-
- Entscheidung Redesign: wenn nach 3 Monate messbarer Optimierung die wichtigsten Geschäftsseiten nicht stabil «Good» (75. Perzentil) erreichen oder Wartungskosten zu hoch sind, Neubau planen.
-
- Später (3–12 Monate)
Entscheidungskriterien: Optimieren vs. Neu aufbauen
Empfehlungen (konkrete Entscheidungsfragen)
-
- Codequalität & Wartbarkeit: Gibt es Tests, Versionierung, klare Trennung von Frontend/Backend? Wenn nein → eher Neuaufbau.
-
- Messbare Hebel: Erreichen Sie durch gezielte Maßnahmen innerhalb von 1–3 Monaten signifikante Verbesserungen (z. B. 75. Perzentil LCP/INP/CLS in den «Good»-Bereich zu bringen)? Wenn ja → Optimieren.
-
- Geschäftsabhängigkeit: Sind Kernprozesse (Buchung, Checkout, CRM‑Integration) durch Architekturschwächen fehleranfällig? Wenn Kernprozesse instabil sind → Neubau eher erforderlich.
-
- Kosten vs. Nutzen: Schätzen Sie die Implementierungs‑ und Wartungskosten beider Optionen; bei einer Code‑Basis, die hohe Fix‑Kosten erzeugt, amortisiert sich Neuaufbau oft mittelfristig.
-
- Zeit & Ressourcen: Haben Sie Entwickler/Agenturkapazität, um umfassende Refactoring‑Arbeiten durchzuführen? Wenn nicht, ist ein Neubau mit moderner Architektur und automatisierten Tests langfristig günstiger.
Konkrete Checkliste (kurz, nutzbar im Audit)
-
- Messung & Monitoring
-
- Search Console: Core Web Vitals Report prüfen.(support.google.com)
-
- PageSpeed Insights / Lighthouse: 5–10 repräsentative Seiten testen.(github.com)
-
- RUM: web‑vitals oder kommerzieller RUM‑Agent implementiert.(github.com)
-
- Messung & Monitoring
-
- Performance‑Quickwins
-
- Bilder optimieren (WebP/AVIF, responsive srcset), CDN aktivieren.
-
- JS/CSS: kritisches CSS inline, nicht‑kritisches asynchron laden; long‑task‑Analyse.
-
- Fonts: font‑display: swap und Preload prüfen.
-
- Performance‑Quickwins
-
- UX & Conversion
-
- Mobile‑First Design prüfen; Formulare vereinfachen; CTAs sichtbar und nicht von Layout‑Shifts betroffen.
-
- Messung von Funnel‑Abbruchpunkten via Analytics.
-
- UX & Conversion
-
- SEO & AI‑Sichtbarkeit
-
- Strukturierte Daten korrekt und serverseitig liefern; content‑quality prüfen (siehe Google‑Leitfaden für AI‑Search‑Optimierung).(developers.google.com)
-
- Indexierungsprobleme beheben; Crawling‑Budget prüfen.
-
- SEO & AI‑Sichtbarkeit
-
- Sicherheit & Betrieb
-
- HTTPS enforced; aktuelle Server‑TLS‑Konfiguration; regelmäßige Backups.
-
- Basis‑Security‑Checklist gegen OWASP‑Top‑Risks durchgehen.(owasptopten.org)
-
- Sicherheit & Betrieb
-
- Business‑Checks
-
- Sind Kernseiten (Produkte/Services/Checkout) in 75. Perzentil für LCP/INP/CLS «Good»?
-
- Können 50–80 % der kritischen Probleme innerhalb von 3 Monaten mit vorhandenen Ressourcen gelöst werden?
-
- Business‑Checks
Abschließende Empfehlung (Kurz)
Machen Sie zuerst ein kurzes, mess‑ und reproduzierbares Audit (1–2 Wochen Arbeit). Wenn das Audit zeigt, dass die Hauptprobleme durch Konfigurations‑ und Frontend‑Fixes lösbar sind, beginnen Sie mit einem priorisierten Optimierungsplan. Wenn hingegen die Codebasis fragmentiert, unsicher oder nicht wartbar ist und die wichtigsten Geschäftsprozesse davon betroffen sind, planen Sie einen kontrollierten Neubau mit klaren Migrationsschritten und Messzielen.
Wichtige Referenzen (Auswahl der Quellen)
-
- Google: Einführung INP / Core Web Vitals; Page Experience Guidance; Search Console Core Web Vitals.(developers.google.com)
-
- web.dev: technische Leitfäden zu LCP, INP, CLS und Optimierungsschritten.(web.dev)
-
- Lighthouse / GoogleChrome Projekte (Lighthouse docs).(github.com)
-
- Google: Leitfaden zur Optimierung für generative AI‑Ergebnisse (AI Search).(developers.google.com)
-
- Österreichische Quellen / KMU‑Zahlen und EU‑SME‑Definition.(bmwet.gv.at)
-
- OWASP: Sicherheitsempfehlungen und Top‑Risiken.(owasptopten.org)
Wenn Sie möchten, kann ich Ihnen ein kurzes Audit‑Template (Fragen, Tools, Prioritäten) erstellen, das Sie Ihrem Entwickler/Agentur geben können — damit bekommen Sie in 7–14 Tagen konkrete Messwerte, die die Optimieren‑vs‑Neuaufbauen‑Entscheidung objektiv machen.
Website-Wachstumsleck-Check
Erkennen Sie die wichtigsten Website-Lecks, Prioritäten und nächsten Schritte mit belastbaren Hinweisen, bevor Sie Geld in Relaunch oder Optimierung investieren.
DigiXRAY Website-Mapping anfordern
Wenn Sie bereits ein konkretes Projekt planen: Projekt-Bedarfsanalyse ausfüllen.