Convert a site to React by inventorying its routes and interactive states, extracting the shared visual patterns into components, moving only genuinely changing values into state, and migrating one coherent slice at a time. Keep semantic HTML, URLs and content intact while you work. Test the rebuilt slice against the original at mobile and desktop sizes before moving to the next one.
Reviewed for material changes on August 13, 2026
Map the website before touching the markup
List the page families rather than treating every URL as unique. A marketing site might have one product template, one article template, a pricing page and a handful of campaign pages. Note which headers, footers, cards, forms and content blocks recur across them.
Then record behaviour: menus, accordions, tabs, filters, form validation, carousels and anything that changes after a user action. Static structure becomes components; changing behaviour is where state and event handling enter the picture.
Choose component boundaries by responsibility
A useful component has a recognisable job and a small, clear interface. Start with the repeated pieces that already exist in the design: SiteHeader, ProductCard, Testimonial and SignupForm are better boundaries than Wrapper2 or BlueSection.
React's own guidance starts by breaking a mock-up into a component hierarchy and identifying the minimal representation of UI state. Follow that discipline. Do not turn every div into a component, and do not store a value in state if it can be calculated from props or existing state.
- Use props for content and controlled variations.
- Keep transient interaction state close to the component that owns it.
- Lift state only when two parts of the interface truly need the same source of truth.
- Name components after their role in the product, not their colour or position.
Move styles and assets deliberately
A bulk copy of the old stylesheet may make the first screen look right and leave months of specificity problems behind. Identify global foundations, layout utilities and component styles. Keep a short compatibility layer for legacy pages, then remove it as each slice moves.
Import local assets through the build system where that improves caching and validation, but preserve public paths when external links depend on them. Confirm the licence for every font and image. Converting a site you do not own does not create permission to reuse its creative work.
Rebuild interactions from outcomes, not old scripts
Write down what an interaction must do before translating the old JavaScript. A menu opens, traps no one, closes with Escape and returns focus sensibly; a form explains errors and does not discard good input. That specification is more valuable than carrying over a pile of DOM selectors.
Use native browser behaviour where it is sufficient. A button should be a button and a link should go somewhere. React changes how you compose the interface; it does not cancel the semantics that browsers and assistive technology already understand.
Move one vertical slice and prove it
Pick a real route with shared navigation, representative content and one meaningful interaction. Put it through build, deployment, analytics and accessibility checks. The first slice should expose weaknesses in the architecture without putting the whole site at risk.
Compare the original and React version at the same viewport sizes, then test keyboard use, form results and real-device loading. Measure field performance after launch when traffic allows it; Google distinguishes real-user data from lab diagnostics because they answer different questions.
Sources and checks
Product limits and prices came from the companies themselves:
- React: Thinking in React
- React: Sharing state between components
- Google web.dev: Web Vitals
- W3C Web Accessibility Initiative: WCAG overview
Plans move. We date every check so you know when to verify again.