Ich habe Kunden jahrelang erklärt, warum eine Website aus dem Baukasten technisch nicht reicht. Schlechter Code, keine Barrierefreiheit, nichts in der Hand. Dann habe ich nachgesehen, ob das stimmt. Tut es nicht.
Zwei verschiedene Dinge heißen „Website mit KI“
Das wird fast immer vermischt, und es ist der Grund, warum die Diskussion so wenig bringt.
Der Baukasten mit KI-Assistent fragt nach Branche, Name und Stil und setzt daraus eine Seite aus vorgefertigten Bausteinen zusammen. Er darf nur bauen, was die Plattform kennt. Ionos und Wix arbeiten so.
Der Code-Agent bekommt eine Beschreibung und schreibt HTML, CSS und JavaScript neu. Nichts ist vorgegeben, alles entsteht im Moment der Anfrage. Das ist der Weg über ein Sprachmodell in der Entwicklungsumgebung.
Beide Wege scheitern an unterschiedlichen Stellen. Wer sie in einen Topf wirft, kommt bei beiden zur falschen Antwort.
Was die Baukästen messbar liefern
WebAIM hat im Februar 2026 die Startseiten der eine Million meistbesuchten Websites automatisiert geprüft. 95,9 Prozent hatten erkennbare Verstöße gegen die WCAG 2, im Jahr davor waren es 94,8 Prozent. Im Schnitt 56,1 Fehler pro Seite.
Aufgeschlüsselt nach Plattform:
| Plattform | Geprüfte Startseiten | Fehler pro Seite | Abweichung vom Schnitt |
|---|---|---|---|
| Squarespace | 2.669 | 33,0 | −41,2 % |
| Wix | 3.183 | 33,3 | −40,6 % |
| HubSpot CMS | 4.237 | 35,1 | −37,4 % |
| TYPO3 | 5.371 | 38,5 | −31,3 % |
| Drupal | 18.222 | 41,2 | −26,5 % |
| Joomla | 3.981 | 45,7 | −18,6 % |
| WordPress | 252.302 | 52,8 | −5,8 % |
Die Baukästen liegen vorn. WordPress, also das System, in dem ich selbst arbeite, liegt knapp unter dem Durchschnitt aller geprüften Seiten.
Eine zweite Messung mit anderem Verfahren kommt zum gleichen Ergebnis. Das HTTP Archive wertet Lighthouse-Accessibility-Scores aus und sieht Wix bei 94 Prozent, Squarespace bei 92, Google Sites bei 90, GoDaddy bei 85. Auch dort liegen die geschlossenen Plattformen über den offenen Systemen.
Die Erklärung ist naheliegend: eine Plattform, die nur ihre eigenen Bausteine ausliefert, kann Kontraste und Formularlabels einmal richtig lösen und dann für alle Kunden ausrollen. Bei WordPress entscheidet das jedes Theme und jedes Plugin neu.
Zwei Einschränkungen gehören dazu, sonst ist die Zahl missbrauchbar. WebAIM schreibt selbst, dass der Zusammenhang zwischen Technologie und Fehlerzahl nicht zwingend auf die Technologie zurückgeht. Und die Wix-Zahl umfasst alle Wix-Seiten, nicht nur die vom KI-Assistenten gebauten.
Was die Code-Agenten messbar liefern
Hier dreht sich das Bild.
WebAccessBench hat 19 Sprachmodelle über 150 realistische UI-Aufgaben geprüft, jede unter drei Bedingungen: ohne Erwähnung von Barrierefreiheit, mit der einfachen Bitte „mach es barrierefrei“, und mit detaillierten Anforderungen. Stand der Auswertung ist der 20. Februar 2026.
Die Modelle produzierten regelmäßig Barrieren, die leicht zu finden und damit leicht zu vermeiden gewesen wären, auch wenn im Prompt ausdrücklich nach Barrierefreiheit gefragt wurde. Verglichen mit großen Stichproben echter Websites zeigten die KI-generierten Interfaces eine höhere strukturelle Fehlerdichte.
Der Teil, der mich am meisten überrascht hat: der einfache Hinweis verbesserte die Ergebnisse um etwa 50 Prozent. Spezialisierte, detaillierte Anweisungen brachten darüber hinaus keine weitere Verbesserung. Man kann sich also nicht aus dem Problem herausprompten.
Das deckt sich mit meiner Arbeit. Ein Agent schreibt auf Anhieb brauchbares Markup, aber Fokusreihenfolge, Zustände von Bedienelementen und Fehlermeldungen in Formularen muss ich jedes Mal selbst nachziehen. Die Stellen, an denen es klemmt, sind erstaunlich konstant.
Was keine dieser Messungen sieht
Beide Studien arbeiten automatisiert, und WebAIM sagt dazu klar: automatisierte Werkzeuge erkennen nicht jeden WCAG-Verstoß, die Zahlen sind eine Untergrenze.
Was kein Prüfwerkzeug beurteilt: ob die Alt-Texte das Richtige beschreiben, ob die Überschriften den Inhalt gliedern oder nur groß sind, ob jemand mit der Tastatur in einer sinnvollen Reihenfolge durch die Seite kommt, ob die Fehlermeldung im Formular erklärt, was zu tun ist. Ein Baukasten mit 33 statt 56 Fehlern ist technisch solider. Über diese Fragen sagt die Zahl nichts.
Das eigentliche Problem liegt woanders
Nach allem, was ich an Daten gesehen habe, entscheidet der Code nicht darüber, ob eine Website Besucher bekommt.
Ich habe die Search-Console-Daten von drei Kundenprojekten über sechs Monate ausgewertet und veröffentlicht. Das deutlichste Ergebnis daraus: bei vergleichbaren Positionen unterscheidet sich die Klickrate einzelner Seiten um den Faktor 28 bis 64. Der Unterschied hing nicht an der Technik. Er hing daran, ob die Suchanfrage schon im Suchergebnis beantwortet war oder nicht.
Meine eigene Website zeigt dasselbe von der anderen Seite. Auf Kategoriebegriffe stehe ich zwischen Position 25 und 70. Auf konkrete Fragen stehe ich zwischen 3 und 11. Dieselbe Seite, dieselbe Technik, dieselbe Person. Der Unterschied ist, wie genau der Inhalt zu einer echten Frage passt.
Genau das kann keiner der beiden KI-Wege leisten. Der Baukasten kennt die Suchanfragen der Zielgruppe nicht. Der Code-Agent kennt sie auch nicht. Beide bauen eine Seite, die aussieht wie eine Website für das jeweilige Gewerbe. Welche Seiten es braucht, in welcher Reihenfolge, auf welche Frage jede davon antwortet, ergibt sich aus Suchdaten und aus Gesprächen mit dem Kunden. Nicht aus einem Prompt.
In den drei Projekten habe ich zuerst die Leistungsseiten gebaut, danach Fachartikel mit regionaler oder fachlicher Eingrenzung, zwei bis drei pro Monat. Ein Projekt wuchs in dieser Zeit von 10 auf 23 Seiten. Die Klicks landeten am Ende auf der Kontaktseite, die vorher 145 Einblendungen hatte und danach über 5.000.
Wofür ich KI tatsächlich einsetze
Ich argumentiere hier nicht gegen KI. Ich arbeite den ganzen Tag damit.
Sie recherchiert Suchdaten, die ich sonst von Hand aus vier Properties zusammentragen müsste. Sie schreibt Auswertungsskripte. Sie baut Entwürfe, die ich verwerfe oder weiterbaue. Sie findet Widersprüche in meinen eigenen Texten, bevor ein Kunde sie findet. Beim Artikel über die drei Kundenprojekte hat sie Fehlschlüsse in meiner Argumentation gefunden, die ich sonst veröffentlicht hätte.
Was sie nicht übernimmt, ist die Entscheidung, welche Seite überhaupt entstehen soll. Das ist keine Stilfrage. Es ist die Stelle, an der Suchdaten, Branchenkenntnis und das Gespräch mit dem Kunden zusammenkommen, und davon liegt nichts im Modell.
Wann ein Baukasten reicht
Es gibt Fälle, in denen die Antwort ja ist, und ich sage das Kunden auch so.
Ein Baukasten reicht, wenn die Website eine Visitenkarte ist. Die Aufträge kommen über Empfehlung, die Seite soll bestätigen, dass der Betrieb existiert, und draufstehen müssen Adresse und Telefonnummer. Sucht niemand bei Google nach dieser Leistung, dann bezahlt der Kunde eine Agentur für Arbeit ohne Ertrag.
Er reicht nicht, wenn Anfragen über die Suche kommen sollen. Dann entscheidet nicht, wie die Seite aussieht, sondern welche Seiten es gibt und auf welche Frage jede antwortet. Das ist Arbeit an Inhalt und Struktur, und die fängt vor dem ersten Entwurf an.
Wer unsicher ist, welcher Fall vorliegt, kann nachsehen. Die Search Console zeigt, auf welche Suchanfragen eine Website heute schon eingeblendet wird und was davon geklickt wird. Steht da nichts, liegt das selten am Code.
Quellen
- WebAIM Million 2026, Auswertung von 1.000.000 Startseiten, Februar 2026: webaim.org/projects/million
- HTTP Archive Web Almanac, Accessibility-Scores nach Plattform, zitiert bei Search Engine Journal
- WebAccessBench, Casey Kreer, Stand 20. Februar 2026: steady.page/bye-bye-barrieren
Welche Systeme für eine Umsetzung in Frage kommen, steht auf der Leistungsseite Webentwicklung mit WordPress.