WordPress-to-React pipeline
Website Migration & Component Builder
Migrating a WordPress site to Next.js by hand is weeks of work that produces a codebase nobody wants to maintain. Builder does the conversion automatically - and, more importantly, produces components a team can actually keep working in.
- Role
- Full Stack Developer, Hybrid MediaWorks
- Period
- May 2025 - Present
- Stack
- Next.js, TypeScript, Node.js, DOM analysis
519 → 49
pages reduced to design templates
The problem with reading an export
The obvious way to convert a WordPress site is to read its HTML export and translate the markup. That approach breaks immediately on real sites. Anything the page assembles at runtime - lazy-loaded images, carousels, popups, sticky headers - simply is not in the export, so the converted site quietly loses behaviour that visitors depend on.
So the pipeline does not read the export. It reads the sitemap and content API to catalogue every page, then opens each one in a real browser and captures what actually renders. The cost is speed: you are running a browser per page instead of parsing a file. The benefit is that what you capture is what users see.
Most pages are the same page
A 500-page WordPress site does not have 500 designs. It has a few dozen, repeated with different content. Generating one component per page produces hundreds of near-identical files - technically a migration, practically unmaintainable.
The pipeline groups pages by shared design template using the underlying WordPress markup, so structurally equivalent pages collapse onto a single component with dynamic content binding. On one site that turned 519 pages into 49 templates. Styling - colour, typography, spacing - is lifted out separately into an editable theme rather than being frozen into each component.
Editing by operation, not by file
Once a site is converted, changing it is the real problem. Letting a model rewrite component files is fast and unsafe: a small edit can silently alter pages nobody was looking at.
Instead, edits are expressed as typed operations against specific elements - restyle, show and hide, reorder, reword - and the scope is shown before anything is approved. An edit reports that it affects 306 pages, and you decide with that in front of you. Bulk changes across a large site become reviewable rather than a leap of faith.
Making it survive large sites
Component generation across hundreds of captured pages is memory-hungry, and the naive version does not finish on the sites that most need converting. Reworking the generation path to process incrementally, rather than holding whole-site state in memory, is what made large migrations complete at all.
Metadata, redirects, self-hosted fonts, and analytics tags carry across too - the unglamorous details that decide whether a migration is shippable or just a demo.
Want the longer version, or something similar built for your team?
Get in touch