Website Maintenance: What Actually Needs Doing Every Month

Quick answer: Real website maintenance takes 4 to 8 hours per month and covers five jobs: a tested restore from backup, dependency and core security updates, a Core Web Vitals field check against Google's 2.5-second LCP and 200ms INP thresholds, a crawl and index audit, and a functional test of every form and payment path. Patchstack found that 46% of WordPress vulnerabilities in 2025 had no patch available at disclosure, which means clicking update is roughly half a security strategy, not a whole one.

Patchstack recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, a 42% jump year over year, with 91% of them sitting in plugins. Most website maintenance plans respond to that number with a single action: update everything, monthly, and invoice. That does not work, because 46% of those vulnerabilities shipped with no patch on the day researchers disclosed them. This post sets out what a genuinely useful month of site upkeep contains, which tasks belong on a slower cycle, and the specific failures we keep finding in production sites that looked perfectly maintained on paper.

What does website maintenance actually cover every month?

Monthly website maintenance covers five distinct jobs, and only one of them involves clicking an update button. Website maintenance is the recurring work that keeps a live site secure, fast, crawlable, and functionally correct after launch, as opposed to the feature work that changes what the site does.

The five jobs are recovery, security, performance, discoverability, and function. Recovery means proving you can restore, not confirming a backup ran. Security means tracking disclosed vulnerabilities against your actual dependency list. Performance means checking field data, not lab scores.

Discoverability means auditing what search engines and AI crawlers can reach. Function means somebody submits the contact form, completes a test checkout, and confirms the email lands in a live inbox.

Agencies that sell maintenance retainers usually bundle four of those five and quietly skip recovery testing, because a restore drill takes an hour and produces no visible deliverable. That hour is the most valuable one in the month. If your monthly report shows plugin version numbers and uptime percentage and nothing else, you are buying site upkeep theatre, meaning maintenance activity that generates a report without reducing any real risk.

Why security updates alone will not keep your site safe

Security updates close known holes on a delay you do not control. Patchstack's 2026 report found that 46% of the 11,334 vulnerabilities disclosed in 2025 had no patch at the moment of disclosure, so for nearly half the attack surface there was nothing to update to.

The unpatched window is the real exposure

The same Patchstack testing found that traditional defences, including web application firewalls and Cloudflare-style protection, blocked only 26% of total attacks and just 12% of attacks targeting WordPress-specific vulnerabilities. Two conclusions follow. A WAF is not a substitute for patching, and patching is not a substitute for reducing what you run.

Surface reduction beats update frequency

We stopped measuring maintenance quality by update cadence at Loop2Tech and started measuring it by plugin count. A site running 34 plugins carries roughly three times the disclosed-vulnerability exposure of a site running 11, and in every audit we have run in Karachi, Pakistan, at least a quarter of active plugins were leftovers from a redesign nobody had switched off.

Deleting an unused plugin removes 100% of its future vulnerabilities permanently. No update schedule matches that return. Deactivating is not enough, because the files stay on disk and remain reachable.

The monthly website maintenance checklist that earns its hours

Run these nine steps in order, once per calendar month, on a fixed date. Order matters: the restore drill comes first so that everything after it happens with a proven rollback in hand.

1. Export the database and files, then restore that export into a staging environment and load the homepage, a product page, and a blog post.
2. Compare your plugin, theme, and package inventory against a vulnerability feed such as Patchstack or Dependabot, and flag anything disclosed without a fix.
3. Delete plugins and themes that are inactive or unused, rather than deactivating them.
4. Apply core, plugin, and dependency updates on staging first, with the same PHP version, object cache, and CDN configuration as production.
5. Pull 28-day field data in Google Search Console and PageSpeed Insights, and confirm LCP, INP, and CLS still pass at the 75th percentile.
6. Crawl the site with Screaming Frog and check for new 404s, redirect chains longer than one hop, and pages that dropped out of the index.
7. Submit the contact form, complete one test transaction, and verify both notifications arrive in a monitored inbox.
8. Review server error logs and slow query logs for anything repeating more than 50 times in the period.
9. Confirm TLS certificate expiry sits more than 30 days out and that domain auto-renewal is active.

Here is the sequence we run for step one and step four on WordPress sites, using WP-CLI:

wp db export backups/pre-update-2026-08-17.sql --path=/var/www/site
wp db import backups/pre-update-2026-08-17.sql --path=/var/www/staging
wp plugin list --update=available --format=table
wp plugin update --all --path=/var/www/staging
wp cache flush --path=/var/www/staging
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://staging.example.com/

Google's own Core Web Vitals documentation sets the passing thresholds at 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS, measured at the 75th percentile of real page loads and segmented by device. Lab scores in Lighthouse do not count for ranking purposes. For the crawl side of step six, our technical SEO checklist of fixes that move rankings covers the diagnostics in depth.

Which site upkeep tasks belong on a quarterly or annual cycle

Not everything deserves a monthly slot, and forcing low-frequency work into a monthly rhythm is how retainers turn into padding. Match cadence to how fast the underlying thing actually changes.

