Websites responsive Design: bestehende Seiten prüfen, nachrüsten und abnehmen

Eine bestehende Website responsiv zu machen ist Umbau, nicht Neubau. Das Layout steht, die Inhalte sind eingepflegt, die Templates laufen produktiv. Genau deshalb scheitert die Nachrüstung selten am fehlenden Wissen über Media Queries, sondern an festen Breiten, absolut positionierten Elementen, Hover-Menüs und Bildern, die für eine einzige Desktopdarstellung erzeugt wurden. Jede dieser Abhängigkeiten muss einzeln gelöst werden, ohne Inhalte, Funktionen oder das vertraute Erscheinungsbild zu beschädigen.

Dieser Leitfaden beschreibt den Weg in der Reihenfolge, in der er im Bestand tatsächlich funktioniert: erst messen, was bricht, dann priorisieren, dann die technische Basis herstellen, dann Layout, Medien und Komponenten umbauen und am Ende geräteübergreifend abnehmen. Die Prüfliste im hinteren Teil ist die Abnahme, nicht die Einleitung.

Schritt 1: Bestandsaufnahme statt Bauchgefühl

Beginnen Sie mit einer Liste der Seitentypen, nicht der Seiten. Eine Website mit 4.000 URLs hat meist zwölf bis zwanzig Templates, und ein Fehler im Template betrifft alle Seiten, die es verwenden. Erfassen Sie mindestens:

• Startseite
• Übersichts- und Kategorieseiten
• Artikel-, Ratgeber- und Produktdetailseiten
• Suche, Filter und Kontaktformulare
• mehrstufige Abläufe wie Warenkorb oder Anmeldung
• die globalen Bausteine Header, Footer, Cookie-Banner und Dialogfenster

Öffnen Sie jeden Seitentyp zunächst in einem Browserfenster und ziehen Sie die Breite langsam zusammen. Ein Gerätewechsel per Dropdown zeigt Ihnen den Bruchpunkt nicht, das langsame Verkleinern schon. Testen Sie anschließend mindestens ein echtes Smartphone: Touchziele, eingeblendete Browserleisten, die Bildschirmtastatur und das Verhalten beim Drehen bildet keine Simulation vollständig ab.

Typische Befunde, nach denen Sie gezielt suchen können:

• Die gesamte Seite lässt sich horizontal verschieben, obwohl sie es nicht müsste.
• Texte, Schaltflächen oder Bilder ragen aus ihrem Container.
• Spalten werden schmaler als ihr Inhalt, statt umzubrechen.
• Navigationselemente oder Sticky-Leisten überdecken den Inhalt.
• Funktionen sind nur per Hover erreichbar und auf Touch tot.
• Modale Fenster lassen sich nicht vollständig sehen oder nicht schließen.
• Tabellen verlieren Spalten oder erzwingen horizontales Scrollen der kompletten Seite.
• Formulareingaben, Abstände oder Schrift sind für Fingerbedienung zu klein.

Protokollieren Sie jeden Befund mit URL, Viewport-Breite, betroffener Komponente, Screenshot und einem Satz Beschreibung. Die Spalte “Komponente” ist die wichtigste: Sie entscheidet später, ob Sie eine Seite oder vierzig Seiten gleichzeitig reparieren.

Schritt 2: Priorisieren nach Auswirkung und Reichweite

Ein unschöner Abstand und ein nicht erreichbarer Absende-Button sind nicht derselbe Fehler. Ordnen Sie die Befunde in drei Klassen und gewichten Sie innerhalb jeder Klasse nach Reichweite, also nach Zugriffszahlen und Geschäftswert des Seitentyps.

Arbeiten Sie zuerst die hohe Priorität auf den reichweitenstärksten Templates ab. So entsteht früh ein tragfähiger Kern, dessen Lösungen Sie auf die übrigen Templates übertragen können, statt neunzehn Einzelfälle parallel offen zu halten.

Schritt 3: Die technische Basis herstellen

Prüfen Sie zuerst, ob im head jeder Seite der Viewport-Meta-Tag steht:

<meta name="viewport" content="width=device-width, initial-scale=1">

Er sorgt dafür, dass mobile Browser die tatsächliche Gerätebreite als Viewport verwenden, damit responsive Regeln überhaupt wie vorgesehen greifen. Fehlt er, rendert der Browser gegen eine angenommene Desktopbreite und skaliert herunter: Ihr CSS ist dann korrekt und wirkungslos zugleich. Bei älteren Websites fehlt der Tag oft nur in einzelnen Sonder-Templates wie Druckansichten oder Landingpages, weshalb eine Stichprobe auf der Startseite nicht genügt.

Durchsuchen Sie danach das Stylesheet nach starren Vorgaben. Kandidaten sind feste Pixelbreiten auf Layoutcontainern, min-width auf Inhaltsbereichen, feste Höhen sowie absolute Positionierung mit negativen Außenabständen:

