Can a React site rank in Google?
Yes. Google crawls, renders and indexes JavaScript, and plenty of React sites rank well, but rendering is an extra step: Googlebot queues the page, runs it in a headless Chromium browser, then reads the rendered HTML. If your server sends an empty shell and a large script bundle, script errors, blocked resources or slow API calls can leave Google with less than your visitors see. Most React SEO work removes that dependency by putting the important content, links and metadata in the HTML the server sends, so every crawler gets the full page immediately.
Rendering strategies and which to choose
Client side rendering sends a minimal HTML shell and builds the page in the browser. It is the default for many single page apps, including those created with Vite, and it is the hardest setup for search because content depends entirely on JavaScript executing correctly.
Server side rendering generates the full HTML for each request on the server, then hydrates it in the browser so it becomes interactive. Static generation does the same work at build time and serves prebuilt HTML files, which is ideal for marketing pages, blogs and documentation that do not change on every request. Many frameworks also support regenerating static pages on a schedule or on demand, which suits large catalogs.
Google recommends server side rendering, static rendering or hydration as the long term approach. It describes dynamic rendering, where bots get a prerendered version and users get the client app, as a workaround rather than a recommended solution in its dynamic rendering documentation. In practice, React teams usually reach for a framework such as Next.js, React Router in framework mode or Astro with React components, and render marketing and content pages on the server or at build time while keeping logged in app screens client rendered.
Titles, descriptions and canonical tags
Every indexable page needs its own descriptive title and meta description, and they should be present in the HTML the server returns. Google's documentation notes that JavaScript can set or change titles and descriptions, but relying on that adds risk, especially for crawlers and link preview tools that never run your scripts. A share preview that shows your app name instead of the article title is a common symptom.
In a framework, this is straightforward. Next.js has a metadata API that renders tags on the server for each route, and recent versions of React can render title and meta elements from inside components and place them in the document head. For a pure client rendered app, a head management library can set tags, but those tags only exist after JavaScript runs.
Canonical tags need extra care. Google advises setting the canonical in the original HTML, and if JavaScript must change it, keeping the value consistent and making sure only one canonical tag exists. Robots meta tags are similar: if the initial HTML contains noindex, Google may skip rendering entirely, so removing it with JavaScript later will not reliably work. Get both right on the server.
Routing, links and status codes
Search engines discover pages by following links, and Google is explicit that it reliably follows links only when they are anchor elements with an href attribute. A clickable div or button that changes routes with JavaScript may work for users but gives crawlers nothing to follow. Use your router's link component, and make sure it renders a real anchor tag with a real URL.
Routing style matters too. Hash based URLs, where every page lives after a pound sign, cannot be reliably resolved by Googlebot as separate pages. Use the History API with clean paths such as /services/roof-repair, which every modern React router supports. Each route should load directly if someone pastes it into a new browser tab, not only when reached by clicking through the app.
Single page apps also struggle with status codes. If every URL returns 200 and the app shows a not found message in the browser, Google may treat those pages as soft 404s. Server rendering lets you return a real 404 for missing content. In a client only app, Google suggests redirecting to a URL that returns a 404 from the server, or adding a noindex robots tag to error views with JavaScript.
Beyond Google: AI assistants and other crawlers
Google renders JavaScript, but its documentation also points out that not all bots can. That matters more than it used to. Social networks generate link previews from your HTML, other search engines vary in how much JavaScript they process, and the crawlers that feed AI assistants and answer engines should not be assumed to render your app the way Google does.
If a page's content only exists after client side rendering, you are betting that every system you care about will execute your JavaScript successfully. Server rendered or static HTML removes that bet. The text, headings, links and structured data are all present in the first response, so any crawler that reads HTML can understand the page.
This is one of the quieter reasons to move content pages off pure client rendering. Being cited in AI answers depends on clear, well organized, factual content that machines can read, plus structured data that describes what the page is about. JSON-LD generated by JavaScript can work for Google if it is tested, but putting it in the server rendered HTML is the more dependable choice for every reader of the page.
AI built React apps and SEO
A growing number of business sites are generated by AI app builders, and many of these tools produce client rendered React apps by default. They look finished in the browser, which is exactly why the search problems go unnoticed until someone checks Search Console and finds pages discovered but not indexed, or indexed with the wrong title.
The typical issues are predictable: one shared title and description across every route, no server rendered content, navigation built from buttons instead of links, missing sitemaps, no canonical tags and every URL returning 200 even when the page does not exist. Performance can also suffer, because large JavaScript bundles delay the moment content appears, which affects both Core Web Vitals and user patience.
None of this means the app has to be thrown away. Often the components and design can be moved into a framework that renders on the server or at build time, with routes, metadata and links corrected along the way. Neon Manatee's vibe coded app cleanup service handles this kind of transition, keeping what works in the generated code and fixing what holds the site back in search.
Testing your React site in Search Console
Do not guess whether Google sees your content. The URL Inspection tool in Google Search Console shows how Google indexed a page, and its live test shows how Googlebot renders it right now. View the rendered HTML and the screenshot, and confirm that the main content, headings, internal links, title, description and canonical are all there. If something is missing, check the page resources and console messages the test reports, since blocked scripts and API errors are common culprits.
The Page indexing report shows which URLs are indexed and why others are not, such as crawled but not indexed, duplicates without a canonical, soft 404s or pages blocked by robots.txt. For structured data, run the Rich Results Test on live URLs. Submit an XML sitemap so Google learns every route, especially in apps where some pages are not well linked.
A simple local habit catches many problems early: load a page with JavaScript disabled, or view the raw page source rather than the inspected DOM. If the content is not in the source, crawlers that do not render will not see it, and Google has to do extra work to find it.
A practical React SEO migration plan
If your React site is client rendered today and search matters to the business, plan the move in stages rather than as a single rewrite. Start with the pages that earn or should earn organic traffic: the homepage, service or product pages, location pages and the blog. Render those on the server or at build time first, and leave authenticated dashboards and app screens client rendered, where search engines have no business going anyway.
Keep URLs identical where possible. If any must change, map every old path to its new one with permanent redirects. Carry over titles, descriptions and structured data, add a sitemap, and fix navigation so every important page is reachable through real links. Then test key templates with the URL Inspection live test before and after launch.
After the move, watch the Page indexing report and performance data in Search Console for several weeks. Indexed page counts, impressions and Core Web Vitals should improve as Google processes the new HTML. If search is a growth channel rather than a one time fix, an ongoing SEO plan keeps the content, links and technical health moving forward together.
Frequently asked questions
Is React bad for SEO?
No. React itself is not the problem. The issue is client side rendering, where content only appears after JavaScript runs in the browser. Google can render that, but it adds steps and risk, and other crawlers may not. Server side rendering or static generation with a framework such as Next.js gives search engines complete HTML immediately.
Does Google render JavaScript?
Yes. Google crawls the URL, queues it for rendering in a headless Chromium browser, then indexes the rendered HTML. Rendering can be skipped for pages that return error codes or carry noindex, and anything that fails to load during rendering may be missed. Use the URL Inspection live test to see what Google renders.
Should I use Next.js for SEO?
Next.js is a common choice because it supports server side rendering, static generation and a metadata API that puts titles and descriptions in the initial HTML. It is not the only option. React Router in framework mode and Astro with React components can also render content pages on the server or at build time.
Is dynamic rendering still recommended?
No. Google describes dynamic rendering as a workaround rather than a recommended solution, because maintaining separate versions for bots and users adds complexity. Google recommends server side rendering, static rendering or hydration instead. Existing setups may still work, but new projects should render on the server or at build time.
How do I check if Google can see my React content?
Use the URL Inspection tool in Google Search Console and run a live test. Review the rendered HTML and screenshot to confirm your content, links, title and canonical appear. Also view the raw page source with JavaScript disabled, since content missing there depends entirely on rendering.
