Redesign oder Neuaufbau? Entscheidungsfaktoren nach einem Website-Conversion-Audit im Mittelstand

Kurzantwort

• Nach einem Website-Conversion-Audit fällt die Entscheidung zwischen Redesign (UI/Content-Änderungen) und Neuaufbau (Architektur/Plattform) hauptsächlich aufgrund messbarer technischer Defizite (Core Web Vitals, Sicherheit, Crawlability), wiederkehrender UX-/Conversion-Hindernisse und des wirtschaftlichen Aufwands im Vergleich zur erwarteten Rendite. Bei klaren Core-Web-Vitals- oder Architekturproblemen empfiehlt sich oft ein gezielter Neuaufbau; bei vorwiegenden inhaltlichen, UX- oder Conversion-Problemen reicht meist ein Redesign mit technischer Nachbesserung. (Details und Checkliste weiter unten.)

Problem und Symptome

• Typische Symptome, die ein Audit aufzeigt, sind: hohe Absprungrate auf Mobilgeräten, niedrige Conversion-Rates trotz Traffic, viele Seiten im Search Console-Report mit Status „Poor/Needs improvement“, langsame Ladezeiten (LCP > 2,5 s), spürbare Interaktions-Verzögerungen (INP > 200 ms), sichtbare Layout-Verschiebungen (CLS > 0,1) oder wiederkehrende Sicherheits-/Indexierungsfehler. Google fordert für eine „gute“ Nutzererfahrung explizite Messgrößen: LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1. (developers.google.com)
• Beispiel: Ein mittelständischer Dienstleister sieht viele Seiten mit „Need improvement“ in der Search Console und gleichzeitig eine mobile Absprungrate von 70 %. Das deutet auf Performance- oder Interaktionsprobleme (technisch) hin — nicht zwingend auf ein vollständiges Neudesign.

Was zu messen ist — und wie

• Felddaten (real users) sind entscheidend: Die Search Console (Core Web Vitals-Report) zeigt P75-Werte über 28 Tage und gruppiert nach URL-Gruppen. Dies bildet die Grundlage, um reale Probleme zu priorisieren. Die Search Console nutzt dabei die Chrome UX Report (CrUX)-Daten (Field Data). (support.google.com)
• Lab- und URL-Tests zur Ursachenbestimmung: PageSpeed Insights / Lighthouse liefern Lab-Metriken und konkrete Diagnosevorschläge pro URL. Sie helfen, spezifische Ressourcenprobleme (große Bilder, Render-blockierende JS, lange Tasks) zu identifizieren. (pagespeedinsights.dev)
• Wichtige Kennzahlen (empfohlen zu erfassen):
  • Core Web Vitals: LCP, INP, CLS (P75, mobil + Desktop). (developers.google.com)
  • Technische SEO: Crawl-Fehler, indexierte URLs, Sitemap-Status, robots.txt-Fehler. (developers.google.com)
  • Conversion-KPIs: Sessions, Absprungrate, Ziel-Conversion-Rate, Funnel-Drop-Offs (z. B. Warenkorb → Checkout oder Anfrageformular → Absenden).
  • Sicherheit/Compliance: HTTPS-Status, bekannte Schwachstellen (OWASP-Top-10 als Prüfliste). (owasp.org)
• Metrik-Methodik: Felddaten geben realistische Prioritäten (Search Console / CrUX). PageSpeed/Lighthouse dienen zum Debugging, aber bei Ranking-/Experience-Entscheidungen sind CrUX-/Search Console-Signale entscheidend. (support.google.com)

Business-Impact kurz erklärt

• Geschwindigkeit und Interaktivität beeinflussen Nutzung und Umsatz: Langsame Seiten führen zu höheren Absprüngen. Google hebt hervor, dass Page-Experience-Signale Bestandteil des Ranking-Systems sind und Core Web Vitals für den Sucherfolg entscheidend sind. (Core Web Vitals als Teil der Page Experience). (developers.google.com)
• Im E-Commerce: Hohe Checkout-Abbruchraten sind ein klarer Umsatzhebel. Das Baymard Institute dokumentiert, dass durchschnittlich rund 70 % aller Warenkörbe abgebrochen werden. Viele Abbrüche sind UX-/Performance-bedingt und durch Optimierungen reduzierbar. Konkrete UX-Verbesserungen am Checkout können den Umsatz unmittelbar steigern. (baymard.com)
• Sicherheit und Vertrauenssignale (HTTPS, aktuelles TLS, OWASP-Risiken) beeinflussen Reputation, Indexierung und rechtliche Haftung. HTTPS wird von Google bevorzugt und sollte Standard sein. (developers.google.com)

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

• Jetzt (tägliche bis 2-wöchige Maßnahmen)
  • Search Console-Check: Core Web Vitals Report + Coverage + HTTPS-Report; priorisiere alle „Poor“-URL-Gruppen. (support.google.com)
  • Notfall-Sicherheit: Stelle sicher, dass HTTPS für alle Seiten aktiv ist (kein Mixed Content) und prüfe auf kritische OWASP-Funde. (owasp.org)
  • Content/CTA-Quickwins: Klare, sichtbare Kontakt-/Kauf-CTAs auf wichtigen Seiten; reduzierte Formularfelder beim Checkout/Anfrageformular.
• Nächste Schritte (2–8 Wochen)
  • Performance-Fixes auf Page-Level: Bild-Optimierung, Caching, kritisches CSS/JS-Splitting, Server-/Hosting-Überprüfung. Testen mit PageSpeed Insights + Lighthouse und erneut mit Search Console Validierung. (pagespeedinsights.dev)
  • UX-A/B-Tests auf Titel, CTA, Formularen; Priorität nach Remarketing-Funnel-Daten.
