Am Laptop sieht die Seite gut aus. Am Handy klebt die Navigation über der Überschrift, der Text ist winzig, und man muss seitlich schieben, um das Ende einer Zeile zu sehen.
Genau dieses Problem löst responsive design. Der Begriff steht in fast jedem Webdesign-Angebot, erklärt wird er selten, und die Zahlen, mit denen er begründet wird, halten häufig keiner Prüfung stand.
Diese Lektion gibt dir beides: die Mechanik dahinter in verständlicher Sprache und fünf Prüfwege, für die du keine Entwicklerkenntnisse brauchst.
Kurzantwort
Was ist responsive design?
Responsive design ist eine Bauweise: Die Website liefert denselben Inhalt unter derselben Adresse aus, und das Layout passt sich der Bildschirmbreite an. Es ist keine Technologie und kein Produkt, sondern ein Ansatz aus fließenden Rastern, flexiblen Bildern und Media Queries.
Google empfiehlt diese Bauweise ausdrücklich, weil sie am einfachsten umzusetzen und zu pflegen sei.
📌 Für wen ist das relevant: Für alle, die eine Website beauftragen, betreuen lassen oder ein Angebot dazu beurteilen müssen.
- Eine Adresse, ein Inhalt, ein Layout, das sich anpasst
- Es gibt keine offizielle Norm für Breakpoints – die kursierenden Zahlen sind Voreinstellungen von Baukästen
- In Deutschland liegen Handy und Desktop nach der belastbarsten öffentlichen Messung praktisch gleichauf – beide Ansichten zählen, abgenommen wird mobil zuerst
Das lernst du in dieser Lektion
Du verstehst, was technisch passiert, wenn sich ein Layout anpasst – ohne CSS zu lernen.
Du kennst die echte Gerätelage in Deutschland und weißt, wo die richtige Zahl für dich steht.
Du prüfst deine Seite in fünf Stufen – vom 30-Sekunden-Test bis zum Werkzeug, auf das Google selbst verweist.
Du erkennst, wann eine Angebotsposition oder ein Fachbegriff im Gespräch nicht stimmt.
Inhalt
01 ·
Was responsive design ist – und was nicht
Die Referenzdokumentation MDN Web Docs beschreibt responsive design als Gestaltungsansatz, der Webseiten auf allen Bildschirmgrößen gut darstellbar macht und dabei die Bedienbarkeit erhält. Der wichtigere Satz steht direkt daneben: MDN stellt ausdrücklich klar, dass es sich nicht um eine eigene Technologie handelt, sondern um eine Sammlung bewährter Verfahren.
Woher der Begriff kommt
Geprägt hat ihn Ethan Marcotte im Jahr 2010 in einem Artikel des Fachmagazins A List Apart. Er beschrieb damit die Kombination dreier Bausteine, die bis heute die Grundlage bilden.
Die drei Bausteine von responsive design
Nach der Begriffsprägung von Ethan Marcotte (2010), Darstellung nach MDN Web Docs (Stand 08/2026)
Baustein 1
Fließende Raster
Das Layout wird in Anteilen definiert statt in festen Pixelbreiten: eine Spalte ist nicht “320 Pixel breit”, sondern “ein Drittel der Fläche”.
Baustein 2
Flexible Bilder
Bilder passen sich der Containerbreite an, statt herauszuragen – über ihre Originalgröße hinaus aber nicht, sonst werden sie unscharf.
Baustein 3
Media Queries
Gestaltungsregeln, die abhängig von der Fensterbreite greifen. Die Punkte, an denen das Layout umspringt, heißen Breakpoints.
Quelle: MDN Web Docs, “Responsive Design” (developer.mozilla.org), abgerufen 16.08.2026 – Stand 08/2026, eigene Darstellung, Ostend Digital.
Schaubild: Die drei Bausteine und was jeder von ihnen leistet – eigene Darstellung, Ostend Digital, Stand 08/2026.
Was sich seit 2010 geändert hat
MDN formuliert es knapp: Moderne CSS-Layoutverfahren sind von sich aus responsiv. Gemeint sind Flexbox und CSS Grid, mit denen Layouts heute standardmäßig gebaut werden.
Wer mit einem gängigen Theme oder Framework arbeitet, bekommt die Anpassungsfähigkeit deshalb als Grundmechanik mitgeliefert. Welche Werkzeuge infrage kommen, klärt die Lektion zu Baukästen, WordPress und Agentur.
💡 Merke
Responsive design ist eine Bauweise, kein Produkt. Es gibt nichts zu installieren und keine Lizenz zu kaufen.
Findest du in einem Angebot trotzdem eine eigene Position dafür, ist das kein Betrug – aber eine Nachfrage wert. Sektion 8 zeigt, wie du das Gespräch führst.
02 ·
Die eine Zeile, an der es oft scheitert
Es gibt ein Fehlerbild, das jeder kennt. Die Seite lädt am Handy, aber sie sieht aus wie eine geschrumpfte Desktop-Seite: alles miniaturisiert, Text unlesbar klein, man muss zum Lesen zoomen.
Das liegt oft nicht am Layout, sondern an einer einzigen fehlenden Zeile im Kopfbereich der Seite.
html
<meta name="viewport" content="width=device-width,initial-scale=1" />
MDN erklärt die Wirkung so: Diese Zeile teilt mobilen Browsern mit, dass sie die Breite des Anzeigebereichs auf die Gerätebreite setzen und das Dokument in der beabsichtigten Größe darstellen sollen. Die Begründung, warum es diese Ansage braucht, ist erfrischend direkt: Mobile Browser neigten dazu, über ihre Anzeigebreite zu lügen.
Ohne diese Zeile tut der Handy-Browser also so, als sei er ein Desktop-Bildschirm, und zoomt die breite Fassung auf Briefmarkengröße herunter. Die Breakpoints aus Baustein 3 greifen dann unter Umständen gar nicht, weil der Browser eine Breite meldet, die es real nicht gibt.
💡 Praxis-Tipp
Du kannst das ohne Technikkenntnisse melden. Musst du am Handy zoomen, um normalen Fließtext zu lesen, schick deinem Dienstleister genau diesen Satz.
Bitte ihn, den Viewport-Meta-Tag im Seitenkopf zu prüfen. Liegt es daran, ist der Aufwand eine Sache von Minuten.
In verbreiteten Themes und Baukästen sitzt die Zeile in aller Regel schon im Vorlagen-Kopf. Auffällig wird sie bei individuell gebauten Seiten, sehr alten Vorlagen und einzelnen Landingpages.
03 ·
Wie viele deiner Besucher wirklich am Handy sind
Kaum ein Ratgeber zum Thema kommt ohne eine Prozentzahl aus. Bevor du eine solche Zahl in deine Planung übernimmst, stell ihr drei Fragen: Wer hat gemessen, in welchem Zeitraum, und was wurde gezählt – Seitenaufrufe, Personen oder Bestellungen?
Die belastbarste öffentlich zugängliche Messung für Deutschland stammt vom Webanalyse-Anbieter Statcounter. Sie ergibt ein anderes Bild als erwartet.
Geräteverteilung in Deutschland, Juli 2026
Anteil an den gemessenen Seitenaufrufen, nicht an den Personen
Grundgesamtheit: Seitenaufrufe auf über einer Million Websites weltweit mit Statcounter-Code. Der Anbieter schreibt selbst, man müsse die Statistik auf Seitenaufrufe stützen statt auf eindeutige Besucher.
Vom Anbieter genannte Grenzen: Korrekturfenster von 45 Tagen, bei kleinen Länderstichproben womöglich zu dünne Datenbasis, keine Ländergewichtung.
Quellen: Statcounter Global Stats, “Desktop vs Mobile vs Tablet Market Share Germany”, ausgewiesener Zeitraum Juli 2026, sowie Statcounter Global Stats FAQ zur Methodik (gs.statcounter.com), beide abgerufen 16.08.2026 – Stand 08/2026, eigene Darstellung, Ostend Digital.
Schaubild: Handy und Desktop liegen in Deutschland praktisch gleichauf – eigene Darstellung, Ostend Digital, Stand 08/2026.
Warum in Ratgebern ganz andere Zahlen stehen
In deutschen Ratgebern zum Thema tauchen deutlich höhere Mobilanteile auf, meist ohne Quelle und ohne Zeitraum. Mit den drei Fragen von oben entlarvst du sie in Sekunden.
Dafür gibt es zwei Erklärungen, und keine davon macht die Zahlen für Deutschland richtig.
Erstens werden weltweite Werte als deutsche ausgegeben; Statcounter weist für dieselbe Periode auch einen Weltwert aus, und der liegt höher. Zweitens wird unterschlagen, was gezählt wurde – ein Wert aus einer Shop-Auswertung, einer Personenbefragung oder einer App-Statistik ist nicht dasselbe wie eine Seitenaufruf-Messung.
🚩 Verrechne die beiden Statcounter-Werte nicht gegeneinander. Die Deutschlandzahl stammt aus einer Auswertung mit drei Kategorien, der Weltwert aus einer mit zwei. Eine Differenz aus ihnen zu bilden, ergäbe eine Zahl, die nirgends gemessen wurde.
Die Zahl, auf die es bei dir ankommt
Warte dabei nicht auf eine amtliche Zahl – für die Geräteverteilung von Seitenaufrufen gibt es keine, das Statistische Bundesamt erhebt die Internetnutzung von Personen. Und der Branchendurchschnitt ist für deine Entscheidung ohnehin die falsche Grundlage, weil er Nachrichtenseiten, Behörden, Onlineshops und Fachanbieter in einen Topf wirft.
Die richtige Zahl steht in deinem eigenen Analytics-Konto. Schlag sie noch heute nach: In Google Analytics 4 findest du sie unter Berichte, Technologie, Gerätekategorie – in etwa zwei Minuten, ohne Entwicklerkenntnisse. Eine Einführung ohne Kursrahmen gibt unser Beitrag zu Google Analytics 4.
ℹ️ Info
Das Alter deiner Zielgruppe verschiebt das Bild. Die ARD/ZDF-Medienstudie 2025 befragt die deutschsprachige Bevölkerung ab 14 Jahren, misst also Menschen statt Seitenaufrufe.
Laut der Berichterstattung über die Studie liegt die tägliche Smartphone-Nutzung in der jüngsten Altersgruppe bei 95 Prozent, bei den ab 70-Jährigen dagegen bei 34 Prozent. Verkaufst du an eine junge Zielgruppe, wiegt die mobile Fassung entsprechend schwerer – an eine ältere, der Desktop.
💡 Merke
Deutschland ist kein reines Handy-Land. Nach der belastbarsten öffentlichen Messung liegen mobile Geräte und Desktop hier fast gleichauf.
Für deine Prioritäten heißt das: Beide Ansichten zählen. Nimm die nächste Seite trotzdem mobil zuerst ab – denn die mobile Fassung ist die, die Google bewertet, wie die nächste Sektion zeigt.
04 ·
Was Google tatsächlich macht
“Google mag mobiloptimierte Seiten” steht in fast jedem Ratgeber. Was Google wirklich schreibt, steht in keinem – dabei ist die Dokumentation öffentlich zugänglich.
Der zentrale Begriff heißt Mobile-First-Indexierung. Die deutsche Google-Search-Central-Dokumentation formuliert ihn so:
“Google verwendet für die Indexierung und das Ranking die mobile Version des Website-Inhalts, der mit dem Smartphone-Agent gecrawlt wurde.”
Google bewertet also nicht die Desktop-Fassung und schaut anschließend zusätzlich aufs Handy. Die mobile Fassung ist die Fassung, die zählt.
Seit Juli 2024 crawlt Google nach eigenen Angaben alle Websites mit dem Smartphone-Crawler. Für dich folgt daraus eine einfache Arbeitsregel: Nimm jede neue Seite und jeden Relaunch mobil zuerst ab, die Desktop-Ansicht danach.
Der Denkfehler, der hier fast überall passiert
Verbreitet ist die Zuspitzung: Wer nicht responsiv ist, fliegt aus dem Index. In dieser Schärfe stimmt das nicht.
Geändert hat sich die Crawling-Methode, nicht eine Durchsetzung von Mobilfreundlichkeit. Eine Seite mit reinem Desktop-Layout, die auf einem Handy lädt, bleibt indexierbar – eine, die auf dem Handy gar nicht rendert, wird es nicht mehr sein.
Präzise heißt das: Google indexiert und rankt anhand der mobilen Fassung, und Mobilfreundlichkeit bleibt laut Google Teil der Page-Experience-Leitlinien. Das ist etwas anderes als ein benannter Rankingfaktor.
Der Satz, den kaum jemand zitiert
Google nennt in derselben Dokumentation drei mögliche Konfigurationen und hebt eine davon ausdrücklich hervor:
“Google empfiehlt responsives Webdesign, weil dieser Ansatz am einfachsten zu implementieren und zu verwalten ist.”
Die drei Konfigurationen und ihre Unterschiede nimmt sich Sektion 8 vor.
Was Google konkret von einer mobilen Fassung erwartet
Nutze die folgende Tabelle als Abnahme-Checkliste: Die linke Spalte fasst Googles Vorgaben zusammen, die rechte ist unsere Übersetzung in die Praxisfolge – die steht so nicht bei Google. Geh sie bei der nächsten Abnahme am Handy Punkt für Punkt durch, mit deinem Dienstleister oder allein.
| Google-Anforderung | Praxisfolge (redaktionelle Einordnung) |
|---|---|
| Inhaltsgleichheit: beide Fassungen enthalten denselben Hauptinhalt. Akkordeons und Tabs sind ausdrücklich zulässig | ✅ Einklappen erlaubt. ❌ Wegblenden nicht – Google sieht sonst nur die gekürzte Fassung |
| Gleiche robots-Meta-Tags in beiden Fassungen | Kein noindex, das nur in der mobilen Variante hängt |
| Kein Lazy Loading für Hauptinhalte, besonders nicht nach Nutzerinteraktion | Was erst nach Klick oder Wisch nachlädt, sieht Google nicht |
| Bilder in gleicher Qualität, mit beschreibendem Alt-Text und möglichst gleichen Bild-URLs | Mobil verkleinerte Bilder kosten Sichtbarkeit in der Bildersuche |
| Videos in unterstützten Formaten, nicht hinter exzessivem Scrollen | Ein Video nach fünf Bildschirmfüllungen wird kaum gesehen |
Wie Suchmaschinen Seiten erfassen und was dabei technisch schiefgehen kann, vertieft die Lektion zu technischem SEO im SEO-Kurs.
05 ·
Breakpoints: die Norm, die es nicht gibt
Breakpoints sind die Punkte, an denen das Layout umspringt: Aus drei Spalten werden zwei, aus dem Menü wird ein Symbol, aus nebeneinander wird untereinander. In Angeboten und Briefings tauchen dazu Zahlenlisten auf, gern mit dem Wort “Standard” davor.
Diese Listen sind keine Standards. MDN nennt gar keinen Satz an Standard-Breakpoints, sondern empfiehlt, sie in relativen Einheiten zu definieren statt in absoluten Größen einzelner Geräte.
Zwei Baukästen, zwei Antworten
Die verbreiteten Zahlen stammen aus den Voreinstellungen zweier CSS-Frameworks. Und die widersprechen sich.
| Stufe | Bootstrap 5.3 | Tailwind CSS |
|---|---|---|
| klein (sm) | ab 576 px | ab 640 px (40rem) |
| mittel (md) | ab 768 px | ab 768 px (48rem) |
| groß (lg) | ab 992 px | ab 1024 px (64rem) |
| sehr groß (xl) | ab 1200 px | ab 1280 px (80rem) |
| größte Stufe | ab 1400 px (xxl) | ab 1536 px (2xl) |
Nur bei 768 Pixeln treffen sich beide. Überall sonst gehen sie auseinander, und beide gelten in ihrem Ökosystem als “Standard”.
Bootstrap sagt selbst, woher die Werte kommen: Jeder Breakpoint sei so gewählt, dass er Container mit Zwölfer-Breiten aufnimmt, und die Bereiche zielten ausdrücklich nicht auf jedes Gerät. Tailwind nennt die eigenen Werte eine von verbreiteten Bildschirmauflösungen inspirierte Voreinstellung und erklärt in einem eigenen Abschnitt, wie man sie ersetzt.
ℹ️ Info
Als grobe Orientierung, ausdrücklich als Faustregel und nicht als Regel:
- unter etwa 576 bis 640 px: Smartphone im Hochformat
- um 768 px: Tablet hochkant oder ein schmal gezogenes Fenster
- ab etwa 1024 bis 1280 px: Laptop und Desktop
Das ist unsere Vereinfachung aus beiden Framework-Tabellen – Bootstrap widerspricht der Gerätezuordnung sogar ausdrücklich.
Die bessere Frage als “welche Zahlen?”
Ein Breakpoint gehört dorthin, wo dein Layout bricht – nicht dorthin, wo ein Gerät angeblich anfängt. Zieh die Kante deines Browserfensters langsam nach links und beobachte, wann die Seite unangenehm wird. Genau dort wäre einer fällig, egal welche Zahl in einer Framework-Tabelle steht.
Mach diesen Zug einmal mit deiner eigenen Startseite und notiere die Stellen, an denen es hakt. Das ist eine etablierte Arbeitsweise des Fachs, kein genormter Standard – und genau deshalb darfst du sie ohne Zahlentabelle anwenden.
💡 Praxis-Tipp
Nennt dir jemand “die offiziellen Breakpoints”, frag nach der Quelle. Die richtige Antwort lautet: das sind die Voreinstellungen unseres Frameworks.
Das ist meist sinnvoll. Problematisch wird es erst, wenn eine Voreinstellung als Norm ausgegeben und deshalb nicht mehr hinterfragt wird.
Eine verwandte Frage betrifft nicht die Technik, sondern die Reihenfolge beim Entwerfen: Fängt man mit dem schmalen oder mit dem breiten Layout an? Das ist das Prinzip Mobile First, und es gehört in die Lektion zu Wireframes und Seitenstruktur.
06 ·
Die vier Fehler, die am meisten kosten
Die meisten Probleme mit responsive design sind nicht exotisch. Es sind vier Fehlerbilder, die immer wieder auftauchen – und die du bis auf eines ohne Werkzeug erkennst.
1. Die Seite ist breiter als der Bildschirm
Du wischst am Handy nach links, und die ganze Seite verschiebt sich seitlich. Ein Element ist breiter als das Fenster und schiebt alles andere mit.
Typische Verursacher sind ein Element mit fester Pixelbreite, eine zu breite Tabelle, ein überbreites Bild, eine eingebettete Karte oder ein Fremdanbieter-Formular. Findest du den Verursacher nicht selbst, reicht als Meldung der Satz: “Die Seite lässt sich am Handy seitlich verschieben, bitte das überbreite Element suchen.”
In der Wahrnehmung ist das der schlimmste der vier Fehler. Ein zu kleiner Button nervt, eine seitlich verrutschende Seite wirkt kaputt.
2. Klickflächen zu klein oder zu eng beieinander
Hier gibt es zwei Regelwerke mit zwei verschiedenen Zahlen, die nicht miteinander verrechnet werden dürfen.
Die Barrierefreiheits-Norm WCAG 2.2 verlangt in Erfolgskriterium 2.5.8 auf Konformitätsstufe AA mindestens 24 mal 24 CSS-Pixel, nennt dazu aber fünf Ausnahmen – etwa für Links mitten im Fließtext. Das strengere Kriterium 2.5.5 auf Stufe AAA verlangt 44 mal 44 CSS-Pixel. Begründet wird sie mit eingeschränkter Feinmotorik und der Vermeidung versehentlicher Klicks auf Nachbarelemente.
Googles Lighthouse-Prüfung arbeitet dagegen seit Jahren mit 48 mal 48 Pixeln als Richtwert und nennt 8 Pixel Abstand als brauchbaren Ausgangspunkt, der bei sehr kleinen Zielen nicht immer reicht.
Merken musst du dir davon nur eines: Brief deinen Dienstleister auf 48 mal 48 Pixel. Wer die größere Zahl einhält, erfüllt beide Regelwerke automatisch. Was daran rechtlich verbindlich ist, behandelt die Lektion zur Barrierefreiheit.
3. Unlesbar kleine Schrift
Überall zitiert wird die Regel: mindestens 16 Pixel für Fließtext, und Google empfehle das. Der erste Teil ist eine brauchbare Faustregel, der zweite stimmt so nicht.
Die 16 Pixel sind eine breit geteilte Branchenkonvention, keine Google-Vorgabe. Der praktikablere Test kommt ohnehin ohne Zahl aus: Kannst du den Fließtext am Handy bei normalem Armabstand lesen, ohne zu zoomen?
4. Mobil versteckte Inhalte
Dieser Fehler hat die größten Folgen für die Sichtbarkeit und entsteht meist in bester Absicht. Der lange Text und die Vergleichstabelle wirken am Handy erschlagend, also werden sie mobil ausgeblendet.
Nach der Mobile-First-Indexierung sieht Google aber nur noch diese gekürzte Fassung. Die Lösung steht in Googles eigener Dokumentation: Einklappen ja, wegblenden nein.
💡 Merke
Drei dieser vier Fehler findest du ohne jedes Werkzeug. Seite am Handy öffnen, seitlich wischen, Text lesen, Buttons treffen.
Nur der vierte verlangt einen Vergleich: Steht am Handy alles, was am Desktop steht? Bedienbarkeit systematisch zu beurteilen, vertieft die Lektion zu Usability.
07 ·
Selbst prüfen in fünf Stufen
Die Reihenfolge geht von “dauert 30 Sekunden” zu “dauert zehn Minuten”. Die erste Stufe ist gleichzeitig die aussagekräftigste.
Stufe 1: das echte Gerät
Öffne deine Seite auf deinem eigenen Handy und stell dir drei Fragen:
- 📌 Muss ich zoomen, um Text zu lesen?
- 📌 Lässt sich die Seite seitlich verschieben?
- 📌 Treffe ich Buttons und Menüpunkte beim ersten Versuch?
Warum diese schlichte Prüfung ganz oben steht, sagt Google selbst. Die Chrome-Dokumentation nennt die eingebaute Gerätesimulation eine Näherung erster Ordnung und rät, im Zweifel tatsächlich auf einem Mobilgerät zu prüfen.
Stufe 2: das Browserfenster schmaler ziehen
Zieh am Laptop die rechte Fensterkante langsam nach links und beobachte, wann das Layout umspringt. Das sind die Breakpoints aus Sektion 5, live und sichtbar.
Die Prüfung braucht null Vorwissen und deckt Layoutbrüche zuverlässig auf. Bedienbarkeit zeigt sie nicht: Ein schmales Desktop-Fenster hat eine Maus statt eines Fingers.
Stufe 3: die Gerätesimulation im Browser
In Chrome öffnest du die Entwicklerwerkzeuge und klickst oben auf das Gerätesymbol. Danach kannst du Fensterbreiten durchspielen, Netzwerk und Rechenleistung drosseln und die Geräteausrichtung wechseln.
Praktisch für schnelle Durchläufe über viele Breiten. Die Einschränkung aus Stufe 1 gilt weiter, denn die mobile Prozessorarchitektur bildet die Simulation nicht nach.
Stufe 4: Lighthouse und PageSpeed Insights
Lighthouse ist in Chrome eingebaut und liefert unter anderem die Klickflächen-Prüfung aus Sektion 6. PageSpeed Insights unter pagespeed.web.dev ist der browserfreie Weg zum selben Motor. Es kombiniert Labordaten aus einem simulierten Aufruf auf einem Mittelklasse-Gerät im Mobilfunknetz mit Felddaten echter Chrome-Nutzer aus dem Chrome User Experience Report über ein rollendes 28-Tage-Fenster.
🚩 Achtung, hier wird oft das Falsche geprüft. PageSpeed Insights misst Geschwindigkeit und Nutzungserlebnis, nicht “ist das Layout anpassungsfähig”. Ein guter Wert beweist nicht, dass die Seite am Handy funktioniert. Was dort genau gemessen wird, behandelt die Lektion zu den Core Web Vitals.
Stufe 5: die Unterseiten, an die niemand denkt
Fast alle Prüfungen enden auf der Startseite. Die Fehler sitzen aber woanders: in Formularen, Tabellen, eingebetteten Karten und Videos, im Menü und in Blogartikeln mit Bildern.
Nimm dir deshalb die drei Unterseiten vor, auf denen deine Anfragen entstehen – typischerweise Kontakt, die wichtigste Leistungsseite und der meistbesuchte Blogartikel – und geh mit ihnen durch Stufe 1.
ℹ️ Was du nicht mehr empfehlen solltest
Der Google-Mobile-Friendly-Test ist abgeschaltet. Zusammen mit dem Mobile-Usability-Bericht in der Search Console wurde er im Dezember 2023 eingestellt. Streich ihn aus deinen Lesezeichen und Checklisten.
Als Begründung nannte Google, es seien inzwischen genug andere belastbare Werkzeuge entstanden, und verwies auf Lighthouse.
🚩 Nicht verwechseln: Mobilfreundlichkeit zählt weiter. Google stellte im selben Zug klar, sie bleibe Teil der Page-Experience-Leitlinien.
Das ist gleichzeitig ein Aktualitäts-Test für jeden Ratgeber zum Thema. Wer dir 2026 den Mobile-Friendly-Test empfiehlt, hat seinen Text seit über zwei Jahren nicht angefasst.
Experten-Tipp aus der Agentur
Mach die Handy-Prüfung nicht allein an deinem eigenen Gerät. Du kennst deine Seite und weißt, wo du hinklicken musst – deshalb siehst du die Stolperstellen nicht mehr.
Gib das Handy jemandem, der die Seite nicht kennt, und nenn nur die Aufgabe: “Finde heraus, was das kostet”. Dann schau zu und sag nichts. Die zwei Sekunden, in denen die Person zögert, sind mehr wert als jeder Werkzeug-Score.
Pascal Cabitza
Geschäftsführer Ostend Digital
08 ·
Responsiv, adaptiv oder eigene Handy-Seite?
Diese Begriffe stehen in Angeboten nebeneinander und werden ständig verwechselt. Google selbst unterscheidet drei Konfigurationen, und “adaptiv” ist keine davon.
| Konfiguration | Was passiert technisch | Googles Haltung |
|---|---|---|
| Responsive design | Dasselbe HTML unter derselben Adresse, Darstellung je nach Bildschirmgröße | ✅ Ausdrücklich empfohlen |
| Dynamic serving | Dieselbe Adresse, aber der Server erkennt das Gerät und liefert anderes HTML | Unterstützt, nicht hervorgehoben |
| Separate URLs | Eigene Adressen je Gerät mit Weiterleitung auf die passende Fassung | Unterstützt, nicht hervorgehoben |
Googles Begründung steht wörtlich in Sektion 4. Verboten ist keine der drei Varianten, und bei großen Portalen mit stark abweichenden mobilen Anwendungsfällen kommen die anderen beiden Wege weiterhin vor.
Warum “adaptiv” in dieser Tabelle fehlt
“Adaptive Design” ist ein Begriff der Design-Fachwelt, geprägt von Aaron Gustafson im Jahr 2011. Die Interaction Design Foundation grenzt ihn so ab: Responsive Layouts verteilen Elemente bei Breitenänderungen neu, adaptive Layouts haben mehrere feste Layoutgrößen und wählen die passendste aus.
🚩 Der häufigste Fehler an dieser Stelle: adaptives Design mit Googles dynamic serving gleichzusetzen. Bei adaptivem Design wählt die Seite unter festen Layouts aus, bei dynamic serving entscheidet der Server, welches HTML er überhaupt ausliefert.
Die eigene Handy-Seite unter m.beispiel.de
Verboten ist dieser Weg nicht. Google unterstützt separate Adressen weiterhin, hebt sie aber nicht hervor und hat bereits 2017 einen eigenen Leitfaden für den Wegzug von m-dot-Adressen veröffentlicht.
Für Selbstständige und kleinere Unternehmen ist er praktisch nie die richtige Wahl. Zwei Inhaltsbestände bedeuten doppelte Pflege, und mit der Mobile-First-Indexierung entscheidet ausgerechnet die mobile Fassung über die Sichtbarkeit.
💡 Praxis-Tipp
Zwei Fragen für dein nächstes Angebotsgespräch. Steht “responsive” als eigene Kostenposition darin, frag, welche Leistung dahintersteckt – die Bauweise bringen die üblichen Werkzeuge mit.
Und wird dir eine separate mobile Website angeboten, frag nach der Begründung für die Abweichung von Googles Empfehlung. Es kann gute Gründe geben, sie sollten nur genannt werden.
09 ·
💡 Recap
Responsive design in 30 Sekunden:
- Eine Bauweise, kein Produkt: dasselbe HTML unter derselben Adresse, angepasste Darstellung – über fließende Raster, flexible Bilder und Media Queries
- Der Viewport-Meta-Tag ist die häufigste Einzelursache dafür, dass eine Seite am Handy wie eine geschrumpfte Desktop-Fassung wirkt
- Handy und Desktop liegen in Deutschland praktisch gleichauf (Statcounter, Juli 2026: 49,41 zu 48,97 Prozent der gemessenen Seitenaufrufe). Weder ist mobil unwichtig noch Desktop zweitrangig – beide Fassungen müssen funktionieren. Maßgeblich für dich ist deine eigene Zahl aus Analytics
- Google bewertet die mobile Fassung. Seit Juli 2024 crawlt Google nach eigenen Angaben alle Websites mit dem Smartphone-Crawler und empfiehlt wörtlich responsives Webdesign, weil es am einfachsten umzusetzen und zu verwalten sei. Nimm deshalb mobil zuerst ab. Nicht indexierbar wird eine Seite aber erst, wenn sie mobil gar nicht rendert
- Für Breakpoints gibt es keine Norm. Bootstrap beginnt bei 576 Pixeln, Tailwind bei 640 – Framework-Voreinstellungen. Der richtige Punkt ist der, an dem dein Layout bricht
- Vier Fehler kosten am meisten: seitlich verrutschende Seiten, zu kleine Klickflächen (WCAG 2.2: 24 mal 24 CSS-Pixel auf Stufe AA, Lighthouse: 48 mal 48), zu kleine Schrift (16 Pixel sind Branchenkonvention, keine Google-Vorgabe) und mobil weggeblendete Inhalte
- Prüf am echten Gerät zuerst. Den Google-Mobile-Friendly-Test gibt es seit Dezember 2023 nicht mehr, Mobilfreundlichkeit zählt laut Google trotzdem weiter
10 ·
Selbstcheck: kannst du das beantworten?
Deine Seite sieht am Handy aus wie eine geschrumpfte Desktop-Version. Was lässt du zuerst prüfen?
Den Viewport-Meta-Tag im Seitenkopf. Fehlt er, meldet der mobile Browser eine Desktop-Breite und zoomt die breite Fassung herunter.
Die Breakpoints greifen dann unter Umständen gar nicht, obwohl die Seite anpassungsfähig gebaut ist.
Jemand nennt dir “die offiziellen Breakpoints”. Was entgegnest du?
Dass es keine offizielle Norm gibt. Bootstrap startet bei 576 Pixeln, Tailwind bei 640, nur bei 768 treffen sich beide.
Das sind Framework-Voreinstellungen; Bootstrap schreibt selbst, die Werte zielten nicht auf konkrete Geräte. Der richtige Breakpoint ist der, an dem dein Layout bricht.
Ein Dienstleister schlägt vor, die lange Vergleichstabelle mobil auszublenden. Deine Antwort?
Nein zum Ausblenden, ja zum Einklappen. Google verlangt Inhaltsgleichheit und erlaubt Akkordeons und Tabs ausdrücklich, solange der Inhalt substanziell derselbe bleibt.
Weggeblendeter Inhalt fällt dagegen aus der Bewertung, weil die mobile Fassung die indexierte ist.
“Über 60 Prozent surfen in Deutschland mobil, ohne responsive Seite fliegst du aus dem Index.” Zwei Korrekturen?
Erstens die Zahl. Nach Statcounter lagen im Juli 2026 in Deutschland mobile Geräte und Desktop mit 49,41 zu 48,97 Prozent der gemessenen Seitenaufrufe praktisch gleichauf; höhere Werte sind meist weltweite Zahlen oder stammen aus einer anderen Grundgesamtheit.
Zweitens die Konsequenz. Aus dem Index fliegt nur eine Seite, die auf Mobilgeräten gar nicht rendert – ein Desktop-Layout, das am Handy lädt, bleibt im Index.
Alle Lektionen des Webdesign- und CRO-Kurses im Überblick →
Quellen und Stand (20 Einträge)
- MDN Web Docs: “Responsive Design” – Definition als Gestaltungsansatz und ausdrücklich nicht als eigene Technologie, die drei Bausteine (fluid grids, fluid images, media queries), Begriffsprägung durch Ethan Marcotte 2010, “Modern CSS layout methods are inherently responsive”, Wirkung und Begründung des Viewport-Meta-Tags, Empfehlung relativer Einheiten für Breakpoints. Norm-nahe Referenzdokumentation, kein Verkaufsinteresse (developer.mozilla.org, abgerufen 16.08.2026)
- Ethan Marcotte: “Responsive Web Design”, A List Apart, 2010 – über MDN belegt, der Originalartikel wurde in der Recherche nicht selbst abgerufen. Deshalb im Text nur die Jahresangabe, keine Monatsangabe (alistapart.com)
- Google Search Central: “Best Practices für die Mobile-First-Indexierung”, deutsche Fassung, laut eigener Angabe zuletzt aktualisiert 20.02.2026 – Definition der Mobile-First-Indexierung im Wortlaut, Empfehlung des responsiven Webdesigns im Wortlaut, Anforderungen an Inhaltsgleichheit, robots-Meta-Tags, Lazy Loading, Bilder und Videos, Zulässigkeit von Akkordeons und Tabs, die drei Konfigurationen. Amtliche Herstellerdokumentation (developers.google.com, abgerufen 16.08.2026)
- Google Search Central: dieselbe Seite in der englischen Fassung, laut eigener Angabe zuletzt aktualisiert 10.12.2025 – zur Absicherung der deutschen Formulierungen sowie für die wörtlichen Definitionen von responsive design, dynamic serving und separate URLs (developers.google.com, abgerufen 16.08.2026)
- Search Engine Land: “Google won’t index sites that do not work on mobile devices after July 5th” – Zitat John Mueller zum Umstieg der letzten verbliebenen Websites auf den mobilen Googlebot. Nur sekundär belegt: Der zugehörige Google-Blogpost war am 16.08.2026 unter der kursierenden Adresse nicht abrufbar (HTTP 404), die aktuelle Google-Dokumentation nennt kein Datum. Im Text deshalb “seit Juli 2024” ohne Tagesdatum (searchengineland.com, abgerufen 16.08.2026)
- Statcounter Global Stats: “Desktop vs Mobile vs Tablet Market Share Germany”, ausgewiesener Zeitraum Juli 2026 – Mobil 49,41 Prozent, Desktop 48,97 Prozent, Tablet 1,61 Prozent (gs.statcounter.com, abgerufen 16.08.2026)
- Statcounter Global Stats FAQ – Methodik: Messung auf Basis von Seitenaufrufen statt eindeutiger Besucher, über eine Million Websites mit Trackingcode, Korrekturfenster von 45 Tagen, Hinweis auf möglicherweise zu kleine Länderstichproben, keine Ländergewichtung (gs.statcounter.com/faq, abgerufen 16.08.2026)
- Statcounter Global Stats: “Desktop vs Mobile Market Share Worldwide”, Zeitraum Juli 2026 – Grundlage für die Aussage, dass der Weltwert über dem deutschen liegt. Nicht mit dem DE-Wert verrechenbar: Der Weltwert stammt aus einer Auswertung mit zwei Kategorien, der deutsche aus einer mit drei (gs.statcounter.com, abgerufen 16.08.2026)
- ARD/ZDF-Medienstudie 2025 – Internetnutzung der deutschsprachigen Bevölkerung ab 14 Jahren, Altersunterschiede in der täglichen Smartphone-Nutzung. Einschränkung: Die im Text genannten Werte stammen aus der Sekundärberichterstattung über die Studie, das Studien-PDF wurde nicht geöffnet (ard-zdf-medienstudie.de, abgerufen 16.08.2026)
- Statistisches Bundesamt, Themenbereich IT-Nutzung – Grundlage für die Aussage, dass es keine amtliche deutsche Statistik zur Geräteverteilung von Seitenaufrufen gibt; Destatis erhebt die Internetnutzung von Personen (destatis.de, abgerufen 16.08.2026)
- Bootstrap v5.3, Dokumentation “Breakpoints” – Standardwerte 576, 768, 992, 1200 und 1400 Pixel sowie die eigene Begründung, dass die Werte auf Zwölfer-Rastern beruhen und ausdrücklich nicht auf konkrete Geräte zielen. Framework-Herstellerdokumentation, Open Source (getbootstrap.com, abgerufen 16.08.2026)
- Tailwind CSS, Dokumentation “Responsive design” – Standardwerte 640, 768, 1024, 1280 und 1536 Pixel, Bezeichnung als Voreinstellung “inspired by common device resolutions”, eigener Abschnitt zu abweichenden Breakpoints (tailwindcss.com, abgerufen 16.08.2026)
- W3C: “Understanding SC 2.5.8: Target Size (Minimum)” und “Understanding SC 2.5.5: Target Size (Enhanced)”, WCAG 2.2 – mindestens 24 mal 24 CSS-Pixel auf Konformitätsstufe AA mit fünf benannten Ausnahmen, 44 mal 44 CSS-Pixel auf Stufe AAA mit vier benannten Ausnahmen, Begründung über eingeschränkte Feinmotorik und versehentliche Aktivierung. Norm/Standard (w3.org, abgerufen 16.08.2026)
- Chrome for Developers / Lighthouse: “Tap targets are not sized appropriately” – 48 mal 48 Pixel als Richtwert, 8 Pixel Abstand als Ausgangspunkt, Doppelbedingung für die Bemängelung, Empfehlung erhöhter Innenabstände bei kleinen Symbolen. Die Seite trägt den Stand 02.05.2019 und ist im Text entsprechend als alte, weiterhin aktive Regel gekennzeichnet (developer.chrome.com, abgerufen 16.08.2026)
- Chrome for Developers: “Simulate mobile devices with Device Mode”, laut eigener Angabe zuletzt aktualisiert 20.02.2024 – Gerätesimulation als “first-order approximation”, ausdrückliche Empfehlung, im Zweifel auf einem echten Mobilgerät zu prüfen, Funktionsumfang und Grenzen (developer.chrome.com, abgerufen 16.08.2026)
- Google for Developers: “About PageSpeed Insights” sowie Chrome for Developers: “How to view Chrome UX Report data on PageSpeed Insights” – Kombination aus Labordaten und Felddaten des Chrome User Experience Report, getrennte Ergebnisse für Mobil und Desktop. Detailangaben zu Testgerät und Zeitfenster wurden bewusst weggelassen, weil sie in der Recherche nur über eine Suchergebnis-Zusammenfassung vorlagen (developers.google.com und developer.chrome.com, abgerufen 16.08.2026)
- Search Engine Land: “Google officially drops Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API” – Abschaltung im Dezember 2023, Googles Begründung und Verweis auf Lighthouse, Klarstellung, dass Mobilfreundlichkeit Teil der Page-Experience-Leitlinien bleibt. Datumsunsicherheit: Sekundärquellen nennen den 1. und den 4. Dezember 2023 und der Google-Originalbeitrag wurde nicht abgerufen, weshalb im Text nur “Dezember 2023” steht (searchengineland.com, abgerufen 16.08.2026)
- Interaction Design Foundation, Mads Soegaard: “Adaptive vs. Responsive Design”, veröffentlicht 16.11.2015, zuletzt aktualisiert 25.09.2025 – Abgrenzung responsiv gegen adaptiv im Wortlaut, Aaron Gustafson als Urheber des Begriffs 2011. Die dort genannte Liste fester Layoutbreiten wurde nicht übernommen, weil sie sich nicht über die Quelle hinaus belegen ließ (ixdf.org, abgerufen 16.08.2026)
- Google Search Central Blog: “How to move from m-dot URLs to responsive site”, September 2017 – im Text ist nur die Existenz des Leitfadens genannt. Der Artikeltext war am 16.08.2026 nicht auslesbar, inhaltliche Aussagen daraus wären nicht belegt (developers.google.com)
- Zur 16-Pixel-Regel: Die verbreitete Angabe, Google empfehle 16 Pixel Mindestschriftgröße, ließ sich am 16.08.2026 auf keine abrufbare Google-Primärquelle zurückführen; die auffindbaren Belege waren durchweg Sekundärquellen ohne Google-Link. Der Sache nach stammt sie aus Googles inzwischen eingestellter Mobile-Friendly-Dokumentation. Im Text deshalb ausdrücklich als Branchenkonvention gekennzeichnet
Du hast geprüft – und willst es sauber gelöst haben?
Wir bauen und betreuen Websites für Unternehmen in Stuttgart und bundesweit. Schick uns, was dir am Handy aufgefallen ist, und wir sagen dir ehrlich, ob es ein Handgriff ist oder ein Strukturthema.
