The live site looked fine. The backups sitting next to it on the server held the database password in plain text and a set of SSH keys that opened a shell on the machine. That was the first thing we found when a [CLIENT INDUSTRY] business with [NUMBER OF STAFF] staff asked us to look at why their WordPress site was so slow on phones.
The slow load turned out to be the least of it.
Short answer for anyone skimming: if your WordPress and Elementor site is slow, fragile and costing you plugin renewals every year, a rebuild in clean custom code can fix all three at once. The part that decides whether it works is the migration: every old URL mapped to a new one with a 301 redirect, so Google carries your rankings across instead of starting from zero.
The site before: what the owner had noticed
The site had been built [WHEN AND BY WHOM THE ORIGINAL SITE WAS BUILT] on WordPress with Elementor and a stack of add-ons. [NUMBER OF PAGES] pages, [NUMBER OF ACTIVE PLUGINS] active plugins, [NUMBER OF PAID PLUGIN LICENSES] of them paid. Nothing unusual there. Elementor is the most popular page builder by a distance: the 2025 Web Almanac found it on 43% of mobile WordPress sites that use a builder, more than double the block editor.
The owner's complaints, in their own order:
- It was slow on phones, which is where most of their prospects found them.
- Plugin updates kept breaking things, [WHAT BROKE AFTER AN UPDATE].
- The renewal invoices for the paid plugins came to about [ANNUAL PLUGIN LICENSE COST] a year, and nobody in the business could say what half of them did.
- They'd read about WordPress sites being hacked and had no way of knowing whether theirs was one of them.
That last worry isn't paranoia. Patchstack's State of WordPress Security in 2026 report logged 11,334 new vulnerabilities in the WordPress ecosystem during 2025, and 91% of them were in plugins. WordPress core itself had six. The risk grows with every plugin you run and every week an update sits waiting.
What we found when we opened it up
Before we quote on any rebuild we take a full copy of the site and go through it: files, database, server folders, plugin list, analytics. On this one the first surprise was in the backups.
Archives of the whole site had been piling up in [WHERE THE BACKUPS WERE STORED]. Inside them were the database username and password in plain text, and SSH keys that gave shell access to the server. Anyone who found and downloaded one of those files had everything they needed.
Nobody does this on purpose. A backup job copies what it's told to copy, and nobody goes back to look. The dangerous file is never the one anyone is thinking about.
Once a password has sat in a downloadable file, you have to assume someone has it. So the order of work was fixed: change every credential that appeared in those archives (database, SSH keys, hosting panel, WordPress admin), delete the old backups, and only then plan the rebuild. Our website security checklist covers the other places secrets tend to hide.
The second finding was more ordinary. The layouts wrapped each element in several nested containers, and add-ons loaded their CSS and JavaScript on pages that didn't use them. The homepage alone pulled [BEFORE HTTP REQUESTS] files and weighed [BEFORE PAGE WEIGHT IN KB] KB. For context, the 2025 Web Almanac puts the median mobile page at about 2.2 MB.
Rebuild or patch? The honest version
Plenty of slow WordPress sites don't need a rebuild. If the design still suits the business, the plugin list is short and the problems are mostly images and hosting, a few days of cleanup is the right call and we'll say so. Compress images, add caching, drop unused plugins, move to a decent server. That's a fraction of the cost.
We recommended a full rebuild here for three reasons:
- The speed problem was structural. Most of the weight came from the page builder and its add-ons, and you can't optimize your way out of the framework your pages are built on.
- The security cleanup meant touching almost everything anyway.
- The owner wanted to stop paying for [NUMBER OF PAID PLUGIN LICENSES] licenses they didn't understand.
One option we'd steer anyone away from: tools that export an Elementor site to static HTML. You get files you can host anywhere, but the same bloated markup, so the site is just as heavy and now harder to edit. We've written more about the trade-offs in custom website vs WordPress vs AI builder.
How the website rebuild went, step by step
1. Content inventory
Every page, image, PDF and form went into a spreadsheet with its current URL, its traffic from Google Analytics and its clicks from Search Console. Pages with links from other sites were flagged so they'd never be dropped. Thin pages with no traffic are candidates for merging into stronger ones, but only with the owner's sign-off.
2. URL mapping and 301 redirects
This is where most rebuilds lose their rankings. Google's own site move documentation recommends permanent server-side redirects (301 or 308), says they don't cost you PageRank, and advises keeping them for at least a year so Google can transfer the signals. It also says to redirect straight to the final page, not through a chain.
Where we could, we kept URLs identical. Where they had to change, each of the [NUMBER OF INDEXED URLS] indexed URLs got a one-to-one 301 to its closest new page. Not all to the homepage, which is the shortcut that quietly throws away years of search history. That came to [NUMBER OF 301 REDIRECTS] redirect rules in the server config, tested one by one before launch.
3. Rebuilding the templates by hand
We kept the look the owner liked and rebuilt it in plain HTML, CSS, a little JavaScript and PHP for shared parts like the header and forms. One stylesheet instead of dozens. Images resized to the size they're shown at and served as WebP. Nothing loads on a page unless that page uses it. If you want the technical reasons this approach loads faster, why hand-coded websites load faster goes through them.
4. Forms and tracking
Every form was rebuilt with server-side validation and spam protection, then tested by actually submitting it and checking the email arrived. Conversion tracking was set up for form submissions, WhatsApp clicks and phone taps, so the owner can see which one people actually use. On the old site, a form could stop sending and nobody would know, because nobody was counting.
5. Testing
Real phones, a tablet and desktop browsers. Every page through PageSpeed Insights. Then we crawled the old URL list against staging to confirm each redirect landed where it should, and did two review rounds with the owner.
6. Launch and Search Console monitoring
Launch was early on a weekday, never a Friday afternoon. We submitted the new sitemap to Google Search Console and Bing Webmaster Tools the same morning, then watched the indexing and 404 reports daily for the first few weeks. Google warns that rankings can wobble while it recrawls and that a medium-sized site can take a few weeks or more to settle.
From signed-off content to launch took [BUILD DURATION IN WEEKS] weeks.
The results
Google's Core Web Vitals targets are the yardstick here: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of visits. Google's threshold notes class anything over 4 seconds LCP or 0.25 CLS as poor.
| Measure | Before | After |
|---|---|---|
| Mobile PageSpeed score | [BEFORE MOBILE PAGESPEED SCORE] | [AFTER MOBILE PAGESPEED SCORE] |
| Largest Contentful Paint (mobile) | [BEFORE MOBILE LCP] | [AFTER MOBILE LCP] |
| Interaction to Next Paint | [BEFORE INP] | [AFTER INP] |
| Cumulative Layout Shift | [BEFORE CLS] | [AFTER CLS] |
| Homepage weight | [BEFORE PAGE WEIGHT IN KB] KB | [AFTER PAGE WEIGHT IN KB] KB |
| Homepage requests | [BEFORE HTTP REQUESTS] | [AFTER HTTP REQUESTS] |
| Plugins | [NUMBER OF ACTIVE PLUGINS] | 0 ([NUMBER OF PLUGINS REMOVED] removed) |
| Annual plugin license cost | [ANNUAL PLUGIN LICENSE COST] | None |
| Monthly inquiries | [BEFORE MONTHLY INQUIRIES] | [AFTER MONTHLY INQUIRIES] ([WEEKS AFTER LAUNCH] weeks after launch) |
For visitors on phones the page weight row matters more than the score. A lighter page uses less mobile data and holds up better on a patchy signal, and that's exactly the visitor a heavy site loses before the first paragraph appears.
One caveat on inquiries: a faster site doesn't create demand. It stops you leaking the demand you already had.
What the owner does differently now
Mostly, less. There's no weekly update nag, no plugin renewal invoices and no wondering whether the latest update broke the form. [HOW THE OWNER NOW HANDLES CONTENT CHANGES, E.G. SENDS TEXT TO X3WEB].
The owner also knows where the backups are kept and who can reach them, and has confirmed the domain, hosting and Google accounts are all registered in the business's name. We'd suggest every owner checks those two things, whoever built their site.
If your site is on WordPress and runs fine, keep it. The case for a rebuild is when speed, security and running costs are all going the wrong way at once, and patching one makes another worse. When that's the situation, the rebuild itself is rarely the risk. A careless migration is.
You can see what's included at each size in our website design packages. Or, if you'd like a second opinion first, send us your site's address and we'll tell you honestly whether it needs a rebuild or just a good clean-out.
Frequently asked questions
Will I lose my Google rankings if I rebuild my website?
Not if the old URLs are mapped properly. Google recommends permanent 301 or 308 redirects from each old URL to its new equivalent, kept for at least a year. Expect some movement for a few weeks while Google recrawls, then things should settle.
How long does a website rebuild take?
For a business site of 8 to 25 pages, three to six weeks from the day all the content is ready is typical. The inventory and redirect mapping take longest, and shouldn't be rushed.
Can I convert an Elementor site to plain HTML?
Export tools can turn an Elementor site into static HTML files, but they keep the same heavy markup and scripts, so the speed problem mostly stays. A hand-coded rebuild of the same design is lighter and easier to maintain.
Is it cheaper to fix a slow WordPress site than rebuild it?
Often, yes. If the plugin list is short and the slowness comes from images, caching or hosting, a cleanup costs far less than a rebuild. A rebuild pays off when the page builder itself is the weight and security or license costs are also a problem.
What should I check before starting a website rebuild?
Check that the domain, hosting and Google accounts are in your name, and ask where your backups are stored and who can open them. Export your Search Console data as a baseline.