• Später (2–6 Monate)
  • Architekturüberprüfung: Wenn wiederholt dieselben Performance-/Indexier- oder Integrationsprobleme auftreten (z. B. CMS-Limits, schwer wartbare Frontend-Architektur), evaluiere Neuaufbau / Plattformwechsel.
  • Governance/Monitoring: Automatisiertes CWV-Monitoring (CrUX API, PageSpeed Insights API), regelmäßige Security-Scans, Content-Governance (Qualitätscheck gegen Googles „helpful content“ Richtlinien). (developer.chrome.google.cn)

Entscheidungskriterien: Redesign oder Neuaufbau

• Redesign (meist günstigere Option), wähle wenn:
  • Probleme sind primär optisch/inhaltlich (schlechtes Messaging, unklare CTAs, veraltete Texte) und die technische Basis (CMS, Hosting) misst akzeptable Core-Web-Vitals-Grenzwerte oder lässt sich mit gezielten Fixes stabilisieren.
  • Such-/Indexierungsprobleme sind Einzelfälle, nicht systemisch; Security-Risiken sind patchbar.
• Neuaufbau (höherer Aufwand, nachhaltiger), wähle wenn:
  • Die Mehrheit der URLs zeigt dauerhaft „Poor“ in der Search Console, insbesondere wegen P75-Messwerten für LCP/INP/CLS über 28 Tage — das deutet auf strukturelle Performance- oder Architekturprobleme hin. (support.google.com)
  • Das CMS/Theme/Tech-Stack verhindert notwendige Optimierungen (z. B. kein kontrollierter Cache, schwergewichtige Frontend-Library, schlechte Bild-Pipeline).
  • Hohe technische Schulden: Sicherheitslücken, veraltete Abhängigkeiten, schlecht wartbare Integrationen oder unskalierbare Hosting-Konfigurationen (z. B. langsame TTFB trotz CDN).
• Wirtschaftliche Schwelle: Berechne „Payback“ — erwartete zusätzliche Leads/Orders × Conversion-Lift × Customer-Lifetime-Value gegen Projekt- und Betriebskosten. Wenn Payback < 12–18 Monate, ist Neubau oft gerechtfertigt; ansonsten zielgerichtetes Redesign.

Verifizierte Fakten (gekürzte Liste)

• Core Web Vitals: LCP ≤ 2,5 s, INP < 200 ms, CLS < 0,1 (als Good-Thresholds). (developers.google.com)
• Search Console bewertet Core Web Vitals auf P75 (75. Perzentil) über 28 Tage; URL-Gruppen zeigen „Poor/Need improvement/Good“. (support.google.com)
• INP (Interaction to Next Paint) hat FID als Responsiveness-Metrik ersetzt (Einführung und Terminierung durch Google/Chrome). (developers.google.com)
• Google hat die „helpful content“-Initiative gestartet: Originalität und Nutzer-Nutzen sind Ranking-Relevanz-Faktoren für Content. (blog.google)
• Baymard Institute dokumentiert einen globalen durchschnittlichen Warenkorb-Abbruch von rund 70 % (Meta-Analyse/Research). (baymard.com)

Empfehlungen (professionelle Einschätzung, getrennt)

• Wenn die Search Console systemisch „Poor“ meldet (viele URL-Gruppen, P75-Grenzen überschritten), ist ein Neuaufbau oder ein Architektur-Refactoring die nachhaltigste Lösung.
• Wenn Probleme hauptsächlich auf wenigen Seitentypen (z. B. Landingpages, Checkout) liegen: Fokussiertes Redesign + technische Fixes beschleunigt ROI.
• Priorisiere: 1) Sicherheitsgrundlagen und HTTPS, 2) Core Web Vitals (LCP → INP → CLS), 3) Conversion-UX (sichtbare CTAs, Formular-Reduktion), 4) Content-Qualität für AI/Serp-Features (helpful content). (owasp.org)
• Arbeite iterativ: Track->Fix->Validate (Search Console Validierung für CWV-Fixes) und messe Umsatzwirkung per A/B-Test.

Kompakte Checkliste (sofort anwendbar)

1. Anmeldung / Check: Search Console anlegen, Core Web Vitals + Coverage + HTTPS prüfen. (support.google.com)
2. Kritisch: HTTPS komplett (kein Mixed Content); Security-Scan gegen OWASP-Top-10. (support.google.com)
3. Performance-Schnelltest: PageSpeed Insights (mobil + Desktop) für Top-10 Seiten; notiere LCP/INP/CLS. (pagespeedinsights.dev)
4. Priorisieren: Alle „Poor“ URL-Gruppen in Search Console als erstes fixen. (support.google.com)
5. UX-Quickwins: Sichtbare CTA, Formularfelder reduzieren, Trust-Elemente (Bewertungen, Garantien).
6. Wenn >30–50 % der wichtigen URLs dauerhaft „Poor“ sind → Architektur-Evaluation (Neuaufbau erwägen). (support.google.com)
7. Monitoring: CWV-Dashboards (CrUX API / Search Console API) + automatisierte PageSpeed-Checks. (developer.chrome.google.cn)

Abschluss-Hinweis
Beginnen Sie mit den Daten aus Ihrer Search Console und PageSpeed Insights: die Plattform gibt sowohl die Messwerte als auch die Validierungs-Workflows vor. Entscheiden Sie wirtschaftlich (Return on Investment), nicht emotional: Ein Redesign kann schnell sichtbar sein, löst aber keine systemischen Architektur- oder Performance-Bremser; ein Neuaufbau kostet mehr, bringt aber oft dauerhafte Skalierbarkeit und geringere Betriebskosten. Verwenden Sie die obigen Kriterien und die Checkliste als Entscheidungs- und Aktionsrahmen.