Audit My Site Get Started

Category: Maintenance operations

  • WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    WordPress Update Management: Core, Theme and Plugin Updates Done Safely

    In this piece

    1. 01Work out what you are actually running
    2. 02Apply updates the safe way
    3. 03Confirm it held

    The three layers you are updating

    Core is WordPress itself, the software that runs everything else. Themes control how the site looks. Plugins add functions core does not have. All three ship updates on their own schedules, and none of them wait for the other two.

    Three layers, two kinds of updateCore can run on autopilot. Theme and plugin updates need a test step first.
    Core

    WordPress itself. Scheduled major releases, minor releases as needed.

    CompatibilityStrict backward compatibility across minor versions
    Auto-update defaultOn, for minor and major releases on WordPress 5.6 or later
    Safe to automate

    Theme

    Controls how the site looks. Ships on the theme author’s own schedule.

    Plugin

    Adds functions core does not have. Ships on each plugin author’s own schedule.

    CompatibilityIndependently coded, no compatibility guarantee with your other plugins, theme or PHP version
    Auto-update defaultOff. Opt-in per item or in bulk since WordPress 5.5
    Test before it goes live

    A mechanism diagram, not a risk score. Testing and rollback on the plugin and theme layer are offered by several providers.

    Diagram comparing WordPress core, theme and plugin update risk.

    Core minor releases are near-automatic and safe, because WordPress core maintains strict backward compatibility across minor versions. That is the whole reason they can run unattended. Plugin and theme updates are a different animal. Each one is written independently, by a different developer, with no obligation to stay compatible with any other plugin, theme or PHP version on your site. WordPress has no way to test that combination in advance, which is exactly why the project leaves plugin and theme auto-update off by default. You have to turn it on per item, or in bulk, since WordPress 5.5.

    That default is worth sitting with. The people who built the update system decided the compatibility risk on this layer was high enough that it should not happen without someone choosing it. “Turn on auto-update for everything” is advice that skips the one step, testing, that actually prevents breakage. It is not wrong that updates should happen. It is wrong about which layer is safe to leave unattended.

    This is the gap a maintenance retainer that separates the safe updates from the risky ones is built to close.

    Check what you have now

    Before changing anything, confirm what is actually running. In wp-admin, the Dashboard > Updates screen shows the current core version and lists any plugin or theme with an update pending. The Plugins screen shows every active plugin and its version number. Appearance > Themes shows the active theme and any child theme in use.

    Write the list down, or export it, before you touch a single update. You cannot tell whether an update changed something if you did not know the state it changed from.

    Verification step

    Confirm the list matches what is actually active in wp-admin, not what you remember installing. Plugins get deactivated and reactivated, themes get swapped, and a list based on memory is often out of date.

    How to handle core updates

    Core minor releases (as-needed maintenance and security fixes, no new features) are safe to leave on auto-update. WordPress ships three major releases a year, roughly four months apart, and on installs running WordPress 5.6 or later, both minor and major releases auto-apply by default. Major releases change more surface area than minor ones, so they carry more risk even though the default treats them the same as minor releases on newer installs. For more detail, see how often WordPress actually ships updates.

    Via plugin

    An update-management plugin can group and schedule core updates, giving you a single place to see what applied and when, rather than checking the Updates screen manually.

    Via server

    WP-CLI or a hosting panel’s built-in update trigger can apply core updates from the command line or a dashboard, which is the more common route on managed hosting.

    How to handle plugin and theme updates

    WordPress does not auto-update plugins and themes by default, and that default is the clearest signal available that this layer needs more than a toggle. The general mechanism for testing an update before it reaches visitors works the same way regardless of who runs it: pull the update into an environment that mirrors the live site, same PHP version, same active plugin and theme stack, same content, apply it there first, and confirm the site still renders and functions before applying it live. Take a backup immediately before the live update goes out, so the change is reversible if something surfaces after it ships.

    Tested-update workflowThe path an update takes before it reaches the live site
    1. 01
      Update pulled into a staging environment mirroring liveSame PHP version, plugin and theme stack, and content.
    2. 02
      Applied in staging
    3. 03
      Checked for rendering and function
    4. 04
      Applied live, with a backup taken immediately before
    Flow diagram showing a WordPress update tested in staging before going live.

    What NoDrama’s own care plans confirm on this layer, and no more: plugin and theme updates run with key pages photographed before and after, and are put back if something breaks, on all three plans. This is not unique to NoDrama. ManageWP, WP Umbrella and WP Remote all offer comparable tested-update mechanisms.

    This is where how NoDrama checks updates matters, because building a test step yourself means standing up and maintaining a second environment.

    Via plugin

    A staging or cloning plugin is the DIY route: it clones the live site into a separate environment where updates can be applied and checked before going live.

    Via server

    Some hosts include a staging environment as part of the hosting plan, which removes the need for a separate plugin.

    Via code

    A developer-run site can manage this with a manual git and WP-CLI workflow, pulling updates into a version-controlled staging branch before deploying to production.

    Via host or CDN

    Some managed hosts and CDN providers offer their own staging or rollback tooling as part of the platform, where it is included.

    Apply the change

    As general good practice, not a documented NoDrama process: apply core minor updates first, since they carry the least risk. Then work through plugin and theme updates via the tested path above, one at a time or in a controlled batch, never all of them at once with no backup in place. No internal NoDrama documentation confirms this specific sequencing. It is standard practice, presented here as such.

    A full pre-update checklist covers the steps in more detail if you are building this process yourself.

    Verify safely

    Load the updated site logged out, in a private or incognito window, not just in wp-admin. Check the pages that matter most: the homepage, any checkout or lead form, and any page that uses the functionality the updated plugin touches. Confirm the backup taken before the update is still current and restorable, not just that it exists.

    Verification step

    Confirm the site functions for a logged-out visitor. A page that loads fine for a logged-in admin can still be broken for everyone else, since caching, session state and admin-only scripts can mask a problem that a normal visitor would hit immediately.

    See how updates are checked and put back.

    NoDrama’s WordPress maintenance service photographs your key pages before and after every plugin and theme update, and puts back anything that breaks.

    See Maintenance Work

    Troubleshoot

    “The update broke the layout”

    This is usually a theme or plugin CSS or JavaScript conflict introduced by the new version. Roll back to the pre-update backup, then test the update again in staging before reapplying it live.

    “A plugin update will not apply, or the site white-screens”

    This is usually a PHP version mismatch. Check the plugin’s stated minimum PHP version against the version your host actually runs, since an update can require a newer PHP version than the site is on.

    What this does not solve

    A tested-update process catches problems before they reach visitors. It does not make every plugin update backward compatible by itself, and it does not eliminate the underlying risk that plugin code can change without warning. Testing reduces the cost of that risk. It does not remove the risk itself.

    Conclusion

    The practical version of this is simple to state, even if it takes some process to run. Core minor releases can be left on autopilot, because WordPress guarantees their backward compatibility. Plugin and theme updates cannot, because WordPress itself treats them as opt-in, and they need to be tested before they go live rather than applied and hoped for. A maintenance retainer that separates the safe updates from the risky ones is the practical way to get updates checked without building a staging process yourself.

  • Do Websites Really Need Monthly Maintenance?

    Do Websites Really Need Monthly Maintenance?

    Start here

    1. 01Understand why this keeps coming up
    2. 02Work out where your site sits
    3. 03Decide what to do about it

    Why a launched site does not stay finished

    WordPress core, the theme and every plugin on a site are written and versioned independently. Each one ships on its own schedule, set by its own author, with no coordination between them.

    Core itself changed pace recently. As WordPress explained in A new cadence for WordPress core: “Starting in 2025, WordPress will move to a single major release per year, with WordPress 6.8 ‘Cecil’ marking the final major release for the calendar year.” The stated reason is “the energy and resources being diverted due to ongoing legal matters,” and the post frames the change as reversible: “If those lawsuits are dropped or resolved, we’ll revisit this cadence and strongly consider returning to a three-releases-per-year schedule.” Before this, the core release cycle handbook targeted roughly one major release every four months, alongside security and maintenance point releases as needed.

    Plugins and themes follow no such pattern. Some ship weekly. Others go years without a touch. When a vulnerability is disclosed in any one component, the patch that fixes it applies to that component alone. A fix sitting on the plugin author’s server does nothing for a site running the version from before the fix existed, because nobody there applied it.

    What actually breaks a site without upkeep

    Two failure modes account for most of what goes wrong on a site nobody maintains.

    The first is an unpatched security hole: a vulnerability gets disclosed, a patch exists, and the site never receives it. The second is a compatibility break: one component updates, another doesn’t, and the two stop working together. Neither requires an attacker with unusual skill or a site with unusual traffic. Both just require time passing with nobody checking.

    Where the vulnerabilities actually concentrate, from Patchstack’s tracking of the first six months of 2025:

    Component Count Share
    Plugins 3,044 89%
    Themes 386 11%
    Core 1 —

    Source: Patchstack, first six months of 2025. Vendor-tracked figure, not an independent industry consensus.

    A table showing that plugins accounted for 89 percent of new WordPress vulnerabilities disclosed in a six-month 2025 period, compared to 11 percent for themes and effectively none for core.

    Across the ecosystem, 6,700 new vulnerabilities were identified in that period, and 57.6% required no authentication to exploit.

    Patchstack is a commercial vulnerability-disclosure vendor, not a neutral industry body, and there is no independent figure to cross-check these numbers against. Read them as what one vendor’s tracking shows, not as an industry consensus. Even with that caveat, the shape of the finding matches the mechanism above: plugins carry almost all of the disclosed risk, because there are far more of them, written by far more separate authors, patched on far more separate schedules than core ever has to coordinate.

    Does a small brochure site really need this

    Not every site carries the same exposure. A low-traffic site with minimal plugins, no forms handling sensitive data and no e-commerce carries meaningfully lower risk than one running a checkout or a client portal. For that specific case, manual, infrequent, self-managed updates can be an adequate, honest answer.

    The maintenance-needed testTwo variables, and the direction each one pushes
    Many componentsFew components
    Many plugins, no sensitive dataMore moving pieces, each on its own release schedule
    Strongest case for ongoing maintenanceMany plugins, and they touch money, personal data or file uploads
    The narrow honest exceptionFew plugins, nothing touching money or personal data
    Few plugins, handles sensitive dataFewer pieces, but what they touch raises the stakes

    No money, data or uploadsHandles money, data or uploads

    A reasoning aid, not a scored model. The two variables and the direction each pushes, with no weighting between them.

    A simple diagram showing how the number of active plugins and whether a site handles money or personal data together determine how strong the case for ongoing maintenance is.

    The practical test is to count the active pieces of software: WordPress core, the theme, and each plugin. Then ask whether any of them touch money, personal data or file uploads. More components and more of that kind of data both push the case for ongoing maintenance further from optional.

    What a security plugin or auto-updates alone still miss

    A security plugin can scan for known threats and, in some cases, keep itself current. It does not update the other plugins running on the site, and it does not create an off-site backup unless someone configures that separately.

    Turning on automatic updates for everything closes the patching gap, but not the compatibility gap. WordPress can apply some updates in the background, but plugins and themes generally are not auto-updated by default, and even where an update applies cleanly, it can still break a specific plugin and theme combination on your site. An unattended auto-update with no rollback path is itself a known way sites go down, which is a large part of why staging and a tested rollback exist as a step rather than a single button. See how NoDrama tests an update before it goes live.

    What monthly maintenance actually has to cover

    Three things, and none of them substitute for the others.

    Backups

    A real backup covers the database and the file system together, on a schedule tight enough that the restore point is actually usable, stored off the live server. A copy that lives on the same server as the site it protects is not a backup for the case where that server is the problem.

    Confirm it

    Check that your backup destination is off-site, not a folder on the same host.

    Update testing

    Update testing happens on a staging copy before anything reaches the live site, with a rollback path ready if the update still breaks something once it is live.

    Confirm it

    After an update, check the specific pages and forms that depend on the updated plugin, not just that the site loads.

    Monitoring

    Monitoring detects an outage: a site that stopped responding. It does not detect a slow, still-running compromise, and it is not a substitute for patching. It is a detection layer sitting alongside the other two, not a replacement for either.

    What this guide does not solve

    This guide does not tell you whether your specific site has already been compromised. That takes a scan of the actual site, not an article about sites in general.

    It also does not hand you a fixed WordPress-specific number for how often maintenance has to run. The honest answer is “as often as the software underneath keeps shipping updates,” which is continuous rather than a fixed monthly figure, even though most care plans, NoDrama’s included, bill on a monthly cycle.

    NoDrama’s care plans cover backups, tested updates and monitoring at three levels of depth.

    See The Three Plans

    Conclusion

    For most sites running more than a handful of plugins, or handling payments, personal data or file uploads, the answer is yes: ongoing maintenance is not optional, because core, the theme and every plugin keep shipping updates on their own schedules whether or not anyone applies them, and plugins in particular carry the overwhelming share of the disclosed vulnerabilities in the ecosystem. The honest exception is narrow. A near-static brochure site with almost no plugins and nothing touching money or personal data can get by on manual, infrequent, self-managed updates. Everything past that point is a question of how many moving pieces are running and what they touch, not whether WordPress as a platform is somehow dangerous on its own.

  • How Often Should a WordPress Site Be Updated?

    How Often Should a WordPress Site Be Updated?

    In this guide

    1. 01Work out what you actually have.
    2. 02Set the cadence and apply it.
    3. 03Confirm it held.

    What “keeping WordPress updated” actually means

    WordPress core, plugins, and themes do not run on the same update mechanism, and that gap is where most of the confusion about update frequency comes from.

    Core minor releases, the point releases that fix security holes and bugs, install themselves automatically on any WordPress site running a reasonably current version, with no admin action required. Core major releases, roughly one every four months, do not install themselves on an existing site unless the owner opts in.

    Plugins and themes are manual by default, unless the WordPress security team decides a vulnerability is severe enough to force a patch through the update API. Outside that forced-patch exception, every plugin and theme update is something the site owner has to apply.

    That split gives a practical rule: a security-flagged release gets a short, defined window. A feature or maintenance release gets batched with the rest and applied on a schedule. NoDrama patches security releases with key pages photographed before and after, and puts back anything that breaks.

    Check what you have now

    Two things to check before setting a policy. First, whether WP_AUTO_UPDATE_CORE is set to minor, true, or false in wp-config.php, since that constant governs core only. Second, which plugins and themes already have auto-updates toggled on, under the Plugins and Themes screens in the dashboard.

    Working out how often to update WordPress plugins on a given site starts with what is already switched on, not with a fixed number.

    Verify it

    List every plugin and theme with auto-update turned on, and confirm someone is actually watching the ones that are not. A setting nobody checks is not a policy.

    Start with a free audit of your current update settings to see where the site actually stands.

    Choose the right cadence

    A workable WordPress update schedule has two real values, not one.

    Anything security-flagged gets a short, defined window, commonly discussed as 24 to 48 hours once it has passed staging. That is industry-common practice, not a NoDrama response-time commitment: NoDrama’s confirmed response times are 4 hours on The Standard, 2 hours on The Higher Standard and 1 hour on The Highest Standard, if a site is down or hacked, and that is a different clock from how fast a patch itself gets classified and tested.

    Everything else, a feature release, a maintenance update, a routine plugin bump, runs on a batch: weekly for most sites, monthly for sites with very little at stake.

    Update type Cadence Trigger
    Core minor (security, bug fixes) Automatic, on WordPress’s own schedule No action needed
    Core major Roughly every 4 months Opt-in on existing sites
    Plugin or theme, security-flagged Short window, commonly 24 to 48 hours, once staging has passed Vulnerability disclosure
    Plugin or theme, routine Weekly to monthly batch Scheduled review
    A table comparing WordPress core, plugin and theme update cadences by type. The 24 to 48 hour window is common practice this piece recommends, not a stated NoDrama SLA.

    The advice this replaces is “update everything the moment a notification appears.” That is the habit that breaks sites, because it skips the step that matters: classify first, security or feature, then apply on the clock that matches. The major release cycle runs on roughly a four-month scoping-to-launch cadence, one more reason a single interval was never going to cover everything WordPress ships.

    For a low-traffic, no-commerce site

    The defaults are a reasonable position here: core minor auto-on, plugins and themes manual, checked monthly. There is not much for an untested update to break, and not much riding on catching it fast.

    For a site with checkout, forms, or client data

    The case for a tighter cadence and staging gets stronger, not because the site is more exposed in the abstract, but because there is more attached to an update going wrong: a broken checkout, a form that silently stops submitting, and a customer finding out before the owner does.

    Apply the change

    To prevent a theme from being able to update on its own, without turning off updates everywhere, WordPress gives you a filter rather than a blanket setting. The auto_update_theme filter is the documented route, and the call that disables it for a single theme is:

    add_filter( 'auto_update_theme', '__return_false' );

    Place that in a plugin file, not directly in wp-config.php. The WP_AUTO_UPDATE_CORE constant in wp-config.php governs core only and does not touch theme auto-updates at all.

    For per-theme control instead of a blanket switch, check $item->slug inside a custom callback on the same filter, rather than returning false for every theme on the site.

    The core-only equivalent lives in wp-config.php: the WP_AUTO_UPDATE_CORE constant, set to false, true, or the string ‘minor’.

    Via code

    For an owner comfortable editing a plugin file or wp-config.php, the filter and the constant above are the whole job.

    Via a managed maintenance plan

    The alternative is having the classify-then-stage-then-test sequence run on the owner’s behalf rather than by the owner: someone else watches for the release, decides whether it is security or routine, and applies it on the matching clock.

    See how NoDrama classifies and patches WordPress updates, with key pages checked before and after.

    Verify it

    After either path, confirm the setting took place. Check the Site Health screen or the auto-update column on the Plugins and Themes screens, rather than assuming the change was saved.

    Verify safely

    Verifying an update safely means testing on staging, not checking the live site after the fact. Apply the update on a copy of the site, not a preview mode on the same install, then load the front page, the key templates, any forms, checkout if the site has one, and the admin login before promoting the change to production.

    The safe-update sequence

    1. 01
      Backup taken
      Files and database together, immediately before.

    2. 02
      Staged
      Applied to a copy of the site, not the live install.

    3. 03
      Tested
      Front page, templates, forms, checkout, admin login.

    4. 04
      Promoted or held
      Passes, it ships. Fails, it stays on staging.

    5. 05
      Verified live
      Same checks again on production, not a homepage glance.

    This is one common sequence, not the only one. NoDrama runs updates on the live site with key pages photographed before and after, and puts back anything that breaks.

    A flow diagram of the staging, testing and promotion sequence for a WordPress update.

    The rollback path only works if a backup was taken immediately before the update, restoring files and the database together, not one without the other. Here’s how backups and rollback actually work once a change needs undoing.

    Verify it

    After promoting, confirm the update on the live site the same way it was checked on staging, the front page, templates, forms, and checkout, not just a glance at the homepage.

    Troubleshoot

    The update went live, and something broke.

    Restore from the backup taken immediately before the update, files and database together, ahead of trying to manually undo a single plugin. Reversing one change by hand risks missing whatever else the update touched.

    WordPress emailed me about a critical error.

    That is Recovery Mode, a built-in fallback that lets an admin log in with the offending plugin or theme paused so it can be deactivated without FTP access. Recovery mode catches fatal errors. It does not catch a page that loads but looks wrong, which is what the staging and test step is for.

    What this does not solve

    Uptime and error monitoring tells you the site is down or throwing an error. It does not tell you an update quietly slowed the site down or broke one form without triggering an error. Catching that needs the staging and test step, not a monitoring alert.

    The short answer, restated

    So, how often should WordPress be updated? Core patches its own security releases without anyone touching it. Everything else, plugins and themes, runs on a policy: fast for anything security-flagged once it is tested, batched weekly or monthly for the rest, and tested on staging before it goes live either way. See the three plans and what each covers if a managed policy is the simpler route.

  • 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.