Skip to content
Novamedia
Let’s talk

Headless WordPress with Next.js: when is it worth it?

When a headless WordPress site with a Next.js frontend pays off, what it adds to build and operations, and the questions to answer before you commit to it.

Headless WordPress with Next.js pays off when a website needs more than a conventional theme can deliver: a custom experience, high performance, integrations with other systems, or the same content used in more places than one site. WordPress handles content and editing, while a custom Next.js frontend renders the site. For a simple brochure site that rarely changes, conventional WordPress is usually the more sensible and cheaper option to run.

The decision is therefore less about technology and more about content, operations and ownership. Below is how the setup works, where it delivers value, what it adds and how to judge whether it fits.

How a headless setup works

In conventional WordPress, one system stores content, runs plugins and generates the pages visitors see. A headless setup splits this in two. WordPress becomes the backend where editors write and organise content, and that content is exposed through an API, either the built-in REST API or GraphQL via a plugin such as WPGraphQL. The Next.js frontend fetches the content, assembles it and serves the site.

Next.js can generate pages ahead of time, regenerate them when content changes, or render them on each request when data must be fresh. That flexibility is a large part of the value. Static pages are fast and cheap to serve, while dynamic pages can pull prices, availability or personalised data from other systems.

Less changes for editors than many expect. They log in to the same WordPress, use the same editor and the same media library. The difference is that the editor does not automatically show content as it will appear on the live site unless a preview flow is built for it.

Where the value lies

  • Design and functionality are not limited by what a theme and its plugins allow, so you can build exactly the experience your business goals call for.
  • Speed and Core Web Vitals become easier to manage because the frontend loads only what each page needs, rather than scripts from a dozen plugins.
  • Security generally improves when the admin system is not publicly exposed on the same domain as the site, although WordPress still needs updates and monitoring.
  • The same content can serve a website, an app, digital signage or other systems because it is delivered through an API rather than locked into a theme.
  • Integrations with booking systems, CRM, product data or internal tools live in the frontend or a dedicated API layer, which makes them clearer and easier to test.

What gets added and what has to be built

Headless is not automatically simpler or cheaper. You run two components instead of one, and each needs hosting, updates and monitoring. Much of what conventional WordPress provides out of the box has to be built or solved separately.

  • Preview, so editors can see drafts exactly as they will look on the site before publishing.
  • Page regeneration when content is updated, so changes appear quickly without rebuilding the entire site.
  • Technical SEO, meaning metadata, sitemaps, redirects, canonical URLs and structured data that SEO plugins would otherwise handle.
  • Forms, search and other plugins that render features in the theme do not work in the frontend automatically and need to be connected or rebuilt.
  • Multilingual content, if the site runs in more than one language, has to be handled in both WordPress and the frontend routing.

None of this is unsolvable and most of it is well understood, but each item takes time. The honest way to see headless is as an investment that has to be justified by flexibility, performance or custom functionality.

When conventional WordPress is the better choice

If the site mainly presents the company, content changes a few times a month and there are no complex integrations, a well-built conventional WordPress theme usually achieves the same result for less money. The same applies when the business relies on many plugins that render features directly on the site, such as off-the-shelf booking forms or event calendars, since those would need to be solved again.

Be realistic about who will look after the site after launch, too. Many agencies and freelancers can take over a conventional WordPress site. A headless site needs developers who know both WordPress and Next.js. For simpler sites, a subscription website or a ready-made product can be the better route, and at Novamedia we point to that when it is enough, for example through our sister company Vefsíða.

What drives the cost

The cost of a headless site depends less on the number of pages than on the number of distinct templates, how flexible the content model must be and how many integrations it needs. A site with five well-defined page types and no external integrations is a very different project from one with product data from an inventory system, user login and two languages.

As an illustration, not a quote: if a headless site with custom design, preview, technical SEO and one or two integrations takes 120 to 200 hours, that is roughly ISK 2.1 to 3.6 million excluding VAT at our hourly rate of ISK 17,880. Custom websites start with us from 80 hours, and more complex projects go beyond the upper end. Operations come on top, because both components need hosting, backups, security updates and monitoring.

A checklist before you choose

  • List who updates content, how often, and what kinds of content they work with, because this shapes the content model in WordPress.
  • Identify the pages that matter most commercially, such as product pages, bookings or applications, and what they need to do that the current site cannot.
  • Map every system the site should pull data from or send data to, and who is responsible for each one.
  • Review the plugins in use today and mark the ones that render features on the site itself, since those will need a new solution.
  • Decide whether content should be reused outside the website, for example in an app or on screens, or whether the website is the only channel.
  • Define who hosts, updates and monitors both WordPress and the frontend after launch, and what that costs per month.
  • Measure the speed and search traffic of the current site before you change anything, so you can judge whether the change delivered.

Common questions

Can we keep our existing WordPress content? Yes, in most cases. The content already lives in WordPress and the frontend reads it through the API. The content model often needs tidying, though, for example when a lot of content is stored in page builders that a frontend cannot easily interpret.

Will we lose search rankings in the move? It should not happen if URLs are kept or redirected correctly and metadata, sitemaps and structured data are carried over. Migrating without that plan is a common reason search traffic drops after a relaunch.

Can we go headless in phases? Yes. It is sometimes sensible to start with the part of the site that matters most, such as product pages or a booking flow, and leave the rest on conventional WordPress for the time being.

How to get started

The best starting point is not choosing a technology but answering the checklist above. If the answers point to complex integrations, a custom experience or content that must be reused elsewhere, headless is probably the right choice. If they point to a simple brochure site, conventional WordPress or a ready-made product is probably better.

If you want an independent assessment before deciding, Novamedia offers Discovery and planning at a fixed price of ISK 214,560 excluding VAT for 12 hours. It covers goals, users, current systems and risks, and ends with prioritised recommendations and an indicative scope, phases and cost estimate. If someone else built your site and you want Novamedia to take it over, that starts with a fixed-price technical review of 4 hours, ISK 71,520. After launch, System operations at ISK 59,900 per month is designed for web systems and backends with a database, which usually describes a headless setup.

More insights

Facing a decision like this?

We answer questions and give a realistic assessment of the next steps — no strings attached.