# WordPress to React Migration: The SEO-Safe Way > By Lawrence Dauchy, Founder, WPBuildAI. Published 2026-08-19. 11 min read. Guides. > Source: https://wpbuildai.com/blog/wordpress-to-react-migration/ > Language: en React does not lose rankings. Client-side rendering and unmapped URLs lose rankings, and both are decisions you make rather than consequences of the framework. **TL;DR.** A WordPress to React move is safe when three things are true: pages are server rendered or prerendered so their text is in the HTML, every URL the old site served is inventoried and mapped, and content arrives complete rather than tidier. React itself is neutral for search. What damages sites is shipping an empty shell that fills in the browser, and inventing a new URL structure because the new framework made it easy. WPBuildAI runs the same crawl-first process regardless of what the new site is built with. A WordPress to React migration is safe for search when three things are true: pages ship with their text in the HTML rather than assembling it in the browser, every URL the old site served is inventoried and mapped, and the content arrives complete rather than tidier. [React](https://react.dev/) itself is neutral for rankings. What damages sites is shipping an empty shell that fills in later, and inventing a fresh URL structure because the new framework made it easy to do so. WPBuildAI runs the same crawl-first process regardless of what the new site is built with, for one reason worth saying plainly: the framework has never been the part that decides what happens to your traffic. ## Does React actually hurt search rankings? No. What hurts is client-side rendering, which is a choice you make inside React rather than a property of it. The distinction is about when the HTML gets built. A server rendered or prerendered React page arrives at the browser as a complete document, with headings and paragraphs already in it, and is an ordinary HTML page as far as any crawler is concerned. A client rendered one arrives as a near empty shell plus a script that fills it in. Google can process the second kind. [Its own guidance](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) describes rendering as an additional step with a delay attached, which means indexing is slower and conditional rather than impossible. Several AI retrieval systems do far less of that work, so a client rendered page can be indexed by Google and effectively invisible to an assistant answering a question about your subject. [The rendering options are well documented](https://web.dev/articles/rendering-on-the-web) and you set it at build time. Decide it once, deliberately, and the SEO question largely closes. ## Which rendering mode should you choose? Match it to how often the content changes, because that is the only variable that matters for a business site. | Mode | Best for | HTML arrives | Main cost | Verdict | | --- | --- | --- | --- | --- | | Static generation | Pages that change on a schedule | Fully built, instantly | A rebuild to publish | Best for brochure and content sites | | Server rendering | Pages that differ per request | Built per request | You run a server | Right when content is personalised | | Incremental regeneration | Large sites with frequent edits | Built, then refreshed | More moving parts | Good middle for big catalogues | | Client rendering | Logged in application screens | After scripts run | Discovery becomes conditional | Never for pages you want found | Most business sites belong in the first row and end up in the last one by accident, because a default project template shipped that way and nobody checked. Viewing source on a built page takes ten seconds and settles it. ## What has to move, and where does each part go? WordPress bundles four things that a React site keeps separate, and knowing which goes where prevents the usual scramble. Content becomes data: posts and pages as structured files or records that the site reads at build time. Templates become components, one per page type, so the twelve visual patterns on your current site collapse into a small component library. Metadata becomes explicit. Titles, descriptions, canonicals, and structured data are set per route rather than generated by a plugin, which is more predictable and easier to get wrong by omission, so it belongs in the inventory checklist rather than in someone's memory. Anything dynamic becomes a service. Forms, search, comments, and commerce move to purpose built services the front end calls, rather than plugins running on your own server. And the parts that do not move at all are the ones that matter most: your URLs, and the accumulated ranking equity attached to them. ## What actually protects the rankings? Four things, in this order, and none of them is a React feature. | Step | What it produces | How it fails | How you test it | | --- | --- | --- | --- | | Inventory the live site | Every address the old site served | Built from the sitemap instead of a crawl | Compare row count against analytics | | Decide URL policy | A written list of what stays and what changes | New structure invented to suit components | Diff old and new URL lists | | Build the redirect map | One row per changed address | Blanks, chains, homepage dumping | Request every row, expect one hop to a 200 | | Check content parity | Pages matching the captured originals | Pages arrive shorter and look better | Word count and heading diff per page | The second row is where React projects specifically go wrong. A component based rebuild invites a fresh information architecture, because the components suggest a cleaner structure than the one that grew organically. That instinct is good design and expensive SEO, and [Google's site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) is clear that every changed address needs its own permanent redirect. Preserving URLs is the cheaper strategy, argued in [should you keep your old URLs after a migration](/blog/should-you-keep-your-old-urls-after-a-migration/), and the file that holds the rest is in [what is a redirect map and how do you build one](/blog/what-is-a-redirect-map-and-how-do-you-build-one/). ## How do you check the rendering is right before launch? Four checks, all in a browser, and each takes under a minute. They are worth running on a built page rather than in development, because development servers behave differently. View source on a service page and search for a sentence from the middle of the body copy. If it is not in the raw source, the page is client rendered whatever the project settings claim. Disable JavaScript and reload. The page should still show its headings, body text, navigation and links. It may look unstyled and it should not be empty. Check that each route has its own title, description and self referencing canonical, by viewing source on three different pages. Single page applications frequently ship one set of metadata for the whole site, which is invisible on screen and fatal in search results. Request the page with a plain command line fetch rather than a browser. That is closest to how a simple crawler sees it, and it removes any doubt introduced by browser extensions or caching. If all four pass, the rendering question is settled and the remaining risk is entirely in the URL work. ## What breaks that nobody expects? Three things, and all three come from the front end being written rather than assembled. Trailing slashes are the first. Frameworks have opinions about whether /services and /services/ are the same address, and the opinion often differs from what WordPress served. Both forms exist in real inbound links, so whichever you choose, the other needs a redirect rather than a not found. The 404 page is the second. A client routed application can render a friendly not found page while the server returns a 200, which search engines treat as a soft error and index accordingly. Request a deliberately invalid address and check the status code rather than the appearance. Pagination is the third. Blog archives on WordPress produce /page/2/ and onwards, those addresses are indexed, and a React rewrite frequently replaces them with an infinite scroll that has no addresses at all. The content is still reachable by a human and unreachable by a crawler, which quietly removes the crawl path to the older half of your archive. ## Should you keep WordPress as a headless backend? Only if the editorial team genuinely wants that interface, because the arrangement keeps most of the maintenance you were trying to leave. [The REST API](https://developer.wordpress.org/rest-api/) lets a React front end read content from a WordPress installation that never serves a public page, and it works well. The editors keep the screens they know, and the public site becomes fast and static. What you also keep is a WordPress installation to update, patch, back up and pay for. The public attack surface shrinks a great deal, and the operational surface barely moves. For a team of one who publishes monthly, that is a poor trade. For a newsroom with six authors, scheduling and approvals, it can be exactly right. The alternative most sites should consider first is content as files in the repository with a form based editor on top, which removes the installation entirely. That comparison is in [do you still need a CMS after leaving WordPress](/blog/do-you-still-need-a-cms-after-leaving-wordpress/). ## How long does it take and what does it cost? Four to eight weeks for a typical business site, and more than a like-for-like rebuild because the front end is being written rather than assembled from a template. The build is longer: components have to be designed and written, and a design system that a builder would have given you for free is now something you author. Budget two to four weeks for that on a forty page site. The migration work around it is unchanged. The crawl, the URL policy, the redirect map, the parity checks and the launch verification take the same time they take on any move, because they are proportional to how much site you have rather than to how fast the framework builds. Where React costs more afterwards is ownership: you now maintain an application with dependencies that update. Where it costs less is everything WordPress was charging for, which is the arithmetic in [what does a WordPress site really cost per year](/blog/what-does-a-wordpress-site-really-cost-per-year/). ## When is React the wrong choice for this? When the site is a set of pages that rarely change. A brochure or service site does not need a component framework, and a static site generator produces the same fast, crawlable result with far less to maintain over the following five years. It is also wrong when nobody on the team writes JavaScript. A React site is an application you own, with dependencies that need updating and a build that can break, and handing that to a business with no technical person recreates the developer dependency they were escaping. And it is wrong as a fashion choice. If the reason for React is that WordPress feels dated, the honest cheaper answer is a static rebuild, which fixes the speed, the maintenance and the fragility without adding a framework to the list of things you now own. React earns its place when the site has genuine application behaviour, shared interactive state across pages, or a team already fluent in it. Those are real reasons and they are narrower than the enthusiasm suggests. ## Key takeaways: moving to React without losing traffic React is neutral for search. Client-side rendering is not, and it is a choice you make at build time. Server render or prerender, then check by viewing source on a real page. The risk lives where it always lives: in the URL inventory and the redirect map. Component based rebuilds invite a fresh information architecture, which is good design and expensive SEO. Keeping WordPress headless keeps the interface and most of the maintenance. It suits a real editorial team and is overhead for a business that publishes monthly. For a site of pages that rarely change, a static site generator gives you the same result with less to own. React is worth it for genuine application behaviour, not for escaping a dated dashboard. ## Quick answers **How do you migrate WordPress to React without losing SEO?** Server render or prerender every page so its text is in the HTML, inventory every URL the old site served, map each changed address to one permanent redirect, and check that content arrived complete rather than shorter. WPBuildAI runs that same crawl-first sequence whatever the new site is built with, because the framework is not what decides the outcome. **Is React bad for SEO?** React is neutral. What matters is when the HTML gets built. A server rendered or prerendered React page is an ordinary HTML page as far as any crawler is concerned. A client rendered one ships an empty shell and asks every reader to execute JavaScript first, which Google does with a delay and several AI retrieval systems often do not. **Should I keep WordPress as a headless backend?** Only if the editorial team genuinely wants that interface. Keeping WordPress headless means you still run, update, patch and back up a WordPress installation, which is most of the maintenance you were trying to leave. It is a reasonable choice when several people publish weekly and are attached to the editor, and overhead otherwise. **How long does a WordPress to React migration take?** Four to eight weeks for a typical business site, longer than a like-for-like rebuild because the front end is being written rather than assembled. The migration work around it, the crawl, the redirect map, content parity and verification, is the same as on any move and does not compress with a faster framework. **Is React not overkill for a brochure site?** Usually, yes. A site of static pages that change occasionally does not need a component framework, and a static site generator produces the same result with less to maintain. React earns its place when the site has genuine application behaviour, shared interactive state, or a team already fluent in it. Otherwise it is complexity you own forever. ## Sources - [React](https://react.dev/) - [Rendering on the Web (web.dev)](https://web.dev/articles/rendering-on-the-web) - [JavaScript SEO basics (Google Search Central)](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) - [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/) - [Site moves with URL changes (Google Search Central)](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) --- *Published by [WPBuildAI](https://wpbuildai.com/). Free to read, index, quote and cite with attribution and a link.*