.wrapper {
  width: 1200px;
}

.content {
  min-width: 900px;
}

.sidebar {
  width: 360px;
}

Diese Angaben sind nicht per se falsch. Kritisch werden sie erst, wenn schmale Viewports keine Alternative erhalten. Für übergeordnete Container ist die Kombination aus flexibler Breite und begrenzter Maximalbreite fast immer der bessere Ersatz:

.wrapper {
  width: min(100% - 2rem, 75rem);
  margin-inline: auto;
}

Der Container nutzt damit auf schmalen Bildschirmen den verfügbaren Raum mit seitlichem Abstand und wächst auf großen Bildschirmen nicht unbegrenzt.

Suchen Sie zusätzlich die Ursache für horizontales Scrollen. Ein verbreiteter Fehlgriff ist overflow-x: hidden auf body oder html: Das versteckt das Symptom, macht überstehende Inhalte aber unerreichbar statt lesbar. Besser ist es, das überbreite Element zu identifizieren und dort zu korrigieren.

Schritt 4: Das Layout in kontrollierten Schritten umbauen

Bauen Sie von außen nach innen um, in dieser Reihenfolge.

Hauptcontainer flexibel machen. Ersetzen Sie feste Breiten durch Grid oder Flexbox mit begrenzter Maximalbreite. Ein zweispaltiges Seitenlayout lässt sich meist so nachrüsten:

.page-layout {
  display: grid;
  grid-template-columns: minmax(0, 1fr) 20rem;
  gap: 2rem;
}

@media (width < 50rem) {
  .page-layout {
    grid-template-columns: 1fr;
  }
}

Das minmax(0, 1fr) ist kein Detail: Ohne die Null als Minimum schrumpft eine Grid-Spalte nicht unter die intrinsische Breite ihres Inhalts, und ein einziger langer Code- oder URL-String erzeugt weiterhin Überbreite.

Reihenfolge im HTML prüfen. Wenn nebeneinanderliegende Bereiche untereinander rutschen, entscheidet die Dokumentreihenfolge, was zuerst gelesen wird. Der Hauptinhalt darf nicht hinter einer langen Seitenleiste liegen. Korrigieren Sie das möglichst im Markup, nicht ausschließlich mit order, weil Tastaturbedienung und Screenreader der Dokumentstruktur folgen.

An der Komponente reparieren, nicht an der Seite. Wenn dieselbe Kachel auf vierzig Unterseiten steht, gehört die Regel in die gemeinsame Komponente:

.card-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1.25rem;
}

Die Spaltenzahl richtet sich damit nach dem tatsächlich verfügbaren Platz. Zusätzliche Regeln für einzelne Gerätemodelle entfallen.

Feste Höhen auflösen. Derselbe Text braucht auf schmalen Viewports mehr Zeilen. Eine fixe Karten- oder Headerhöhe schneidet ihn ab. Verwenden Sie min-height dort, wo eine Mindestgröße gestalterisch nötig ist, und lassen Sie die reale Höhe vom Inhalt bestimmen.

Schritt 5: Breakpoints aus dem Inhalt ableiten

Breakpoints sollten sich am Platzbedarf des Inhalts orientieren und vorzugsweise mit relativen Einheiten statt anhand bestimmter Gerätemodelle definiert werden. Eine Liste von Gerätebreiten veraltet jedes Jahr, der Punkt, an dem eine Navigation nicht mehr in eine Zeile passt, bleibt stabil.

Das Verfahren ist mechanisch: Fenster langsam verkleinern, beobachten, wann eine Komponente kippt, dort den Breakpoint setzen. Verlässliche Signale sind umbrechende Navigationspunkte, zwei Spalten, die für ihren Inhalt zu schmal werden, Überschriften mit störenden Einzelwörtern, zu dicht aneinanderrückende Bedienelemente und eine Kartenansicht, die ihre sinnvolle Mindestbreite verliert. Notieren Sie zu jedem Breakpoint, welche Komponente ihn begründet hat. Das verhindert, dass später jemand einen Wert “aufräumt”, dessen Zweck niemand mehr kennt.

Media Queries wenden CSS-Regeln abhängig von Merkmalen wie Viewport-Breite, Auflösung, Ausrichtung oder Benutzereinstellungen an. Für die Nachrüstung genügt in der Regel die Breite in rem, ergänzt um prefers-reduced-motion, falls animierte Menüs im Spiel sind.

