Skip to main content

Case Study: How We Built a GEO-Optimized Bilingual Website (Our Own)

By Shalli15 May 2026Updated: 18 May 202610 min read

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:

  1. 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)
  2. Rank in Google in both markets ??? competing against local agencies in Ireland and established German web agencies
  3. Get cited by AI search engines ??? a new and largely uncharted ranking challenge
  4. Load fast everywhere ??? visitors in Dublin and Dortmund both expect sub-second pages
  5. 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/Services
    ,
    anetstudios.com/blog
  • German:
    anetstudios.com/de/ueber-uns
    ,
    anetstudios.com/de/dienstleistungen
    ,
    anetstudios.com/de/blog

German routes use German-language slugs (not

/de/About
but
/de/ueber-uns
). This is a deliberate SEO decision ??? Google treats the URL slug as a relevance signal, and a German-speaking user searching for "Webentwicklung" is more likely to click a result with
/dienstleistungen
in the URL than
/Services
.

Each 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:

  1. Launches a headless Chromium browser
  2. Creates a fresh browser context per route
  3. Navigates to the route and waits for network idle
  4. Captures the fully rendered HTML including all dynamically injected content
  5. Saves the output as a static HTML file

The result is a

dist/
folder containing pure HTML files that require zero JavaScript to display their initial content. Search engine crawlers and AI scrapers get complete, rendered pages without needing to execute any JavaScript.

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.txt
file (inspired by the emerging convention for AI-readable site descriptions) at both
anetstudios.com/llms.txt
(659 words, English) and
anetstudios.com/de/llms.txt
(521 words, German).

These 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/plain
content type. No database, no CMS ??? the content is embedded directly in the Worker code for maximum reliability and speed.

Level 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

MetricValue
Time to First Byte (TTFB)73 milliseconds
Total page load (server)73 milliseconds
Pre-rendered routes33 (English + German)
JavaScript required for initial renderNone (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

MetricValue
Schema.org types on homepage15 distinct types
llms.txt (English)659 words
llms.txt (German)521 words
Blog posts (English)4 published
Blog posts (German)4 published
Legal pages7 (3 German-specific, 4 English/Irish)
Hreflang coverage100% of routes

Architecture

ComponentTechnology
Frontend frameworkReact + Vite
Pre-renderingPlaywright (headless Chromium)
HostingDocker container (Hetzner, Germany)
SEO/GEO layerCloudflare Worker (edge)
DNS and CDNCloudflare
SSLCloudflare (automatic)
DeploymentDocker 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
more readily than
/de/Services
, and Google treats the slug as a relevance signal for local-language queries. The extra effort of maintaining two slug structures pays for itself in click-through rates.

3. 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.