Case Study: Unsere eigene Website – AEO-first, barrierefrei und ohne ein einziges Foto

Die beste Case Study, die wir zeigen können, ist die Seite, auf der du gerade liest. rocket-monkeys.com ist unser eigenes Projekt – gebaut nach genau den Prinzipien, die wir Kunden empfehlen: statisch statt aufgebläht, zitierfähig für KI-Suchmaschinen, barrierefrei nach WCAG 2.1 AA und komplett ohne Stockfotos. Hier legen wir offen, welche Entscheidungen wir getroffen haben, warum – und was davon sich auf euer Projekt übertragen lässt.

TL;DR

• Stack: Astro 5 (statisches HTML, kein Server nötig), Tailwind CSS v4, gehostet beim deutschen Provider – kein Vendor-Lock-in, keine laufenden Plattformkosten.
• AEO-first: Alle Inhalte server-gerendert und damit für KI-Crawler lesbar, JSON-LD-Wissensgraph, llms.txt, hreflang für Deutsch/Englisch.
• Kein einziges Foto: Sämtliche Visuals sind animierte Inline-SVGs – winzig, scharf auf jedem Display und ohne Layout-Sprünge.
• Barrierefrei: WCAG 2.1 AA, automatisiert geprüft mit axe-core über alle Seitentypen in Hell und Dunkel – aktuell 0 Verstöße, mit veröffentlichter Barrierefreiheitserklärung.
• Interaktiv ohne Backend: Risiko-Checker, Schnell-Checks und PDF-Checklisten laufen rein im Browser – kein Server, keine Datenbank, nichts zu warten.

Die Ausgangslage: Eine Agentur-Website, die beweist statt behauptet

Wer „Webentwicklung und KI-Integration” verkauft, dessen eigene Website ist das erste Arbeitszeugnis. Unsere Anforderungen an uns selbst: Die Seite muss in KI-Suchmaschinen wie ChatGPT und Perplexity zitierfähig sein (das ist unser Kerngeschäft), sie muss das Barrierefreiheitsniveau erfüllen, das wir mit dem BFSG-Angebot verkaufen, und sie muss schnell sein – ohne dass jemand monatlich Plugins aktualisiert.

Die naheliegende Lösung – WordPress mit Page-Builder – fiel früh raus. Nicht weil WordPress schlecht wäre, sondern weil eine Content-Site mit klarer Struktur keinen PHP-Server, keine Datenbank und keine 30 Plugins braucht. Jede dieser Komponenten ist Wartungsaufwand und Angriffsfläche.

Warum Astro – und was „statisch” hier wirklich heißt

Die Seite ist mit Astro 5 gebaut und wird zu reinem HTML, CSS und minimalem JavaScript kompiliert. Es gibt keinen Anwendungsserver: Was der Browser bekommt, sind fertige Dateien. Das hat drei Konsequenzen, die man im Betrieb jeden Tag merkt:

1. Geschwindigkeit: Statisches HTML mit selbst gehosteten Schriften und Inline-SVGs lädt schlicht schneller als jede dynamisch zusammengebaute Seite.
2. Sicherheit: Wo kein Server-Code läuft, gibt es keine SQL-Injections, keine veralteten Plugin-Lücken, kein Admin-Login zum Absichern.
3. Hosting-Freiheit: Die Seite läuft auf gewöhnlichem deutschem Webspace. Kein Vercel-, kein Cloudflare-Zwang – und damit auch keine Abhängigkeit von US-Plattformen. Warum uns das wichtig ist, steht ausführlich auf unserer Seite zur Cloud-Souveränität.

Einzige serverseitige Ausnahme: ein kleines PHP-Skript für das Kontaktformular – mit Honeypot, Zeitfalle und Rate-Limit gegen Spam. Mehr Backend hat diese Seite nicht.

AEO-first: Gebaut, um zitiert zu werden

Unser wichtigstes Designprinzip klingt unspektakulär: Alles, was zählt, steht im HTML. KI-Crawler wie GPTBot oder PerplexityBot führen oft kein JavaScript aus. Eine Seite, deren Inhalte erst im Browser zusammengebaut werden, ist für sie halb unsichtbar.

Konkret heißt das bei uns:

• Auch der animierte Chat im Hero-Bereich – unser auffälligstes Gestaltungselement – ist server-gerendert. Das Skript tippt den Text nur sichtbar nach; im Quelltext steht er vollständig. Crawler lesen ihn, Screenreader auch.
• Jede Seite trägt einen JSON-LD-Graphen (Organisation, Website, Artikel, FAQ, Breadcrumbs), der Suchmaschinen und KI-Systemen die Zusammenhänge maschinenlesbar erklärt.
• Eine kuratierte llms.txt führt KI-Systeme zu unseren wichtigsten Inhalten – ergänzend, nicht als Wundermittel; was sie realistisch bringt, haben wir im llms.txt-Guide aufgeschrieben.
• Artikel beginnen answer-first: Der erste Absatz beantwortet die Kernfrage eigenständig, weil Retrieval-Systeme einzelne Passagen aus dem Kontext reißen.

