WordPress Hosting

What WordPress actually costs a small business after launch

WordPress runs about 59% of all sites built on a known content management system and roughly 40% of all websites, which is why it is the default answer to almost every website question. The purchase price is not the interesting number. The interesting number is what it asks of you every month after the designer's invoice is paid.

Consider the release record. WordPress 7.0 shipped on 20 May 2026 and had four point releases inside three months, the most recent on 12 August 2026. WordPress.org's own position is that only the most recent release in a series is safe to use and actively maintained. That cadence is not a criticism of the project; it is the shape of the commitment. Somebody has to apply those updates, and somebody has to notice when one breaks a page.

Underneath core sit the themes and plugins, each with its own author, release schedule and likelihood of being abandoned. Underneath those sits PHP, which retires versions on a published timetable whether or not your plugins are ready. The maintenance question is not "will this need work" but "who is doing it, on what schedule, and what happens when an update breaks the homepage on a Friday."

That is the honest framing of the cost. A WordPress site is not a thing you buy. It is a thing you keep, and the keeping is a recurring chore whose schedule is set by other people.

How WordPress sites actually get compromised

The blunt version, supported by the disclosure data: it is almost never WordPress itself.

Patchstack's State of WordPress Security in 2026 counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem during 2025, a 42% increase over the year before. Of those, 91% were in plugins and 9% in themes. Six were in WordPress core, and all six were rated low priority. Core is not the problem. The two thousand lines of somebody's abandoned slider plugin are the problem.

Speed is what makes this dangerous rather than merely untidy. For heavily exploited vulnerabilities, the median time between public disclosure and mass exploitation was five hours, and roughly half of high-impact vulnerabilities were being exploited within twenty-four hours. Attackers scan the entire internet for the vulnerable version string almost immediately. An unpatched site is not "a bit risky." It is a countdown against a clock measured in hours.

Two things people assume will save them mostly do not. Hosting-level security stacks blocked only 12% of known-exploited WordPress vulnerabilities and 26% of exploit attempts overall in that dataset, so a host advertising a firewall is not a substitute for updating. And paid plugins are not safer: 76% of vulnerabilities in premium and freemium components were exploitable in real attacks, and premium components carried around three times more known-exploited vulnerabilities than free ones.

Where the honest reading gets more complicated

Vulnerability counts are not incident counts. Sucuri's most recent full Hacked Website and Malware Threat Report found that 95.5% of infections it cleaned were on WordPress sites, and that 39.1% of the content management systems it found infected were out of date at the point of infection — but only 13.97% of compromised sites still had a known-vulnerable component installed when the cleanup happened.

Those datasets measure different things, and the responsible conclusion sits between them. Many real compromises are never traced to a specific plugin flaw at all: reused and stolen passwords, a hosting control panel that got taken over, and cross-contamination from another infected site on the same shared server are all substantial contributors. Anyone telling you nine out of ten hacks are caused by plugins is repeating a number that does not say what they think it says. What the evidence supports is narrower — outdated software is the largest identifiable factor, and credentials are the other one.

What a compromised site gets used for is worth knowing too, because most owners never notice: spam links injected into your pages and shown only to Googlebot; redirects that fire only for mobile visitors, so the site looks fine on your desktop; mail relayed from your domain, which wrecks your deliverability for months; and card skimmers on checkout pages.

What managed WordPress hosting actually includes

There is no standard definition of "managed WordPress hosting." The term is marketing. In practice a managed plan claims some subset of: automatic core updates and sometimes plugin updates; server-level page caching tuned for WordPress; daily off-server backups with one-click restore; a staging site; WordPress-aware firewalling and malware scanning; and support staff who will look at a WordPress error instead of calling it an application issue.

The way to tell whether a plan is genuinely managed is to read the restrictions rather than the features. Real managed platforms ban things: a blocklist of caching, backup and security plugins that conflict with the platform, no arbitrary scheduled tasks, sometimes no outbound mail from the server. Those restrictions exist because the platform is taking real responsibility for the areas they cover. A plan that promises management and forbids nothing is usually ordinary shared hosting with a one-click installer attached.

