For most businesses, no. But the reasons have changed, and they are more specific than the performance arguments usually offered on either side.

There are now two kinds of machine reading your website, and they fail in opposite ways. AI crawlers, the ones that decide whether ChatGPT can cite you, do not execute JavaScript at all. AI browser agents, the ones that complete tasks on a customer’s behalf, do execute JavaScript but fail at interaction — and the specific things they fail on are the patterns modern JavaScript frameworks use most. A rebuild can expose you to both problems at once.

Here is the framework, as of October 2026.

What do most rebuild proposals fail to account for?

Start with the finding that matters most if you care about appearing in AI answers.

Vercel and Merj analysed crawler behaviour across Vercel’s network and nextjs.org and reported that none of the major AI crawlers render JavaScript. That list included OpenAI’s GPTBot, OAI-SearchBot and ChatGPT-User, Anthropic’s ClaudeBot, Meta’s Meta-ExternalAgent, ByteDance’s Bytespider, and PerplexityBot.

Their data showed ChatGPT and Claude crawlers do fetch JavaScript files — 11.5% and 23.8% of their requests respectively — but do not execute them. The conclusion was blunt: they cannot read client-side rendered content.

Three important caveats before you act on this. The study was published in December 2024, which makes it twenty-two months old — crawler capabilities may have changed and nobody has published an equivalent update that I can find. Vercel sells the framework and hosting that solve this problem, which is worth knowing even though the data is theirs and the methodology is disclosed. And Vercel itself noted that content in the initial HTML response, including JSON data or delayed React Server Components, may still be indexed, because models can interpret non-HTML content.

So the honest version is not “JavaScript kills your AI visibility.” It is that content which only appears after client-side JavaScript runs was invisible to the major AI crawlers as of late 2024, and no public evidence says that has changed.

Why is the second machine worse news for single-page apps?

Browser agents are a different population. ChatGPT’s agent, Claude’s computer use, Perplexity’s Comet — these drive a real browser, run your JavaScript, and try to complete a task.

Merj published task-level testing of these agents in September 2026, which is recent enough to be useful. It ran 100 purpose-built tests across perception, grounding, planning, execution and recovery, in rounds in November 2025 and March 2026.

The headline is encouraging and the detail is not. Average success across tests rose from roughly 30% to roughly 60% between rounds. Agents are improving quickly. They are also still failing about four tasks in ten.

Now look at what they fail on, with approximate success rates from the March 2026 round:

Read that list again as an architecture description. Canvas rendering, virtualised lists, skeleton loaders, div-based controls, optimistic UI that updates after a delay, overlays — these are not exotic. They are the default patterns of a modern React application.

One more finding worth knowing because it is about trust rather than architecture: on a test where a destructive control carried a misleading ARIA label, one agent clicked Cancel instead of Save in all 25 runs. Merj’s conclusion was that wrong ARIA can be worse than missing ARIA. That is a caution for anyone whose rebuild includes a hand-rolled component library.

A necessary clarification: Merj did not test whether crawlers execute JavaScript, and does not address SPAs or rendering strategy. It treats rendering as a stage that happens before the interaction it measures. So these two studies are complementary rather than confirming each other, and I am not claiming the newer one validates the older one.

What does this mean for the rebuild decision?

Three consequences, and they do not all point the same way.

If AI citation matters to you, server-side rendering is not optional. This does not mean avoiding React. Next.js, Remix, Astro and Nuxt all render on the server. It means that if your rebuild ships a client-side rendered single-page application, you have plausibly made your content invisible to the crawlers that feed ChatGPT and Perplexity. That is a configuration decision inside the rebuild, not an argument against the framework.

If transactions matter to you, semantics beat architecture. Real button and anchor elements, accessible names on icon-only controls, ARIA that tells the truth, persistent success and error states, no transparent click-eaters. Merj’s recommendation is to define these once in your design system components rather than per page. Notably, all of that is achievable on any stack and ignorable on any stack.

And the patterns that break agents are the ones frameworks make easy. Virtual scrolling for a long product list is good engineering and bad for agents. That is a real tension, not a reason to avoid the technique, but it is something to decide deliberately rather than inherit from a component library.

When does a rebuild genuinely make sense?

Five cases, and they are not about AI.

