WordPress, Astro or Next.js: which fits your business?

These tools solve different parts of the problem

WordPress is a content management system. It brings together an editing interface and the software used to deliver a website. Astro and Next.js are web frameworks: they provide a foundation for developers to build the site, but the editing experience depends on what is added to the project. Calling all three a CMS can hide that distinction.

For a small business, the useful comparison starts with daily tasks. Who updates a service page? How does a draft become a published article? Will customers sign in? What happens when the person who built the site is unavailable? The answers matter more than the popularity of a framework.

All three can support a professional website. None removes the need for clear content, accessible design, suitable hosting or maintenance. Choose the setup that meets your requirements with a workload your team can manage.

Start by watching someone edit a page

Before discussing architecture, make a short list of routine changes: updating opening hours, adding a team member, publishing news and replacing a document. Ask the proposed developer to show how those tasks would work in the finished system.

If the website changes only occasionally, you may be comfortable sending approved updates to a provider. If several colleagues publish every week, an editing interface with suitable roles and previews becomes more important. For bilingual content, ask how editors can tell which language is complete and which needs review.

A free-form page builder can offer flexibility, but it also gives editors more ways to introduce inconsistent layouts. Structured fields can protect the design, but they need to cover the content the business actually publishes. Neither approach is automatically more independent: independence comes from a workflow the team understands.

When WordPress is a useful fit

WordPress is worth considering when you need an established editing environment and common publishing features. Its core provides content and user management; themes and plugins extend the design and behaviour. The official plugin documentation explains that relationship.

A local organisation publishing articles, vacancies and events may find a well-configured WordPress site practical. The key is to select a focused set of components and keep the editing experience understandable. Installing an extension for every small requirement can make future updates harder to coordinate.

Ask who maintains the theme and plugins, which licences must renew and what happens when an extension is abandoned. Keep a staging or recovery process appropriate to the site. WordPress’s update guidance recommends backing up before an update so there is a way to recover if something goes wrong.

A careful WordPress build can be fast and usable. A crowded theme and an accumulation of scripts can also make it slow. Judge the implementation and maintenance plan alongside the product name.

When Astro deserves a look

Astro focuses on websites where content is central. Its documentation describes an approach that renders content on the server and avoids sending client-side JavaScript unless it is needed. Interactive components can be added where the page requires them.

This can suit a service website, a publication or a documentation site. A straightforward public site can be generated as static files, while other projects use server rendering. “Built with Astro” therefore does not by itself tell you whether a database, an application server or a CMS is part of the setup.

The editing question remains. Content stored in files can work well for a technical team or infrequent changes. A team that wants an admin interface can connect a CMS. That adds an editing system to select, configure and maintain, so include it in the proposal rather than assuming it comes with the framework.

A static public site reduces the code executed when a visitor requests a page. Forms, search services, build dependencies and any connected CMS still need attention. Static delivery changes the maintenance work; it does not make that work disappear.

When Next.js matches an application requirement

Next.js is a React framework that can support public pages and application features in the same project. In its App Router, pages and layouts use Server Components by default, with Client Components for browser interactions. The official explanation sets out that division.

It is a sensible candidate when the brief includes a customer portal, permissions, personalised information or workflows connected to business systems. Those requirements deserve application design: access controls, validation, failure handling and a way to investigate errors.

A developer can also use Next.js for a simple business website. Ask whether the chosen setup brings practical value for your team and whether its operating requirements fit your budget. The framework’s flexibility only helps when the project uses it for a reason.

Hosting depends on the features selected. A server-backed application needs an environment that supports them; a static export has a different set of capabilities. Get the actual deployment arrangement in writing so a future handover does not depend on assumptions.

Where a headless CMS such as Payload fits

A headless CMS manages content separately from the public presentation. Editors work with an administration interface; the website retrieves or reads the content and presents it using its own design. This allows a structured content model to serve more than one presentation, but someone still has to build the connection.

Payload is one option. Its documentation describes an open-source TypeScript backend integrated with Next.js, including an admin panel, APIs, authentication and access controls. That makes it relevant to content management and some application requirements.

It is not a promise of an instantly finished website. Content fields, editor permissions, previews, language handling and the public layouts must reflect the project. An additional content type may require development even if adding an entry to an existing type is easy for an editor.

Ask to see the specific editing tasks from your brief. A headless setup earns its complexity when that separation helps your organisation publish, reuse or govern content.

Compare the operating costs, not just the build

List the costs of hosting, software services, licences, routine maintenance and small changes. A setup with a modest hosting bill may still need developer time for every content update. A more substantial initial build may give editors useful autonomy. You need the combined picture.

Think about who can support the site as well. Ask for access to the repository or agreed source deliverables, a list of services, configuration instructions and a backup process. Open-source software can make components available, but it does not automatically provide your project’s custom source, account access or documentation.

For a Swiss business with several languages, include the continuing work of keeping content aligned. Check who reviews a changed service description and how the second language gets updated. The technology should make that responsibility visible.

Our website budget guide explains the difference between a starting price and a scoped proposal. Use the same distinction when comparing technology options.

Test performance and usability on representative pages

A framework’s reputation is not a test result. Ask to check a representative page with the real images, fonts, forms and third-party tools enabled. A plain demonstration page says little about a finished site with a large video and several tracking scripts.

Read the page on a phone and use the navigation with a keyboard. Check whether the content is available promptly and whether the layout shifts while it loads. For measurement terminology, Google’s Web Vitals overview explains loading, responsiveness and visual stability.

These checks do not replace a fuller quality review. They help you ask better questions before committing. Ask the developer which performance constraints the proposal covers and how later additions will be assessed.

Three example briefs, three useful conversations

A consultancy that changes its offer twice a year: discuss a small content-focused site, how updates are requested and whether a CMS would save enough effort to justify its setup. Astro could fit, but the editing agreement matters just as much.

An association publishing frequent news with several editors: start with roles, drafts, previews and training. WordPress may provide a suitable starting point; a structured headless CMS may also work if the organisation’s needs justify it.

A service business with a customer area and internal workflows: discuss the application requirements, permissions and integrations before choosing the public site design. Next.js with an appropriate backend may be a candidate. The support plan needs to cover an application, not only brochure pages.

These are illustrative situations, not reports of client results. They show why a technology recommendation should follow the brief.

Questions before choosing your stack

Which tool is best for SEO?

All three can produce crawlable, well-structured pages. Content, internal links, metadata and implementation quality still need work. Ask how the proposed site handles those tasks rather than treating the framework as a ranking advantage.

Can the site move to another provider?

Plan that before the build. Establish what source, content exports, account access and documentation you will receive. A handover should be workable for the actual system, including hosted services and integrations.

Should we replace an existing WordPress site with a newer framework?

Only if that addresses a real problem. First inspect the current site, its dependencies and the team’s editing needs. A targeted repair may be enough; a migration has its own cost and needs a plan for content and URLs.

Tell us how your team needs to use the website. We can compare suitable options and explain the maintenance each would involve.