Jede Agentur, die Redesigns verkauft, hat eine Zahl: drei Jahre, oder zwei, oder fünf. Keine davon stammt aus Forschung — sie stammt aus der Länge eines typischen Verkaufszyklus. Eine Website verfällt nicht mit dem Alter, wie ein Dach verfällt. Sie verfällt, wenn die Welt um sie herum sich bewegt und sie stehen bleibt, und die Dinge, die sich bewegen, tun das an veröffentlichten, prüfbaren Daten: Ein PHP-Zweig verliert den Sicherheitssupport, eine Barrierefreiheitsrichtlinie wird durchsetzbar, eine Ranking-Metrik wird ersetzt, ein Browser-Feature wird sicher nutzbar. Genau das macht „ist es so weit?“ beantwortbar statt zur Geschmacksfrage. Klick unten auf jede Phase für das, was darin wirklich altert, was du messen solltest und welche Meilensteine den Punkt markieren, an dem Reparieren aufhört, die günstigere Option zu sein.
— Timeline
Wann ein Redesign deiner Website fällig ist — und wann wirklich nicht.
Nichts an einer Website läuft nach drei Jahren ab. Bestimmte Dinge altern an Daten, die du nachschlagen kannst — eine Runtime, ein Barrierefreiheitsgesetz, eine Ranking-Metrik, ein Designsystem — und jedes davon hat eine andere Antwort. Hier steht, was wann altert und welche Signale einen Neubau wirklich rechtfertigen.
Was wirklich altert, Jahr für Jahr
Jahr 0 ist der Launch-Tag — oder der Tag deines letzten Redesigns, je nachdem, was später war. Wähl eine Phase, um zu sehen, was darin altert, was du messen solltest und welche Meilensteine hineinfallen.
Jahre 0–1
Jahr eins: messen, nicht anfassen
Eine Website unter einem Jahr braucht so gut wie nie ein Redesign, und der Druck, sie zu ändern, kommt meist aus dem eigenen Haus, nicht aus den Daten. Die einzige Arbeit, die sich hier auszahlt, ist Messung: Du kannst in Jahr drei weder für noch gegen ein Redesign argumentieren, ohne eine Basis aus Jahr eins zum Vergleichen.
Was wirklich altert
- Es ist noch nichts gealtert. Der Stack ist aktuell, das Design ist das, das alle abgenommen haben, und die Inhalte sind so frisch, wie sie je sein werden.
- Was sich ändert, ist deine eigene Meinung davon. Teams langweilen sich an einem Design ungefähr achtzehn Monate, bevor Kunden überhaupt merken, dass es existiert — Vertrautheit ist keine Veralterung.
- Echte Nutzung kommt an und widerlegt Annahmen: Seiten, die niemand auf dem Zettel hatte, werden die meistbesuchten, und Seiten, um die wochenlang gestritten wurde, bekommen fast keinen Traffic.
- Kleine strukturelle Fehler tauchen auf — ein Formularfeld, das Leute verliert, ein Menüpunkt, den niemand versteht. Das sind Korrekturen, kein Redesign.
Was du messen solltest
- Nimm im ersten Monat eine Basis auf: Core Web Vitals aus Felddaten, Conversion-Rate je Seitentyp, organische Einstiegsseiten und den Mobilanteil am Traffic. Alles Spätere in dieser Timeline wird an diesen vier Zahlen gemessen.
- Verfolge, welche Seiten tatsächlich Traffic verdienen. Ein Redesign, das mit einem Seiteninventar begründet wird, schlägt eins, das mit einem Moodboard begründet wird.
- Notier jedes „das sollten wir ändern“, statt auf jedes einzeln zu reagieren. Ein Jahr dieser Liste ist das ehrlichste Redesign-Briefing, das du je bekommst.
Meilensteine
- J0Basis beim Launch erfasst — Vitals, Conversion, Einstiegsseiten, Geräteverteilung
- J1Erstes volles Jahr gegen diese Basis ausgewertet
Die Jahre sind ein realistisches Band, keine Regel — eine gut gewartete Seite kann Jahr sechs ohne strukturellen Handlungsbedarf passieren, und eine schlecht geplante landet in achtzehn Monaten im Neubau-Territorium. Die datierten Punkte sind prüfbar: die PHP-Supportfenster, der INP-Wechsel am 12. März 2024, der European Accessibility Act ab dem 28. Juni 2025 und die 30-Monats-Baseline-Regel stammen alle aus den Quellen unten. Phasenstruktur und Schwellen sind unsere eigenen, aus Kundenprojekten.
Das Signal, was es wirklich heißt und was die Behebung kostet
| Was du siehst | Worauf es meist hindeutet | Reparieren oder neu bauen |
|---|---|---|
| Traffic ist flach, Rankings sind stabil | Ein Inhalts- und Intent-Problem. Die vorhandenen Seiten sind nicht die Seiten, nach denen gesucht wird. | Reparieren. Das ist ein Inhaltsprojekt, und ein Redesign ändert das Ergebnis nicht. |
| Conversion ist gefallen, obwohl sich bei dir nichts geändert hat | Etwas Externes hat sich bewegt — das Angebot eines Wettbewerbers, eine Anzeigen-Landingpage, eine Browser-Voreinstellung, eine Preiserwartung. | Reparieren auf Seitenebene. Ein Conversion-Redesign trifft die Templates, die verloren haben, nicht die ganze Seite. |
| Jede Inhaltsänderung braucht Entwicklung | Das CMS wurde um das alte Design herum modelliert, nicht um deine Inhalte. Die Reibung summiert sich täglich. | Reparieren, wenn das Modell korrigierbar ist; neu bauen, wenn die Plattform nicht abbilden kann, was du verkaufst. |
| Deine Runtime ist über das Ende des Sicherheitssupports hinaus | Eine datierte, prüfbare Tatsache — keine Meinung. Und der günstigste Punkt auf dieser Liste. | Reparieren. Ein Website-Upgrade erledigt das, ohne das Design anzufassen. |
| Sie erfüllt WCAG 2.1 AA nicht und du verkaufst an EU-Verbraucher | Rechtliches Risiko seit dem 28. Juni 2025, mit Sanktionen je Mitgliedstaat. | Erst reparieren. Neu bauen nur, wenn die Markup-Struktur selbst die Konformität blockiert. |
| Über 60% Mobiltraffic auf einem Desktop-zuerst-Layout | Ein struktureller Bruch zwischen Design und Publikum, keine Stilfrage. | Templates neu bauen. Responsives Verhalten nachträglich in ein Desktop-Grid zu zwingen kostet mehr als Ersetzen. |
| Jede neue Seite braucht ein neues Einzelfall-Template | Das Designsystem wurde von Ausnahmen aufgefressen — Nielsens Kohärenzargument in der Praxis. | Neu bauen. Das ist das einzige Signal auf der Liste, das eine Reparatur wirklich nicht löst. |
Fünf dieser sieben Signale enden bei Reparatur. Dieses Verhältnis ist das ehrliche Bild und der Grund, warum wir eine Analyse anbieten, bevor wir ein Redesign anbieten, und nicht umgekehrt.
Die Drei-Jahres-Regel ist ein Verkaufszyklus, kein Befund
Hinter „alle zwei bis drei Jahre ein Redesign“ steht keine Studie. Es gibt keine gemessene Halbwertszeit für eine Website, keinen Punkt, an dem HTML verfällt, und keinen Beleg, dass eine vier Jahre alte Seite schlechter konvertiert als eine ein Jahr alte, wenn beide gepflegt werden. Es gibt eine oft wiederholte Zahl, die zufällig dazu passt, wie oft eine Agentur dir gern ein Projekt verkaufen würde.
Der nützliche Ersatz für die Regel ist eine Frage: Was genau hat sich geändert, seit diese Seite gebaut wurde, und verlangt die Behebung den Austausch der Struktur? Fast immer lautet die ehrliche Antwort auf die zweite Hälfte nein. Inhalte sind veraltet, ein Template performt schlecht, eine Abhängigkeit ist überholt, eine Barriere muss weg — all das ist Reparaturarbeit, und sie als Redesign zu bepreisen ist der häufigste Weg, auf dem Unternehmen bei ihrer Website zu viel ausgeben.
Vier Uhren laufen unterschiedlich schnell
Inhalte laufen am schnellsten. Leistungen, Preise, Team, Case Studies und Belege veralten innerhalb von ein bis zwei Jahren nach jeder echten Veränderung im Unternehmen, und kein Maß an visueller Politur gleicht eine Seite aus, die eine Firmenversion beschreibt, die es nicht mehr gibt.
Die Plattform-Uhr läuft nach veröffentlichten Daten. PHP gibt jedem Zweig zwei Jahre aktiven Support und ein weiteres Jahr Sicherheitsfixes, alles vorab angekündigt — 8.2 bekommt nach dem 31. Dezember 2026 keine Sicherheitsfixes mehr, und jeder Zweig davor ist längst darüber hinaus. Frameworks, CMS-Versionen und Zahlungs-APIs funktionieren genauso. Nichts davon ist eine Überraschung, und genau deshalb ist es vermeidbar, davon überrascht zu werden.
Die Standards-Uhr läuft langsamer, ist aber härter. Interaction to Next Paint hat First Input Delay am 12. März 2024 als Core Web Vital abgelöst, mit einer „gut“-Schwelle von 200 ms im 75. Perzentil — eine auf die alte Metrik optimierte Seite hat sich nicht verändert, wohl aber das, wonach sie benotet wurde. Auf der Browser-Seite zählt ein Feature erst 30 Monate nach der Unterstützung durch alle Kernbrowser als Baseline „widely available“, ein drei Jahre alter Codebestand schleppt also Workarounds mit, die inzwischen reines Gewicht sind.
Die rechtliche Uhr hat die härtesten Kanten. Der European Accessibility Act ist seit dem 28. Juni 2025 durchsetzbar, wird gegen EN 301 549 durchgesetzt, das auf WCAG 2.1 AA aufbaut, und gilt auch für Unternehmen außerhalb der EU, die an EU-Verbraucher verkaufen. Das ist die eine Uhr, bei der „machen wir nächstes Jahr“ einen Preis hat, den eine Aufsichtsbehörde festlegt und nicht du.
Upgrade schlägt Redesign öfter, als Redesign-Verkäufer zugeben
Nimm die sieben Signale aus der Tabelle oben. Fünf davon werden repariert, ohne die Struktur anzufassen: ein Inhaltsprojekt, eine Conversion-Korrektur auf Template-Ebene, ein Runtime-Upgrade, eine Barrierefreiheitskorrektur, eine Korrektur des Inhaltsmodells. Nur zwei — ein Desktop-zuerst-Layout unter mobilem Mehrheitstraffic und ein von Ausnahmen ersetztes Designsystem — verlangen wirklich einen Neubau, weil in beiden Fällen genau die Struktur das Falsche ist.
Finanziell ist das relevant, weil die beiden Wege nicht annähernd gleich teuer sind. Ein Website-Upgrade bringt die Seite auf einen unterstützten Stack und repariert, was kaputt ist, während Design, URLs und Ranking-Historie erhalten bleiben. Eine Technische Analyse ist der günstigere Schritt vor beiden Entscheidungen: Sie liefert Versionsnummern, Feld-Vitals und Konformitätslücken als Liste, damit das Redesign-Gespräch bei Fakten anfängt statt bei der Person im Raum, die die Startseite am meisten satthat.
Wir sind ein kleines Studio und haben keine Redesign-Quote zu erfüllen. Einer Kundin oder einem Kunden zu sagen, dass 800 € Inhaltsarbeit reichen statt eines fünfstelligen Neubaus, kostet uns die größere Rechnung und gewinnt die Beziehung — dieser Tausch hat sich jedes Mal gelohnt.
Wann ein Neubau wirklich die richtige Antwort ist
Das stärkste Argument für einen Neubau ist nicht visuell und war es nie. Jakob Nielsen hat es 2009 präzise formuliert: Inkrementelle Änderung ist normalerweise richtig, weil Menschen Umbrüche nicht mögen — aber „auf lange Sicht zerstört Inkrementalismus die Kohärenz und verlangt nach einer neuen UI-Architektur“. Jede Seite, die fünf Jahre lang geflickt wurde, erreicht irgendwann den Punkt, an dem Besucher faktisch die Flicken benutzen und nicht das Design.
Das zweite belastbare Argument ist strukturell: Das Inhaltsmodell kann nicht mehr abbilden, was das Unternehmen verkauft. Einen Markt, eine Sprache, einen Produkttyp oder eine Leistungslinie hinzuzufügen sollte ein neuer Eintrag sein, kein Workaround. Wenn es jedes Mal ein Workaround ist, ist das Datenmodell das Problem, und Designarbeit reicht dort nicht hin. Unser Leitfaden zur mehrsprachigen Architektur behandelt die Variante, die am härtesten zubeißt.
Das dritte ist messbar statt architektonisch: Die Änderungskosten steigen. Wenn die letzten fünf Anfragen sichtbar länger gedauert haben als dieselben Anfragen vor zwei Jahren, ist diese Linie das Neubau-Argument, und es ist das einzige, das den Kontakt mit der Finanzleitung übersteht.
Kein guter Grund: Das Team langweilt sich, ein Wettbewerber hat relauncht, oder das Design „wirkt veraltet“ auf die Leute, die es täglich sehen. Das sind echte Gefühle und furchtbare Briefings. Wenn ein Neubau keine der vier Zahlen bewegen würde, die du in Jahr eins als Basis festgehalten hast, ist es ein Neuanstrich — völlig legitim zu kaufen, solange er auch als solcher bepreist und begründet wird.
Neu bauen, ohne wegzuwerfen, was schon funktioniert
Ein Redesign, das Rankings verliert, ist eine selbst zugefügte Wunde und häufig genug, um vorhersehbar zu sein: URLs ändern sich ohne Weiterleitungen, das Staging-noindex geht in Produktion, interne Links zeigen auf die alte Struktur. Die komplette Abfolge steht in Redesign ohne SEO-Verlust, und für größere Plattformen behandelt der Leitfaden zur Enterprise-CMS-Migration die Mechanik der Umstellung.
Behalte die Belege, ersetze die Struktur. Das Seiteninventar, die Templates mit der besten Conversion, die Einstiegsseiten mit organischem Traffic und die Texte, die an echten Kunden getestet wurden, sind Vermögenswerte — ein Neubau sollte sie alle erben und nur das neu schreiben, was die Daten als Fehlschlag ausweisen.
Plan das Stabilisierungsfenster ein, statt so zu tun, als gäbe es keins. Echter Traffic findet Dinge, die Staging nie findet, und ein Neubau ist nicht am Launch-Tag fertig — er ist fertig, wenn der erste Monat ruhig vergangen ist. Genau dafür ist Monatliche Wartung gedacht.
Wie wir das mit Kunden entscheiden
Wir starten mit einer Technischen Analyse, weil sie die strittige Hälfte der Frage in wenigen Tagen klärt: Versionen gegen End-of-Life-Daten, Core Web Vitals aus dem Feld inklusive INP, WCAG-2.1-AA-Lücken und ein Seiteninventar mit Traffic daran. Der größte Teil der „braucht das ein Redesign?“-Debatte löst sich auf, sobald diese vier Listen existieren.
Lautet die Antwort Reparatur, deckt ein Website-Upgrade den Stack und die kaputten Teile ab, und ein Conversion-Redesign genau die Templates, die Geld verlieren — keines von beiden fasst URLs oder Ranking-Historie an.
Lautet die Antwort Neubau, sagen wir das und planen ihn gegen die Basis aus Jahr eins, nicht gegen ein Moodboard. Ein Neubau, der nicht benennen kann, welche Zahlen er bewegen soll, ist ein Neuanstrich mit größerer Rechnung, und den verlieren wir lieber, als ihn zu liefern.
Quellen
Jede datierte Aussage oben — Supportkalender, Metrikwechsel, die Barrierefreiheitsfrist und die Baseline-Regel — stammt aus diesen Quellen, geprüft im August 2026. Phasenstruktur, Schwellen und die Aufteilung zwischen Reparatur und Neubau sind unsere eigenen, aus Kundenprojekten.
- PHP — Supported Versions ↗
Der offizielle Supportkalender: Jeder Zweig bekommt rund zwei Jahre aktiven Support plus ein weiteres Jahr Sicherheitsfixes. PHP 8.2 (veröffentlicht am 8. Dezember 2022) erhält Sicherheitsfixes bis zum 31. Dezember 2026, 8.3 bis zum 31. Dezember 2027, 8.4 bis zum 31. Dezember 2028. Alles vor 8.2 ist bereits End-of-Life.
- web.dev — Interaction to Next Paint becomes a Core Web Vital on March 12 ↗
Googles eigene Ankündigung, dass INP am 12. März 2024 First Input Delay als Core Web Vital abgelöst hat und FID im selben Zug abgekündigt wurde.
- web.dev — Interaction to Next Paint (INP) ↗
Definiert die Schwellen im 75. Perzentil: gut bei 200 ms oder darunter, verbesserungswürdig zwischen 200 und 500 ms, schlecht über 500 ms — und bestätigt INP als Nachfolgemetrik von FID.
- EUR-Lex — Directive (EU) 2019/882 (European Accessibility Act) ↗
Die Richtlinie selbst. Die Mitgliedstaaten wenden ihre Maßnahmen seit dem 28. Juni 2025 an, für E-Commerce, Bankdienstleistungen, Verkehr und digitale Verbraucherdienste — einschließlich Unternehmen außerhalb der EU, die an EU-Verbraucher verkaufen.
- web.dev — Baseline ↗
Definiert „newly available“ (von allen Kernbrowsern unterstützt) und „widely available“ (30 Monate nach diesem Datum). Diese 30 Monate sind der Grund, warum ein drei Jahre alter Codebestand meist Workarounds mitschleppt, die er nicht mehr braucht.
- Nielsen Norman Group — Fresh vs. Familiar: How Aggressively to Redesign ↗
Jakob Nielsen, September 2009. Plädiert für inkrementelle Änderung als Standard, mit genau der Ausnahme, auf die sich dieser Leitfaden stützt: „auf lange Sicht zerstört Inkrementalismus die Kohärenz und verlangt nach einer neuen UI-Architektur.“
- HTTP Archive — Web Almanac 2025, CMS chapter ↗
Core-Web-Vitals-Bestehensquoten nach Plattform aus dem echten Web — nützlich als externer Maßstab, wenn du beurteilst, ob deine Felddaten ein Seiten- oder ein Plattformproblem zeigen.
— FAQ
Häufig gestellte Fragen
Unsicher, ob deine Seite einen Neubau braucht oder nur eine Reparaturliste?
Schick uns die URL und was dich daran stört, und wir sagen dir, welches von beidem es tatsächlich ist — auch wenn die Antwort „lass sie in Ruhe“ lautet.