React SEO is the work of making a React website’s public pages discoverable, readable and eligible for search indexing. The framework name is not the deciding factor. What matters is what each URL returns, which content appears after rendering, and whether navigation, metadata and indexing instructions describe the right page.
A useful starting question is: can someone open an important page directly and receive its actual content without first visiting the homepage, signing in or clicking a button? That test often reveals more than installing another SEO package.
This guide concentrates on React routes, rendering and release checks. For the wider website review, use our technical SEO guide.
Can Google index a React website?
Yes. Google can execute JavaScript and use the resulting content for indexing. However, a page that looks correct in your own browser can still depend on blocked resources, failed requests or saved session data. Successful rendering also does not guarantee that Google will index or rank the page.
In Google’s JavaScript SEO documentation, crawling, rendering and indexing are separate stages. Providing useful HTML from the server reduces dependence on browser execution, while also helping crawlers that do not run JavaScript.
Start by separating public search pages from private application screens. A pricing page, product category or help article may need organic visibility. An authenticated customer dashboard usually has a different job. You can keep an interactive application while giving its public pages a more dependable delivery method.
Choose rendering by page type
React is a UI library, not a requirement to send every visitor an empty HTML shell. Your framework, data loading and deployment determine how a particular route is delivered.
| Approach | What it does | Where to consider it |
|---|---|---|
| Client-side rendering (CSR) | The browser runs JavaScript to build the main interface. | Interactive application screens. Public search pages need careful rendering and access checks. |
| Server-side rendering (SSR) | The server generates HTML while handling a request. | Public pages whose content needs request-time data. Check server response time and caching. |
| Static generation or prerendering | HTML is produced ahead of the visitor’s request. | Articles, service information and other content with a workable update process. |
| A mixture across routes | Different pages use different delivery methods. | A public marketing website alongside a more interactive account area. |
These are implementation choices, not ranking bonuses. A statically generated page that has not been rebuilt can serve outdated information. A server-rendered page can still be slow or contain the wrong canonical.
Next.js is one option; it is not a requirement for React SEO. React Router’s Framework Mode also documents server rendering and static prerendering. Check the mode and deployment your project actually uses before following a framework tutorial.
For an existing site, first identify the failing route or template. Rebuilding an entire application to fix one missing title or one broken server rewrite may be unnecessary.
Give every public page a working URL and crawlable links
Test an inner page by pasting its full address into a new browser session. Then refresh it. A route that works only after clicking through the application may expose a hosting or routing problem when requested directly.
Use normal paths such as /services/kitchen-renovations/ for distinct pages rather than relying on /#/services/kitchen-renovations. Configure the server and router together: valid routes should work directly, while invented routes should not all become successful copies of the homepage.
For navigation, inspect the rendered output of your components. A link to another page should produce an <a> element with a real href. A clickable card implemented only as a div with a JavaScript handler is not an equivalent discovery mechanism. Google’s crawlable link guidance explains the expected markup.
Keep buttons for actions such as opening a filter or submitting a form. For a card that opens a service page, a meaningful linked heading can provide both a clear destination and a useful anchor.
Add preferred, indexable public routes to the sitemap, but keep internal navigation working too. Our XML sitemap guide covers submission and file maintenance separately.
Make content available without a previous session or interaction
A product description may appear perfectly after you select a store, accept a prompt or navigate from a category. That does not prove the same description is available when the product URL is opened on its own.
For important public templates, test these conditions:
- A clean visit: open the URL without a login or previously saved preferences.
- No interaction: check whether the main description and important links load without clicking, scrolling or accepting a permission request.
- A failed content request: inspect what the page shows if its API times out. A permanent “Loading…” message is not useful page content.
- A fresh deployment: check that HTML and JavaScript assets belong to compatible releases and that the referenced files still load.
Google’s rendering service does not preserve cookies or local storage between page loads. Its JavaScript troubleshooting guidance also covers failed resources and asset caching. The practical implication is to make each public URL work as an independent entry point.
An accordion is not automatically an SEO problem. Content already present in the rendered page differs from content fetched only after someone opens a tab. Google does not interact with pages like a visitor; use its lazy-loading guidance when deciding which content can be deferred.
Keep optional features optional. A product comparison widget can load later without making the product name, description and primary navigation wait for it.
Keep titles and indexing signals correct for each route
Open two different public pages and compare their titles, descriptions and canonical URLs. Then move between them through the application and use the browser’s Back button. Shared layouts should not leave the previous page’s metadata behind.
Use the metadata system your application supports
React 19 introduced built-in support for document metadata. Current React can place title elements and metadata elements in the document head when rendered from components. A separate head-management package is therefore not a universal requirement. Older projects need an approach compatible with their installed React version.
For the Next.js App Router, follow the framework’s Metadata API: static metadata or generateMetadata, depending on the route. Avoid having a layout, plugin and custom client effect independently manage the same tags.
Current Next.js can stream metadata for dynamically rendered pages and handles some crawlers differently. Do not diagnose missing metadata from the first response chunk alone. Inspect the completed response and rendered output, and test the preview service if social sharing is the actual problem.
Check canonical and robots instructions before and after rendering
A product route should not inherit the homepage canonical simply because both use the same layout. Keep the preferred URL consistent across canonical tags, internal links and sitemap entries. Google’s canonicalisation guidance explains the relationship between these signals.
Do not send noindex in the initial HTML of a page intended for search and expect JavaScript to remove it reliably: Google may skip rendering after seeing that instruction. Also avoid changing an existing canonical to a different address during hydration. Correct the source of the instruction, then verify the public response.
Test missing pages and redirects on the deployed application
A branded “page not found” screen can still return HTTP 200. That mismatch is common when a hosting rule sends every path to the same application shell. Test the response status, not just the text visitors see.
| Test URL | Expected outcome |
|---|---|
| A valid public article or service route | A successful response with the intended page content. |
| An invented URL or permanently deleted page without a replacement | A genuine not-found response, normally 404 or 410. |
| A URL with a permanent, relevant replacement | A permanent redirect, normally 301 or 308, to that replacement. |
| A route affected by a temporary server failure | An appropriate error response, rather than a successful blank page. |
Google’s HTTP status documentation describes how these responses are processed. Do not send every missing URL to the homepage.
Next.js needs an additional check: its not-found documentation states that streamed responses can return 200, whereas non-streamed responses return 404. The notFound() function also adds a noindex directive. Inspect the actual status and robots output in your deployment; calling the function is not proof that the browser received a 404.
Where a legacy CSR application cannot immediately return appropriate statuses, Google documents error-page workarounds such as adding noindex to the error view. Keep that handling limited to genuine errors, and retest navigation from an error view to a valid page so the exclusion does not persist.
Check hydration and performance without removing useful design
Hydration attaches React behaviour to HTML already generated on the server. React expects the server and initial client output to match. Investigate mismatches involving dates, random values, browser-only conditions or different data snapshots rather than hiding the warning. See React’s hydration reference.
A hydration warning is not automatic proof of an indexing failure. Check what actually breaks: does the main content disappear, does the wrong product render, or does a navigation control stop working?
For performance, investigate the work a visitor’s device must do. Large bundles, expensive interactions and unnecessary third-party scripts can make an otherwise attractive site feel slow. Split optional functionality where appropriate and measure the affected route after the change.
Keep images that explain the product or improve the page’s presentation. Serve suitable sizes, reserve their dimensions and avoid delaying the main visible image unnecessarily. Removing every illustration is not a substitute for finding the real bottleneck.
Google’s Core Web Vitals guidance identifies LCP, INP and CLS as the relevant measures. Use field data when available alongside lab diagnostics. A high Lighthouse score does not establish that the page is indexed or that real visitors have good interaction performance.
A React SEO release checklist you can hand to a developer
Choose a small test set: the homepage, a service or category page, a detail page, one retired URL and one invented URL. Repeat the checks after changes to routing, templates, data fetching or deployment rules.
| Check | Evidence to record |
|---|---|
| Direct entry and refresh | The intended page works without a preceding navigation step. |
| Initial and rendered content | The main heading, description and key links remain available; record any content that depends on JavaScript. |
| Metadata and directives | Correct title, canonical and robots instructions on direct entry, route changes and Back navigation. |
| Failure handling | Actual status and content for missing URLs, retired URLs and failed data requests. |
| Google’s current view | URL Inspection results, rendered HTML and any relevant resource or JavaScript errors. |
| Visitor experience | Working navigation and forms, stable images and usable interactions on mobile. |
In Search Console, compare the stored indexing result with the live test. They answer different questions. A live test checks current access and processing; it does not prove the URL is already indexed. Google explains the available evidence in its URL Inspection documentation.
Write fixes as testable tasks. For example: “The case-study route shows its description only after visiting the portfolio. Make the description available on direct entry, then verify it in the rendered HTML.” That gives a developer a reproducible problem and a clear completion check.
What changes when AI search is part of the goal?
The same delivery questions remain useful: can the relevant system retrieve the public page, and does it receive the information the page promises? Do not assume every AI service renders JavaScript like Google.
For Google’s AI Overviews and AI Mode specifically, a supporting page must be indexed and eligible for a search snippet. Google does not require a special AI file or additional special markup. Its AI features documentation is the relevant reference; meeting those conditions does not guarantee a citation.
Do not adopt separate bot-only rendering as the default shortcut. Google describes dynamic rendering as a workaround rather than its recommended long-term solution. Prefer a maintainable delivery strategy that serves the same substantive public content to visitors and crawlers.
Fix the delivery problem, then assess search performance
When a React route is accessible, renders correctly and sends consistent instructions, investigate the remaining search question on its own merits. The content may need a clearer purpose, stronger evidence or better internal support. Another rendering change will not solve every ranking problem.
Use our guide to why a website is not ranking on Google for that next diagnosis. For help connecting technical findings with content and business priorities, see Maple Web Design’s SEO services in Vancouver.
