The problem: an empty page in disguise
Frameworks such as React are usually set up with a build tool like Vite to produce a single-page application. The server sends one small HTML file, often containing little more than <div id="root"></div>, plus a JavaScript bundle. The visitor's browser downloads and runs that script, and only then does the page appear.
For a person on a fast connection this works. For anything that reads HTML without running the script, the page is effectively blank: no headings, no text, no links.
We found this on our own website
When we audited codecreststudio.vercel.app in October 2026, the deployed HTML for every route was the same empty shell. Every page also shared one title and description, and the canonical tag pointed to a custom domain that did not resolve in DNS. In practice that meant every page was telling search engines that its "real" address was somewhere that didn't exist.
None of this was visible in a browser. The site looked and worked perfectly. That's what makes the problem easy to miss.
How to check your site in two minutes
- Open your page, right-click and choose View page source (not Inspect, which shows the page after JavaScript has run).
- Search the source for a sentence you can see on the page. If it isn't there, the content is rendered by JavaScript.
- Check the
<title>,meta name="description"andlink rel="canonical"on two different pages. If they are identical, search engines see your pages as near-duplicates. - Paste the canonical URL into a new tab. It should load the same page, not an error.
Why it matters for Google, social previews and AI answers
Google's own JavaScript SEO documentation (opens in a new tab) explains that pages are crawled, queued for rendering and then indexed; rendering can happen later than the crawl. Other systems are less forgiving. Link-preview bots for messaging and social apps generally read only the initial HTML, which is why a client-rendered page often shares with the wrong title or no image. Many other crawlers, including some used by AI search tools, also rely on the HTML they receive.
Server-rendered or prerendered HTML removes the guesswork: everyone receives the same complete page.
Your options, from simplest to most involved
| Approach | How it works | Good for |
|---|---|---|
| Build-time prerendering (static generation) | Each route is rendered to an HTML file during the build | Marketing sites, blogs, portfolios: content that changes when you deploy |
| Server-side rendering | HTML is generated on each request | Frequently changing or personalised pages |
| Migrating to a framework with rendering built in | Next.js, Astro, Remix and similar handle it for you | New builds, or sites that need both static and dynamic pages |
| Dynamic rendering | Serve bots a pre-rendered copy and users the app | Google describes this as a workaround, not a recommended long-term solution (opens in a new tab) |
What we changed on our own site
Our site is React with Vite, deployed on Vercel. Rather than rewrite it in another framework, we added a build-time prerender step:
- The app's routes are rendered on the server during the build, one HTML file per page.
- Each page declares its own title, description, canonical URL, social tags and structured data in one place, and the same declaration drives both the generated HTML and in-browser navigation.
- The XML sitemap is generated from the same list of routes, so it can't drift out of date.
- The catch-all rewrite that returned the app for any address was removed, so unknown URLs now get a real 404 response instead of a "page" with status 200.
- Canonical URLs now point at the domain the site is actually served from.
The visual design and animations are unchanged: the browser still loads the same React app, it just starts from complete HTML.
A note on AI-built websites
Many AI website builders generate exactly this kind of React and Vite single-page app. They are a fast way to get a good-looking first version, but check the page source before you rely on the site for search traffic. If you need help, our website development service covers this kind of rebuild, and our redesign checklist lists what to protect when you change a live site.
