How long does a headless WordPress site take to build?

Why does headless take longer than a classic theme?

Because there are two systems and a seam between them, and the seam is most of the work. WordPress has to expose its content and custom fields cleanly; the front end has to render every one of them; preview has to show editors their draft on the new front end; publishing has to trigger the front end to update; images have to flow from the WordPress media library through the front end's image pipeline; and every URL the old site ranked for has to arrive at the right new page. A classic theme gets most of that for free by living inside WordPress.

What the extra weeks buy is on the same page as the cost: a front end that loads like a static site, a content model built to be parsed and cited by search engines and AI assistants, and inquiries that can go straight into a CRM instead of an inbox. Whether that is worth it for your site is a question for discovery.

What happens in the eight weeks?

Discovery and architecture take two weeks, the build four, launch two. The URL map is week two's work on purpose.

What did a nine-week rebuild actually spend its time on?

The last headless rebuild I shipped replaced a live WordPress site of about thirty-five routes. From the first commit to the day the new front end took over took nine weeks and fifty-three commits. Twenty-one of those, 40%, landed in the final two weeks, and almost none of them were features:

• Three rounds of requested edits from the client, each after a review of the staging site.
• Photo swaps and copy corrections once real content sat in real templates.
• Metadata audits: titles, descriptions and schema checked page by page against the old site.
• A content-security-policy exception for the client's tag manager, and brute-force protection on the WordPress side.
• Build fixes and deploy retries on launch day, then page-level corrections in the two days after.

On the measurements that mattered, the new front end took total blocking time on throttled mobile from over a second to a tenth of one, and the Lighthouse SEO score from 61 to 100. None of that would have held without the redirect map, which is why it was week two's work and not week seven's. The overall website timeline shows the same launch fortnight on every kind of build.

What stretches a headless build?

• Custom fields designed page by page instead of as a model, so every template needs its own wiring.
• A legacy URL structure with years of search history and no redirect map.
• Third-party scripts that need exceptions from the front end's content-security policy, discovered in week seven.
• Preview expectations: editors reasonably expect the WordPress preview button to show the new front end, and that is build work, not configuration.
• Images: a media library of unsized originals that the front end has to serve responsively.

Each of these is a discovery question. Asked in week one, they are line items; found in week seven, they are the reason a site launches late.

When is headless not worth the extra weeks?

When your team is happy in a well-built classic theme and the site has no performance or product need a theme cannot meet. A custom block theme is four to six weeks, one host, one system to run. Headless is the right call when the site has to be fast and interactive without taking the editor away from the people who publish, and when search and AI visibility are part of the brief. If the editor can go too, a React site without WordPress behind it is the simpler build. The way I scope a headless build starts by asking which of those is true.

Questions