WordPress rebuilds.
Overview
Most WordPress sites we’re asked to fix have the same story: a theme bought years ago, a page builder layered on top, twenty-odd plugins, and nobody quite sure which ones are safe to remove. Editing is slow, pages are heavy, and every update feels like a gamble.
You usually know before anyone tells you. Publishing a simple page takes half an hour and still comes out looking slightly wrong. The site is fine on your laptop and sluggish on a phone. An update broke the layout once, so now nobody updates anything, which is exactly how sites get compromised.
A rebuild keeps what works, your content, your URLs, your rankings, and replaces what doesn’t with a lean custom theme your team can edit without breaking the layout.
What we look at before quoting
We don’t quote a rebuild off a screenshot. The first thing we do is inventory the site as it actually is, because the cost of a rebuild lives in the things nobody mentions: the eleven-year-old plugin wired to a payment gateway, the three templates that look identical but aren’t, the media library with four thousand unoptimised images.
That audit is written down and handed to you whether or not you go ahead with us. If it turns out you don’t need a rebuild, we would rather tell you that in week one than in week six.
What we look at first
- Every URL on the site, crawled and listed
- Which templates exist and which are actually used
- Every plugin, what it does, and whether anything still needs it
- PHP and WordPress versions, and what is holding them back
- Database size, and how much of it is revisions and orphaned meta
- Page weight, image formats and what is blocking first paint
- Forms, payment and anything wired to a third party
What carries over
- Your content, moved programmatically rather than retyped
- Your URLs, or a permanent redirect for any that must change
- Page titles, descriptions and structured data
- Your media library, with images re-encoded rather than re-uploaded
- Analytics and Search Console, reconnected and verified after launch
- Your domain and email, which we do not touch unless you ask
How a rebuild runs
- 01
Audit and map
24 hoursWe crawl the existing site and write down what is actually there: every URL, every template, every plugin, the PHP version, the database size, the page weight. You get the findings whether or not you go ahead.
A written audit and a URL map - 02
Structure and design
Weeks 1–2We agree the templates the site really needs and the blocks each one is built from. Design happens against your real content, not placeholder text, because real headlines are longer than the ones in a mockup.
Agreed templates and a block list - 03
Build on staging
Weeks 2–3The theme is built from scratch on a staging site you can log into and watch take shape. Each block is registered properly, locked where it needs to stay on brand, and editable everywhere else.
A staging site you can log into - 04
Migrate the content
Week 3Posts, pages, media and menus are moved across programmatically rather than retyped, so nothing is lost in a copy and paste. Anything that has to change address gets a redirect written for it.
Content in place, redirects written - 05
Test and launch
Week 4We test every template, every form and every redirect, on real devices as well as a desktop. Launch happens at a quiet hour with the old site kept intact and reachable until we are sure the new one is behaving.
Live, with the old site still recoverable
Typical shape of a rebuild, live within four weeks. Every job is scoped on its own.
Keeping the rankings you already have
This is the part clients worry about, and they are right to. A badly handled rebuild can undo years of search visibility in an afternoon, usually because URLs changed and nobody wrote the redirects.
So we start from the URL map, not the design. Every address on the old site is listed before anything is built. Pages that keep their address keep it exactly, including the trailing slash. Anything that has to move gets a permanent redirect written at the server, not bolted on with a plugin, so the redirect survives the plugin being removed later.
Titles, meta descriptions and structured data travel with the content rather than being rewritten from scratch. Internal links are rewritten to point at final addresses instead of bouncing through a redirect. The sitemap is regenerated and resubmitted on launch day, and we watch Search Console for the weeks afterwards, because the useful signal shows up in coverage and query data, not in a single score.
Why page weight matters: Core Web Vitals in plain EnglishBuilt on blocks, not a page builder
The new theme is built from blocks designed around your content: hero, feature grid, testimonials, FAQs, whatever the site actually uses. Each one is locked down enough to stay on-brand and flexible enough that you won’t need a developer to publish a page.
That is a different thing from a page builder. A builder gives an editor a blank canvas and an infinity of options, which is why builder sites drift out of alignment within a year and why they are so hard to leave. Blocks give your editors the components you have already agreed, so a new page comes out looking like the rest of the site because it is made of the same parts.
It also means the markup stays readable. Nothing is stored as a wall of shortcodes that only one plugin can decode, so the site is still yours if you ever hand it to someone else.
Pick a block on the left to start the page.
Quarterly results published ahead of schedule.
A short, readable summary that tells a visitor what this page is for.
Read the report“We can publish a page in ten minutes now. It used to take an afternoon and still come out wrong.”
Operations leadNorthbridgeLaunch day
Launches are boring when they are planned and eventful when they are not. We lower the DNS time-to-live a day ahead so a rollback takes minutes rather than hours. Content is frozen on the old site while the last sync runs, so nothing published that morning goes missing.
Before the switch we walk the redirect map, every template, every form and the checkout if there is one, on real devices as well as a desktop. After the switch we warm the cache, re-verify analytics and Search Console, confirm the SSL certificate and the security headers, and put uptime monitoring on it.
The old site is kept intact and reachable on a temporary address until the new one has settled. Nothing is deleted on launch day.
What you get
- A custom block theme with no page-builder dependency, running on current PHP
- Your content and media migrated programmatically, with redirects for any changed URL
- Plugins cut back to the ones that earn their place, each removal explained
- A staging site you can log into throughout the build, and keep afterwards
- Written notes covering the blocks, the templates and how to publish
- A handover call with the people who will actually be editing the site
Questions we get asked
Will I lose my search rankings?
That is the risk a rebuild has to manage, and it is why we start with a crawl rather than a design. Every URL either keeps its address or gets a permanent redirect, titles and descriptions come across with the content, and we watch Search Console for the weeks after launch so anything odd is caught while it is still small.
Do we have to retype all our content?
No. Posts, pages, media and menus are moved programmatically. Retyping is where content gets lost and where formatting quietly breaks, so we avoid it. You will want to review the important pages, but you are reviewing, not rekeying.
Can we keep the theme we paid for?
Sometimes, and we will tell you honestly which case you are in. If the theme is well built and the trouble is really the twenty plugins stacked on it, tidying is cheaper than rebuilding. If editing a page means fighting a builder, a rebuild pays for itself in the time your team stops losing.
What happens to our plugins?
Each one gets checked for what it does and whether anything still needs it. Some become a few lines in the theme, some are genuinely doing a job and stay, and some have not been used since 2019. Every removal is a decision we explain, not a cull.
Will we be able to edit it ourselves?
That is the point of building on blocks. Your editors pick from components that are already on brand instead of arranging boxes by hand, so a new page looks right without a developer. You get a written reference for the blocks and a handover call.
Who owns the code when it is finished?
You do. It is your site, on your hosting, with no licence to keep paying us for and nothing that stops another developer picking it up. If you later want to move on, everything is standard WordPress and readable.
What if something breaks after launch?
The old site stays intact and recoverable while the new one settles. After that, most clients move onto a care plan so updates, backups and monitoring are handled, but that is a choice rather than a condition of the rebuild.