Bei Mobile First wird zunächst ein einfaches Layout für schmale Viewports erstellt und anschließend für breitere Ansichten erweitert. In einem gewachsenen Desktop-Stylesheet ist die vollständige Umkehr auf einen Schlag riskant. Der pragmatische Weg im Bestand: Das bestehende CSS bleibt zunächst die Basis, Sie ergänzen gezielte Regeln für schmale Ansichten, und jede Komponente, die Sie ohnehin anfassen, wird beim Umbau auf Mobile First gedreht. Nach einigen Wochen ist der Anteil der invertierten Komponenten groß genug, um den Rest nachzuziehen.

Schritt 6: Navigation umbauen

Die Navigation ist der aufwendigste Teil fast jeder Nachrüstung. Ein eingeklapptes Menü braucht einen echten Button als Auslöser, kein div mit Klick-Handler:

<button
  class="menu-toggle"
  aria-expanded="false"
  aria-controls="main-navigation">
  Menü
</button>

JavaScript aktualisiert aria-expanded bei jedem Wechsel. Zusätzlich gehören dazu: eine verständliche Beschriftung, eine ausreichend große Bedienfläche, ein sichtbares Fokusmerkmal, Schließen per Escape und ein Fokus, der nach dem Schließen zum Auslöser zurückkehrt.

Mehrstufige Hover-Menüs dürfen nicht unverändert auf Touch übertragen werden. Untermenüs brauchen einen eigenen Auslöser, und der erste Tipp auf einen Elternpunkt darf nicht gleichzeitig das Untermenü öffnen und die Seite laden.

Schritt 7: Bilder, Videos und Einbettungen

Die erste Maßnahme verhindert Überbreiten. Medien lassen sich mit max-width: 100% daran hindern, über die Breite ihres Containers hinauszuragen:

img,
video,
iframe {
  max-width: 100%;
}

img,
video {
  height: auto;
}

Damit ist die Darstellung gerettet, die Übertragung noch nicht: Ein Smartphone lädt weiterhin die Datei, die für eine große Desktopdarstellung erzeugt wurde. Die HTML-Attribute srcset und sizes sowie das picture-Element ermöglichen die Auswahl geeigneter Bildressourcen für unterschiedliche Darstellungsbedingungen:

<img
  src="team-800.jpg"
  srcset="team-480.jpg 480w, team-800.jpg 800w, team-1400.jpg 1400w"
  sizes="(max-width: 48rem) 100vw, 50vw"
  alt="Das Projektteam in einem Besprechungsraum"
  width="1400"
  height="933">

srcset mit sizes überlässt dem Browser die Auswahl der passenden Auflösung. picture setzen Sie ein, wenn auf schmalen Viewports ein anderer Bildausschnitt nötig ist, etwa weil das Motiv im Panoramaformat unkenntlich wird. Die Angaben width und height bleiben in beiden Fällen wichtig, damit der Browser den Platz vor dem Laden reserviert und der Text nicht springt.

Eingebettete Videos und Karten stabilisieren Sie über das Seitenverhältnis:

.media-embed {
  width: 100%;
  aspect-ratio: 16 / 9;
  border: 0;
}

Widgets von Drittanbietern prüfen Sie separat. Deren interne Breiten sind über das eigene Stylesheet oft nicht erreichbar, und die Lösung ist dann eine Konfiguration beim Anbieter oder ein Ersatz.

Schritt 8: Typografie, Formulare und Tabellen

Lesbarkeit entsteht nicht durch proportionales Verkleinern. Fließtext behält auf kleinen Geräten seine komfortable Größe, verkleinert werden übergroße Überschriften, Randabstände und dekorative Leerflächen. Für Überschriften eignet sich clamp(2rem, 1.5rem + 2vw, 3.5rem), für lange Wörter und URLs overflow-wrap: anywhere, für die Zeilenlänge auf großen Bildschirmen max-width: 70ch.

Formulare werden auf schmalen Viewports einspaltig. Labels bleiben sichtbar, Fehlermeldungen stehen am betroffenen Feld, und die Bildschirmtastatur darf das aktive Feld nicht dauerhaft verdecken. Prüfen Sie das an einem echten Gerät, nicht im Emulator.

Tabellen brauchen eine Entscheidung pro Fall. Bei wenigen Spalten genügt ein eigener Scrollbereich, damit nur die Tabelle scrollt und nicht die Seite:

.table-wrapper {
  overflow-x: auto;
  max-width: 100%;
}

Bei komplexen Datensätzen ist eine gestapelte Darstellung als Schlüssel-Wert-Paare meist besser. Spalten einfach auszublenden ist keine responsive Lösung, sondern Informationsverlust. Denselben Blick brauchen Cookie-Banner, Dialoge mit langen Texten, Kalender und Datumsauswahl, Codeblöcke, Vergleichstabellen, Kartenanwendungen, Charts sowie Sticky Header und schwebende Kontaktbuttons.

Die Abnahme: geräteübergreifende Prüfliste

Prüfen Sie nach jeder Änderung nicht nur die Komponente, sondern den kompletten Seitentyp.

