Audit My Site Get Started

Category: By Role

  • How Much Does WordPress Maintenance Cost?

    How Much Does WordPress Maintenance Cost?

    What this guide covers

    1. 01What drives the number.
    2. 02What it means for a site like yours.
    3. 03What to check before you sign.

    The short answer on WordPress maintenance cost

    Website maintenance pricing splits into three bands, and which one applies to you depends on what the site does, not how it looks.

    Personal or brochure site: roughly $0 to $50 a month.

    Some vendor guides put the low end even tighter, $5 to $25 a month, for a site with no ecommerce and no client data.

    Small business site: roughly $35 to $300 a month.

    One published worked example puts a small restaurant site doing basic maintenance, no marketing work included, at about $81 a month.

    Business, membership, or ecommerce site: roughly $150 to $1,000 or more a month.

    Ecommerce sites specifically run $300 to $1,000 or more a month, and at the top end, medium businesses report annual maintenance spend of $12,000 to $30,000 a year, with large or enterprise sites at $30,000 to $50,000 or more a year.

    The three price bands

    Monthly maintenance cost, by what the site does

    Personal or brochure

    $0 to $50 / month

    Small business

    $35 to $300 / month · $81 marker: worked example, small restaurant site

    Business or ecommerce

    $150 to $1,000+ / month

    Bars are scaled against a $0 to $1,000 a month axis. Ranges as stated by vendor pricing pages and agency estimates, not an audited survey.

    Bar chart showing WordPress maintenance cost ranges by site type, from $0 to $50 a month for personal sites up to $150 to $1,000 or more a month for business and ecommerce sites.

    None of those figures come from an audited industry survey. They are the range that repeats across several vendor pricing pages and agency blogs, and this guide treats them as a market pattern, not a fixed rate card.

    The test that matters more than the number itself: ask what a quote excludes, not what it includes. A plan near the bottom of that range and a plan at $140 a month can both say “backups and security.” Only one of them usually says what happens when an update breaks something.

    How WordPress maintenance pricing actually works

    The three ways it gets sold

    The same word, “maintenance,” covers three genuinely different purchases, and comparing across them without noticing is where most confusion starts.

    Per-task or hourly freelancer billing.

    You pay $50 to $150 an hour, or a flat $50 to $300 a month, for someone to apply updates and fix what breaks. Nothing is tested or staged unless that person happens to do it manually, and coverage depends entirely on them being available when you need them.

    Self-serve SaaS tooling.

    Tools like WP Umbrella, ManageWP, and WP Remote put a dashboard in front of you and you approve every change yourself. WP Umbrella, for example, prices its base plan at $2.19 per site a month, with encrypted incremental backups on a daily, weekly, or monthly schedule retained for 50 days, continuous uptime monitoring, and a bulk “Safe Update” feature with automatic rollback if an update fails. Security scanning and hourly backups are separate add-ons at $2 and $2.49 a site a month. These capability claims come from the vendor’s own pricing page, not from independent testing.

    Managed care-plan retainer.

    You pay one flat monthly fee, and a defined process, run by a person or a team, reviews, tests, and responds on your behalf within a stated window. This is what a managed care plan actually does that separates it from the first two options: someone is watching the process, not just running a script.

    What actually moves the price

    Four things separate a cheap plan from an expensive one, and none of them is a marketing word.

    1. 01Backup frequency and retention. Daily versus hourly, and how many days or versions get kept.
    2. 02Whether updates are tested before going live, or just applied and hoped for.
    3. 03Whether there is a stated human response time, in writing, not “we’ll get to it.”
    4. 04What happens when something breaks. Does a rollback exist, is it automatic or manual, and who actually runs it.
    Verify it

    Before you compare two quotes, ask each vendor to answer those four questions in writing. A vendor who cannot answer one of them plainly has told you something too.

    Why this matters for a site that makes you money or holds client data

    A cheap plan with no tested update path is a manageable gap on a site nobody depends on. It stops being manageable once the site is doing real work: taking orders, holding client records, or feeding a paid campaign. An update that breaks checkout on a Friday, with nobody watching for it, is the kind of thing you find out from a customer rather than from a report.

    The counter-case matters just as much. A personal or low-traffic brochure site, run by an owner willing to check in on it periodically, genuinely does not need a premium retainer. Paying for a 4-hour response time on a site that generates no revenue and holds no client data is paying for a guarantee you have no use for.

    What the gap actually costs shows up in more places than uptime. A site nobody is maintaining tends to get slower as plugins pile up unchecked, which is what an unmaintained site costs you in load time even before anything breaks outright.

    What good WordPress maintenance pricing looks like

    A well-specified small business plan, priced in the low hundreds a month, states its backup frequency plainly, says how much work it will take on for you, and includes a monitored uptime check you can point to. A plan under fifty dollars a month, by contrast, often covers only backups and a security scan, with nothing tested before it goes live and no stated response time anywhere in the agreement.

    NoDrama’s own three tiers are one clean illustration of the “what does the price actually include” test, because the differences between them are stated rather than implied:

    Typical sub-$50 plan The Standard
    $129 / month    		 The Higher Standard
    $249 / month    		 The Highest Standard
    $479 / month
    Backups Backups only, frequency often unstated Daily Every 12 hours Every change
    Response if down or hacked No response time stated 4 hours 2 hours 1 hour
    Small jobs at once No job allowance stated One Two Three
    Restore test Restore testing not stated Once a year Twice a year Every 3 months
    Table comparing a typical sub-$50-a-month WordPress plan against NoDrama’s The Standard, The Higher Standard, and The Highest Standard tiers on backup frequency, response time, small jobs at once, and restore testing. The sub-$50 column is a market pattern, not a named competitor.

    Every tier includes the same features. What moves between them is how often the site is backed up, how fast someone responds when it is down or hacked, how many small jobs get worked on at once, and how often a real restore is tested. See the full plan breakdown for what each tier covers in full.

    What to do about it before you sign

    Run any quote you are comparing through the same short list.

    1. 01Ask what is excluded, not what is included. A vendor’s answer to this question is more informative than their feature list.
    2. 02Get backup frequency, retention, and storage location in writing. “Backed up” without a number attached means nothing.
    3. 03Get the response time, and how much work is included, in writing. “We’ll get to it” is not a commitment.
    4. 04Confirm whether updates are tested before going live. And what happens if a test fails.
    5. 05Check the agreement itself. A quote is a price. An agreement states what a real maintenance agreement has to specify, including what happens when something goes wrong.

    Not sure what your current setup actually covers?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    Common misconceptions about WordPress maintenance cost

    “More expensive always means safer.”

    This does not hold up on the numbers. WP Umbrella delivers automated backups, uptime monitoring, and automatic rollback for $2.19 a site a month, far below Codeable’s Basic retainer at $140 a month, which adds one human developer hour alongside similar automated coverage. The price gap is mostly the human time and the response commitment, not the underlying automated feature set.

    “A free security plugin is basically a maintenance plan.”

    It usually covers scanning only. It does not test an update before it goes live, does not verify that a backup actually restores, and does nothing when something breaks.

    “My host’s backups have this covered.”

    Hosting price and maintenance price are separate line items. A host-level backup is not the same as a tested, verified restore process, and a cheap plan built around that assumption is usually the one that skips the risk that matters most.

    What this does not solve

    No figure in this guide comes from an audited industry survey. Every number is a vendor’s own stated price or a market estimate from an agency blog, and several of the tool prices quoted here are vendors pricing their own product. This guide names that plainly rather than implying an authority that does not exist.

    This guide also does not tell you which plan a specific site needs. That depends on traffic, how much revenue the site is exposed to, and how much downtime the business can absorb, none of which a pricing table can answer. That is what an audit is for, not a price comparison.

    So, what should WordPress maintenance actually cost you?

    The number itself means little without knowing what it excludes. The honest comparison across any two quotes is backup frequency, whether updates are tested before going live, and whether there is a stated response time, not the headline price on its own. A five dollar plan and a five hundred dollar plan can both be correct choices, for different sites, and the way to tell them apart is the list above, not the invoice.

  • What Are the Security Risks of WordPress?

    What Are the Security Risks of WordPress?

    Contents

    1. 01Understand where the risk actually sits. The short answer, and how it actually works.
    2. 02See why it matters for your site. Why it matters for your situation, and what good security discipline looks like.
    3. 03Know what to do and what still isn’t covered. What to do about it, and the common misconceptions.

    The short answer on WordPress security risks

    Of 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, 91 percent were found in plugins, 9 percent in themes, and only 6 low-priority issues were in core, per Patchstack’s 2026 State of WordPress Security whitepaper. That split is not close. Core’s share is statistically negligible against plugins alone.

    The direct implication follows from the numbers, not from opinion: WordPress the platform is not where the risk sits. The unaudited third-party code running on top of it, chosen and installed by whoever manages the site, is.

    How WordPress security risk actually works

    Why plugins and themes carry the risk core does not

    Core ships from a single, reviewed codebase. It’s maintained by a security team of more than 50 people who backport fixes to older versions rather than forcing every site onto the newest release to stay patched, per the WordPress Security Team’s own review process.

    A plugin or theme is a different situation entirely. It’s an independently authored package, written by a separate developer of whatever skill level they happen to have. WordPress.org’s directory review checks a plugin at submission, but it doesn’t continuously re-audit every version update that ships after that. A plugin that passed review in 2022 can ship a vulnerable update in 2026 with no equivalent second check.

    This is also where the cost math changes. Verified, tested updates catch the failure mode where a legitimate patch breaks something on the live site, which is a different problem from a plugin’s own code carrying a vulnerability in the first place. See what tested, verified updates actually cost to have covered for how that piece works.

    Verify it

    For any plugin you’re evaluating, check whether it names a security team or a documented disclosure process on its own listing page. A plugin with neither has no equivalent of core’s review process behind it.

    The four vulnerability classes behind nearly all plugin and theme issues

    Nearly all of the 91 percent plugin figure and the 9 percent theme figure comes down to four recurring mechanisms, as WordPress’s own definitions of these vulnerability classes lay out.

    SQL injection

    Unsanitized input gets run as a database command instead of passed through a prepared statement.

    Cross-site scripting (XSS)

    Unescaped output lets attacker-supplied JavaScript run in a visitor’s or an admin’s browser.

    Cross-site request forgery (CSRF)

    A state-changing action fires using a logged-in admin’s own session, because the plugin skipped its nonce check.

    Broken access control

    A user reaches an action or a piece of data that should have required a higher capability level.

    Four cards covering SQL injection, XSS, CSRF, and broken access control, each with a one-line description of how it occurs.

    A nonce, in WordPress’s own terminology, is a Number Used Once. It’s the mechanism a plugin is supposed to check before it lets a state-changing action run, and a missing nonce check is what turns a normal admin action into a CSRF opening.

    Verify it

    For a specific plugin, check its own changelog for language like “sanitization,” “escaping,” or “capability check” fixes. That’s usually the tell that one of these four classes got patched in that release.

    Why this matters for a site you are responsible for

    An outdated plugin isn’t a slow decay. It’s a published map. Once a vulnerability is disclosed along with its fix, any site still running the unpatched version becomes identifiable by version fingerprinting and targetable at scale by automated tools, per WordPress’s own hardening guidance, which states plainly that the exploit information for a disclosed vulnerability is almost certainly in the public domain once the fix ships.

    An inactive plugin doesn’t remove that exposure. Its files still execute if they’re present on the server and registered, deactivation just stops the plugin from loading on the front end, it doesn’t delete the code. If you’re not using a plugin, delete it rather than deactivating it and leaving it there.

    The same logic that connects an unmaintained site to slow performance connects it to exploitability: both come from code nobody is watching. See why an unmaintained site slows down the same way it gets exploited for how that overlaps.

    What good security discipline actually looks like

    Running fewer, well-maintained plugins from established developers who patch quickly is a real, measurable reduction in risk. Risk scales with how many separate third-party codebases a site is running, not with running WordPress itself.

    Severity is the other variable worth watching directly. A high-severity vulnerability, 17 percent of 2025’s total per Patchstack, is associated with likely mass-scale, automated exploitation. That’s the practical test for how urgently a given patch matters: a plugin that’s unmaintained, has a large install base, and handles user input or authentication is high-risk regardless of how small it feels in your own stack.

    See what a maintenance plan should actually include for how that discipline gets specified rather than assumed.

    What to do about it

    1. 01Delete plugins you’re not using. Deactivating leaves the files on the server, where they still execute if registered.
    2. 02Check whether a plugin’s developer is still actively patching it. An abandoned plugin stays exploitable no matter how quickly you’d apply an update if one existed.
    3. 03Apply security updates on a defined schedule. Not whenever someone happens to remember.
    4. 04Confirm updates are tested in staging before they go live. A legitimate security patch can still break site functionality when applied blind, which is a different failure than the vulnerability it patches, and both need a fix.

    Not sure how many plugins on your site are still actively maintained?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    Verify it

    After any update, confirm the site still renders and the admin dashboard still loads before considering the patch applied. A rollback path only helps if someone checks that it worked.

    Common misconceptions about WordPress security

    “WordPress itself is insecure.”

    Core’s share of 2025’s disclosed vulnerabilities was 6 low-priority issues, statistically negligible against plugins’ 91 percent. The platform isn’t the risk. The unaudited third-party code running on top of it is.

    “A security plugin covers this.”

    A security plugin helps with detection and hardening, but it doesn’t patch a vulnerable plugin’s own code. That code stays vulnerable until its own developer ships a fix, or a virtual-patching rule addresses it in the meantime.

    “Popular plugins are safer.”

    Popularity increases how worthwhile a plugin is to build an automated attack against. It doesn’t guarantee the code was reviewed for the four vulnerability classes above.

    Getting this in writing matters as much as getting it right in practice. See what a maintenance plan should actually specify about updates for the language that closes that gap.

    What this does not solve

    Tested updates and staged rollback catch the case where a legitimate patch breaks something. They don’t find an undisclosed, zero-day vulnerability, and they’re not a substitute for a web application firewall or real-time malware scanning.

    This guide isn’t a claim that any specific site is, or isn’t, currently compromised.

    So, what are the real security risks of running WordPress?

    The risk sits in the plugins and themes running on top of core, not in core itself, and it concentrates further in whatever is outdated, abandoned, or simply numerous. Fewer, actively maintained third-party codebases is the practical lever, not switching platforms.

  • Why Is My WordPress Site So Slow?

    Why Is My WordPress Site So Slow?

    Contents

    1. 01Work out which layer is slow. What “slow” actually means, and confirming where the time is going.
    2. 02Fix the layer that is actually slow. The three ways to fix it, from easiest to most manual.
    3. 03Confirm it is held and stop it from recurring. Verify the fix, troubleshoot the remaining edge cases, and keep it from coming back.

    What “slow” actually means for a WordPress site

    Slow is a number, not a feeling. Two numbers, in fact: time to first byte, the gap between the browser asking for the page and the server sending back the first byte of a response, and render time, how long the browser then takes to paint and settle the page a visitor actually sees.

    Google measures both through Core Web Vitals, assessed at the 75th percentile of real visits so one fast or slow load does not skew the picture. Largest Contentful Paint (LCP), the render time of the largest image or text block in the viewport, is good at 2,500 milliseconds or under. Interaction to Next Paint (INP), how quickly the page responds to a visitor’s interactions across the whole visit, is good at 200 milliseconds or under. Cumulative Layout Shift (CLS), the sum of unexpected layout shifts as the page loads, is good at 0.1 or under.

    Server response (TTFB)

    Hosting, plugins running on every request, and database queries.

    Above ~600 to 800ms flags a server-side problem

    Page weight

    Full-size images and the theme’s full CSS and JavaScript bundle.

    LCP good at 2,500ms or under

    Browser rendering

    Render-blocking scripts, stylesheets, and third-party embeds.

    INP good at 200ms or under, CLS at 0.1 or under

    All three vitals are measured at the 75th percentile of real visits. These are Google’s general Core Web Vitals thresholds, not WordPress-specific ones.

    A slow WordPress site usually comes from one of three places:

    Server-side load.

    The hosting environment, an overloaded database, or plugins that run heavier queries than they need to.

    Unoptimized front-end weight.

    Full-size images, render-blocking scripts and stylesheets, or a theme that loads its entire CSS and JS bundle regardless of what the page uses.

    No caching layer.

    Every visit reprocesses the same PHP and database work from scratch instead of serving a version already built.

    Which one applies to your site is not a guess. It is the next step.

    Confirm where the time is actually going

    Run a PageSpeed Insights check, or look at the field-data Core Web Vitals for the page, before you change anything. That gives you a TTFB number and a render-time picture to compare against once you have made a change.

    If TTFB alone is high, roughly above 600 to 800 milliseconds before any content starts, the problem is server-side: the hosting environment, the plugins running on every request, or the database being asked the same questions too many times.

    If TTFB looks fine but the page still finishes rendering slowly, the problem sits in the front end: images, render-blocking CSS or JavaScript, or third-party scripts like chat widgets, ad tags or web fonts loading synchronously.

    Verify it

    Write down the specific number, TTFB, and the Core Web Vitals reading before you touch anything. That is the only way to confirm a fix actually moved it rather than assuming it did.

    Fix it

    Option 1, easiest, recommended: page caching plus image compression

    A page cache stores the fully rendered HTML after the first PHP and database cycle runs, then serves that stored copy on repeat requests instead of running PHP and the database again. Paired with image compression, this catches the two most common causes on a typical site: repeat-visit server load and oversized static assets.

    What it misses matters as much as what it catches. A page cache does not cover logged-in visitors, cart or account pages, or any URL with a query string, all excluded from caching by design because that content is meant to be dynamic. If your slow pages are the ones a logged-in user or a shopper sees, caching alone will not touch them.

    This is also the baseline a maintenance plan should already be checking as part of ongoing upkeep, not a one-time install and forget.

    Verify it

    Re-check the TTFB and Core Web Vitals numbers from the section above, on the same page, after the cache has had time to build.

    Option 2, done for you: a CDN plus performance work as part of a managed plan

    A content delivery network (CDN) serves cacheable static assets, images, CSS, JavaScript, from an edge node physically closer to the visitor, and keeps a pre-warmed connection open to the origin server. The first request for a given asset is an origin pull, fetched from your server and cached at the edge. Every request after that is served from the edge until the cache expires.

    What a CDN cannot do is speed up PHP execution, database queries, or anything generated dynamically at the origin server on every request. If the slowness is server-side, a CDN sits on top of the problem without reaching it.

    Caching plugin CDN
    Logged-in pages Not cached Not cached
    Cart or account pages Not cached Not cached
    Static assets (images, CSS, JS) Cached at origin Cached at edge, closer to visitor
    Dynamic HTML (PHP, database output) Not touched Not touched
    Table comparing what a caching plugin and a CDN each cover, showing both miss logged-in pages and cart pages, and neither speeds up dynamic HTML.

    See how the CDN and performance work is scoped as part of a managed plan, since CDN allocation and the performance work around it are handled as ongoing configuration rather than a one-time setting.

    Verify it

    Confirm the origin pull happened (the first load of an asset after a change) and that the second load of the same asset comes from the edge, then re-check TTFB against the number you noted earlier.

    Option 3, manual: clean the database and audit plugins one at a time

    Post revisions, spam comments, expired transients, and orphaned tables accumulate in the WordPress database over time and are not purged automatically. Every uncached query against a bloated database takes measurably longer than the same query against a clean one.

    Deactivating plugins one at a time is a reasonable way to find an obvious offender, a single plugin running an expensive query on every page load. It is the longest path of the three, and it will still miss the cumulative database bloat, image weight, and theme bloat that no single plugin caused on its own.

    Verify it

    After cleaning the database or deactivating a plugin, re-run the same TTFB check and confirm the number moved before assuming the change worked.

    Verify the fix actually worked

    Re-run the same check you used to note the original number on the same page, cold. Not immediately after clearing a cache, since the first load after a cache clear rebuilds the cache and will look artificially slow. Compare the new TTFB and Core Web Vitals reading against the number you wrote down at the start. If it has not moved, the fix touched the wrong layer.

    Troubleshoot

    The site is fast on desktop but slow on mobile.

    Mobile and desktop Core Web Vitals are measured and reported separately. A fix that improves desktop LCP or INP does not automatically carry over to mobile field data. Check the mobile-specific numbers directly rather than assuming a desktop result applies.

    I installed a CDN, and nothing changed.

    This is the direct symptom of a server-side bottleneck a CDN cannot reach. A CDN only speeds up cacheable static assets served from the edge. If TTFB was already the problem, adding a CDN leaves it untouched. Re-check TTFB specifically rather than the overall load time.

    It’s fast for me but slow for everyone else.

    You are likely viewing a warmed, cached, or logged-in version of the page that a first-time or logged-out visitor does not get. Check the page from a logged-out session, ideally on a different network, before concluding the fix worked for everyone.

    Prevent it recurring

    Run the same diagnostic monthly, not just after a complaint. A monthly health report that tracks TTFB and Core Web Vitals over time catches drift before it becomes a complaint, which is what a monthly health report actually tracks as part of ongoing maintenance.

    Not sure which layer is slowing your site down?

    Send NoDrama your URL and get a free website audit, no pitch attached.

    Audit My Site

    What this does not solve

    The diagnostic above finds and addresses the common causes: server load, page weight and missing caching. It does not replace hosting that is genuinely undersized for a high-traffic site, where the fix is a hosting change, not a configuration one. It also does not audit custom code written specifically for your site, since that requires a developer familiar with the codebase, not a maintenance diagnostic.

    Google has publicly confirmed that page speed is a ranking signal. This piece does not quote a specific figure for how much it weighs, because no verifiable figure exists to quote.

    Unmaintained plugins that slow a site down are often the same plugins carrying real security exposure, so a speed audit and a security review usually turn up the same list.

    So, why is your WordPress site actually slow?

    It comes down to one of three layers: server response time, page weight, or browser rendering, and the fix depends on which one the diagnostic points to. Check TTFB first. A high number means the problem is server-side. A fine TTFB with a slow finish means the problem is in what the browser has to load and render. Fix the layer the numbers point to, not the layer that is easiest to buy a plugin for, and re-check the same numbers afterward to confirm it held.

  • How to Speed Up a WordPress Site

    How to Speed Up a WordPress Site

    The short answer

    There are seven usual suspects: slow server response, no caching, unoptimized images, a missing or misconfigured CDN, plugin or theme bloat, database bloat, and render-blocking code. None of them has a single fix that covers all seven, and treating one symptom (a slow load) as if it always has one cause is the mistake most speed advice makes.

    Server

    Slow origin response time before anything else runs.

    Caching

    No page cache, no object cache, or a cache that isn’t being hit.

    Images

    Uncompressed, oversized, or lazy-loaded above the fold.

    CDN

    Missing entirely, or configured so static files never hit the edge.

    Plugins and theme

    Queries, CSS and JavaScript added to pages that don’t use the feature.

    Database

    Revisions, expired transients and orphaned metadata piling up.

    Render-blocking code

    CSS and JavaScript that delays the first paint of the page.

    Seven possible causes of a slow WordPress site: a map of possibilities, not a priority order. The order to check them in lives in “What to do about it” below.

    The order to check them in matters more than any individual tactic. Server response and caching come first, because a slow origin server undermines everything built on top of it. Images and the CDN come next, since they’re the most visible cause on a typical page. Plugin and database cleanup come last, because they take the most care to do safely. How the speed work gets scoped breaks down what a structured pass through all seven actually looks like.

    How it actually works

    Caching, images, and the CDN

    Full-page caching serves a static, pre-built copy of a page to a visitor instead of running PHP and querying the database on every request. Object caching goes a layer deeper: it stores the results of expensive database queries so the same query doesn’t run twice. Browser caching stores static assets like CSS and images directly on the visitor’s device so a repeat visit doesn’t re-download them. Each of these solves a different part of the problem, and none of them fixes a query or a page that was slow to begin with. As Jetpack puts it, caching will hide performance issues, but it will not fix the root cause.

    Images are the biggest lever most sites have, and also where the most common piece of advice backfires. Lazy loading defers loading an image until it’s about to scroll into view, which is useful for images far down the page. Applied indiscriminately, including to the image at the top of the page, it’s measurably worse: web.dev’s own A/B test found that lazy-loading above-the-fold images made archive pages 13 to 15 percent slower on both desktop and mobile. That’s specifically because the largest above-the-fold image is usually the LCP element, the one Core Web Vitals is timing, and delaying it delays the whole measurement. WordPress core now recognizes this and doesn’t lazy-load the first featured or content image on a page for that reason.

    A CDN caches static content, images, CSS, JavaScript, at edge locations closer to the visitor, so a request travels a shorter physical distance. Cloudflare’s own illustrative figures put a request from Atlanta at roughly 1,100 milliseconds and the same request from Singapore at roughly 3,000 milliseconds without a nearby edge location, a reduction of about 63 percent with one, though that’s a directional example rather than a guarantee for any specific site. What a CDN can’t do is speed up PHP execution or a slow database query. It moves static files closer to the visitor. It doesn’t touch what happens on the origin server before those files are generated.

    Verify it

    After each change, run a Core Web Vitals check rather than trusting that the change worked. A caching or CDN change that looks right in the plugin settings can still leave LCP, INP or CLS unchanged if the actual bottleneck was somewhere else.

    Plugins and the database

    Every active plugin can add its own database queries, CSS and JavaScript to a page load, whether or not that plugin’s feature is actually being used on that page. There’s no verified number for how many plugins is too many. Any specific count offered as a safe threshold isn’t backed by a real source, so treat it as noise.

    Database bloat builds up the same way: post revisions, expired transients and orphaned metadata from removed plugins accumulate in the database and slow down the queries that run on every page load. Cleaning it up means removing rows and rebuilding indexes, and a backup before either of those steps isn’t optional. Plugin and theme updates are also a common, overlooked cause of a sudden slowdown: an update can silently change caching behavior or add a heavy new dependency, which is exactly what the update process that catches a plugin-caused slowdown is built to catch before it ships to the live site.

    Verify it

    After a database cleanup or a plugin change, re-run the Core Web Vitals check and confirm the backup taken beforehand actually restores, not just that it exists.

    Why it matters for a business site

    Google’s own documentation is more measured than most speed advice suggests. Google Search Central states plainly that Core Web Vitals are used by its ranking systems, and in the same breath that Google Search always seeks to show the most relevant content, even if the page experience is sub-par. Speed is a factor. It isn’t the only one, and a faster page that’s less relevant to the search still loses to a slower, more relevant one.

    For a small, low-traffic brochure site, a caching plugin plus a free CDN tier can genuinely be enough. The honest gap a managed service closes isn’t the initial setup, it’s what happens in the months after: a plugin update that silently disables the cache, an unoptimized image uploaded straight from a phone, or database bloat that nobody’s watching build up. None of those show up the day they happen. They show up as a slow site three months later with no obvious cause.

    What good looks like

    The benchmark is Core Web Vitals, measured at the 75th percentile and split by mobile and desktop, not a single load-time number:

    Metric Threshold for “good”
    Largest Contentful Paint (LCP) 2.5 seconds or less
    Interaction to Next Paint (INP) 200 milliseconds or less
    Cumulative Layout Shift (CLS) 0.1 or less
    Thresholds are measured at the 75th percentile, split by mobile and desktop.

    An update is one of the most common causes of a site suddenly missing one of these three, which is why testing an update before it goes live, and having a rollback if it breaks something, ties directly back to speed rather than being a separate concern. The ongoing maintenance routine that speed work depends on covers more than the update itself.

    What to do about it

    Work through these in order rather than picking the one that sounds most familiar:

    1. 01Check server response time first. If the origin server itself is slow, caching and a CDN only mask the problem for cached pages and do nothing for anything dynamic.
    2. 02Add page caching. A full-page cache serves a static copy instead of rebuilding the page on every request, which is the change most likely to matter on most sites.
    3. 03Fix above-the-fold lazy loading. Make sure the first visible image, usually the LCP element, loads eagerly rather than lazily. Reserve lazy loading for images further down the page.
    4. 04Compress and correctly size images. An oversized or uncompressed image is one of the most common reasons LCP misses the 2.5 second threshold.
    5. 05Clean up database bloat, with a backup first. Remove stale revisions, expired transients and orphaned metadata, and confirm the backup restores before making any changes.

    Every NoDrama plan includes page and browser caching, image compression and conversion, and real visitor speed data each month. Every plan gets the same global CDN. What differs is backup cadence: daily on The Standard, every 12 hours on The Higher Standard, and on every change on The Highest Standard. What’s included at each plan level has the full breakdown.

    Verify it

    After working through the list, re-run the Core Web Vitals check and compare it to the thresholds above rather than to how the site feels.

    Common misconceptions

    “Lazy-load every image.”

    Wrong for the LCP element specifically. web.dev’s own test showed lazy-loading above-the-fold images made archive pages 13 to 15 percent slower. Lazy-load what’s below the fold, not what’s above it.

    “Page speed is a major ranking factor, full stop.”

    Google’s own position is narrower than that. Core Web Vitals feed the ranking systems, but Google states directly that it still favors the more relevant page even when its page experience is worse.

    “A CDN fixes a slow site.”

    A CDN moves static content closer to the visitor. It does nothing for a slow database query or an unoptimized PHP process on the origin server, so a slow origin stays slow behind a CDN.

    What this does not solve

    None of the above fixes under-provisioned hosting. If the server itself doesn’t have the resources for the site’s traffic, caching and a CDN reduce how often that limit gets hit, but they don’t raise the limit. The same goes for a badly written theme: code that runs unnecessary queries or ships excessive CSS and JavaScript stays slow no matter how well everything around it is tuned. A full care plan covers the parts of ongoing WordPress operation that sit outside performance work specifically.

    Is my WordPress site actually slow, and what’s the fix?

    A slow WordPress site is almost always more than one problem at once: server response, caching, images, the CDN, plugins, the database and render-blocking code all contribute, and there’s no single fix that covers all seven. The honest way to check is Core Web Vitals at the 75th percentile, LCP at 2.5 seconds or under, INP at 200 milliseconds or under and CLS at 0.1 or under, worked through server response and caching first, then images and the CDN, then plugin and database cleanup, verifying with a fresh Core Web Vitals check after each step.

  • The WordPress Maintenance Checklist

    The WordPress Maintenance Checklist

    Get the checklist

    Copy this into a doc, a spreadsheet or a project board. It is ordered by cadence, not by importance, because a task that runs continuously and a task that runs monthly are both required, just not on the same day.

    WordPress maintenance checklist

    • Uptime monitoringContinuous
    • BackupsDaily to weekly, scaled to activity
    • Update review, core, plugins and themesWeekly
    • Security scanning and hardeningOngoing
    • Performance checkMonthly
    • Database and log cleanupMonthly

    Each line names the task and the cadence only. The next section covers what “correctly” means for each one, because a task run on schedule but run wrong is not much better than a task skipped.

    If the list above is more than you want to track by hand, see which parts of it NoDrama’s plans cover.

    Run each task correctly

    Updates, staged and tested

    A WordPress core update is not a single event on a single day. WordPress’s 2026 release schedule runs three major releases roughly four months apart, and plugins and themes ship on their own separate schedules on top of that. WordPress’s built-in auto-update system, introduced in WordPress 5.5, checks for available plugin and theme updates twice a day by default.

    That default check is not the same as a safe default rollout. WordPress’s own documentation on plugin and theme auto-updates says plainly that you may want to make sure you can roll back to a previous version before enabling them. The correct sequence is staging first, live push second, rollback held ready as the fallback if the live push still breaks something the staging test missed.

    The update pipeline

    Staging test
    The update installs on a clone first. Key pages and forms checked there.

    →

    Live push
    Passed on staging. The same update goes to production.

    →

    Rollback if needed
    The fallback path when the live push breaks something staging missed.

    Rollback is a fallback path that depends on a recent backup existing, not an automatic or instant recovery.

    Flow diagram of a WordPress update tested on staging before it goes live, with rollback as the fallback.
    Verify it

    After any update goes live, confirm the site’s key pages and forms still load and submit correctly. A staging test that passed is not the same evidence as a live push that held.

    Backups, matched to how often the site changes

    WordPress.org’s own backup guidance sets the cadence by activity rather than by a flat weekly rule for every site: once a week for smaller sites with fewer posts, daily for high-activity sites with a lot of posts.

    A backup has to cover both halves of the site to be useful. WordPress.org is direct about this: you need both the database and the files to fully restore a typical WordPress site, not one or the other. Keep 3 to 5 recent backups stored across at least two locations, so a single storage failure does not take out the only copy.

    Verify it

    Actually restore from a backup at least once, on a staging copy, rather than trusting that the backup file exists. A backup nobody has restored is a backup nobody has tested.

    Security scanning and hardening

    A security scan checks the site’s installed core, plugins and themes against databases of known, disclosed vulnerabilities. That is useful and it is also limited: a scan catches what has already been found and published. It does not catch a zero-day, a misconfigured server, or a weak password, because none of those show up in a vulnerability database.

    Hardening is a separate layer that sits alongside scanning rather than replacing it: correct file permissions, disabling the in-dashboard file editor, and protecting wp-config.php from being read directly.

    Verify it

    Confirm the scan actually ran and produced a dated result, and confirm hardening settings held after the last update. Some updates reset file permissions or reactivate a setting the update assumed was default.

    Uptime monitoring

    Uptime monitoring answers one question continuously: is the site responding right now. It does not answer why the site is down, and it does not catch a site that returns a page but is broken in a way that does not trip a downtime alert, a checkout that loads but will not process a card, for instance.

    Verify it

    Confirm the monitoring alert path itself still works by triggering a test alert periodically, so the first real outage is not also the first time anyone finds out the alert never fires.

    Performance and database cleanup

    A monthly performance check catches drift before it becomes a pattern: the same page that loaded fine last month, loading slower this month because of an accumulation of plugins, images or database bloat. It’s the comparison against last month’s result, not a single reading, that reveals the drift.

    Database cleanup removes what accumulates in the background and nobody deletes on purpose: old post revisions, expired transients, spam comments and orphaned metadata left behind by deactivated plugins. Left alone, these slow database queries and inflate the size of every backup that follows. Take a fresh backup before running any cleanup, since a cleanup tool that deletes the wrong table row is not something you want to discover without a way back.

    Verify it

    Confirm the site still loads and functions correctly after cleanup, the same way you would after an update.

    What reviewers and auditors actually check

    Anyone reviewing whether this routine actually ran, an auditor, an insurer, a new hire taking over the site, checks for evidence rather than intent. That means:

    • What updated, and when, with a dated log rather than a memory of “we keep it current”.
    • Whether the last backup completed and whether it has ever been restored, not just whether a backup file exists.
    • What the last security scan found, and whether anything flagged was addressed.
    • Uptime over the review period, as a record rather than an impression.

    A routine that ran but left no trace is indistinguishable, to a reviewer, from a routine that never ran.

    What this checklist does not cover

    This checklist covers the recurring maintenance work. It is not a security incident response plan for something that has already gone wrong, it is not a compliance program for a specific regulatory standard, and it is not a full site rebuild. Those sit on the other side of a boundary this checklist does not try to cover.

    Where teams get this wrong

    The same three mistakes show up across sites of every size.

    A security plugin gets installed once and never checked again.

    Installing a scanner is a decision made on one day. Reading its findings is a habit, and the habit is the part that lapses.

    Auto-updates get switched on with no backup and no rollback path behind them.

    The update mechanism runs on schedule either way. Whether a bad update costs an afternoon or costs nothing depends entirely on whether a rollback exists to fall back on.

    A one-off backup gets mistaken for a routine.

    Someone took a backup before a big change six months ago, and the site has changed a dozen times since then without another one.

    NoDrama’s plans cover the core of this list on every tier: updates kept current, off-site backups daily or more often, malware scans every 12 hours, uptime checked every minute, and real visitor speed data each month. Database cleanup is not part of the plans. See what every plan includes.

    Conclusion

    A WordPress maintenance routine is six jobs on six different clocks: updates tested before they go live, backups matched to how often the site changes, security scanning paired with hardening, continuous uptime monitoring, a monthly performance check, and regular database cleanup. Running any one of them on the wrong cadence, or running them without a way to verify they held, is how a routine task turns into a surprise.

  • What Is a WordPress Care Plan?

    What Is a WordPress Care Plan?

    The mechanism

    Before shot
    Key pages photographed before the update runs.

    →

    Update and compare
    The update runs on the live site. The same pages are photographed again and compared.

    →

    Put back
    Anything that changed or broke goes back to the last working version.

    Before-and-after checks and rollback are common across providers, not unique to NoDrama.

    A WordPress update checked with before-and-after screenshots of key pages, and put back if anything breaks.

    The short answer

    A WordPress care plan is a recurring, paid service in which a provider takes over the ongoing work a live WordPress site needs once it’s launched: keeping the software current, backing the site up, watching for security issues, and picking up when it goes down. Nobody owns a fixed definition of the category, so what’s actually inside a given plan depends on the provider selling it.

    The pieces that recur across the market are: core, plugin and theme updates tested before they go live, backups on a schedule with a real restore path, a scan-and-response loop for security, uptime monitoring, and some bounded amount of human support. A CDN or performance layer is common but not universal to the category. That last part matters if you’re comparing providers on price alone, because a plan without a CDN isn’t necessarily a worse plan, it may just be a narrower one. This is how NoDrama runs the maintenance side specifically, one version of the bundle rather than the only one.

    How it actually works

    The update pipeline

    The mechanism that separates a working care plan from a plugin subscription is how an update gets checked. A care plan photographs the key pages before an update runs, runs it, photographs them again and compares, and puts it back if something broke.

    WordPress treats update urgency seriously at the platform level too. When WordPress 7.0.4 shipped as a security release, the release notes said it is recommended that sites update immediately, and that sites supporting automatic background updates would begin updating shortly on their own. That’s useful, and it’s also incomplete on its own: automatic updates close the exposure window, but they don’t check what the update did to a specific site’s plugin and theme combination. That’s the gap a before-and-after check closes.

    Verify it

    After any update goes live, confirm the site’s actual pages still load and function. Confirming the update installed is not the same check.

    Backups, security, and uptime

    Three separate systems get lumped under “security” on most sales pages, and they do different jobs.

    Backups

    Only as good as three properties: how often it runs, how many restore points exist, and whether the restore has actually been exercised.

    Security

    A scan-and-response loop, not a one-time hardening pass followed by silence. A scanner nobody reads is a cost, not a control.

    Uptime

    Detects that the site did not respond inside a check window. It flags that something needs a look, it does not diagnose what’s wrong.

    Each of these only counts if it runs as an ongoing process rather than a one-time setup step, and the plan worth paying for is the one that keeps running it.

    Why it matters for a live business site

    Whether any of this is worth paying for comes down to two questions: what it would cost the business if the site broke or went dark for a period, and whether anyone will actually run the schedule themselves.

    A brochure site with no forms, no checkout and no compliance obligation, run by an owner who genuinely follows a backup-and-update routine, doesn’t need a paid plan to stay fine. That’s a reasonable place to stop reading and keep doing what you’re doing.

    A revenue-generating or reputation-critical site is a different calculation. An update that breaks checkout, or a stretch of days where nobody notices the site is down, costs more than the plan would have. The failure mode that most often pushes an owner from DIY to a paid plan isn’t one dramatic event. It’s a freelancer who built the site going quiet, or a schedule that got followed for the first few months and then quietly stopped.

    What good looks like

    A care plan worth paying for shows three things: updates tested off the live site rather than pushed straight to production, a restore that has actually been run at least once rather than assumed to work, and a monthly record showing this happened in a given period.

    Vendor pricing guides put the market for this category roughly between $100 and $500 a month, with brochure sites at the low end and ecommerce sites at the high end. That’s a market range from vendor pricing pages, not a NoDrama figure, and it’s worth treating as a rough band rather than a quote. What a maintenance retainer actually covers varies by provider inside that range, which is why the bundle matters more than the number on its own.

    Plan Price Backups Response if down or hacked Small jobs at once Restore test
    The Standard $129/month Daily 4 hours One Once a year
    The Higher Standard $249/month Every 12 hours 2 hours Two Twice a year
    The Highest Standard $479/month Every change 1 hour Three Every 3 months
    NoDrama’s The Standard, The Higher Standard and The Highest Standard plans compared by backup frequency, response time, small jobs at once and restore testing.

    What to do about it

    Before signing anything, ask the provider these questions and check the answers against what the sticker price implies.

    • Are updates tested somewhere other than the live site before they ship?
    • When was the backup last actually restored, not just taken?
    • What does a security scan alert lead to, and who reads it?
    • What does the monthly report actually show?
    • What’s excluded at this price, not just what’s listed?
    • If a CDN is included, what size, and does that matter for this site’s traffic?

    NoDrama’s care plans lay out exactly what’s tested, backed up, and watched every month. See the three plans and what each one covers.

    Common misconceptions

    “I installed a backup plugin and a security plugin, so I’m covered.”

    A plugin is software installed once. A care plan is an operating process: someone confirms the backup restores, and someone reads the scan alert and decides what to do about it. The software doesn’t run itself.

    “Auto-updates handle this.”

    Automatic updates shrink the window a known vulnerability is exposed for, which matters. They don’t check what the update did to a specific site’s combination of plugins and theme. That’s the gap a before-and-after check closes.

    “The $30 plan and the $1,000 plan are basically the same thing with a different price tag.”

    Not reliably. One vendor’s account of the market puts plans priced around $30 to $50 a month as commonly running with no staging environment testing at all. A plan at that price is closer to an auto-update setting with a subscription fee than to the update pipeline described above.

    What a care plan does not solve

    A care plan keeps a site running the way it was built. It doesn’t fix a site that was built badly in the first place, and it isn’t a substitute for development work when a site needs new functionality or a redesign.

    A CDN, where a plan includes one, cuts load time for static assets like images and scripts. It doesn’t fix a slow database query, bloated code, or a plugin conflict, which is the separate speed work a CDN does not replace.

    Is a WordPress care plan worth it for my site

    A WordPress care plan is worth paying for once a site’s downtime or a broken update would cost more than the monthly fee, and once nobody in the business will reliably run updates, backups and monitoring on a schedule themselves. The category has no fixed bundle, so the question worth asking of any provider is whether updates get tested before they go live, whether a restore has actually been exercised, and whether a monthly record proves any of it happened. Where a site is low-traffic, low-risk, and someone will genuinely follow the schedule, DIY is a reasonable answer. Where it isn’t, the bundle matters more than the sticker price.

  • Is WordPress Secure? The Honest Answer

    Is WordPress Secure? The Honest Answer

    The short answer

    Core is not where the risk lives.

    Patchstack tracks WordPress vulnerabilities two ways, and the two numbers don’t match:

    • Patchstack’s live database: 20 core vulnerabilities out of 11,259 tracked in 2025. That is 0% of the total.
    • Patchstack’s 2026 whitepaper: 6 core vulnerabilities out of 11,334 tracked in 2025. The whitepaper calls these “low priority” issues.

    This guide won’t average the two or pick a winner. Either way, the core sits at roughly 0 to 0.2% of everything tracked in 2025. Both reports agree on the rest: plugins account for 91% and themes for the remaining 9%.

    The other half of “is WordPress secure” is a market-share question, not a security one.

    As of 21 August 2026, WordPress runs 40.7% of all websites. It runs 58.9% of every site with an identifiable content-management system. That is according to W3Techs, an independent source that tracks this directly. WordPress’s own security page gives a different figure: “more than 43% of the web”. That is WordPress’s self-reported number. Don’t average the two.

    Running the largest share of the web makes WordPress the largest target pool. That is arithmetic, not the same as being the least secure platform on the web. The distinction matters before you look at what hardening actually covers.

    How WordPress security actually works

    Core, plugins, and themes get patched in different ways. That difference explains most of what follows.

    How core gets patched

    WordPress 3.7 introduced automatic background updates for core. The goal was security.

    Before WordPress 5.6 (released December 2020), a new install auto-updated only minor releases and translation files by default. From 5.6 onwards, a new install auto-updates both minor and major releases by default. WordPress’s own documentation calls turning that off “strongly discouraged”.

    Who patches the core? In WordPress’s own words: “more than 50 trusted experts, including lead developers, security researchers, and key contributors to every component of WordPress.” They even backport fixes to older, unsupported versions as a courtesy. No one is obligated to keep running those fixes for you, but the team ships them anyway.

    Confirm it

    Open the site’s update settings, or ask whoever manages hosting. Check that both minor and major core updates run automatically, not just minor ones.

    Why plugins and themes are different

    Plugins and themes don’t get the same treatment as core.

    WordPress.org’s security team can force an update to a specific plugin or theme, but only “in special cases”. This happens through the WordPress.org API, when a critical vulnerability needs patching everywhere at once, no matter what the owner set up.

    Outside that rare case, keeping a plugin or theme current is the owner’s job. An abandoned plugin stops getting fixes but stays installed, active, and reachable, which is the exact gap the 2025 numbers describe above.

    What a firewall or security plugin actually catches

    A firewall or security plugin checks the perimeter. It doesn’t patch anything.

    Patchstack’s 2026 whitepaper cites two penetration-testing studies. Hosting-level defences blocked only 12% of attacks on known, already-disclosed vulnerabilities. That rate rose to 26% across a broader set of vulnerability types.

    12–26%Attacks blocked at the perimeter

    A real layer, working by matching known attack patterns at the edge. It doesn’t rewrite the vulnerable code inside a plugin.

    It also can’t catch a backdoor already planted inside a theme or plugin file. That is exactly how a pirated (“nulled”) plugin works. The backdoor ships inside the same zip file a legitimate copy would use. Nothing forced its way in, so there is no signature to catch at the door.

    What a compromise actually costs to recover from

    What decides how a compromise ends? Not the firewall. The backup.

    A tested, offsite backup lets you restore the site to a known-good point. Without one, you rebuild from nothing.

    Whatever caused the breach, a vulnerable plugin, a guessed password, or a nulled theme, matters less at that point. What matters is whether you have a short restore ahead of you or a full rebuild.

    Why it matters even if the core is well maintained

    Sites still get compromised for a simple reason: almost all the attack surface sits in plugins and in what an owner does with them, not in core.

    Core didn’t get worse. The exposure lives in the 91% of 2025’s tracked vulnerabilities that sat in plugins, plus outdated versions, abandoned installs, nulled downloads, and reused admin passwords. None of that runs through WordPress’s security team. An unpatched plugin isn’t an abstract risk score. It is a defaced homepage or a compromised checkout page, the kind of thing a customer notices before the owner does.

    The 90% figure still gets repeated as if it were current. It isn’t. It traces back to Sucuri data from 2018, reported in a March 2019 Infosecurity Magazine article, which makes it roughly seven years stale. Whatever it measured about 2018 installs, it says nothing about security today, or even then. Treating it as a live statistic repeats the exact error this guide opened with: mistaking market share for a security score.

    There is a quieter point worth stating. Leaving WordPress’s free, built-in core auto-updates on solves the smallest slice of the real risk, and it costs nothing. A site owner who does only that has correctly handled the roughly 0 to 0.2% that lives in the core, for free. It doesn’t touch the 91% sitting one layer up in plugins, which is a maintenance question, not something core patches for you.

    What good WordPress security looks like

    What actually reduces this risk is a short, concrete list, not a product:

    • Keep core, plugins, and themes current. Test every update before it goes live, not after.
    • Remove abandoned or nulled plugins and themes. Check for ones you forgot were still active.
    • Use strong, unique admin credentials. Brute-force attacks against wp-login.php are their own attack surface, separate from any software bug. A weak or reused password doesn’t need a vulnerability to succeed.
    • Run file-integrity or malware monitoring. It tells you when a file changed after installation, so it catches a compromise that already happened. It doesn’t stop the first entry; that is what the points above are for.

    What to do about it

    Start with the plugin list, not the firewall. Three actions cover most of this:

    1. 01Audit every installed plugin and theme. Remove anything unused or no longer maintained by its developer. An abandoned plugin doesn’t announce itself. It just stops getting fixed. NoDrama’s free WordPress audit tool does this scan in minutes if you would rather not do it by hand.
    2. 02Turn on core auto-updates for both minor and major releases, if they are not on already. This slice of the problem is free and already solved.
    3. 03Decide who runs tested updates, file-integrity monitoring, and backups: your team, or a retainer that does WordPress operations full-time. Either answer works. What matters is that someone actually does it. See plan pricing and what’s included to compare that against doing it yourself.
    Confirm it

    After any of the above, log the date and what changed. Use a spreadsheet or maintenance log, something that outlives whoever made the change and stays checkable later.

    Common misconceptions

    “A security plugin is a complete answer.”

    It is a perimeter check, and it needs its own updates, like anything else on the site. The pentest figures above put its real block rate at 12 to 26% against known vulnerabilities. That is a partial layer, not a substitute for patching the plugin underneath.

    “My host’s security features cover this.”

    Hosting-level defences carry the same 12 to 26% block rate described above. They are the same category of perimeter defence. They harden the server. They don’t patch the vulnerable code inside a specific plugin.

    “WordPress gets hacked constantly because it’s insecure.”

    This usually traces back to the 90% figure: 2018 data, reported in 2019. It describes market-share exposure, not a security verdict. Running the largest share of the web means showing up in the largest share of hacked-site counts. That is just arithmetic, whatever the underlying security looks like.

    What this does not solve

    None of the above patches a specific vulnerable plugin for you. It doesn’t replace the judgement call of deciding a plugin is abandoned and removing it. It doesn’t replace reading what an update changes before it goes live, especially on a site that depends on that plugin working a certain way.

    Automation and monitoring narrow where your attention needs to go. They don’t remove the need for it.

    Is WordPress actually secure?

    The software WordPress ships from wordpress.org, backed by a security team of more than 50 people and a habit of backporting fixes to old versions, is well maintained. It is not the meaningful risk.

    What determines whether a WordPress site is secure is what runs on top of core and who keeps it current: which plugins are installed, whether they are still maintained, whether the admin password would survive a guess, and whether anything watches for a change after the fact.

    That is a maintenance question about one specific site, not a verdict on the platform every site like it happens to run on.