--- title: "React SEO: Why Your AI-Built React Site Isn't Ranking" slug: "react-seo" url: "https://fimo.ai/blog/react-seo" category: "Marketing" date: 2026-09-22T00:00:00.000Z description: "React SEO can work, but browser-built React won't get you there. How to tell which React app your coding agent gave you, why react-helmet stops short, and the three fixes." cover: "https://fimo.ai/media/blog/uploads/2026/09/22/GnhI5JU6-react-seo--cover-1790098819621.png" --- # React SEO: Why Your AI-Built React Site Isn't Ranking _React SEO can work, but browser-built React won't get you there. How to tell which React app your coding agent gave you, why react-helmet stops short, and the three fixes._ ## Key Takeaways - React SEO only goes wrong when React runs in the visitor's browser, which is what most coding agents build unless you say otherwise. - You can tell which kind you have in a minute, from the page source and three files in the repository, without a developer. - react-helmet and the "add meta tags" fixes, which is most react js SEO advice, write the tags with JavaScript, so Google reads them late and the AI crawlers never read them at all. - There are three ways out, pre-render for crawlers, move to a React framework that renders on the server, or hand the code to a platform that serves it server-rendered, and only the last one is a fix you don't repeat. Every founder whose coding agent built their site this year has heard that React is bad for SEO. It isn't true, and it isn't quite false either, which is why most of the advice on it is useless. React itself is fine, it's a library for building the parts of a page (buttons, menus, forms), and Google indexes React sites all day. What's bad for SEO is a React app that assembles the whole page inside the visitor's browser, which is what Claude Code, Codex, Cursor, Bolt and the rest hand you unless you told them otherwise. There are three ways out, and only one means you never do this again. ## Is React bad for SEO? Only the browser-built kind. Ask a coding agent for "a website" with nothing about rendering and it usually reaches for React with Vite, because that's the quickest way to get something on screen. Vite is the build tool that packages a React app to run in the browser, and out of the box it makes a single-page app, one nearly empty HTML page plus a bundle of JavaScript that draws every screen after it loads. That pattern is where React and SEO fell out. Google runs your JavaScript after a queue and gets there eventually, while the crawlers behind ChatGPT, Perplexity and Claude don't run it at all, which is why a browser-built page shows up late in Google and never in AI answers. The evidence is in our [JavaScript SEO post for AI-built sites](https://fimo.ai/blog/javascript-seo-ai-built-websites), and Google's own guidance, updated in March 2026, still calls rendering on the server ["a great idea"](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) because "not all bots can run JavaScript". React's own team says the same thing more politely. Its [Creating a React App page](https://react.dev/learn/creating-a-react-app) opens with "we recommend starting with a framework", and the [from-scratch route](https://react.dev/learn/build-a-react-app-from-scratch) that starts with Vite warns that the build tool "only supports single page apps". Your agent took the from-scratch route and skipped the warning. ## Which kind of React app did your agent give you? Three tells anyone can spot Start with the 60-second test from our [JavaScript SEO post](https://fimo.ai/blog/javascript-seo-ai-built-websites). Open your homepage, right-click, choose View Page Source, and search for a sentence from your hero. If the sentence is there you're fine, and if the source is one empty
and a stack of script tags, the page only exists after JavaScript runs and everything below is about your site. The second check is the repository, the folder of code your agent wrote, usually on GitHub, and your agent can look for three things. One, a single index.html at the top level, which [Vite's docs](https://vite.dev/guide/) call "front-and-central" because in a browser-built app that one file is the whole site. Two, a vite.config.js or vite.config.ts next to it. Three, nothing that looks like a server, no server.js, no entry-server file, no app or routes folder full of pages. All three present and you have a browser-built React app, while a React SEO friendly setup looks like the opposite, a file per page that runs on the server and finished HTML in the source. ## Does react-helmet fix React SEO? It sets the tags, it doesn't serve them Most of the advice you'll have found is about react-helmet or its successor react-helmet-async, and it deserves fair credit. It's a small library that lets each screen in a React app set its own title, description and social tags, and on a site that already renders on the server it's a sensible way to manage them. In a browser-built app, though, react-helmet writes those tags with JavaScript after the page loads, so Google picks them up once it renders and a crawler that never runs JavaScript never sees them, or the page they describe. You've written a beautiful label for a box the crawler can't open, and because most react js SEO advice stops at the label, installing it changes nothing in ChatGPT. ## The three fixes that work, and what each one costs you Every react seo optimization fix does one job, getting finished HTML into the first response a crawler gets, and there are three ways to do it. | **Fix** | **In plain English** | **When it fits** | **What it costs you** | | --- | --- | --- | --- | | Pre-render for crawlers | A service spots a search or AI crawler and hands it a saved, finished copy of each page, while humans still get the app | You can't touch the codebase, or you need something this week | Two versions of every page, a snapshot that goes stale between publishes, and a shell for any crawler the service can't verify | | Move to a server-rendering React framework | The same React components, but a framework (Next.js, React Router in framework mode, Astro with React islands, among others) builds each page on the server and sends finished HTML | You own the code and your agent can still work on it | A rebuild, in practice a day or two for a dozen-page site with the same agent, plus a framework your team keeps current | | Hand the code to a platform that serves it server-rendered | Your agent rebuilds the site on a server-rendering setup once, and the platform serves every page as finished HTML from then on and keeps titles, links and structured data right | You'd rather nobody on your team thinks about rendering again | The rebuild once, then the platform's plan, from free | Accurate as of September 2026. If you own the code and it's a marketing site, you're choosing between moving to a framework and handing the code to a platform, and pre-rendering is for everyone else. Pre-rendering is what the hosted builders added for their older apps, and it's the right call when the code isn't yours to change, though Google's page on serving crawlers a pre-rendered copy, updated in December 2025, calls it ["a workaround and not a long-term solution"](https://developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering) and points you at server rendering instead. Moving to a framework is smaller than it sounds. Next.js (React with server rendering built in), React Router in framework mode (the router your app probably already uses, in its server mode) and Astro with React islands (a mostly-HTML site that only ships JavaScript for the interactive bits) all take your existing components, and Lovable moved every new project to server rendering in May 2026. Once you're on one of those, a shorter list of things can still break, and we've written that one up on its own. ## Haven't shipped yet? Give your coding agent this sentence If you're still building, the whole problem is one line in the prompt, and that line covers most of what gets called react seo best practices. "Build this with a React framework that renders every public page on the server. Every page must return its full content, title, meta description and canonical link in the initial HTML, with no JavaScript needed to read it. When you're done, fetch a built page without a browser and show me the source to prove it." The last sentence is the one people skip, and an agent that has to prove the source notices when it hasn't done the job. ## How Fimo handles React SEO for you We built Fimo to turn the code your coding agent wrote into a website that runs itself, and rendering is the first thing it takes off your plate. Here's how it works. You paste Fimo's setup prompt into the agent that built your site, whatever agent and whatever stack, and it connects the repository and creates the first preview. If what you have is a browser-built React app, your coding agent rebuilds it on a server-rendering framework (Next.js, React Router, Astro and more), same components, and Fimo takes it from there. From then on every page Fimo serves is [finished, server-rendered HTML](https://fimo.ai/features/seo-geo), so Google reads it on the first visit and so does ChatGPT. The sitemap and robots file stay in sync as pages ship and retire, and titles, descriptions and social cards are set on every page. Then an SEO agent keeps it that way. It [runs on a schedule you set](https://fimo.ai/features/autonomous-agents), daily, weekly or on publish, audits every page and proposes fixes to titles, metadata, internal links and structured data (the machine-readable labels on each page). Every run lands in a branch, a copy of the code where the changes wait with a preview and a diff, and you merge it or bin it, so nothing goes live on its own and anything merged can be rolled back. Your code stays yours, in your repository, and the free tier needs no card. ## Why teams leave a browser-built React site alone, and what a month costs Nobody rebuilds a site that looks finished. Google does get round to indexing it, so the Search Console graph looks slow rather than broken, and asking the agent you paid last month to redo it feels like conceding the first build was a mistake, when the build was fine and nobody told it how to render. The cost of leaving it runs per page. Every page you publish while you wait goes out as an empty shell to the AI crawlers and sits in Google's render queue before it counts, so a site adding a post a week hands the answer engines four unreadable pages a month. The rebuild costs the same day or two now or in six months, and the pages you lose in between are the only variable. ## Pick how your React pages render before you write another one React was never your SEO problem. The React app that builds itself in the browser was, handed to you by an agent nobody told to do otherwise. Tell your agent now, or [bring Fimo into the mix, for free](https://fimo.ai/auth/sign-up), and the pages render properly from here on. React SEO, sorted! ## FAQ ### Is React good for SEO? Yes, once the pages are rendered on the server or built to static HTML, which every framework on React's recommended list can do, and a plain React with Vite app isn't until you change how it renders. ### Is React still bad for SEO in 2026? Only the browser-built kind, and it's worse off than in 2022, because the buyers who used to search Google now ask ChatGPT and Perplexity first, and those crawlers never got the rendering upgrade Googlebot did. ### Does react-helmet fix SEO? Not on its own, because it sets the tags and something else has to serve them. On a server-rendered site it's a fine way to manage titles and descriptions, and on a browser-built site it's decoration until you fix the rendering. ### Do I need to rebuild my React site for SEO? Only the rendering layer, which is where most reactjs SEO problems live. Your components, styles and content move to Next.js, React Router in framework mode or Astro as they are, so it's a move rather than a rewrite. ### How do I do SEO with React? Settle rendering first, then the ordinary list applies, one title and description per page, canonical links, a sitemap, internal links between pages, and a check that all of it is in the page source with JavaScript switched off, because every item on that list is invisible to a crawler if the rendering is wrong.