Case Study: How I Rebuilt a Slow WordPress Site and Tripled Its Google Rankings

The Brief

This client had been running a WordPress site built on Elementor for about four years, with a stack of page-builder addons, a slider plugin, three different caching plugins layered on top of each other, and a contact-form plugin nobody remembered installing. The business itself was healthy, but the site had quietly become a liability — mobile PageSpeed scores in the low 20s, a homepage that took over 6 seconds to become interactive, and rankings that had been sliding for over a year despite the content itself being decent.

The client's ask was simple: “make it fast again.” What made this project interesting is that fixing WordPress in place was a real option on the table, and part of my job was proving — with data, not opinion — that a rebuild was the better call.

The Performance Audit

Before touching anything, I ran a full audit across PageSpeed Insights, GTmetrix, and Chrome DevTools to find out exactly where the time was going, not just that the site was slow.

None of this was a hosting problem — the client was already on decent managed WordPress hosting. It was architectural: a page-builder rendering approach fighting against every performance best practice at once.

Why Rebuild Instead of Optimise In Place

I always try optimisation first before recommending a rebuild — a rebuild carries real SEO risk if it's not handled carefully. In this case, I still spent a day testing standard WordPress optimisation: a proper caching plugin, image compression, deferred JS, removing unused plugins. It moved the mobile score from 22 to about 48. Better, but nowhere near good enough, because the bottleneck wasn't configuration — it was Elementor itself generating bloated markup and depending on jQuery for every interaction.

• Elementor renders deeply nested divs for layout that a hand-built component tree avoids entirely — this alone was adding hundreds of KB of unnecessary markup per page.
• The client wanted to keep adding service pages going forward — doing that on a slow foundation just compounds the problem with every new page.
• Core Web Vitals are a confirmed Google ranking factor, and this client competes in a market where three competitors were already outranking them despite thinner content — speed was a realistic lever to pull.

The Migration Approach

Tech Stack

Handling the Redirect Map

Where URL paths did change — mostly a handful of category-style URLs that WordPress generates automatically — every one was mapped and shipped as a permanent redirect in the Next.js config, not left to a plugin or manual .htaccess edits:

After launch, Google Search Console was checked daily for the first two weeks specifically for 404 spikes and coverage errors — catching a broken redirect on day two is a five-minute fix, catching it a month later after Google has re-crawled and dropped the page is a much bigger problem.

Results (3 Months Post-Launch)

Three months after launch, keyword positions that had been stuck between page 2 and page 3 for over a year started moving into the top 10, and the site's tracked keyword count in the top 3 roughly tripled. None of the pre-existing ranking pages were lost during the transition, which was the top priority going in — a faster site that tanks rankings during migration is not a win. Organic traffic for the core service pages was up meaningfully, and the client stopped getting complaints from customers about the site “taking forever to load on their phone.”

Key Lessons