When I first wrote this article in 2023, I was much more enthusiastic about Hugo for new website builds.
I still think Hugo is an excellent tool. It is fast, stable, simple to deploy, and very good at turning structured content into a static website. For the right project, especially a simple blog or documentation-style site, it can still be a brilliant choice.
But I use it much less than I used to.
The reason is not that Hugo became worse. It is that I was trying to repurpose Hugo for websites that were always more complex than a traditional static blog.
The marketing sites I build need reusable sections, flexible page layouts, forms, analytics, integrations, and sometimes dynamic components that talk to APIs or internal systems. Hugo can be pushed in that direction, but I found myself adding more frontmatter, more template logic, and more project-specific workarounds than I wanted.
For that kind of work, Astro has become my default.
What Hugo is still good at
Hugo is very strong when the website is mostly a straightforward blog.
If you need a fast, simple publishing workflow built around Markdown files, Hugo still makes a lot of sense. It compiles quickly, produces static output, and keeps the runtime footprint very low.
That is a useful set of tradeoffs. For a very simple blog, I would still happily consider it.
It also encourages a clean separation between content and presentation. Editors can focus on Markdown content while the templates control the layout. For some teams, that is exactly what they need.
For documentation sites and knowledge bases, I would now usually start with Astro and Starlight instead. Starlight is Astro’s documentation framework, and it gives you a much stronger foundation for navigation, search, content structure, and documentation-specific UI without needing to build all of that yourself.
Where Hugo started to feel limiting
The friction appeared when I tried to use Hugo for marketing websites with lots of reusable sections and page variations.
Most business websites are not just a collection of blog posts. They need service pages, landing pages, case studies, comparison sections, testimonials, pricing blocks, forms, calls to action, product cards, resource hubs, and campaign-specific layouts.
Hugo can do this, but I found myself fighting the structure more often than I wanted to. Building and reusing flexible page sections was possible, but it often meant pushing more information into frontmatter, adding conditional template logic, and creating conventions that only really made sense for that one project.
That added complexity made the build harder to maintain. The site could work well, but the route to getting there felt more fragile than it needed to be.
That matters because consistency is one of the main things clients are paying for. I want to be able to create a section once, reuse it across different page types, adjust it safely, and keep the design system coherent as the site grows.
For simple blogs, Hugo’s model is elegant. For modern marketing sites with lots of varied sections, I found Astro easier to manage.
Why Astro became my default
Astro gives me the static-first performance benefits I liked about Hugo, but with a component workflow that fits the way I build websites now.
I can create reusable sections, layouts, cards, buttons, image components, and content templates in a way that feels natural. I can keep most pages lean and static, then add interactivity only where it is genuinely needed.
That island architecture is useful. If a page needs a React or Preact component, a calculator, a filterable interface, a search tool, or something that talks to an API, Astro handles that without forcing the whole site to behave like a heavy JavaScript application. Interactive pieces can be loaded only where they are needed, which protects performance instead of making every page pay for every possible feature.
The tooling also fits my current workflow better. Astro works nicely with TypeScript, Tailwind, content collections, image optimisation, component libraries, SEO integrations, sitemap generation, and modern build workflows. It is quick to start, but it does not feel limiting when the project grows.
I have even built a reusable WildPress Astro boilerplate for new static builds. It includes reusable components, Tailwind, Preact islands, image optimisation, validation scripts, sitemap generation, Pagefind search, and optional deployment support.
That kind of foundation makes it easier to start a project with good defaults instead of rebuilding the same decisions every time.
How this fits small business websites
Most WildPress clients are hands-on business owners. They are not usually asking for a static blog in isolation.
They need websites that support sales, marketing, enquiries, content publishing, campaign landing pages, analytics, automations, and internal workflows.
That is why Astro has become such a good fit. It lets me build fast marketing websites with reusable sections and clean templates, while still leaving room for dynamic functionality where the business needs it.
It also works well with modern client editing workflows. When Astro is paired with a Git-backed CMS such as Pages CMS, clients can update structured content while the site stays in version control. That makes changes easier to review, roll back, and deploy through separate environments.
For some clients, this now extends into AI-assisted editing. They can use tools such as Codex or Claude Code through a desktop workflow to request content and layout changes in plain language. Because the project has validation checks, version control, and deployment environments around it, I can give clients more control without removing the guardrails that keep the site stable.
Hugo can be used in similar workflows, and it may continue to improve for that kind of work. But for my current projects, Astro gives me the better balance of performance, structure, and flexibility.
Where WordPress still fits
Astro is not a replacement for WordPress in every situation.
For many business websites, WordPress is still the better choice because it gives non-technical teams a familiar editing experience, a mature admin area, and a broad plugin ecosystem. I cover that side of the decision in Why choose WordPress? and on the WordPress development service.
The right choice depends on the workflow.
If the client needs a full CMS, complex editorial permissions, WooCommerce, or lots of admin-managed content, WordPress may be the more practical foundation. If the client needs a fast marketing site, a cleaner frontend, and a more component-led build, Astro is often the better fit.
My current recommendation
I would still consider Hugo for a simple static publishing project, a blog, or a documentation-style website where the content model is clear and the layout needs are modest.
For most new marketing websites, I now reach for Astro first.
It keeps the speed and simplicity I liked about static-site generators, but gives me a better way to build the kind of reusable, flexible, business-focused websites that clients tend to need now.
If you are planning a new marketing website or considering a move away from an older static or WordPress setup, read more about Astro website development at WildPress.