React Development — Interfaces That Search Engines Can Still Read

The mistake we get called in to fix

A single-page app is shipped, it looks excellent, and six months later nobody can work out why the site gets no search traffic. The pages render fine in a browser and return almost nothing to a crawler.

It is fixable — usually by moving the marketing routes to server rendering or static generation and leaving the application behind a login as it is. It is considerably cheaper to decide this before the build than after.

When we would tell you not to use React

If the site is content and forms, a server-rendered stack will be faster to build, faster to load and easier to keep indexable. Reaching for React because it is current is how a five-page brochure ends up with a build pipeline.

We would rather talk you out of it at the quote stage than rebuild it later.

Choosing the rendering mode per route

Next.js gives you static generation, server rendering and client rendering, and the useful decision is per route rather than per project. Marketing pages are static or server-rendered so they are fast and crawlable. The logged-in application can render on the client, because nobody needs Google to index a dashboard.

Getting this wrong in either direction is expensive. Statically generating personalised content serves the wrong data to the wrong person; client-rendering a pricing page hides it from search entirely.

Performance is a budget, not a switch

React ships JavaScript, and JavaScript costs more than its download size — it has to be parsed and executed, on whatever phone the visitor owns. A bundle that feels instant on a developer laptop can take several seconds to become interactive on a mid-range Android.

So we set a budget at the start and measure against it: what loads on first paint, what is deferred, and which dependency is worth its weight. A date picker that costs more than the rest of the page put together is a common find.

Accessibility is harder in a single-page app

A traditional page load tells a screen reader that something changed. A client -side route change does not, so users can be moved to a new page and never be told. Modals trap focus, infinite scroll strands keyboard users, and none of it shows up in a visual review.

It is fixable with route announcements, deliberate focus management and testing with a keyboard before a mouse. Worth doing on its own merits, and it overlaps almost completely with the markup quality search engines rely on.

Inheriting an existing React project

Common requests: it is slow, it is not indexed, or the person who built it has gone and nobody dares upgrade anything. All three are tractable.

We start by measuring rather than rewriting. A rewrite is occasionally the right answer and is almost always the expensive one, and most React codebases we are shown need three or four specific fixes rather than a fresh start.

What we do

• React and Next.js builds, or joining an existing codebase
• Rendering strategy decided per route, not per project
• Component libraries your team can extend without us
• Rescue work on SPAs that are not being indexed
• Core Web Vitals measured on real visitors, not lab scores