We don’t usually write about our own website, but the reasoning behind how siivix.com is built comes up often enough in conversations with clients evaluating their own web infrastructure that it’s worth writing down. This is a technical company’s site — most of our traffic arrives through search, from people evaluating a testing partner or researching a simulation platform, not from brand recall. That made SEO performance a build requirement, not a marketing afterthought, and it’s the main reason we chose Astro.js.
The problem with typical marketing-site stacks
A lot of corporate sites are built on JavaScript frameworks designed for interactive applications, then adapted to serve mostly static marketing content. That mismatch shows up in Core Web Vitals scores: large client-side JavaScript bundles delay Largest Contentful Paint, hydration work delays interactivity, and layout shifts from late-loading fonts or images hurt Cumulative Layout Shift. Search engines treat all three as ranking signals, so a slow, JavaScript-heavy marketing site is fighting its own stack before a single word of content gets evaluated.
None of this is a criticism of those frameworks — they’re built for a different problem. The mismatch is choosing them for a site that’s fundamentally a collection of documents, not an application.
What Astro.js does differently
Astro’s core model is straightforward: ship HTML by default, and only ship JavaScript for the specific components that need interactivity — a pattern the framework calls islands architecture. For a site like siivix.com, where nearly every page is static content, that means most pages ship close to zero client-side JavaScript.
A few specific choices in how we built the site follow directly from that:
Static generation with per-route control. Pages are prerendered at build time by default, so there’s no server round-trip or client-side data fetching delaying content. Our one dynamic route — the contact form’s submission handler — runs as an on-demand serverless function on Vercel, without forcing the rest of the site into server rendering.
Structured metadata as a first-class concern. Every page on the site defines its own title, meta description, Open Graph data, and JSON-LD structured data through a shared SEO component, rather than a single site-wide template with placeholder values. Astro’s component model makes that easy to enforce consistently — the SEO component is a required part of every page’s layout, not an optional add-on.
Image and font handling that doesn’t fight performance. Astro’s built-in image tooling handles responsive sizing and modern formats without a separate pipeline, and font loading is scoped and preconnected rather than blocking render.
Content collections for structured content. This blog runs on Astro’s content collections, which means posts are type-checked Markdown/MDX files with a defined schema — no CMS API round-trip at request time, and no risk of a missing field silently breaking a page’s metadata.
Programmatic SEO without duplicate-content risk
One thing we cared about specifically: building long-tail landing pages — for terms like “UAV testing platforms” or “IoT device certification testing” — without producing thin, duplicated content that search engines discount. Astro’s static routing makes it straightforward to generate those pages from a structured data source while still writing genuinely distinct content for each one, because the templating and the content are separate concerns. The page structure is programmatic; the paragraphs are not.
The result
We won’t claim a specific ranking outcome — that depends on far more than the stack — but the build-time fundamentals are where they should be: minimal JavaScript shipped by default, prerendered HTML for every static page, and structured metadata enforced by the framework rather than left to page-by-page discipline. For a site whose primary job is being found and read, that’s the right set of defaults to start from.
If you’re evaluating a rebuild for a technical company’s site, our honest advice is the same reasoning we used: start from what your site actually is — mostly documents, with a few genuinely interactive parts — and pick a framework that defaults to serving it that way.
Siivix Oy builds testing and simulation platforms for IoT and UAV systems. See our services or get in touch if you’re evaluating a technical rebuild of your own.