Getting a Client-Rendered React Site Indexed: Why We Added Prerendering to a Travel Platform

A travel blog lives or dies by search. For a content-driven travel platform with article listings, article pages, a travel awards programme and API-backed travel content, the app was built as a client-rendered React application. To make sure search engines could index its pages, we added static prerendering. This post explains why that mattered and how to decide on rendering for your own content product.

The project

The platform includes:

• Blog listing pages and individual article pages.
• Pages for a travel awards programme.
• Travel content integrated from an API.
• Social sharing on every article.

It is built with React, React Router, NextUI, Tailwind CSS, Framer Motion and Zod. It was delivered by a three-person MindForge team across 162 commits.

Why client-side rendering is a risk for content

In a client-rendered app, the server sends a mostly empty HTML page and JavaScript builds the content in the browser. For an application behind a login, that is fine. For public content that needs to be found, it adds risk.

Google can render JavaScript, but it describes the process in stages, with rendering happening after crawling, in its JavaScript SEO basics guide. Other crawlers, including many social platforms that build link previews, may not run JavaScript at all. If the first HTML response is empty, those systems see an empty page.

For a travel platform whose articles are meant to be shared and searched, that is the whole business at risk.

Why prerendering

Prerendering generates the HTML for each page ahead of time, so the first response already contains the article: title, text, links and metadata. The page still becomes a full React application in the browser afterwards.

Static prerendering made the existing client-rendered app indexable without rebuilding it on a different framework. The pages search engines and social platforms fetch are complete, while visitors still get the interactive app.

Google's own guidance points in the same direction. It describes dynamic rendering, serving different content to bots, as a workaround rather than a long-term solution in its dynamic rendering documentation, and recommends server-side rendering, static rendering or hydration instead.

What prerendering does not fix

Prerendering makes content readable. It does not make it well structured. A content platform still needs:

• A unique title and description for every page.
• Proper heading structure within articles.
• Social sharing metadata so links preview correctly.
• Internal links between related content.

Choosing a rendering strategy from the start

If you are starting a content product today, make this decision before writing the first page:

• Mostly public content that changes occasionally: static generation or prerendering.
• Public content that changes constantly or is personalised: server-side rendering.
• Private application screens behind a login: client-side rendering is fine.

Many products mix these, with public marketing and content pages rendered on the server or at build time and the logged-in app rendered on the client. Choosing a framework that supports all three avoids the retrofit we did here. This website, for example, generates its blog pages statically at build time.

A checklist for content that needs to be found

• Check what your pages return with JavaScript disabled.
• Make sure every public page delivers complete HTML on the first request.
• Give every page its own title, description and sharing metadata.
• Avoid serving different content to crawlers and people.
• Decide rendering per section of the site, not once for everything.

The anonymised write-up is in our work library. For multi-language sites, the next question is URL structure, covered in building bilingual Arabic and English apps. Making existing products discoverable is part of our product improvement service.