Turning a static webpage into an Astro site

The first version of the Snnr website was deliberately simple: a lightweight static page that introduced the company, the services we offer, the products we are building, and the best way to get in touch. That was enough to publish quickly, but it also meant every content change lived close to the page markup.

As the site started to grow, the better shape became clear. The homepage still needed to stay fast and static, but the content needed more structure. Services, portfolio items, careers, contact details, and blog posts should be editable as content, not buried inside a single page template.

That is what the Astro migration gives us.

Why Astro was a good fit

Astro keeps the site static by default, which suits a marketing website well. Pages can be generated at build time, hosted cheaply, and delivered quickly without adding runtime complexity. At the same time, Astro gives the codebase a cleaner structure for layouts, components, routes, and content collections.

The result is still a static website, but it is no longer a single static webpage.

The site now has reusable Astro components, a shared layout, generated blog routes, and Markdown-backed collections for the parts of the site that change most often. That means the website can grow without each update becoming a template edit.

Moving content into Markdown

Most of the site content now lives under src/content/. Each content area has its own collection:

• site for homepage copy, navigation, hero content, section headings, and footer text.
• services for the service cards.
• products for portfolio and product cards.
• careers for open role cards.
• contact for contact details and form labels.
• blog for posts like this one.

This makes the editing model much clearer. Updating a service, adding a portfolio item, or publishing a blog post is mostly a matter of editing Markdown frontmatter and body copy. The Astro templates decide how that content is rendered.

The blog is a good example. Posts are Markdown files in src/content/blog/, validated by the blog collection schema, listed on the blog index, and rendered through the shared blog post route. Publishing is controlled by the draft flag, so a post can stay private until it is ready.

What changed in the project

The migration split the website into the pieces it needed:

• src/pages/ contains the Astro routes for the homepage and blog.
• src/layouts/ contains the shared page layout.
• src/components/ contains small reusable UI pieces.
• src/styles/ contains global styling.
• src/content/ contains the Markdown collections that drive the site.

That structure is intentionally modest. It avoids turning the site into an application when a static site is the right tool, but it gives us enough separation to maintain it properly.

Deployment stays simple

The generated site is still deployed as static files. The GitHub Pages workflow installs dependencies, builds Astro, and uploads the generated dist/ output. The custom domain remains in public/CNAME, which Astro copies into the build output.

So the publishing flow is straightforward: edit content, build the site, and let GitHub Pages serve the static result.

What this unlocks

This change gives Snnr a better foundation for writing and maintaining the website. We can add engineering notes, Azure architecture decisions, product updates, and lessons from AI, IoT, and cloud-native delivery without reshaping the site every time.

The important part is not that the website uses Astro. It is that the site now matches how it will be maintained: static where it should be static, structured where it needs to grow, and simple enough to keep improving.