We Stopped Building Service-Business Sites on WordPress — Here's Why
August 20, 2026 · The Valley Marketing Group
For years, every service business website we built at Valley started the same way: install WordPress, pick a theme, add a page builder, and layer on a dozen plugins to make it do what the client actually needed. In 2026, we stopped. Every new site we build for HVAC companies, dental practices, roofers, med spas, and plumbers now runs on GitHub, Astro, Supabase, and Resend — no WordPress core, no plugin folder, no PHP. This wasn't a trend we chased. It was a decision forced by data on security, speed, cost, and reliability that got harder to ignore every year we kept building on the old stack.
The Security Case: A Plugin Ecosystem Nobody Can Fully Patrol
WordPress powers a huge share of the web, and that scale is exactly the problem. In 2025, WordPress logged 11,334 new vulnerabilities — a 42% jump year-over-year — according to Colorlib's WordPress hacking statistics report. That number tells you almost everything about why we walked away from the platform for client work.
Here's the part that matters most: 91% of those vulnerabilities were in plugins, not WordPress itself. Only 9% were in themes. WordPress core — the actual software Automattic maintains — had just 6 vulnerabilities all year, and every one of them was rated low priority. WordPress core is not the problem. The plugin ecosystem sitting on top of it is.
That distinction matters because a typical service-business WordPress site doesn't run "WordPress." It runs WordPress plus a page builder plugin, an SEO plugin, a forms plugin, a caching plugin, a security plugin (ironically, itself a common attack vector), a booking plugin, and often a handful of theme-specific add-ons — each maintained by a different developer, on a different release schedule, with a different level of security discipline. We cover the mechanics of this in depth in our companion piece on the hidden security bill of WordPress plugins, but the short version is: every plugin you install is a door you didn't build and can't fully inspect.
Speed of Exploitation Is the Real Threat, Not Just Volume
Vulnerability counts alone undersell the risk. What should actually worry a business owner is how fast a disclosed vulnerability turns into an active attack. According to research covered by Webmastered's analysis of WordPress plugin vulnerabilities, the median time from public disclosure to first exploitation is just 5 hours. Automated bot networks scan for newly disclosed CVEs and start hitting vulnerable sites within the same business day.
Two more numbers from that same research explain why patching alone isn't a reliable defense:
- 43% of new WordPress vulnerabilities require zero authentication to exploit — meaning an attacker doesn't need a stolen password or admin session, just a URL and a known flaw.
- 23% of disclosed vulnerabilities had no patch available within 30 days of disclosure — so even a business owner who checks for updates religiously can be running a known-vulnerable plugin with no fix to apply.
Worse, the same report found that more than half of the plugin developers Patchstack notified about vulnerabilities did not patch before the flaw went public. That's not a hypothetical gap — it's the normal operating condition of the plugin ecosystem. A vulnerability gets found, the developer is told, and in over half of cases nothing gets fixed before the information is out in the open for anyone to exploit.
For a dental practice or HVAC company, this isn't an abstract IT risk. A compromised site can mean patient or customer data exposure, a defaced homepage during a busy lead-generation month, or — most commonly — a site quietly hijacked to serve spam links or malware to visitors, tanking both trust and search rankings before anyone notices.
What "No Server-Side Application" Actually Means for Security
The architecture we build on now removes most of this attack surface by design. A static site is one where the HTML, CSS, and JavaScript are generated ahead of time and served as plain files rather than assembled by a server on every request. There's no PHP interpreter running on your server, no database connection string sitting in a config file, no admin login panel at a guessable URL, and no plugin directory for an attacker to probe. If there's no server-side application processing requests, there's no server-side application to exploit. Dynamic functionality — forms, bookings, authenticated dashboards — still exists, but it runs through isolated, purpose-built backend services (in our stack, Supabase) rather than a single monolithic CMS that handles everything from rendering your homepage to storing your database credentials in the same process.
The Performance and Core Web Vitals Case
Security was the first reason we moved. Performance is the reason we haven't looked back. Google's Core Web Vitals — the real-world speed and stability metrics that factor into search rankings — show a wide, well-documented gap between WordPress and Astro-based sites.
According to 2026 data from the Chrome UX Report and HTTP Archive, reported by Search Engine Journal's Core Web Vitals comparison, Astro sites pass Core Web Vitals on mobile at a 60% rate compared to WordPress's 38% — a 22 percentage point gap. That's not a marginal difference; it means the average WordPress site is failing the exact metrics Google uses as a ranking signal, while the average Astro site is passing.
The same data breaks down why:
- Astro's Largest Contentful Paint (LCP) is 65% faster than the WordPress average.
- Astro's HTML output is 72% lighter than WordPress's.
- Average total page weight is 1.65MB for Astro versus 2.63MB for WordPress — roughly a 40% reduction in what a visitor's phone has to download.
- Astro ships zero client-side JavaScript by default.
That last point is worth explaining because it's the architectural reason for all the other numbers. We go deeper on the mechanics in our dedicated Astro vs. WordPress Core Web Vitals breakdown, but the short version: Astro is a web framework built around "islands architecture," meaning it renders pages to static HTML at build time and only loads JavaScript for the specific interactive components that need it — a booking widget, a contact form, an image carousel — rather than shipping an entire framework's runtime to render a page that's mostly static text and images. WordPress, by contrast, typically loads jQuery, a page-builder runtime, several plugin scripts, and theme JavaScript on every single page load, whether or not that page uses any of it.
For a service business, the practical translation is simple: a plumber's "Emergency AC Repair" page needs to load fast on a stressed-out homeowner's phone on a spotty connection. A 2.63MB page competing against a 1.65MB page is starting the race a lap behind, and Google's ranking algorithm notices the same gap your customers do.
Why Speed Compounds Into Rankings and Conversions
Core Web Vitals aren't just a vanity metric — they're one of the signals Google's algorithm uses directly, and they correlate strongly with bounce rate and conversion rate independent of SEO. A visitor who lands on a slow, JavaScript-heavy page from a Google Ads click is a visitor who might leave before your phone number even renders. When we rebuild a client's site on Astro, we're not chasing a PageSpeed score for its own sake — we're removing friction between an ad click or organic search result and a phone call or form submission.
The True Cost Case: What WordPress Actually Costs Once You Add It Up
The pitch for WordPress has always been "it's free." The software is. Running it safely and well for a service business rarely is. We've written a full breakdown in our piece on the hidden monthly costs of WordPress for service businesses, but the hosting math alone makes the case.
Managed WordPress hosting from providers like Kinsta or WP Engine — the tier most small business sites actually need to run reliably — starts around $30–40/month at the entry level, typically capped around 25,000 visits and 10GB of storage, according to Fastlancer's Kinsta vs. WP Engine comparison. That's before adding a security plugin subscription, a backup service, an SEO plugin's paid tier, a page builder license, and the SMTP plugin covered below. Most real client sites we've audited land closer to $150–400/month once every recurring plugin and service fee is totaled.
Static site hosting on platforms like Netlify, Cloudflare Pages, or Vercel ranges from free to roughly $3–20/month at comparable traffic levels, per Spendark's static site hosting cost calculator. The gap isn't a rounding error — it's the difference between a site that costs a business owner real monthly overhead indefinitely and one that costs close to nothing to keep running.
The Maintenance Cost No One Prices Into the Quote
The dollar figure only tells part of the story. WordPress also carries an ongoing maintenance burden that doesn't show up on an invoice but shows up in time: core updates, plugin updates, theme updates, PHP version compatibility checks, and the periodic "something broke after an auto-update" fire drill. Every plugin is a dependency that can conflict with another plugin, break after a WordPress core update, or simply get abandoned by its developer — at which point it becomes a permanent, unpatched liability sitting on the site until someone finds and removes it.
Static sites built with Astro remove most of that maintenance surface. There's no plugin folder to patrol, no core software requiring monthly security patches, and no page-builder runtime that can silently break when a theme updates. Structured content and dynamic features live in Supabase instead of a sprawling plugin stack — we detail exactly which categories of WordPress plugins Supabase replaces, from forms to bookings to review widgets to custom post types, each swapped for a single managed backend rather than a dozen separately maintained add-ons.
The Email and Lead-Reliability Case
For a service business, a website's entire job usually comes down to one thing: getting a lead notification into the right inbox the moment a form is submitted. This is the piece that fails silently on WordPress most often, and it's the piece owners notice least until a lead is already gone.
Most WordPress contact form plugins rely on the server's default mail function or a bolted-on SMTP plugin to actually send that notification email. According to Mailtrap's analysis of WordPress transactional email plugins, most of these WordPress SMTP plugins route email through shared or bolted-on infrastructure rather than dedicated transactional email infrastructure with its own sending reputation. That distinction is the whole problem. Transactional email — the kind that has to arrive, not just get sent — depends on sender reputation: a track record with inbox providers that determines whether a message lands in the inbox or the spam folder. When a WordPress SMTP plugin shares sending infrastructure with thousands of other unrelated sites, some of which are sending spam, your lead notification email inherits whatever reputation that shared pool has built up — good or bad.
We go deeper on this exact failure mode, including how deliverability actually breaks, in our comparison of Resend versus WordPress SMTP for lead notifications. The short version: a form that "submitted successfully" on the front end tells a customer nothing about whether the business ever received it. We've audited WordPress sites where the contact form worked perfectly from the visitor's side for months while every notification silently landed in a spam folder no one checked — meaning every lead during that window was lost with no error, no bounce, and no way to know it happened.
Our stack uses Resend, a transactional email service built specifically for this job — dedicated sending infrastructure, proper authentication (SPF, DKIM, DMARC configured correctly from day one), and delivery logs we can actually check when a client asks "did that lead come through?" instead of guessing.
Why We Chose This Specific Stack: GitHub, Astro, Supabase, Resend
Rejecting WordPress is only half the decision. The other half is what to build instead, and we didn't pick these four tools arbitrarily — each one replaces a specific WordPress function with a purpose-built equivalent.
Astro: The Framework
Astro is a modern web framework designed to build fast, content-focused websites by rendering pages to static HTML at build time and only shipping JavaScript for components that genuinely need interactivity. For a service business site — mostly informational pages, service descriptions, location pages, and a handful of forms — that's close to a perfect match. There's no reason a page describing your roofing services needs the same JavaScript runtime as a full web application.
Supabase: The Backend
Supabase is a backend-as-a-service platform built on PostgreSQL that provides a database, authentication, file storage, and serverless functions in one managed system. This is what replaces the plugin stack: instead of a forms plugin, a reviews plugin, a booking plugin, and a custom post type plugin each maintained separately, structured data lives in one real, queryable database with one security model to reason about.
GitHub: Version Control and Deployment
Every change to the site lives in Git version control, meaning every edit is tracked, reversible, and reviewable before it goes live — a sharp contrast to WordPress, where a plugin update or a client's late-night edit can break a live site with no easy undo. Deployment happens automatically when code is pushed, with no manual FTP uploads or server-side file edits involved.
Resend: Transactional Email
As covered above, lead notifications and automated emails run through dedicated infrastructure rather than a shared SMTP plugin, so deliverability is something we can verify rather than hope for.
Together, these four pieces form what's often called a Jamstack architecture — a way of building websites where the front end is pre-built and served as static files while dynamic functionality is handled by separate, specialized APIs rather than one monolithic server-side application. Each layer does one job well, each layer can be audited independently, and no single compromised plugin can take down the whole site.
Want us to look at your setup?
Free 24-hour audit. No pitch, no pressure.
What Migration Actually Looks Like
The most common objection we hear is some version of "that sounds like a full rebuild, and we don't have time for that." It is a rebuild — but it's a scoped, sequenced one, not a leap into the unknown. See our full 30-day migration playbook for the complete step-by-step process, but at a high level, migrating a service business site off WordPress follows a consistent pattern:
- Content and structure audit. Every page, blog post, image, and piece of schema markup on the existing site gets catalogued before anything changes, so nothing gets lost in translation.
- SEO baseline capture. Current rankings, URL structure, meta titles and descriptions, and backlink profile are documented so the new site can preserve or improve on them rather than starting from zero.
- Rebuild on Astro. Pages are rebuilt with the same URLs wherever possible (with proper redirects where they can't be), the same core content, and the performance benefits baked in from the start.
- Data migration to Supabase. Anything dynamic — blog posts, locations, staff bios, reviews — moves into a structured database rather than staying scattered across plugin-specific tables.
- Forms and email cutover to Resend. Lead notification paths are tested and verified before the old form is retired, not after.
- Parallel testing and DNS cutover. The new site runs in parallel with the old one until it's fully verified, then DNS is switched — typically with minutes of downtime, not days.
The businesses we've migrated off WordPress — dental practices, med spas, and home service companies among them — go through this same sequence. It's disruptive for a project, not disruptive to daily operations, because the old site keeps running lead-capture duty right up until the new one is verified and ready.
Who This Is — and Isn't — Right For
We're not going to pretend this stack is the right answer for every website on the internet. It isn't. If your business runs a large content team publishing dozens of posts a week through a familiar WordPress editor, or you rely heavily on a specific WordPress plugin ecosystem with no real equivalent (certain complex membership sites, for instance), a full migration needs a harder conversation about trade-offs.
But for the businesses we actually build for — local service companies whose website's job is to load fast, rank well, and reliably turn visitors into phone calls and form submissions — the case is straightforward. You're not running a publishing platform. You're running a handful of service pages, location pages, a blog for SEO, and a lead capture form, and none of that requires a general-purpose CMS carrying a decade of plugin-ecosystem baggage to do its job.
If your current WordPress site is fast, secure, and converting well, there's no urgency to rip it out. But if you've had a plugin conflict break your site, a hosting bill that keeps creeping up, a PageSpeed score you're embarrassed by, or — most seriously — a nagging suspicion that leads have gone missing without anyone noticing, those are the exact symptoms this architecture was built to eliminate.
The Trade-offs We're Honest About
We'd rather lay out the real trade-offs than pretend this switch is a strict upgrade with no downside, because a business owner deserves an honest picture before committing to a rebuild.
Content Editing Is Different, Not Easier or Harder — Just Different
WordPress's biggest genuine strength is its editing experience: a familiar, block-based editor that a non-technical staff member can use to update a page or publish a blog post without touching code. Our stack replaces that with a structured content workflow through Supabase and, for code-level changes, Git-based deployment — which is more structured and less error-prone once someone's used to it, but it is a different mental model than clicking into a WordPress page and typing. We build content-management interfaces for clients specifically to bridge this gap, but it's a real adjustment, not a non-issue.
The Plugin Ecosystem Also Means a Marketplace of Solutions
WordPress's massive plugin catalog is a security liability, as covered above — but it's also, undeniably, a marketplace where a huge range of functionality already exists as a one-click install. If a client needs a highly specific, niche feature that a WordPress plugin already solves off the shelf, building the equivalent from scratch on our stack is real, billable engineering work rather than a plugin download. This is exactly why we said earlier that businesses with unusual, plugin-ecosystem-dependent requirements deserve a harder conversation rather than a blanket recommendation.
Upfront Cost vs. Ongoing Cost
A WordPress site is often cheaper to launch initially — a theme and a handful of plugins can get a basic site live fast. Our stack typically has a higher upfront build cost because more of the site is custom-built rather than assembled from existing components. The economics favor us specifically because of what happens after launch: the ongoing hosting, security, and maintenance costs we detailed above compound every month a WordPress site stays live, while a static site's ongoing costs stay close to flat. For a business planning to keep the same site for three-plus years, the total cost of ownership tends to favor the upfront investment. For a business that needs something live in a week and doesn't yet know if it'll still exist in a year, that calculation can look different.
The Broader Industry Shift We're Part Of
We're not the only agency making this move, and it's worth understanding why the shift is happening industry-wide rather than assuming it's a niche preference. The broader category this stack belongs to is often called Jamstack — JavaScript, APIs, and Markup — and it's grown specifically because the web has split into two distinct needs that WordPress tries to serve with one monolithic tool: content that should be as fast and simple as possible to deliver (marketing pages, blog posts, service descriptions), and functionality that genuinely needs a live backend (forms, bookings, authenticated dashboards, payments). Trying to handle both with the same PHP application running on every request is the exact architectural compromise that produces the security, speed, and cost gaps covered throughout this post.
Large publishers, e-commerce platforms, and SaaS companies made this shift years ago for the same underlying reasons — decoupling content delivery from application logic scales better, breaks less, and costs less to run at volume. What's changed more recently is that the tooling has matured enough — Astro, Supabase, and providers like Resend among them — that this architecture is now practical and affordable for a single-location HVAC company or dental practice, not just an enterprise engineering team with a dedicated DevOps staff.
A Practical Framework for Deciding If This Is Right for You
If you're a service business owner trying to figure out where you land on this, a few honest questions tend to surface the answer faster than a generic pros-and-cons list:
- How many people edit your site content, and how often? If it's you or one marketing person updating a blog post occasionally, the WordPress-editor advantage matters less than if you have a content team publishing daily.
- Do you rely on a specific, hard-to-replace WordPress plugin? Certain complex membership systems, niche booking tools, or industry-specific plugins may not have a clean equivalent, and that's a legitimate reason to slow down and scope carefully before migrating.
- Has your site ever been hacked, or do you genuinely not know if it's ever been compromised? If the honest answer is "we're not sure," that uncertainty is itself informative — a properly monitored site shouldn't leave you guessing.
- What's your actual monthly WordPress spend once every plugin subscription and hosting fee is totaled? Most owners underestimate this until they add it up line by line.
- Do you know, with certainty, that every lead form submission this month reached your inbox? If you can't answer that confidently, that alone is worth investigating regardless of what platform you're on.
None of these questions have a universally right answer — they're meant to surface where your specific situation sits, because "should I migrate off WordPress" is a business decision that depends on your content workflow, your current site's condition, and your growth plans, not a one-size-fits-all recommendation.
The Bottom Line
We didn't stop building on WordPress because it's an old platform or because a newer stack is trendier. We stopped because the data on security, speed, cost, and lead reliability all pointed the same direction, year after year, until continuing to build on it stopped making sense for the businesses we serve. A stack where 91% of vulnerabilities live in third-party plugins, where the average site fails Core Web Vitals on mobile, and where lead emails can silently vanish into a spam folder isn't a stack we're willing to hand a client and call it done.
Not sure whether a migration makes sense for your business? Our free audit looks at your current site's security exposure, Core Web Vitals scores, hosting costs, and lead notification reliability, and tells you plainly whether a move off WordPress would actually move the needle — no obligation, no generic sales pitch.
How Valley Can Help
We Help Businesses Like Yours Get More Leads — and Close More of Them
The Valley Marketing Group is a Phoenix-based marketing agency specializing in AI-powered lead generation, paid advertising, and web development for local service businesses.
- Google Ads & paid search — campaigns built to generate qualified leads, not just clicks
- AI phone receptionist — never miss a call or lead while you're on the job
- Website design & development — WordPress, Webflow, Shopify, WooCommerce
- SEO content & local search — rank for the searches your customers are already making