Field test: Astro for a bilingual marketing site
We rebuilt ezappsllc.com in Astro — 47 static pages, English and Spanish, content collections as the source of truth. What held up after months of real edits.
Our marketing site is 47 static pages in two languages, built with Astro. This is not a framework tour — it is what actually held up after months of shipping real changes to a production site, and where we had to fight.
Content collections earned their keep
The site’s seven service buckets live as MDX files validated by a schema. An eighth bucket cannot exist without a file that passes validation — titles have length limits, categories are enums, ordering is checked at build time.
That sounds bureaucratic until the first time a bad edit fails the build instead of shipping a broken page. The schema is the contract; the build is the reviewer that never gets tired.
The islands model matches marketing reality
Almost everything on a marketing site is static. Astro renders it to plain HTML — no hydration, no client framework tax. The few interactive pieces (a contact form with reCAPTCHA, a before/after slider, theme toggling) are small script islands that load only where used.
Result: the pages are fast because there is nothing to be slow. No bundle diet, no lazy-loading strategy meetings.
Image handling, the honest version
Astro’s asset pipeline converts and compresses at build time — one of our decorative atlas images went from 2 MB source to a 96 KB WebP without anyone thinking about it.
The catch: build-time images are build-time only. When we later added admin-authored blog posts that publish through an API without a rebuild, the atlas approach could not follow. We ended up drawing covers in CSS instead — a better fit for content that changes at runtime.
Bilingual without a plugin
English and Spanish are parallel page trees sharing components, with a small translation helper and per-locale content files. The sitemap emits hreflang alternates. No i18n framework, no runtime translation library — just files.
For two locales this is clearly right. At five-plus locales you would want more tooling; we are not pretending otherwise.
Where it fought us
- Anything dynamic needs a decision. Static output means admin-published content either triggers rebuilds or renders client-side. We chose client-side for instant publishing and accepted the SEO trade on those pages.
- Scoped styles are scoped. Component styles do not reach DOM your scripts create at runtime. The fix (global, namespaced styles for shared markup) is easy — the surprise the first time is not.
The verdict
For content-heavy, mostly-static sites, Astro is the strongest tool we have shipped with: schema-validated content, near-zero JavaScript by default, and a build that catches mistakes before visitors see them. For app-like surfaces we still reach for React — and the two coexist fine, which is exactly our production setup.