Gates zuerst, Ästhetik danach: Wie man messen kann, ob eine KI-gebaute Website gut ist

Meinungsstück — Erfahrung aus eigenen Projekten, keine repräsentative Messung.

Eine KI baut Ihnen heute in vier Minuten eine Website, die auf dem Bildschirm gut aussieht. Das ist keine Übertreibung und kein Marketing — es ist der Normalfall geworden.

Das Problem daran ist unscheinbar und teuer: Aussehen ist die einzige Eigenschaft einer Website, die man ohne Werkzeug beurteilen kann. Und es ist die einzige, die nichts darüber aussagt, ob sie funktioniert.

Ob eine Seite auf dem Handy 5 Sekunden lädt, ob der wichtigste Knopf unsichtbar ist, ob der Text bei einem langen deutschen Wort aus dem Bild läuft — das sieht man auf dem Vorschaubild nicht. Man muss es messen. Und genau das tut in dieser Branche fast niemand, weder bei KI-gebauten noch bei handgemachten Seiten.

Ich habe deshalb angefangen, einen Benchmark dafür zu bauen. Dieser Artikel erklärt das Prinzip — und warum es auch dann nützlich ist, wenn Sie nie einen Benchmark fahren, sondern nur eine Website kaufen wollen.

Was heute gemessen wird — und was dabei durchfällt

Wer prüfen will, wie gut KI-Modelle Websites bauen, findet zwei Lager von Tests. Beide haben dasselbe blinde Auge.

Das erste Lager bewertet Schönheit. Zwei Ergebnisse werden nebeneinandergelegt, ein Mensch oder ein Bildmodell wählt das schönere. Das ergibt eine Rangliste des Geschmacks. Über Ladezeit und Barrierefreiheit sagt sie nichts.

Das zweite Lager bewertet Code. Gemessen wird, ob der Code baut, ob er einer Vorlage optisch ähnelt, ob Tests durchlaufen. Auch legitim — und ebenfalls blind für die Frage, wie sich das Ergebnis auf einem gedrosselten Handy verhält.

Echte Arbeit scheitert aber genau am Zielkonflikt zwischen beidem: der beeindruckende Seitenkopf, der die Ladezeit ruiniert. Das aufgeräumte Layout, dessen Markenfarbe die Kontrastanforderungen verletzt. Kein verbreiteter Test zwingt ein Modell, alle drei Dinge gleichzeitig zu erfüllen.

Dazu kommt ein zweites, unbequemeres Problem: Viele etablierte Programmier-Benchmarks sind inzwischen ausgereizt — Spitzenwerte über 90 %, teilweise durch Memorierung der Aufgaben. Zwischen Laborergebnis und Praxis klafft messbar eine Lücke. Ein Test, dessen Aufgaben im Trainingsmaterial stehen, misst Erinnerung, nicht Können.

Das Prinzip: erst die Gates, dann der Geschmack

Der Kern ist ein einziger Satz: Objektives Durchlassen schlägt subjektives Bewerten.

Praktisch heißt das: Eine generierte Seite wird nicht angeschaut und benotet. Sie wird gerendert und gemessen. Erst wenn sie harte, maschinell gemessene Grenzen einhält, wird überhaupt über Aussehen geredet.

Das hat drei Vorteile, die alle in dieselbe Richtung zeigen:

• Billig zu fahren. Messen kostet Rechenzeit, kein Gremium.
• Schwer zu manipulieren. Man kann eine Kontrastmessung nicht durch Selbstbewusstsein bestehen.
• Kontaminationsresistent. Die Bewertung kommt aus der Messung des gerenderten Ergebnisses, nicht aus einem memorierbaren Lösungsschlüssel. Es gibt keinen „richtigen Code“, den man auswendig lernen könnte.

Die vier Gates

Jede Aufgabe ist ein Auftrag mit mitgeliefertem Inhalt — echter deutscher Text, echte Bildmaße. Das Modell darf sich weder Blindtext noch schmeichelhafte Bildformate aussuchen. Dann läuft das Ergebnis durch vier Stufen.

Gate 0 — Baut und rendert es überhaupt?

Binär. Der Code muss fehlerfrei bauen und im Browser ohne weiße Seite und ohne fatalen Konsolenfehler erscheinen. Nicht bestanden heißt 0 Punkte. Für Code, der nicht läuft, gibt es keine Teilnote.

Gate 1 — Geschwindigkeit (mobil, gedrosselt)

Gewicht ist hier kein Selbstzweck: eine leichtere Seite lädt nicht nur schneller, sie verbraucht auch weniger Strom — dieselbe Zahl entscheidet über beides.

Gate 2 — Barrierefreiheit

Gate 3 — Responsive-Integrität, gerechnet statt beurteilt

