Case Study: How We Built a GEO-Optimized Bilingual Website (Our Own)
Case Study: How We Built a GEO-Optimized Bilingual Website (Our Own)
When we decided to rebuild the ANET Studios website in early 2026, we had a problem that most of our clients also face: we needed a site that performed in two very different arenas. It had to rank on Google for commercial search terms in both English and German. And it had to show up in AI search engines ??? ChatGPT, Perplexity, Google AI Overviews, Gemini ??? where a growing number of business decision-makers now research vendors.
Traditional SEO was not enough. A templated WordPress build was not going to cut it. We needed something purpose-built, and we decided to use our own site as a proving ground for every technique we recommend to clients.
This case study documents what we built, how we built it, and the real numbers it produced. If you are considering a website that needs to work across both traditional search and AI-powered discovery, the lessons here apply directly.
The Challenge
ANET Studios operates in two markets: Ireland (headquartered in Athlone) and Germany (office in Altena). That meant the site needed to:
- Serve two languages natively ??? not machine-translated afterthoughts, but genuinely localised content with proper German legal pages (Impressum, Datenschutz, AGB) and Irish-market pages (Privacy Policy, Terms and Conditions)
- Rank in Google in both markets ??? competing against local agencies in Ireland and established German web agencies
- Get cited by AI search engines ??? a new and largely uncharted ranking challenge
- Load fast everywhere ??? visitors in Dublin and Dortmund both expect sub-second pages
- Be technically maintainable ??? a small team cannot babysit a fragile CMS
The constraint that made this interesting: we had to accomplish all five without a traditional server-rendered framework (Next.js, Nuxt) because we wanted full control over the rendering pipeline and zero runtime server costs beyond static hosting.
The Solution: React + Vite + Playwright Pre-rendering
We chose a single-page application (SPA) architecture built with React and Vite, combined with a custom pre-rendering step using Playwright. Here is how the pieces fit together.
Architecture overview
The site is a React SPA that renders in the browser as any modern React app does. But before deployment, a Playwright script launches a headless browser, visits every route, waits for the page to fully render (including all async data), and saves the resulting HTML to disk. The output is a folder of static HTML files ??? one per route ??? that can be served by any static file server or CDN.
This gives us the best of both worlds: the developer experience of a React SPA during development, and the SEO and performance characteristics of a fully static site in production.
Bilingual architecture
The site uses a subdirectory structure for languages:
- English (default): ,
anetstudios.com/About,anetstudios.com/Servicesanetstudios.com/blog - German: ,
anetstudios.com/de/ueber-uns,anetstudios.com/de/dienstleistungenanetstudios.com/de/blog
German routes use German-language slugs (not
/de/About/de/ueber-uns/dienstleistungen/ServicesEach language has its own set of legal pages required by its market. German visitors get Impressum (legally required for German websites under TMG Section 5), Datenschutz (GDPR privacy policy in German), and AGB (terms and conditions). Irish/English visitors get Privacy Policy, Terms and Conditions, and Cookie Policy.
Hreflang tags on every page tell Google which version to show in each market:
<link rel="alternate" hreflang="en" href="https://anetstudios.com/About" />
<link rel="alternate" hreflang="de" href="https://anetstudios.com/de/ueber-uns" />
Pre-rendering: 33 routes, two languages
The Playwright pre-render script processes 33 routes across both languages. Each route gets its own isolated browser context to prevent state leakage (cookies, localStorage) between language versions. The script:
- Launches a headless Chromium browser
- Creates a fresh browser context per route
- Navigates to the route and waits for network idle
- Captures the fully rendered HTML including all dynamically injected content
- Saves the output as a static HTML file
The result is a
dist/The GEO Layer: Making AI Search Engines Understand Us
Traditional SEO gets you into Google. GEO (Generative Engine Optimization) gets you cited by AI. We implemented GEO at three levels.
Level 1: Schema.org structured data (15 distinct types)
The Cloudflare Worker that sits in front of our site injects Schema.org structured data into every page response. On the homepage alone, we use 15 distinct Schema.org types:
- Organization ??? company name, logo, founding date, social profiles
- ProfessionalService ??? service area, opening hours, price ranges
- WebSite ??? site-level metadata and search action
- FAQPage + Question + Answer ??? structured FAQ data that AI engines can directly quote
- OfferCatalog + Offer + Service + PriceSpecification ??? detailed service and pricing data
- PostalAddress ??? both office locations with full addresses
- GeoCoordinates ??? latitude and longitude for local search
- Place ??? physical business locations
- Person ??? team member data
- OpeningHoursSpecification ??? business hours by day
This is not decorative. AI search engines like Perplexity and ChatGPT with browsing parse structured data to extract facts. When someone asks "What does ANET Studios charge for web development?", the PriceSpecification schema provides a machine-readable answer that the AI can cite with confidence.
Level 2: llms.txt ??? direct communication with AI crawlers
We serve a dedicated
llms.txtanetstudios.com/llms.txtanetstudios.com/de/llms.txtThese files provide a concise, structured summary of what ANET Studios does, who we serve, what we charge, and how to contact us ??? written specifically for large language models. Unlike a homepage that is designed for human visitors with visual hierarchy and marketing copy, llms.txt is pure information density optimised for AI retrieval.
The Cloudflare Worker intercepts requests for these paths and serves the content with the correct
text/plainLevel 3: Content structure optimised for citation
Every page on the site follows a citation-friendly structure:
- Clear, factual headings that match common AI search queries ("What is GEO?", "Web development pricing Ireland")
- Specific numbers and data points that AI engines prefer to cite (research shows content with statistics gets 74% more AI citations)
- FAQ sections on key pages that directly answer the questions users ask AI assistants
- Short, quotable paragraphs ??? AI engines cite 1-2 sentence excerpts, not long paragraphs
The Cloudflare Worker: SEO Infrastructure Without Server Costs
Instead of running a Node.js server for SEO logic, we use a Cloudflare Worker ??? a serverless function that runs at the network edge, closer to visitors. The Worker handles:
- Dynamic meta tag injection ??? page-specific title tags, descriptions, and Open Graph tags for social sharing, injected into the HTML before it reaches the browser
- Schema.org injection ??? structured data added to each page based on its path
- llms.txt serving ??? AI-readable site descriptions in English and German
- Hreflang management ??? language alternate links injected consistently
- Bot-specific responses ??? search engine crawlers and AI scrapers get pre-rendered HTML with full structured data; human visitors get the SPA experience
This architecture means our SEO infrastructure costs effectively nothing to run (Cloudflare Workers' free tier handles our traffic volume comfortably) and adds zero latency because the Worker runs at the CDN edge.
The Results
Here are the real numbers from our production deployment, measured in May 2026.
Performance
| Metric | Value |
|---|---|
| Time to First Byte (TTFB) | 73 milliseconds |
| Total page load (server) | 73 milliseconds |
| Pre-rendered routes | 33 (English + German) |
| JavaScript required for initial render | None (pre-rendered HTML) |
A TTFB of 73 milliseconds means the server responds before most visitors' browsers have finished DNS resolution. The page is fully rendered in the HTML ??? no JavaScript needs to execute before the visitor sees content.
SEO and GEO coverage
| Metric | Value |
|---|---|
| Schema.org types on homepage | 15 distinct types |
| llms.txt (English) | 659 words |
| llms.txt (German) | 521 words |
| Blog posts (English) | 4 published |
| Blog posts (German) | 4 published |
| Legal pages | 7 (3 German-specific, 4 English/Irish) |
| Hreflang coverage | 100% of routes |
Architecture
| Component | Technology |
|---|---|
| Frontend framework | React + Vite |
| Pre-rendering | Playwright (headless Chromium) |
| Hosting | Docker container (Hetzner, Germany) |
| SEO/GEO layer | Cloudflare Worker (edge) |
| DNS and CDN | Cloudflare |
| SSL | Cloudflare (automatic) |
| Deployment | Docker Compose with backup scripts |
Key Takeaways
1. Pre-rendering beats server-side rendering for small-to-medium sites
If your site has fewer than a few hundred routes, pre-rendering with Playwright is simpler, faster, and cheaper than running a server-side rendering framework. You get the same SEO benefits (complete HTML for crawlers) without the runtime server costs or the complexity of hydration mismatches.
2. Bilingual sites need bilingual slugs
Translating your content but keeping English URL slugs is a common mistake. German users click
/de/dienstleistungen/de/Services3. Schema.org is not optional for AI search
AI search engines rely heavily on structured data to extract facts. A site with rich Schema.org markup gives AI engines quotable, structured information. A site without it forces the AI to infer facts from unstructured text ??? which means it is more likely to get details wrong or skip you entirely.
4. llms.txt is cheap insurance
Writing a 500-700 word summary of your business for AI crawlers takes an hour. Serving it costs nothing. The potential upside ??? being accurately represented when someone asks an AI assistant about your services ??? makes this one of the highest-ROI investments in GEO.
5. Edge computing eliminates the SEO-or-performance trade-off
The traditional choice was: serve a fast static site with limited SEO, or run a server-rendered site with full SEO but more complexity and cost. Cloudflare Workers eliminate this trade-off. You serve static files for speed and inject SEO metadata at the edge for completeness. Both goals are achieved without compromise.
Applying This to Your Business
You do not need to build the exact same architecture to benefit from these principles. Here is what matters regardless of your tech stack:
- Measure your TTFB. If it is over 500 milliseconds, your hosting or architecture is holding you back.
- Check your Schema.org markup. Paste your URL into Google's Rich Results Test and see what Google finds. If the answer is nothing, you are invisible to structured-data-dependent AI search.
- Create an llms.txt file. Even a basic one-page summary of your business, services, and contact information gives AI crawlers something accurate to work with.
- Test in both languages. If you serve multiple markets, search from each market in each language and verify you are showing up.
If you want help implementing any of these techniques for your own site, get in touch. We build websites designed to perform in both traditional search and the new AI-powered discovery landscape. Every technique in this case study is available as part of our web development and SEO/GEO services.
Frequently Asked Questions
What is the difference between pre-rendering and server-side rendering?
Pre-rendering generates HTML files at build time (before deployment), while server-side rendering generates HTML on every request (at runtime). Pre-rendering is faster and cheaper for sites with a fixed number of routes because the HTML is already built and waiting. Server-side rendering is better for sites with millions of dynamic pages (like e-commerce catalogues) that cannot all be pre-built.
Do I need a Cloudflare Worker for GEO optimization?
No. A Cloudflare Worker is one way to inject SEO and structured data at the edge, but you can achieve the same result with server-side rendering frameworks (Next.js, Nuxt), static site generators (Astro, Eleventy), or even WordPress plugins that generate Schema.org markup. The principle matters more than the specific technology.
How long does it take to see results from GEO optimization?
AI search engines update their indices more frequently than Google (some refresh weekly), so you may see AI citation improvements within 2-4 weeks. Traditional SEO results from structured data and content improvements typically take 2-6 months to fully materialise, depending on your market competitiveness.
Is llms.txt an official standard?
As of May 2026, llms.txt is an emerging convention rather than a formal standard. It was proposed as a way for websites to provide AI-readable summaries, similar to how robots.txt communicates with search engine crawlers. Major AI search engines have been observed to request and use llms.txt files, making it a practical investment regardless of its formal standardisation status.
Can a small business afford this kind of website?
Yes. The techniques described in this case study do not require enterprise budgets. A professionally built custom website with pre-rendering, structured data, bilingual support, and GEO optimization starts at around EUR 5,000-8,000 at ANET Studios. Managed hosting including all the SEO infrastructure starts at EUR 59 per month. The site is designed to pay for itself through improved search visibility and higher conversion rates.