The other structural difference is metering. Managed plans are typically sold against a monthly visit allowance — a well-known entry plan permits one site and 25,000 visits a month — while ordinary shared hosting generally is not metered that way. For a brochure site doing a few hundred visits a month that ceiling is irrelevant; it becomes very relevant the month a Facebook post about your restaurant gets shared around the lake. WordPress.org publishes its full release history, which is the cheapest way to audit whether a managed plan is doing the updating it charges for.

Every plugin is permanent surface area

Given that 91% of disclosed vulnerabilities live in plugins, the plugin count effectively is the risk profile. The correct question at install time is not "does this do something useful" but "what happens to this site when the author stops updating it." Some specific habits, and what they cost:

• Installing a plugin for something a theme setting or six lines of code already does. You have traded a one-time task for a permanent dependency with an unknown owner.
• Deactivating plugins instead of deleting them. The files are still on disk and, for a whole class of vulnerabilities, still reachable by direct URL. Delete them.
• Nulled or pirated premium plugins and themes. Free money is the delivery mechanism. The backdoor is the product.
• Keeping an abandoned plugin because it still works. It works right up until its disclosure lands, and then the exploitation window is measured in hours.
• Skipping updates for a year because nothing changed on the site. Nothing changed on the site. Everything changed on the internet.

There is a version of this on almost every five-page site we are asked to look at: a security plugin, a caching plugin, a backup plugin, an SEO plugin, a page builder, a slider and a contact form, each a subscription, a compatibility risk and a future entry in a vulnerability database. Most of those sites would be faster, cheaper and safer with three plugins instead of seven. The full Patchstack report is public if you want to see how the counts break down.

When a Mabank business does not need WordPress at all

This is the section most hosting companies will not write, so here it is plainly. A large share of the small-business sites around Cedar Creek Lake would be better off without WordPress, and we will say so before quoting anything.

If the site is fewer than about ten pages, has no blog and no store, and changes a handful of times a year, it does not need a content management system. A static site has no database, no plugins, no login page and nothing to patch, so the entire section above about compromise simply does not apply to it. It loads faster and costs less to host. For a church office in Kemp, an insurance agent in Gun Barrel City, or a contractor whose site exists to say what he does and how to reach him, that is very often the right answer, and it is the recommendation we give most often.

If nobody at the business is ever going to log in and edit the site, the CMS is pure liability. The entire value of WordPress is self-editing. If the owner is going to email changes to somebody anyway — and most do, after the first month — then all the CMS contributes is an attack surface and a maintenance bill.

If your site already runs on Wix, Squarespace or Shopify and it works, do not move it to WordPress. Those platforms patch themselves, cannot be broken into through an abandoned plugin, and impose no update chore. The honest reasons to leave one are specific: you need something the platform cannot do, you are being priced out, or you want your content portable. "WordPress is better for search rankings" is not one of them, and we will not claim it.

If you sell a handful of items with no inventory tracking, you probably do not need WooCommerce. Square Online or a payment link handles that, and keeps you away from checkout plugins, payment-card exposure, and an entire category of attack that brochure sites never face.

And if you are on a managed WordPress plan for a low-traffic brochure site that already has a human updating it monthly, you are paying twice. Managed hosting earns its premium when it replaces a person. It is a poor purchase when it duplicates one, when you intend to keep running your own caching and backup plugins anyway, or when its headline features are all things your existing host already does.

What a maintenance plan actually consists of

If WordPress genuinely is the right tool — you publish regularly, you have a store, you edit the site yourself, you need a plugin ecosystem for something specific — then the work is repetitive, unglamorous and worth doing on a schedule:

1. Update core, themes and plugins promptly, on a staging copy where the site is complicated enough to justify one, and check the pages most likely to break afterward.
2. Take backups off the server and test a restore, because an untested backup is a belief rather than a backup.
3. Remove what is not in use: deactivated plugins, unused themes, dormant admin accounts.
4. Keep PHP current, deliberately and as its own change, never at the same time as a host move.
5. Enforce credentials. Unique passwords and two-factor authentication on every administrator account, because credential reuse is the failure the vulnerability statistics do not capture.
6. Watch for the quiet symptoms: unexplained new admin users, files modified at hours nobody works, a sudden change in what search engines have indexed for your domain.

None of that is exotic. It is a checklist run on a schedule, and the reason to buy it from somebody is that a checklist nobody runs is worth nothing.