Your site is genuinely slow in a way that is not fixable. If you have already compressed images, cut third-party scripts and caching is configured, and your Core Web Vitals are still failing because of the platform itself, that is a real argument.

You need an interface your current platform cannot express. Configurators, complex filtering, real-time data, calculators, dashboards. If you are fighting your CMS on every feature, the fight has a cost.

You are supporting multiple front ends from one content source. Website plus mobile app plus kiosk plus partner feed. This is what headless is actually for, and the businesses that need it usually know.

Your developers cannot work on it. If every change requires a specialist you no longer employ, the maintenance cost is already a rebuild in instalments.

You need content and presentation separated for organisational reasons. Multiple teams, multiple markets, governance requirements.

When is it a mistake?

Four signs you are about to spend money badly.

The main argument is performance, and nobody has established why the current site is slow. A badly built headless site is slower than a well-built WordPress one. Headless is not a performance feature; it is an architecture choice with performance consequences in both directions.

The main argument is that it is modern. This is the most expensive reason in software and it is remarkably persistent.

Nobody has asked who maintains it. A WordPress site can be edited by your marketing coordinator. A custom React front end usually cannot. Factor in either developer availability or the ongoing retainer, because one of them is now a permanent line item.

Your content model has not been designed. Headless makes you define your content structure explicitly. Most organisations discover during the build that they have never agreed what a product, a service or a location actually is in their business. That discovery is valuable and it is not free.

The decision framework

Four questions in order. If you cannot answer one, stop there.

What specifically does the current site prevent you from doing? Name the feature or the metric. If the answer is general dissatisfaction, a rebuild will reproduce it in a new codebase.

Has the cheap version been tried? Image optimisation, script audit, caching, a template rewrite. These are weeks rather than quarters and they resolve a surprising share of rebuild requests.

If you rebuild, is the content server-rendered? This should be a stated requirement in the brief, not a detail the developer chooses later. The AI crawler evidence makes it a commercial requirement rather than a technical preference.

Who edits it and who maintains it on day ninety? If the honest answer is the agency that built it, price that in for three years.

The honest summary

For most small and mid-size businesses, a React or headless rebuild in 2026 is a solution looking for a problem, and the money is better spent on the specific thing that is broken.

If you do rebuild, the AI-era requirements are concrete and cheap to specify: render content on the server, use real interactive elements, keep your ARIA honest, and be deliberate about virtualised and canvas-based interfaces because agents struggle with both.

The architecture matters much less than those four decisions, and those four decisions are available on whatever platform you are already using.

Frequently asked questions

Do AI crawlers render JavaScript?

Vercel and Merj reported in December 2024 that none of the major AI crawlers do, including GPTBot, ClaudeBot, PerplexityBot, Meta-ExternalAgent and Bytespider. Gemini and AppleBot are the exceptions, both rendering through browser-based infrastructure. That study is now 22 months old and no equivalent public update exists, so treat it as the best available evidence rather than current fact.

Is headless better for SEO?

Not inherently. What matters is whether content is server-rendered. A server-rendered React site is fine; a client-side rendered single-page application was invisible to the major AI crawlers as of the most recent public testing. Headless is an architecture choice, not an SEO feature.

Is headless faster than WordPress?

Sometimes, and a badly built headless site is slower than a well-built WordPress one. If performance is the reason for your rebuild, establish why the current site is slow first — image weight, third-party scripts and caching account for most cases and are far cheaper to fix.

Can AI shopping agents use a React site?

They run JavaScript, so rendering is not the barrier. Interaction is. Merj’s September 2026 testing found agents succeeding only around 30% of the time on virtual scrolling and canvas-rendered interfaces, and around 55% on div-based buttons without a role attribute — all common React patterns. Real semantic elements matter more than the framework.

How do I know if I actually need a rebuild?

Name the specific thing your current site prevents, confirm the cheap fixes have been tried, require server-side rendering in the brief, and establish who maintains it after launch. If you cannot answer the first question with a feature or a metric, a rebuild will reproduce the problem in a new codebase.

Not sure whether your site is the problem?

A platform consultation looks at what your current site is actually costing you — speed, crawler access, agent readiness, maintenance — and tells you whether a rebuild is justified or whether three weeks of work on what you have gets you there.

Book a platform consultation. If the answer is keep what you have and fix four things, that is what we will tell you.