Kein horizontales Wegscrollen bei 390 px und 1440 px. Kein abgeschnittener Text. Klickflächen mindestens 44 px. Gemessen über Geometrie im Browser — scrollWidth gegen clientWidth, überstehende Elemente einzeln aufgelistet.

Zuletzt: Ästhetik — aber nur, wenn alles davor hält

Erst dann wird das Aussehen bewertet, und zwar nach einer Rubrik statt nach Bauchgefühl: visuelle Hierarchie, Rhythmus und Abstände, Farbharmonie, typografische Qualität, Passung zur Marke, und die ehrlichste Frage von allen — würde ich das einem Kunden ausliefern?

Die Formel, um die es eigentlich geht

Die Punktevergabe ist der Punkt, an dem der Benchmark eine Haltung bekommt:

• Rendert nicht → 0
• Ein Gate gefallen → gedeckelt, Ästhetik wird gar nicht mehr bewertet
• Alle Gates bestanden → 0,5 als Startwert, die zweite Hälfte verdient sich über Geschmack

Daraus folgt die Aussage, die mir wichtig ist: Eine schöne Seite, die bei Barrierefreiheit oder Ladezeit durchfällt, landet unter einer schmucklosen Seite, die alles besteht.

Das ist keine Feindschaft gegen gutes Design — ich verdiene mein Geld mit Gestaltung. Es ist eine Reihenfolge. Qualitätsgrenzen sind nicht verhandelbar, Schönheit ist der Stichentscheid.

Warum die Aufgaben deutsch sind

Nicht aus Patriotismus, sondern weil deutscher Text die Layouts kaputt macht, die auf englischen Text hin optimiert wurden. Deutsche Fassungen laufen rund 30 % länger. „Grundstücksverkehrsgenehmigung“ ist keine Schikane, das ist ein Wort, das auf echten Kundenseiten in echten Überschriften steht.

Genau diese Klasse von Fehlern habe ich in eigenen Bauten oft genug gemessen, um sie ernst zu nehmen. Ein Beispiel aus meinen Notizen: Ein Seitenkopf lief auf dem Handy nach rechts weg. Ursache war nicht der Text, sondern ein zwölfspaltiges Raster mit großzügigen Lücken — die Spalten schrumpfen auf dem Handy, die Lücken nicht. Elf Lücken × 2,6 rem ergaben allein 486 px, bei einem Bildschirm von 390 px. Gemessen: 499 px Seitenbreite, 109 px Überstand, neun überstehende Elemente. Auf dem Desktop war davon nichts zu sehen.

So etwas findet kein Blick auf ein Vorschaubild. Das findet nur eine Messung.

Zwei Gründe, warum Messen allein noch nicht reicht

Damit dieser Artikel nicht selbst zur Werbebroschüre wird, zwei Belege dafür, dass auch Messwerkzeuge falsch liegen können — beide aus eigener Arbeit.

Der Screenshot log, die Messung nicht. Ein Handy-Screenshot zeigte eine überall abgeschnittene Seite, während die Überlauf-Messung bei 320, 360 und 390 px sauber meldete. Fast hätte ich ein Layout „reparieren“ lassen, das nie kaputt war. Ursache: Chrome erzwingt auf macOS eine Mindest-Fensterbreite von rund 500 px. Die Angabe --window-size=390 verkleinert das Fenster nicht, sie beschneidet nur das Bild. Die Seite wurde also nie bei 390 px gerendert, sondern bei ~500 px und links abgeschnitten. Merksatz seither: Wenn Screenshot und Messung sich widersprechen, misstraue zuerst dem Screenshot — und prüfe, wie er entstanden ist.

Der Kontrastfehler, den kein automatischer Test findet. Ein Primärknopf stand dunkel auf einer gleich dunklen Markenfläche. Der Textkontrast war formal exzellent — weiß auf dunkelviolett, 15,2:1. Der automatische Test meldete grün, weil er Text gegen Hintergrund prüft. Nur war die Knopffläche gegen die Fläche dahinter 1:1, also unsichtbar. Der Nutzer sah keinen Knopf, sondern schwebende weiße Buchstaben.

Beides sind Gründe für Messung, nicht gegen sie. Aber sie zeigen, wo die Arbeit wirklich liegt: nicht im Bewerten, sondern im Bauen von Prüfungen, die die richtige Frage stellen.

Was Sie davon haben, wenn Sie nur eine Website kaufen wollen

Sie müssen keinen Benchmark fahren. Sie können aber die drei Fragen stellen, die dasselbe leisten — bei mir oder bei jedem anderen Anbieter, der mit KI arbeitet:

