This site: building an AI-era agency site with a full entity graph
The most inspectable case study an agency can publish is its own website, because you are looking at the artifact right now. We rebuilt optimoweb.net as a 102-page static Astro site with full English/Spanish parity across the entire funnel, a cascading JSON-LD entity graph rooted in a single Organization node, and llms.txt manifests for AI crawlers. Measured results: Lighthouse performance 100, largest contentful paint 1.0 s, and wire bytes down 70% through gzip, ETag revalidation, and tiered caching.
At a glance
The real numbers.
| Metric | Number |
|---|---|
| Static pages built (full EN/ES locale parity, reciprocal hreflang) | 102 |
| Location service-area hubs with per-city market context | 27 |
| Industry hubs / pillar guides / competitor comparisons | 7 / 8 / 5 |
| Branded 1200×630 social cards generated at build time | 102 (one per page) |
| Lighthouse performance score | 100 |
| Largest contentful paint | 1.0 s |
| Wire bytes after gzip + ETag + tiered caching | −70% |
All numbers are first-hand — measured on our own build, not estimated.
On this page
The starting point
An agency site is a marketing site: content changes when we decide it changes, nobody logs in, and there is no cart. That profile is exactly where a fully static build wins — no database to attack, no plugin stack to patch, nothing dynamic to slow down. It is also the profile where search is changing fastest: AI assistants and Google’s AI Overviews increasingly answer without a click, so the site had to be built to be cited, not just ranked — the thesis of our AI-era SEO guide and the AI-SEO service it comes from.
The other constraint was clarity about scope: this is the same architecture we sell as web design & development, so it has to demonstrate the playbook, not just describe it — the difference we lay out in OptimoWeb vs a traditional agency.
The approach
The site is data-driven, not hand-built page by page. Services, locations, industries, guides, comparisons, and pricing each live in typed content files; Astro templates render them into full hub pages at build time. Consistency in internal links, breadcrumbs, and schema is therefore an architecture property, not a diligence property — every one of the 102 pages gets the same treatment because it comes from the same source of truth.
- Full locale parity: the entire funnel — services, pricing, locations, industries, guides, comparisons — exists in both English and Spanish, with reciprocal hreflang on every pair. Not a translated afterthought; the same depth in both languages.
- 27 location hubs with genuine per-city market context (16 US metros, 11 Colombian cities), not swapped-city boilerplate.
- 7 industry hubs, 8 pillar guides, 5 competitor comparisons — each a full page with FAQ, internal-link rails, and schema.
- A pricing hub carrying OfferCatalog schema, so packages are machine-readable — see pricing.
- A CSS-first mega menu: hover panels built from real crawlable
<a>links, no JavaScript required for navigation.
The stack
- Astro, static output — every page pre-rendered to HTML at build time.
- Typed content files driving hub templates (services, locations, industries, guides, comparisons, case studies).
- A cascading JSON-LD entity graph from a single Organization
@idroot: Service nodes withareaServed, WebPage with Speakable, BreadcrumbList, and FAQPage on every page that shows a visible FAQ. - Build-time social-card generator — 102 branded 1200×630 og:image cards, one per page, rendered during the build.
- llms.txt + llms-full.txt — plain-text manifests giving AI crawlers a clean, factual map of the business.
- Delivery layer: gzip pre-compression, ETag/304 revalidation, tiered Cache-Control — on our own self-hosted infrastructure.
- Contact form through self-hosted mail — no SaaS form service in the loop.
What shipped
The measurable layer, on the live build: Lighthouse performance 100, largest contentful paint of 1.0 s, and wire bytes down 70% after the delivery pass — the metrics we explain for non-developers in Core Web Vitals for business owners. Every page ships its own branded social card, so nothing shares as a gray rectangle. And the whole thing costs what static hosting costs — the ownership shape from the 5-year math guide, applied to ourselves. What a build like this costs a client is itemized in full in what a website really costs in 2026.
The rule we enforce on this site and every client build: schema never claims what the page does not visibly say. No invented ratings, no phantom reviews. The FAQPage markup on this page is the FAQ you can read below — that is the whole trick.
The real trade-off: a static site means a rebuild for every content change. For a site we edit through git anyway, that costs nothing. For a marketing team publishing daily we would weigh it differently — and the fork between this and a builder platform is exactly what OptimoWeb vs Squarespace walks through.
Outcomes
What this delivered — plainly.
- 102 static pages with full English/Spanish parity and reciprocal hreflang across the entire funnel
- 27 location hubs, 7 industry hubs, 8 pillar guides, 5 competitor comparisons, pricing hub with OfferCatalog schema
- Cascading JSON-LD entity graph from a single Organization @id root — Service/areaServed, WebPage/Speakable, BreadcrumbList, FAQPage on every page
- llms.txt + llms-full.txt manifests for AI crawlers
- 102 branded 1200×630 og:image social cards generated at build time
- Lighthouse performance 100; LCP 1.0 s; wire bytes −70% via gzip + ETag + tiered caching
- CSS-first mega menu — crawlable links, zero JS required to navigate
- Contact form delivering through self-hosted mail — no SaaS form service
Questions
FAQ
Why publish your own website as a case study?
Because it is the one project where every claim is inspectable from your browser right now — the 102 pages, the entity graph, the social cards, the Lighthouse score. Nothing is inflated because nothing can be: you are inside the artifact.
What does "full entity graph" actually mean?
One canonical Organization node with a fixed @id is the root; every page emits WebPage, BreadcrumbList, Service, or FAQPage nodes that reference it. Authority signals cascade from a single root instead of fragmenting into disconnected schema blobs per page.
Would you build my business site this way?
If your content profile fits — marketing sites, documentation, landing systems that change on your schedule — yes, static is the strongest option. If your team publishes daily, needs an editor UI, or sells online, we will recommend WordPress or a headless commerce stack instead, and explain the trade-off.
Is Lighthouse 100 realistic for a normal business site?
On a static or well-tuned stack, yes for the templates that matter. What usually makes it impossible is third-party scripts — chat widgets, tracking pixels, embedded video. We scope those clearly per project.
What are llms.txt and llms-full.txt?
Plain-text manifests at the site root that give AI crawlers a clean, factual summary of the business — services, areas, pricing anchors, and canonical URLs — so assistants cite the site accurately instead of guessing from scraped fragments.
Keep reading
The guides behind this build.
Want your site built like this?
Same architecture, your business: a fast, owned, AI-readable site with the entity graph, locale parity, and performance numbers to show for it.