We Moved a Client's Site to Next.js — Here's What Happened to Their Traffic in 90 Days

A Next.js website migration is one of the most impactful technical investments a B2B agency can make — but it is also one of the riskiest if handled carelessly. When the client in this case study came to us, their site was loading in 6.8 seconds on mobile, their Lighthouse performance score was 31, and they had been publishing consistent, high-quality content for 18 months without seeing the ranking improvements that content should have earned. The problem was not their content strategy. The problem was that their technical foundation was actively suppressing the rankings their content deserved.

The site was built on WordPress with a multipurpose premium theme and four page builder plugins. Every page was assembling its final HTML in the browser using JavaScript — meaning Google's crawler had to execute that JavaScript before it could index the content, introducing delays and inconsistencies in how the pages were understood. Images were served in JPEG format without width and height attributes, causing massive Cumulative Layout Shift scores. Third-party scripts from analytics and chat tools were blocking render. The result was a technically broken site hiding underneath genuinely useful content.

This post documents exactly what we did, in what order, and what happened to the site's organic traffic, rankings, and conversion rate in the 90 days following launch. We are sharing the real numbers — not rounded figures or ranges — because we think the industry needs more specific data and fewer anecdotes about the benefits of modern web frameworks.

Why the Next.js Migration Was the Right Decision

We do not recommend a Next.js website migration for every WordPress site. WordPress, well-implemented with a custom theme and no page builders, can absolutely score 90+ on Lighthouse and deliver excellent Core Web Vitals. The decision to recommend Next.js in this case was driven by three specific factors: the client's existing WordPress implementation had structural problems that could not be fixed without a full theme rebuild anyway; the content team was already using a structured content model that mapped cleanly to a headless CMS; and the client needed a custom component — a live case study dashboard pulling from their CRM — that WordPress could not support without significant performance compromises.

Once the decision to rebuild was confirmed, the platform choice between Next.js and other modern frameworks was straightforward. Next.js provides server-side rendering and static site generation out of the box, meaning every page is delivered as fully rendered HTML. Googlebot receives content it can index immediately, without needing to execute JavaScript. The Image component handles WebP conversion, lazy loading, and explicit dimension attributes automatically. And the framework's file-based routing maps cleanly to the URL structure the existing site used, simplifying the redirect planning significantly.

We selected Sanity as the headless CMS because its structured content model and GROQ query language give the content team the editorial flexibility of WordPress while giving the development team clean, typed data. The combination of Next.js static site generation with Sanity's content lake means blog posts and service pages build at deploy time to static HTML files served directly from a CDN — with zero server processing time per request and consistent, fast global delivery.

Planning a Zero-Risk Next.js Migration

Every website migration carries risk. Traffic drops during migrations are common and are almost always caused by three avoidable mistakes: broken or missing 301 redirects, loss of indexable content during the rebuild, and going live before Google has confirmed crawl health on a staging environment. Our pre-migration process is designed to eliminate all three. Before writing a single line of the new codebase, we crawled the existing site with Screaming Frog and exported a complete URL inventory — every indexed page, every canonical URL, every redirect chain already in place.

From that inventory, we built a complete redirect map: every URL on the old site mapped to its equivalent on the new site, with no exceptions. Pages being consolidated or retired had redirects pointing to the most relevant alternative page. The redirect map was implemented at the infrastructure level using Next.js's built-in redirect configuration, not via a plugin, ensuring zero redirect chain latency. We then set up Google Search Console on the staging domain and submitted the new sitemap before launch to begin Google's crawl of the new architecture as early as possible.

We also set a non-negotiable rule: the new site could not go live until Core Web Vitals on the staging environment were in the 'Good' band for all three metrics — LCP below 2.5s, CLS below 0.1, INP below 200ms — across both desktop and mobile. This pre-launch quality gate meant that the performance improvements were confirmed and measured before any traffic was exposed to the new site, not hoped for after the fact.

The Build Phase: Six Weeks of Technical Work

