A migration is an inventory, a map and a measured switch, and the addresses are the part most people get wrong.
Leaving WordPress is not a redesign and it is not a risk to your search standing, if it is done as an engineering job rather than a creative one. The job has three parts: an inventory of what you have, a map from every old address to its new home, and a switch that is measured before and after. This piece sets out each, what is kept, what is not, and how long it takes.
Before anything is built, everything on the current site is listed: every page, every address, every product, every form and where it delivers, every file and image, and every plugin and what it is for. The list is yours and you see it first. On the IFS Coatings site it ran to 45 active plugins, several hundred pages and more than 400 colours with their data sheets.
The inventory answers the question most owners cannot: what does the site actually contain, and what of it earns its place. Pages nobody visits are not deleted on our say-so; they are listed with their visit count and you decide. Nothing is retired without your agreement, and anything retired is redirected somewhere sensible rather than left to return an error.
Every old address goes in one column. Its fate goes in the next: kept at the same address, redirected to a new one, or retired with a redirect to the nearest index and a reason. No address is dropped.
The reason this matters is that your search standing belongs to addresses, not to pages. Google’s guidance is plain: a permanent redirect is the strongest signal that the new page is the one to index, and the old address passes its standing to the new one. Links from distributors, specifiers, directories and old emails keep working. A visitor who bookmarked a data sheet in 2019 still gets it.
The map is a plain text file that deploys with the site, so it cannot drift out of step with the pages. Before launch, every line is tested by a script that follows each redirect and checks it ends at a working page. After launch, Search Console is watched for 90 days for any old address that still gets visits and was missed.
Where addresses change at all, it is because the old ones were wrong: WordPress artefacts like ?p=123, duplicate addresses for the same page, or paths named by a plugin. Even those are redirected, not dropped.
| Old address | Goes to | Code |
|---|---|---|
/services/website-development/ | /services/websites/ | 301 |
/case-studies/why-speed-matters/ | /insights/what-makes-a-website-fast/ | 301 |
/services/seo/ | /website-risk-analysis/ | 301 |
/products/ | /work/ | 301 |
/writing/* | /insights/:splat | 301 |
Your addresses, as above. Your content, extracted from the old site and checked rather than copied blind, because WordPress stores text with its formatting tangled in, and a check finds the broken links and the placeholder copy nobody noticed. Your design, if it works on a mobile phone and loads fast; if it does not, we say so, and the usual answer is to keep its look and rebuild its construction. Your forms, delivering to the same inbox, with spam protection and no forms plugin. Your images and documents, at the same addresses.
Nothing from the old server comes across as code. Not the theme, not the plugins, not the database. That is the point of the move: what remains has no plugins to patch and no login to attack. The functions those plugins performed are rebuilt in the page itself: a product finder as plain content and a filter, a gallery as images, a form as a form.
Your editing experience changes. The editor has one form per kind of thing on the site and nothing else, with every change saved and reversible. It is not a page builder, and a team that wants to drag blocks around the page should know that before, not after.
The new site is built beside the old one, on a private address you can open on your mobile phone throughout. When it is ready and the map is tested, the domain is pointed at the new site. The old site serves until the moment the new one does, so there is no downtime and no notice to customers. We measure both on the day, with the same tool and the same settings, and send you the before and after. For Matthew Brook’s site the main content went from 4.8 seconds to 1.1 seconds on a mobile phone, measured two hours apart on the day of the switch.
A brochure site of up to about 30 pages, with forms and a simple editor: a number of weeks that the plan sets, from the plan to launch. A product library or a site with hundreds of pages: scoped in the plan, because the inventory decides it. A shop with accounts and prices: in phases, with customers and prices carried across, and its own piece on this site. The audit that starts everything takes five working days.
List your plugins and when each was last updated by its developer. Count your pages. Find out which addresses get visits, from Search Console if you have it. If you would rather we did that, the Website Risk Analysis is that inventory in written form, with the map as an appendix if you decide to move. Either way, tell us the address and what the site must do, and an engineer will reply within one working day.