The annual runtime upgrade causes the most damage when skipped, and it hits emerging-market clients hardest. Shared hosting plans sold in Pakistan frequently pin PHP to an end-of-life version, so plugin updates install but silently fail to run their migration routines. Check the PHP version before you blame the plugin.

How website maintenance protects rankings and AI citations

Maintenance failures show up in search performance before anyone notices them in the browser. WordPress runs 40.8% of all websites according to W3Techs, so the decay patterns are well documented and entirely predictable.

Three regressions do the most damage. Redirect chains accumulate after content pruning and burn crawl budget, the finite number of URLs Googlebot fetches from your site in a given period. Broken structured data drops rich results and removes the machine-readable context that AI Overviews and AI Mode use to attribute claims. Slow third-party scripts push INP past 200ms on mid-range Android devices, which is what most traffic in South Asia arrives on.

The AI layer adds a newer failure mode. A page that returns a 500 to an AI crawler, or one whose FAQ markup breaks, quietly stops appearing in generated answers, and standard rank tracking will not show it. Add a monthly AI citation check to the same cycle, using the method in our guide to measuring GEO and AI share of voice. Keep your schema markup for SEO and AEO validated in the same pass.

Who should own site upkeep, and what it costs to get wrong

Assign one named owner with server access, not a shared inbox. Maintenance fails through diffusion of responsibility far more often than through lack of skill.

The most common failure we find is not a missing backup. It is a backup nobody has ever restored, usually because the host capped snapshot size and silently excluded the uploads directory. That site has a green backup indicator and no recoverable media library. We found exactly this on a Shopify-adjacent build we later rescued, and the pattern repeats across the lifestyle brand storefront work we have shipped.

The second most common failure is a contact form posting to an address that stopped resolving after a domain migration. Nobody reports it, because the sender sees a success message. We now send a canary submission on the first of every month and treat a missing canary as a priority incident.

When the monthly cycle stops holding the site together, the honest answer is a rebuild rather than a bigger retainer. Our post on signs your business needs a website rebuild covers where that line sits, and our web development team takes on sites in that state. Where maintenance intersects with visibility, our AEO, GEO and SEO services run the crawl and citation half of the cycle. If AI crawlers are part of your traffic mix, decide deliberately whether you need an llms.txt file.

Start here this month

Do three things this week. Restore last night's backup into a staging environment and load three real pages, because an untested backup is a guess. Open your plugin list and delete everything nobody can justify by name, since deletion removes future vulnerabilities permanently while updates only close past ones. Pull 28 days of Core Web Vitals field data in Search Console and confirm LCP still clears 2.5 seconds at the 75th percentile. If you want the crawl, schema, and AI citation half of the cycle handled properly, our AEO, GEO and SEO service covers it. Send us your current maintenance report and we will tell you what it is missing.

Frequently asked questions

What is included in a website maintenance plan?

A website maintenance plan should include a tested restore from backup, core and plugin security updates tracked against a vulnerability feed, Core Web Vitals field monitoring, a monthly crawl and index audit, functional testing of forms and checkout, error log review, and TLS certificate monitoring. Plans that report only uptime percentage and plugin version numbers omit the two tasks that prevent the most costly failures, which are restore testing and form verification. Expect 4 to 8 hours of real work per month for a standard business site.

How do I test whether my website backup actually works?

Restore the backup into a separate staging environment and load at least three real pages: the homepage, a product or service page, and a blog post with images. Confirm the media library resolves, the database import completes without errors, and any user accounts still authenticate. A backup that has never been restored is an assumption, and the most frequent defect Loop2Tech finds is a host snapshot that silently excludes the uploads directory because of a size cap.

Is a maintenance retainer better than fixing issues as they break?

A maintenance retainer costs less than break-fix work for any site that generates revenue, because the expensive failures are the silent ones. A contact form posting to a dead address or a Core Web Vitals regression can run for months without anyone reporting it, while the traffic and lead loss compounds. Break-fix only makes economic sense for brochure sites with no forms, no transactions, and no organic search dependency.

Why did my site slow down after a plugin update?

A plugin update usually slows a site because it added new front-end assets, invalidated the object or page cache, or introduced a database query that runs without an index. Check the change first by comparing INP and LCP field data in Google Search Console before and after the update date, then inspect the slow query log. On shared hosting with an end-of-life PHP version, updated plugins can also fall back to slower compatibility code paths, so confirm the runtime version before rolling the plugin back.

How often should I update WordPress plugins?

Update WordPress plugins monthly as a baseline, and within 72 hours for any vulnerability rated high severity or already exploited in the wild. Patchstack found that 91% of the 11,334 WordPress ecosystem vulnerabilities disclosed in 2025 sat in plugins, so plugin hygiene carries most of the risk. Always apply updates on a staging environment that mirrors the production PHP version, object cache, and CDN configuration, because staging without matching infrastructure hides the exact failures you are testing for.