Kein einziges Foto: Animierte SVGs statt Stock-Bilder

Auf der gesamten Seite gibt es kein Foto und kein Pixelbild im Content. Jedes Visual – vom Logo über die Service-Illustrationen bis zu den Intro-Grafiken der Unterseiten – ist ein animiertes Inline-SVG, per CSS-Keyframes bewegt.

Das ist keine Stilübung, sondern Kalkül: SVGs wiegen wenige Kilobyte statt mehrerer hundert, sind auf jedem Display gestochen scharf, verursachen keine Layout-Sprünge (CLS) und passen sich automatisch an Hell- und Dunkelmodus an. Und: Jede Animation respektiert die Systemeinstellung „Bewegung reduzieren” – wer keine Bewegung will, bekommt ein ruhiges, vollständiges Bild.

Barrierefreiheit: Erst liefern, dann verkaufen

Wir bieten BFSG-Umsetzung als Leistung an – also muss die eigene Seite das Niveau halten. Der Weg dorthin war ein Audit mit axe-core über alle Seitentypen, jeweils in Hell- und Dunkelmodus. Die Befunde waren lehrreich: Zwei Kontrastprobleme steckten ausgerechnet in unseren Markenfarben (zu blasse Labels auf dunklem Grund) und im Cookie-Banner, dessen Glas-Effekt je nach Untergrund den Kontrast fraß.

Beides haben wir im Design-System gelöst – eigene Kontrast-Token statt Einzelfall-Fixes, deckender Banner statt Transparenz. Ergebnis: 0 WCAG-2.1-AA-Verstöße im automatisierten Audit, dazu Tastatur-Durchläufe und Screenreader-Stichproben von Hand. Der Audit-Befehl liegt als Script im Projekt und läuft bei jeder größeren Änderung erneut – Barrierefreiheit als Prozess, nicht als Einmal-Aktion. Die Details stehen in unserer Barrierefreiheitserklärung.

Ehrlich gesagt: Ein automatisiertes Audit findet nur einen Teil der Probleme. Deshalb steht in der Erklärung auch, was noch nicht perfekt ist – etwa das dekorative Technologie-Laufband, das bewusst weiterläuft. Transparenz schlägt Schönfärberei.

Interaktive Tools ohne Backend

Die Seite enthält inzwischen mehrere interaktive Werkzeuge: einen EU-AI-Act-Risiko-Checker, den BFSG-Schnellcheck, den Compliance-Radar und den Cloud-Workload-Check. Alle laufen rein clientseitig – die Logik steckt als Entscheidungsbaum im ausgelieferten HTML, es gibt keinen API-Call und keine Datenübertragung.

Das Muster ist bewusst wiederverwendbar: ein Fragenkatalog als JSON, eine kleine Skript-Logik, ein Ergebnis mit konkreten nächsten Schritten. Neue Self-Checks entstehen so in Stunden statt Wochen – und die PDF-Checklisten daneben nutzen schlicht die Druckfunktion des Browsers mit sauberem Print-Stylesheet. Kein PDF-Generator, kein Server, nichts, was kaputtgehen kann.

Was sich davon auf euer Projekt übertragen lässt

Nicht jedes Unternehmen braucht diese exakte Architektur. Aber die Prinzipien sind übertragbar:

Prinzip	Was es bei euch bedeutet
Statisch, wo möglich	Content-Seiten brauchen selten einen Anwendungsserver – weniger Kosten, weniger Angriffsfläche
Server-gerenderter Content	Eure Inhalte sind für Google und KI-Suchmaschinen vollständig lesbar
SVG statt Stock-Fotos	Schneller, schärfer, markentauglich – und automatisch theme-fähig
Barrierefreiheit als Prozess	Audit-Tools in den Workflow, nicht einmalig vor dem Launch
Tools ohne Backend	Self-Checks und Rechner als Lead-Magnets – ohne Betriebskosten

Was wir bewusst nicht behaupten: dass dieser Ansatz für hochinteraktive Anwendungen, Shops mit Warenwirtschaft oder Portale mit Login die richtige Wahl wäre. Dort gelten andere Regeln – und auch das sagen wir im Erstgespräch ehrlich.

Fazit

Diese Website ist unser Proof of Work: AEO-first gebaut, nachweislich barrierefrei, ohne Foto-Ballast und ohne Plattform-Abhängigkeit. Wenn ihr wissen wollt, wie diese Prinzipien auf euer Projekt übersetzt aussehen – vom Relaunch bis zum Self-Check-Tool für eure Kunden –, schreibt uns für ein unverbindliches Erstgespräch an info@rocket-monkeys.com.