Home › Insights › WordPress rebuilds
Guide · Web design · Measured
Rebuilding a WordPress site without WordPress
Short answer: a page-builder WordPress site carries an enormous amount of machinery your visitors have to download before they see anything. We measured a real 32-page contractor site against its static rebuild on the same day. The homepage went from 432KB of HTML to 48KB, from 35 JavaScript files to one, and from ten plugins to none. Here is what that means, how the migration works, and when you should ignore all of this and stay on WordPress.
The measurement
These are not estimates or vendor claims. We fetched the live homepage of a plumbing contractor’s WordPress site , Astra theme, Elementor and Elementor Pro, plus eight other plugins, and counted what the browser is asked to deal with. Then we measured the same page in the static rebuild.
Each pair is scaled to its own maximum — the five measures are different units and do not share an axis. Figures measured on the same day from the live site and the rebuild.
| What the browser handles | WordPress + Elementor | Static rebuild |
|---|---|---|
| HTML document size | 431,976 bytes | 47,973 bytes |
| <script> tags on the page | 58 | 3 |
| Separate JavaScript files | 35 | 1 |
| Render-blocking files in <head> | 64 | 2 |
| WordPress plugins loading | 10 | 0 |
| Total CSS + JavaScript weight | spread across 35 files | 62KB, two files |
The result, on Google’s own scale
What sites built this way actually score
The measurements above are page weight and request counts. Here is what Google makes of the finished result — and you can check both of these yourself in about thirty seconds at pagespeed.web.dev.
- 100Performance
- 100Accessibility
- 100Best practices
- 99SEO
Core Web Vitals — 3/3 passed
- 98Performance
- 99Accessibility
- 100Best practices
- 99SEO
Core Web Vitals — 3/3 passed
The scores are the easy half. The badge underneath them is the half that counts. A PageSpeed number is a lab test run on demand. Core Web Vitals is Google’s assessment of how the site behaved for real visitors on real connections over the previous month — and it is a confirmed ranking signal. Passing all three thresholds is the part most competitors never manage, because you cannot optimize your way there while sixty files still have to load before the page can paint.
None of this comes from tuning. It comes from what is not there: no content management system assembling the page on request, no database query ahead of the first byte, no theme, no page builder, no plugins shipping code to visitors who will never use it.
The word “elementor” appears 810 times in that homepage’s source. Almost none of it is your content. It is per-widget CSS and JSON settings blobs that the builder inlines into every page so the editor can reconstruct the layout later. Your visitor downloads all of it to read your phone number.
Why page-builder sites get heavy
It is not carelessness on anyone’s part. It is the architecture doing exactly what it was designed to do.
- Every plugin loads on every page. A booking plugin used on one page still ships its CSS and JavaScript to your homepage, because WordPress has no reliable way to know it will not be needed.
- Page builders inline their own settings. Elementor writes the styling for each widget directly into the page so it can rebuild the editing interface. That is sensible for the editor and pure weight for the visitor.
- Themes and add-ons stack. A theme, a theme add-on pack, a builder, a builder Pro version and a third-party widget library each add their own layer. We counted five such layers on this one site.
- Everything is assembled on request. A database query, PHP execution and template rendering happen before the first byte reaches the visitor, every single time.
What actually changes
Speed, most obviously. Sixty-four render-blocking files in the document head means sixty-four things that must be fetched before the page can paint. Two means two. On a phone on cellular data outside a job site, that difference is the gap between a customer waiting and a customer tapping the next result.
The attack surface disappears. Most WordPress compromises arrive through a plugin, a theme, or the login page. Remove the database, the PHP and the admin login and that entire category has nothing to target. This matters more than speed for a business holding customer records.
The maintenance treadmill stops. Ten plugins is ten update streams, each capable of breaking the site or conflicting with another. Static files do not have versions to patch.
Hosting gets cheap and boring. No PHP version to keep current, no database to tune or back up, no memory limits. Plain files on a plain server.
The automation you gain
This is the part people do not expect. Removing WordPress does not mean doing more by hand — it means the repetitive work moves into a build step that runs in a second and never forgets.
- One command moves the site between staging and live. The rebuild we measured is authored for the domain root, but a single flag rewrites every internal link, image path, canonical tag, sitemap entry and server rule to sit under a staging subdirectory instead — and flips the staging copy to noindex so Google never sees two versions. Reversing it is the same command without the flag. No file gets edited by hand, so nothing gets missed.
- Sitemaps and structured data are generated, not maintained. Add a page and it appears in
sitemap.xmlwith the right canonical and schema automatically. Nobody has to remember. - Images are optimized at build time. Resized and converted to modern formats once, on the way to disk, rather than by a plugin on every request.
- Forms route straight to email with spam filtering, with no plugin to update and no database of submissions sitting on the server.
- Redirects are generated from the old URL map, so nothing that ranked today returns a 404 tomorrow.
The pattern is the same throughout: anything a person would otherwise have to remember becomes something the build does every time.
Where search is going
Built for machines that read, not render
A growing share of the questions your customers used to type into Google now get answered by an AI assistant instead — ChatGPT, Perplexity, Copilot, and Google’s own AI overviews. Those systems reach your site through crawlers, and here is the part that matters: most of them do not execute JavaScript.
That is a problem for a page-builder site, because a large amount of what a visitor sees is assembled in the browser after load. If your navigation, your service list, your address or your structured data only exist once JavaScript has run, an AI crawler arrives, finds an almost-empty document, and moves on. It cannot cite what it cannot read.
We saw exactly this on a live client site recently. Its header, footer and business schema were all injected by JavaScript after a config file loaded — so to any crawler that does not render, the site had no navigation and no structured data at all. Fixing it meant putting the facts back into the HTML where machines can find them.
What we do instead
- Everything ships in the HTML. Headings, copy, navigation, contact details, service areas — present in the source, not assembled afterwards. What a person reads is exactly what a crawler receives.
- Structured data in the head, not injected. Business details, opening hours, service areas, articles, FAQs and breadcrumbs as static JSON-LD, so the facts are unambiguous rather than inferred from prose.
- An
llms.txtfile at the site root. An emerging standard that gives AI systems a clean, plain-text map of what a site covers and where. Almost nobody in this market publishes one yet. - Genuine question-and-answer content. Assistants quote passages that answer a question directly. Pages written as answers get quoted; pages written as brochures do not.
- Speed, again. Crawlers work to budgets. A site that responds in a fraction of a second gets more of itself read, more often.
We are not going to promise you rankings inside an AI assistant, nobody can, and anyone who does is guessing. What we can say is narrower and verifiable: a site whose content only exists after JavaScript runs is invisible to most of them today. Building in plain HTML with real structured data costs nothing extra and removes that risk entirely, whichever way this goes.
When you should stay on WordPress
We would rather talk you out of this than sell you the wrong thing.
Stay if you publish frequently and multiple people need to write without involving us. A blog with weekly posts and three authors belongs in a CMS.
Stay if you run a real store. WooCommerce with inventory, variants and shipping rules is a serious application, and replacing it is a much larger project than replacing a brochure site. We spent six years, from 2015 to 2021, building and running large WooCommerce stores — which is exactly why we will tell you to keep one rather than rebuild it. Everything on this page comes from having run WordPress in production, not from disliking it at a distance.
Stay if you depend on a specific plugin that genuinely does something custom — a booking system tied to your scheduling software, a members area, a searchable database.
For everything else — the contractor, the practice, the trades business with a dozen service pages that change twice a year — the CMS is machinery serving nobody. That is the case where a rebuild pays for itself.
How the migration actually goes
1. Inventory every URL. Before anything is designed, we list every page the current site serves and what ranks. That list becomes the redirect map, and it is the single thing that determines whether you keep your rankings.
2. Rebuild the content, not the layout. We take your real copy and rewrite the structure around what people search for, rather than replicating a builder layout in a different tool.
3. Stage it at a hidden address. The whole site goes up somewhere only you can see, deliberately noindexed, and you walk every page before anything public changes.
4. Cut over with redirects live from minute one. Old URLs point to new ones the moment the switch happens, not the week after.
5. Watch Search Console. Coverage and impressions get monitored for weeks afterward, because that is where a migration problem shows up first.
An honest note about these numbers
Page weight and request counts are objective, so we published them. We have not published traffic or lead figures for this rebuild, because it is staged and has not launched — and inventing results is exactly the thing that makes people distrust this industry. When it launches and there are real numbers, we will put those here too.
If your site is slow, hard to change, or you are paying monthly for plugins nobody uses, tell us what you’re running and we will tell you honestly whether a rebuild is worth it. Sometimes the right answer is to tune what you have.