1. „Zeigen Sie mir die Seite auf einem gedrosselten Handy.“ Nicht auf Ihrem Bildschirm. Nicht als Bild. Als Messwert: Largest Contentful Paint unter 2,5 Sekunden.
2. „Was sagt ein Barrierefreiheits-Test?“ Null kritische Verstöße ist eine Zahl, keine Meinung. Ab 2026 ist das für viele Betriebe zusätzlich eine Pflicht, nicht nur eine Qualitätsfrage.
3. „Läuft irgendwo bei 390 Pixeln Breite Text aus dem Bild?“ Wer darauf mit „sieht gut aus“ antwortet, hat nicht gemessen.

Fällt eine Antwort weich aus, ist die Seite nicht geprüft — unabhängig davon, ob ein Mensch oder ein Modell sie gebaut hat. Das ist übrigens der Grund, warum ich offen sage, dass ich mit KI arbeite: Die Frage ist nicht, ob eine Maschine beim Bauen hilft. Die Frage ist, ob danach jemand nachgemessen hat.

Zwei kostenlose Werkzeuge, mit denen Sie selbst anfangen können, bevor überhaupt eine Zeile Code geschrieben ist: der Design-Konfigurator übersetzt ein bestehendes Logo in konsistente Design-Token, der Konfigurator zeigt, welche Bausteine einer Website tatsächlich etwas bewirken — beides ohne Verkaufsgespräch.

Jetzt kostenlosen Website-Check machen →

Jetzt Website anfragen →

Die Ergebnisse

Platzhalter — bewusst leer.
Dieser Artikel beschreibt das Verfahren, nicht die Rangliste. Der Lauf über mehrere Modelle steht aus, weil dafür Zugänge zu den Modellen unter Test nötig sind. Ich veröffentliche hier keine geschätzten Zahlen — das wäre genau die Sorte Behauptung, gegen die der ganze Ansatz gerichtet ist.
Sobald der erste Durchlauf steht (acht Aufgaben, nur Gates, mehrere Modelle), kommen die Durchfallquoten pro Stufe als eigener Artikel. Die interessantere Zahl ist ohnehin nicht, wer gewinnt, sondern wo die Modelle scheitern: an der Geschwindigkeit, an der Barrierefreiheit oder am Überlauf.

Häufige Fragen

Ist ein automatischer Test nicht ungerecht gegenüber schönem Design?
Nein — er verschiebt nur die Reihenfolge. Schönheit wird bewertet, aber erst, nachdem die messbaren Grenzen halten. Eine Seite, die niemand auf dem Handy benutzen kann, ist nicht schön, sondern ein Bild.

Warum nicht einfach Lighthouse laufen lassen?
Lighthouse ist ein Teil davon (Gate 1 und Teile von Gate 2). Es beantwortet aber nicht, ob mitgelieferter Inhalt vollständig sichtbar bleibt, ob bei 390 px etwas ausläuft, und schon gar nicht, ob das Ergebnis nach etwas aussieht.

Kann ein Modell den Test nicht einfach lernen?
Genau dagegen ist er gebaut. Es gibt keinen Lösungsschlüssel — die Bewertung entsteht aus der Messung des gerenderten Ergebnisses. Zusätzlich wandern Aufgaben monatlich durch, ein Teil bleibt unveröffentlicht, und die Inhaltsdaten werden erneuert, damit ein memoriertes Layout auf neuen Text nicht mehr passt.

Gilt das nur für KI-gebaute Seiten?
Nein. Dieselben vier Gates fahre ich vor jedem Launch gegen meine eigenen Seiten. Der Unterschied zwischen handgemacht und maschinengebaut liegt nicht in der Prüfung — er liegt darin, ob geprüft wird.

Quellen

• Lighthouse (Google) — Performance- und Accessibility-Messung, programmatisch
• axe-core (Deque Systems) — Regelwerk für automatische Barrierefreiheitsprüfung, WCAG-basiert
• Playwright — Rendering, Screenshots, Geometrieprüfung im Browser
• WCAG 2.1 AA — Kontrast- und Bedienbarkeitsanforderungen
• Core Web Vitals (Google) — LCP, CLS, INP als Feldmetriken
• LiveCodeBench — Vorbild für rollierende Aufgabensätze gegen Kontamination
• Eigene Messnotizen (TB Webdesign, Juni–August 2026): Raster-Überlauf 486 px Lückenbreite bei 390 px Viewport · Chrome-Mindestfensterbreite ~500 px unter macOS · Knopffläche 1:1 bei 15,2:1 Textkontrast

Vollständige Spezifikation des Benchmarks (englisch, technisch): livewebvitalsbench/SPEC.md. Wenn Sie an den Ergebnissen interessiert sind, schreiben Sie mir — ich schicke den Folgeartikel, sobald der erste Lauf steht.

Timo Birck betreibt TB Webdesign, eine Webdesign- und GEO-Agentur in München.