Rendering changes what arrives first
A traditional server page sends meaningful HTML in the initial response. A client rendered React application may send a small shell and rely on JavaScript to request data and construct the page. Google can render JavaScript, but rendering happens as an additional processing step and the application can fail before important content appears.
Other crawlers and user initiated retrieval systems may execute less JavaScript, use different time limits, or rely on a search index rather than rendering the application directly. Crawlable HTML reduces this dependency. It also improves resilience for people on slow devices, unstable connections, restrictive networks, and assistive technology combinations.
| Approach | Initial response | Typical use |
|---|---|---|
| Client rendering | Application shell, then JavaScript builds content | Highly interactive tools where indexing is secondary |
| Static generation | Prebuilt HTML for each route | Service pages, articles, documentation, portfolios, and marketing pages |
| Server rendering | HTML generated for each request or cached response | Dynamic indexable pages with current data |
| Hybrid rendering | Different methods by route | Sites that combine marketing content and authenticated application surfaces |
Choose rendering by page job
Not every route needs the same rendering method. A public service page has stable content and benefits from static HTML. An article library can be generated from structured source files at build time. A dashboard behind authentication may rely on client rendering because search indexing is not its job. An inventory page may require server rendering or incremental generation because availability changes.
Start with the user and indexing requirement. If a page should rank, be cited, or serve as a durable landing page, make its main content available without a long chain of client requests. Hydration can add interaction after the document arrives. A visual particle sequence or 3D scene can remain client side while the surrounding message, navigation, and links remain semantic.
Generate route specific metadata in the document
Every indexable route needs a distinct title and useful meta description. Add a self referencing canonical when the URL is the preferred version. Set robots directives intentionally. Provide Open Graph fields for sharing and a stable image when one is available. The title and main heading should describe the same page without being forced to match word for word.
Client side metadata libraries can update the document after load, but static generation makes the values available in the first response. This is more reliable for crawlers, social preview systems, link unfurlers, and debugging tools. It also prevents every route from sharing the generic title in the original application shell.
Return real status codes and stable routes
A single page application fallback often returns the homepage shell with a 200 status for every path, including routes that do not exist. This creates soft 404 behavior and makes removal or redirection difficult to express. Static hosts can serve a real file for each public route and return 404 for missing content. Server frameworks can set the status during rendering.
When a URL moves, use a server redirect to the closest relevant destination. Do not rely only on a client effect that waits for the application to load and then changes location. Keep redirect chains short. When content is permanently removed without a replacement, return 404 or 410 and provide a useful human facing missing page.
Use crawlable links and semantic page structure
Standard anchor elements with resolvable href values provide a durable discovery path. A click handler on a generic element may work for a person with a mouse and still fail for crawlers, keyboard users, or assistive technology. Use buttons for actions and anchors for navigation. Descriptive link text helps readers and systems understand the destination.
Build the document with one main landmark, descriptive headings, paragraphs, lists, tables, figures, and article elements where those structures fit. Canvas and WebGL can create excellent visual experiences, but they should not be the only place that a client name, service description, or page relationship exists. Provide accessible text and static fallbacks for meaningful visual information.
Hydrate only what needs to move
Shipping a large JavaScript bundle for static prose increases parsing, execution, and hydration work without improving the reading experience. Split code by route, lazy load noncritical interaction, and keep server or static content usable before hydration. Reserve heavy 3D, video, and data visualization for moments where they advance the page's argument.
Set width and height for images, preload only critical resources, and avoid layout shifts when components hydrate. Watch Interaction to Next Paint, Largest Contentful Paint, and Cumulative Layout Shift in eligible field data. A fast blank shell is not a good result if the meaningful content arrives much later.
Test what the server sends and what the browser renders
- Request the production URL and inspect the response status, headers, and initial HTML.
- Confirm that title, canonical, main heading, body content, and important links exist in the expected output.
- Load the page with JavaScript disabled or delayed and confirm that the core message and navigation remain available.
- Use URL Inspection in Search Console for Google's indexed and live view.
- Crawl the production host to find duplicate titles, broken links, missing canonicals, soft 404s, and redirect chains.
- Check the browser console, network failures, mobile overflow, keyboard path, and reduced motion behavior.
- Validate structured data against the rendered page and visible content.
A durable React publishing plan
For a React marketing site, keep interactive brand moments inside the application while generating service, about, contact, work, and article routes as static HTML. Use one content source to create page copy, metadata, structured data, internal links, sitemap entries, and feed items. This reduces drift between what the page says and what discovery files claim.
Run generation before local development and production builds. Validate that every intended URL creates an output file. Keep the production origin in one configuration value. Then deploy the static routes with the application assets and verify the live domain, not only the local preview.
Frequently asked questions
Is React bad for SEO?
No. React can publish highly discoverable pages when the architecture delivers meaningful HTML, stable routes, correct status codes, route-specific metadata, and ordinary links. Risk rises when a public page is only an empty shell until several scripts and data requests succeed. Choose static generation, server rendering, or a hybrid based on the job of each route.
Why does crawlable HTML matter if search engines render JavaScript?
Browser rendering costs more computation and introduces more failure points than retrieving ready HTML. Academic crawling research shows why modern JavaScript pages require expensive browser work, while mobile studies show that devices and networks vary substantially. Sending the core page in HTML improves resilience for crawlers, users on constrained connections, previews, and assistive technology.
How do you test JavaScript SEO on a production site?
Inspect the initial response and the rendered document. Verify the status, title, canonical, main heading, body copy, and internal links in both views. Test missing routes, redirects, JavaScript failure, mobile overflow, keyboard use, and structured data. Crawl the public host after deployment because a local build cannot prove CDN rules, redirects, or live headers.
Does crawlable HTML mean a React site cannot be interactive?
No. The page can send useful HTML first and hydrate selected components afterward. Navigation, copy, headings, links, and conversion context remain available while galleries, forms, motion, or data views gain richer behavior in the browser. This progressive approach keeps the public argument resilient without giving up React for interaction. The design decision is which elements truly require client execution, not whether the whole page must choose one rendering method.
Academic sources
These peer reviewed papers, conference proceedings, and scholarly preprints support the research and implementation guidance in this article. Each link points to the publication or an academic repository.
- Sprinter: Speeding Up High-Fidelity Crawling of the Modern Web (USENIX NSDI)Research on the computing cost and fidelity challenges of browser-based crawling.
- Evaluating the Efficacy of Next.js: A Comparative Analysis with React.js (New York University Abu Dhabi / arXiv preprint)Preprint comparison of React and Next.js under performance, SEO, usability, and network conditions.
- Web Experience in Mobile Networks: Lessons from Two Million Page Visits (The Web Conference / ACM)Large-scale evidence on the effect of access networks, devices, browsers, and page composition.
- Do you agree? Contrasting Google’s Core Web Vitals with actual web QoE (Quality and User Experience / Springer Nature)Research comparing objective loading metrics with perceived web quality.