How I Moved Mackex from WordPress to a Fast Next.js Site

Mackex Services is an electrical infrastructure contractor in New South Wales. The website needed to feel credible for a real construction services business, keep content manageable for non-developers, and load quickly on mobile without carrying the usual weight of a theme-heavy WordPress build.

I rebuilt the site as a Next.js App Router frontend, kept WordPress as the content system, connected the two through WPGraphQL, and deployed the public experience on Vercel. The result is a headless WordPress setup: editors can still manage content in WordPress, while visitors receive a faster, cleaner, more controlled frontend.

This is a technical case study about the engineering decisions behind the migration. It is not a claim that every WordPress site should become headless, or that performance should be judged without real production measurement.

Why I did not just redesign WordPress

A WordPress redesign can be the right answer when the site is content-heavy, plugin needs are simple, and the team already has reliable hosting and maintenance. In this case, the public site needed a more controlled frontend than WordPress themes usually provide.

The practical architecture was simple: WordPress became the back office, Next.js became the storefront.

The site needed to feel engineered, not decorated

Mackex is not a lifestyle brand or a SaaS startup. It is an electrical infrastructure contractor working across serious commercial, government, rail, road, mining, and energy environments. The design direction had to support that reality: practical, sturdy, easy to scan, and confident without becoming loud.

That philosophy shaped the frontend work. The site needed to look modern, but not fragile; polished, but not generic; fast, but still rich enough to communicate a real operating business.

The production shape

Visitor
  |
  v
Vercel edge / Next.js App Router
  |
  +-- pre-rendered public routes
  +-- ISR refresh for content changes
  +-- image, metadata, sitemap, and schema control
  |
  v
WordPress content system
  |
  +-- WPGraphQL API
  +-- custom post types and media
  +-- editor-owned content

The frontend uses Next.js 15, React 19, TypeScript, Tailwind CSS, Apollo Client, and Vercel. The CMS side remains WordPress with WPGraphQL. The site includes a home page, about page, service pages, project and case-study pages, blog routes, NSW location pages, contact form handling, sitemap, robots, Open Graph metadata, and structured data.

The most important reliability detail is that the frontend has static fallbacks for important sections. If WordPress is slow or temporarily unavailable, the site should still be able to render a usable public experience instead of turning a CMS problem into a full-site outage.

Where the speed came from

I did not treat performance as one magic setting. The speed work came from removing runtime work, making content cacheable, and being more deliberate about what the browser downloads.

1. Move public rendering out of WordPress. Next.js serves the public pages instead of asking PHP, a theme, and multiple plugins to assemble each visitor request.
2. Pre-render content-heavy routes. Pages, services, projects, case studies, locations, and blog content can be generated ahead of time or refreshed through ISR instead of recomputed for every user.
3. Use WPGraphQL as a content boundary. The frontend requests only the fields it needs instead of receiving full theme-rendered HTML for every concern.
4. Optimize image delivery. Next.js image handling gives the frontend control over remote image dimensions, layout stability, lazy loading, and modern delivery patterns.
5. Keep third-party scripts intentional. Analytics and Speed Insights are useful, but the site does not need a collection of WordPress plugin scripts on every public route.
6. Build static fallbacks for critical content. A slow CMS should not make the core marketing site feel broken.

That combination is what makes the site feel fast: fewer moving parts on the public request path, less unnecessary JavaScript, predictable page generation, and a CDN-first deployment model.

The migration was also an SEO cleanup

A framework migration is risky if the new site loses URLs, metadata, schema, internal links, or crawl coverage. My pre-launch audit focused on the small technical details that can quietly hurt discoverability.

The lesson is boring but important: a fast site that loses its commercial pages, metadata, or internal links is not a successful migration.

The migration was not only a frontend rewrite

I approached the work as four connected problems: preserving the content that already existed, improving the public experience, protecting search visibility, and making future changes easier to ship.

That was the real shape of the project: content reconciliation, frontend performance, SEO repair, and operational cleanup all moving together.

Headless WordPress still needs operational polish

Moving to Next.js solved the public frontend problem, but it also made the CMS contract more important. The next improvements are less flashy and more operational.

• Use WordPress modified dates for sitemap lastModified values instead of stamping every URL with the deployment date.
• Use on-demand revalidation from WordPress publish/update events so editors do not wait for the normal ISR window.
• Keep GraphQL queries paginated so project growth does not silently truncate content.
• Bring Yoast SEO fields into GraphQL where possible instead of duplicating authored SEO data in code.
• Audit featured-image alt text in WordPress so accessibility and search metadata are content-owned, not code-guessed.
• Move repeated hardcoded content, such as testimonials, FAQs, team content, and logos, into a cleaner CMS-controlled model when editing frequency justifies it.

My migration checklist

1. Decide whether WordPress is the full site or only the CMS.
2. Inventory routes, redirects, service pages, blog URLs, media URLs, metadata, and forms before building.
3. Design the Next.js data layer around stable content contracts, not page-builder leftovers.
4. Pre-render what can be pre-rendered, then add ISR or on-demand revalidation for content freshness.
5. Keep a documented environment-variable, content-source, and launch-verification plan.
6. Verify sitemap, robots, canonical URLs, Open Graph, schema, analytics, forms, and mobile links before launch.
7. Measure production behavior after launch with real user data, not only local lab scores.

For Mackex, the win was not "WordPress bad, Next.js good." The win was putting each tool in the job it handles best: WordPress for content management, Next.js for the public experience, and Vercel for fast global delivery.

Sources and next steps

Public references checked while writing: Next.js App Router docs, Next.js ISR guide, Next.js Image component docs, WPGraphQL quick start, and Vercel Speed Insights docs.