Case Study: Our Own Website – AEO-First, Accessible, and Without a Single Photo

The best case study we can show you is the site you’re reading right now. rocket-monkeys.com is our own project – built on exactly the principles we recommend to clients: static instead of bloated, citable by AI search engines, accessible to WCAG 2.1 AA, and entirely free of stock photos. Here we lay out the decisions we made, why we made them – and which of them carry over to your project.

TL;DR

• Stack: Astro 5 (static HTML, no server required), Tailwind CSS v4, hosted with a German provider – no vendor lock-in, no recurring platform fees.
• AEO-first: All content is server-rendered and therefore readable by AI crawlers, plus a JSON-LD knowledge graph, llms.txt, and hreflang for German/English.
• Not a single photo: Every visual is an animated inline SVG – tiny, crisp on any display, and free of layout shifts.
• Accessible: WCAG 2.1 AA, automatically audited with axe-core across all page types in light and dark mode – currently 0 violations, with a published accessibility statement.
• Interactive without a backend: Risk checkers, quick assessments, and PDF checklists run entirely in the browser – no server, no database, nothing to maintain.

The Starting Point: An Agency Website That Proves Instead of Claims

If you sell “web development and AI integration,” your own website is your first reference. The requirements we set for ourselves: the site has to be citable in AI search engines like ChatGPT and Perplexity (that’s our core business), it has to meet the accessibility level we sell with our BFSG offering (the BFSG is Germany’s Accessibility Act, the national implementation of the European Accessibility Act), and it has to be fast – without anyone updating plugins every month.

The obvious solution – WordPress with a page builder – was ruled out early. Not because WordPress is bad, but because a content site with a clear structure doesn’t need a PHP server, a database, or 30 plugins. Every one of those components is maintenance overhead and attack surface.

Why Astro – and What “Static” Actually Means Here

The site is built with Astro 5 and compiles down to pure HTML, CSS, and minimal JavaScript. There is no application server: what the browser receives are finished files. That has three consequences you notice in day-to-day operations:

1. Speed: Static HTML with self-hosted fonts and inline SVGs simply loads faster than any dynamically assembled page.
2. Security: Where no server code runs, there are no SQL injections, no outdated plugin vulnerabilities, no admin login to harden.
3. Hosting freedom: The site runs on ordinary German web space. No Vercel, no Cloudflare requirement – and therefore no dependency on US platforms. Why that matters to us is covered in detail on our cloud sovereignty page.

The only server-side exception: a small PHP script for the contact form – with a honeypot, time trap, and rate limit against spam. That’s all the backend this site has.

AEO-First: Built to Be Cited

Our most important design principle sounds unspectacular: everything that matters is in the HTML. AI crawlers like GPTBot or PerplexityBot often don’t execute JavaScript. A site whose content is only assembled in the browser is half invisible to them.

In practice, that means:

• Even the animated chat in our hero section – our most eye-catching design element – is server-rendered. The script merely types out the text visually; in the source code, it’s there in full. Crawlers read it, and so do screen readers.
• Every page carries a JSON-LD graph (organization, website, articles, FAQ, breadcrumbs) that explains the relationships to search engines and AI systems in machine-readable form.
• A curated llms.txt points AI systems to our most important content – as a complement, not a silver bullet; we’ve written up what it realistically delivers in our llms.txt guide.
• Articles open answer-first: the first paragraph answers the core question on its own, because retrieval systems pull individual passages out of context.

Not a Single Photo: Animated SVGs Instead of Stock Images

There isn’t a single photo or raster image anywhere in the site’s content. Every visual – from the logo to the service illustrations to the intro graphics on subpages – is an animated inline SVG, moved by CSS keyframes.

That’s not a stylistic exercise; it’s calculated: SVGs weigh a few kilobytes instead of several hundred, render razor-sharp on any display, cause no layout shifts (CLS), and adapt automatically to light and dark mode. And every animation respects the system-level “reduce motion” setting – if you don’t want movement, you get a calm, complete image.

Accessibility: Deliver First, Sell Second

We offer BFSG implementation as a service – so our own site has to hold that standard. Getting there meant an audit with axe-core across all page types, each in light and dark mode. The findings were instructive: two contrast issues sat, of all places, in our brand colors (labels too pale on a dark background) and in the cookie banner, whose glass effect ate contrast depending on what was behind it.

We fixed both in the design system – dedicated contrast tokens instead of one-off patches, an opaque banner instead of transparency. The result: 0 WCAG 2.1 AA violations in the automated audit, plus manual keyboard walkthroughs and screen reader spot checks. The audit command lives as a script in the project and runs again with every major change – accessibility as a process, not a one-time event. The details are in our accessibility statement.

To be honest: an automated audit only catches part of the problems. That’s why the statement also lists what isn’t perfect yet – like the decorative technology ticker that deliberately keeps moving. Transparency beats window dressing.

Interactive Tools Without a Backend

The site now includes several interactive tools: an EU AI Act risk checker, the BFSG quick check, the compliance radar, and the cloud workload check. All of them run entirely client-side – the logic ships as a decision tree inside the delivered HTML, with no API calls and no data transmission.

The pattern is deliberately reusable: a question catalog as JSON, a small piece of script logic, a result with concrete next steps. New self-checks come together in hours instead of weeks – and the PDF checklists next to them simply use the browser’s print function with a clean print stylesheet. No PDF generator, no server, nothing that can break.

What Carries Over to Your Project

Not every company needs this exact architecture. But the principles are transferable:

Principle	What it means for you
Static where possible	Content sites rarely need an application server – lower costs, smaller attack surface
Server-rendered content	Your content is fully readable by Google and AI search engines
SVG instead of stock photos	Faster, sharper, on-brand – and automatically theme-aware
Accessibility as a process	Audit tools built into the workflow, not a one-off before launch
Tools without a backend	Self-checks and calculators as lead magnets – with zero running costs

What we deliberately do not claim: that this approach is the right choice for highly interactive applications, shops with inventory management, or portals with login. Different rules apply there – and we say so honestly in the first conversation.

Conclusion

This website is our proof of work: built AEO-first, demonstrably accessible, free of photo bloat and platform dependency. If you want to know what these principles look like translated to your project – from a relaunch to a self-check tool for your customers – write to us for a no-obligation initial conversation at info@rocket-monkeys.com.