Darstellung und Reflow

• Bei 320 CSS-Pixeln Breite bleiben Inhalte und Funktionen vollständig erhalten.
• Die Seite als Ganzes erzeugt kein horizontales Scrollen, Ausnahmen wie breite Datentabellen haben einen eigenen begrenzten Scrollbereich.
• Nichts überdeckt sich, nichts ist abgeschnitten, Medien bleiben in ihren Containern.
• Hoch- und Querformat funktionieren, Browser-Zoom bis 200 Prozent lässt alle Inhalte erreichbar.

Die 320 Pixel sind kein willkürlicher Wert: WCAG 2.2 Erfolgskriterium 1.4.10 verlangt für nicht ausgenommene, vertikal scrollende Inhalte Reflow bei einer Breite von 320 CSS-Pixeln ohne Informations- oder Funktionsverlust und ohne zweidimensionales Scrollen.

Navigation und Bedienung

• Hauptmenü öffnet und schließt zuverlässig, Untermenüs funktionieren mit Touch, Tastatur und Maus.
• Fokusmarkierungen sind sichtbar, die Tabulatorreihenfolge entspricht der Lesereihenfolge.
• Buttons und Links liegen nicht zu dicht beieinander.
• Sticky Elemente verdecken keine Aktionen, Dialoge lassen sich vollständig bedienen und schließen.

Inhalte und Medien

• Überschriften, lange Wörter, URLs und Codeblöcke erzeugen keine Überbreite.
• Bilder behalten ihr Seitenverhältnis, passende Größen werden ausgeliefert, das Motiv bleibt bei geändertem Ausschnitt erkennbar.
• Videos enthalten erreichbare Steuerelemente.
• Tabellen behalten verständliche Überschriften und Zuordnungen.

Formulare

• Jedes Feld hat eine erkennbare Beschriftung, Eingaben lösen kein unbeabsichtigtes Zoomen aus.
• Auswahlfelder und Datumseingaben funktionieren auf Touchgeräten.
• Fehler- und Erfolgsmeldungen erscheinen im sichtbaren Bereich, Absenden, Zurückgehen und Abbrechen sind jederzeit erreichbar.

Geräte und Browser

• Ein kleines und ein großes Smartphone real getestet, eine mittlere Breite geprüft, schmale und breite Desktopansicht geprüft.
• Die tatsächlich unterstützten Browser sind berücksichtigt, das Drehen des Geräts verursacht keine Überlagerungen, eine vergrößerte Standardschrift schneidet nichts ab.

Regressionen verhindern

Halten Sie zu jeder Korrektur fest, auf welchem Seitentyp der Fehler auftrat, welche Komponente verantwortlich war, bei welcher Breite er sichtbar wurde, welche Änderung ihn behoben hat und welche Nachbarkomponenten deshalb erneut zu prüfen sind. Aus diesen fünf Angaben entsteht nebenbei die Dokumentation Ihres Grid- und Breakpoint-Systems.

Definieren Sie außerdem eine kleine Referenzmenge: Startseite, eine Inhaltsseite, eine Übersicht, ein Formular und der komplexeste Sonderfall. Diese fünf Seiten werden nach jeder Änderung an globalem Stylesheet, Navigation, Grid oder Typografie erneut durchgeprüft. Das ist der günstigste Regressionstest, den ein Bestandsprojekt bekommen kann.

Wann Nachrüsten nicht mehr die richtige Antwort ist

Eine schrittweise Nachrüstung lohnt sich, solange Struktur, Inhalte und zentrale Funktionen tragfähig sind. Ein Neuaufbau wird wirtschaftlicher, wenn die Templates untereinander abweichende Layoutsysteme verwenden, wenn zentrale Funktionen an veraltetem JavaScript hängen oder wenn nahezu jede Komponente feste Abmessungen besitzt. Die Bestandsaufnahme aus Schritt 1 bleibt auch dann wertvoll, denn sie sagt dem neuen System, welche Funktionen es abbilden und welche Seitentypen es zuerst abdecken muss.

Der Maßstab für den Erfolg ist nicht die perfekte Momentaufnahme auf drei ausgewählten Geräten. Responsive Web Design ist ein Gestaltungsansatz, mit dem Webseiten auf unterschiedlichen Bildschirmgrößen und Auflösungen benutzbar dargestellt werden, und der Begriff, den Ethan Marcotte 2010 über fluide Raster, flexible Medien und Media Queries beschrieben hat, zielt genau darauf: Eine Seite ist dann fertig nachgerüstet, wenn sie auf den Platz reagiert, den ihr Inhalt tatsächlich bekommt. Flexible Container, aus dem Inhalt abgeleitete Breakpoints und einzeln geprüfte Komponenten sorgen dafür, dass das auch zwischen den getesteten Breiten gilt.