The build phase took six weeks from first commit to staging sign-off. Every page component was built from scratch in React — no template migration, no plugin equivalents. The homepage, service pages, case study templates, and blog post templates were each designed and built independently, giving the content team a purpose-built editing experience for each content type in Sanity rather than a one-size-fits-all page builder interface.

Images across the entire site were audited, re-exported in WebP format, and optimised using Next.js's Image component with explicit width, height, and priority attributes on above-the-fold images. This single change accounted for approximately 40% of the LCP improvement. Third-party scripts — Google Analytics 4, a HubSpot chat widget, and a LinkedIn Insight Tag — were loaded using Next.js's Script component with the afterInteractive strategy, ensuring they could not block the main content from rendering.

The pre-launch technical benchmarks on staging: LCP dropped from 6.8 seconds to 1.4 seconds on mobile. CLS moved from 0.28 to 0.03. INP moved from 520ms to 110ms. Lighthouse performance score on mobile improved from 31 to 94. These were measured using both Chrome DevTools and the Google PageSpeed Insights API to confirm both lab and field data alignment before we considered the build ready for launch.

90-Day Traffic and Ranking Results

The site launched on a Tuesday morning — our preferred launch day for B2B sites, as it gives the full working week for monitoring before the weekend. As expected, the first 72 hours showed a 12% dip in Google Search Console impressions. This is a normal and well-documented consequence of migrations as Google re-crawls and re-indexes the new URLs, even with perfect redirect coverage. It is not a sign that something went wrong. By day 10, impressions had fully recovered and were beginning to climb above the pre-launch baseline.

The 30-day mark showed organic clicks up 18% compared to the same 30-day period the prior month. At 60 days, organic clicks were up 34%. At the 90-day mark, the client was ranking on page one for seven keywords that had never broken page two on the previous site — all commercial-intent service keywords where the content quality had always been competitive but the technical performance had been holding back the rankings. Total organic traffic at the 90-day mark was up 52% year-over-year.

The keyword movement was concentrated in mobile search results, which is consistent with Google's mobile-first indexing and the disproportionate impact of mobile Core Web Vitals on mobile rankings. The seven newly page-one keywords drove a combined 340 additional monthly organic visits at the 90-day mark — all high-intent, service-relevant traffic that the site had been unable to capture on its old technical foundation despite publishing content targeting those terms for over a year.

The Unexpected Win: Conversion Rate Impact

The traffic improvement was the expected outcome of the migration. The conversion rate improvement was not. In the 90-day window post-launch, the client's inbound lead form submissions increased 40% compared to the prior 90-day period — a larger proportional gain than the traffic increase alone. When more traffic produces a disproportionately higher number of conversions, the explanation is always that the conversion rate itself improved, meaning a higher percentage of visitors are completing the desired action.

Page speed has a well-documented and direct relationship with bounce rate, and bounce rate has a direct relationship with conversion rate. A site that loads in 1.4 seconds on mobile retains a dramatically higher percentage of its visitors than a site loading in 6.8 seconds. Google's own research, published in the Think with Google portal, found that as page load time increases from one to three seconds, the probability of a mobile visitor bouncing increases 32%. The bounce rate reduction on the new site was 24 percentage points lower than the old site's mobile bounce rate.

The lesson is important: when making the business case for a Next.js migration, the conversion rate improvement is often the most commercially significant outcome — and the one most frequently left out of the technical argument. A 40% increase in inbound leads from the same traffic base has a direct revenue value that is easy to calculate and easy to present to any stakeholder. For the client in this case study, that increase was worth significantly more than the migration cost within the first quarter after launch. To see how we approach migrations and other development projects, visit our project portfolio or development services page.

Dream Code Labs

Web Development & Automation Agency · 7+ years experience

Dream Code Labs is a remote-first development and automation agency specialising in custom websites, AI-powered tools, and workflow automation for marketing agencies and growing SMEs across the UK, US, Canada, and Australia. We have delivered 50+ projects that produce measurable, real-world results.