Rebuilding a WordPress site is not simply a change of theme. The work touches hosting, the database, the plugins and the address of every page — and through those addresses, the visibility you have already earned in Google. Prepared properly, a WordPress site redesign runs without downtime and without losing traffic. Prepared badly, it produces error pages, silent contact forms and rankings that slip.
This guide follows the method I used on a WooCommerce shop whose hosting still ran an obsolete version of PHP — which is why the first migration attempt failed outright. It keeps the real order of operations: preparation, staging, theme and plugins, migration, redirects, testing, launch, monitoring. Most of the value sits in the inventory you build before anyone opens a design file.
Why rebuild, and when
WordPress is still the base layer under most business sites: according to W3Techs (reading of 10 September 2026, all websites analysed), it powers 40.3% of all sites and 58.8% of those running an identifiable CMS.
The signals that justify a rebuild rather than another round of patches are fairly consistent:
- the theme is unmaintained, or depends on a page builder you want to drop;
- hosting runs a PHP version that no longer receives security fixes;
- the site is awkward on mobile, or fails Core Web Vitals;
- the structure no longer matches what your customers look for;
- any change requires a developer.
One of these calls for a targeted fix. Three or four together, and a rebuild usually costs less than the sum of the patches. Settle scope and budget first: the website redesign guide works through that decision.
Preparation: inventory, backup, prerequisites
Take an inventory of what exists
You cannot keep or redirect what you have not listed. Export the full list of URLs — a crawler is enough for a few hundred pages — plus the pages with clicks in Search Console, the landing pages in your analytics, and the pages that attract external links. That spreadsheet becomes the migration plan: one row per URL, one decision per row.
List the invisible parts too: active plugins, forms and where their emails go, measurement and consent scripts, third-party accounts, and redirects left over from earlier changes.
Make a full backup, then test it
A WordPress backup covers the files (wp-content, wp-config.php) and the database. UpdraftPlus, Duplicator and All-in-One WP Migration produce both in one operation. What matters is not the tool but the restore test: a backup never restored elsewhere is a hypothesis, not a safety net. Keep the copy off the server you are about to rebuild.
Check your PHP version
This is what blocked the shop mentioned above: the migration plugin refused to install on hosting still running PHP 5. Changing version takes a few clicks in the host's control panel, but test it on a copy first — an older plugin can stop working.
The official WordPress requirements recommend PHP 8.3 or later with MariaDB 10.11 or MySQL 8.0. WordPress still runs on PHP 7.4, but the same page notes those versions have reached end of life. The WordPress.org statistics (sites that report their data, reading of 10 September 2026) show 17.0% still on PHP 7.4, and roughly 38% on some branch before 8.2 — that is, on a version that no longer receives fixes.
| PHP branch | End of active support | End of security fixes | Status on 10 September 2026 |
|---|---|---|---|
| 8.1 and earlier | Past | Past | End of life |
| 8.2 | 31 December 2024 | 31 December 2026 | Security fixes only |
| 8.3 | 31 December 2025 | 31 December 2027 | Security fixes only |
| 8.4 | 31 December 2026 | 31 December 2028 | Active support |
For a rebuild today, PHP 8.3 or 8.4 is the sensible choice: compatible with maintained plugins, and covered by fixes for at least two more years, per the official PHP support calendar.
Work on a staging site
A rebuild never happens on the live site. You work on a copy — a subdomain, a temporary domain or a local environment — imported from the backup you have tested. Two precautions apply from the moment it exists. Block indexing (Settings, Reading, "Discourage search engines from indexing this site") and add server-side password protection, because that checkbox is only a request to well-behaved crawlers. Then disable automatic emails and any connection to payment or delivery services, so no real customer is charged from a test site.
Choosing the theme and the plugins
What matters in a theme
The theme decides speed, accessibility and maintenance effort for several years. The criteria that count:
- Maintenance: date of the last update, and declared compatibility with the current WordPress version and with PHP 8.3 or 8.4.
- Performance: run the theme's own demo through PageSpeed Insights before you buy. A slow demo will not get faster with your content in it.
- Editor: native WordPress blocks, or a classic theme with a page builder. The first limits your dependence on a third-party editor.
- Accessibility and mobile: keyboard navigation, readable contrast, layouts that hold together on small screens.
Two practical rules: use a child theme if you will modify theme code, or your changes vanish at the next update; and skip the demo import, which drags in plugins and media you will never use.
Thinning out the plugins
Every plugin is both a potential attack surface and a potential source of slowness. Patchstack's State of WordPress Security in 2025 report (2024 data, published March 2025) counted 7,966 vulnerabilities across the ecosystem over the year: 96% in plugins and 4% in themes, against seven in WordPress core. A third had no patch available when they were disclosed.
So go through the list plugin by plugin: duplicates of what the new theme already does, plugins with no update for over a year, plugins nobody can explain. Keep the structural ones — SEO, forms, cache, consent, backup, WooCommerce — once you have confirmed they work.
Migrating content and planning the redirects
If the structure changes, every old URL needs a decision in the inventory: kept, redirected to the page that replaces it, or removed with a 410 when nothing equivalent exists. Google recommends permanent redirects (301 or 308) and advises keeping them for at least a year; it also warns that ranking fluctuation is expected for weeks afterwards. Site-wide rules belong in .htaccess or the Nginx configuration, page-by-page rules in a plugin such as Redirection.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-services/?$ /services/ [R=301,L]
RewriteRule ^blog/old-article/?$ /insights/new-article/ [R=301,L]
</IfModule>Redirect chains are the usual failure: an old address pointing at another old address that redirects again. Map each URL to its final destination in one hop. On a larger site, a technical SEO audit of the staging copy surfaces the chains and the orphan pages before they reach production.
Testing before you go live
Testing happens on staging, against a written list. The points that come up most often:
- every form sends a message, to the right recipient, with the right fields;
- on a shop: a full test-mode checkout for each payment method, plus confirmation emails, delivery charges and stock levels;
- redirects verified by crawling the inventory file, not by spot-checking;
- display on a real handset, not just the browser's device simulator;
- speed: Google's Core Web Vitals thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, at the 75th percentile of page loads;
- analytics and consent banner working, HTTPS certificate valid, XML sitemap regenerated, robots.txt free of any rule inherited from staging.
If the performance figures do not pass, fix them before launch. The page on website speed separates what belongs to hosting, to caching, and to images and the theme.
Launch day, and the weeks after
Pick a low-traffic window and take a fresh backup of the old site first. You then either replace files and database on the existing hosting, or point the domain at new hosting — in which case DNS propagation can take several hours. Immediately afterwards: remove the indexing block, confirm redirects respond on the final domain, and walk the forms and the checkout again for real.
Monitoring runs for several weeks: the Pages report in Search Console for 404s and excluded pages, the Performance report for clicks page by page, the PHP error log, analytics for landing pages before and after. A temporary dip while Google recrawls is normal; a sharp drop on specific pages almost always means a missing redirect or a noindex left behind, which the page on Google indexing covers in detail.
Common questions
How long does a WordPress rebuild take?
For a brochure site of a few dozen pages, four to eight weeks between inventory and launch is a common range, testing included. A shop or a site of several hundred pages takes longer, particularly when structure and URLs both change. The timeline usually depends on how quickly content and approvals arrive from your side.
Do I need to change hosting to rebuild a WordPress site?
Not necessarily. If your current host offers PHP 8.3 or later, MariaDB 10.11 or MySQL 8.0, HTTPS and a staging environment, it will do. Moving is justified when those prerequisites are missing, or when server response times stay high even with caching in place.
Does a rebuild cost you your rankings?
A well-prepared rebuild keeps most of them. Losses almost always trace back to URLs changed without a redirect, deleted pages that were receiving traffic, or an indexing block left in place after launch. Google notes that temporary fluctuation is normal while it recrawls, so judge over weeks rather than days.
Which PHP version should a rebuilt WordPress site use?
WordPress recommends PHP 8.3 or later. On the current schedule, PHP 8.3 receives security fixes until the end of 2027 and PHP 8.4 until the end of 2028. Test your chosen version on a copy first, since an older plugin may not be compatible.
Can I keep the same theme and rebuild only the content?
Yes, provided the theme is still maintained, compatible with the current WordPress and PHP versions, and fast enough. The rebuild then covers structure, content, plugins and hosting, which reduces both budget and risk. Changing theme is only worth it when the existing one genuinely blocks you.
What should I check if traffic drops a fortnight after launch?
Start with the mechanical causes. Check that the staging noindex and robots.txt rules were removed, sample URLs from your inventory to confirm each returns a single 301 to a live page, and compare the Pages report with the previous month.