What website maintenance includes and what it does not

What maintenance is not

Start here. This is where most confusion lives.

Services, prices, photos, bios, location landing pages, and hours are content work, not maintenance. Scope/bill them separately: a retainer for regular changes, per-request quotes for occasional ones.

Visual redesign, layout restructuring, and UX improvements need separate scope/pricing. Maintenance adjusts design only when necessary to repair broken functionality.

Maintenance is not new feature development either. Adding a booking system, a new contact form, an online store, a client portal, or any functionality that did not exist in the original site build — those are development projects. Each one gets scoped, estimated, and built. Maintenance keeps what exists running correctly; it does not build new things.

Maintenance is predictable monthly infrastructure work regardless of content. Twelve unchanged months cost the same; three new service pages add separate charges. Confusing scopes means unused bundled hours or wrongly expected coverage.

What maintenance covers

Maintenance covers the infrastructure that keeps a live website running correctly over time. Your content does not need to change for this work to be necessary. The environment underneath the content does.

PHP management. Most sites, including ArdinGate's, use PHP. Published lifecycles end security patches: PHP 7.4 in November 2022, 8.0 in November 2023. Forced hosting upgrades can break functions, deprecated features, or third-party code. Proactively update in controlled environments, test, and fix compatibility before visitors see it. Scheduled upgrades cost less and disrupt less than deadline-driven emergencies.

Server updates. Nginx/Apache, MySQL/MariaDB, system libraries, and operating systems all need regular security patches. Unpatched servers accumulate exposure regardless of careful application code.

SSL renewal. Let's Encrypt expires every 90 days; commercial certificates commonly yearly. Expiry triggers Chrome blocks, Safari unsafe warnings, or Firefox crossed padlocks; visitors leave or cannot proceed. Monitor dates, automate renewal where possible, and manually verify otherwise.

Daily offsite backups recover compromise, hardware failure, or destructive changes. Same-server copies disappear with the server. Automate separate-storage backups with standard thirty-day retention, enough to predate a week-undetected compromise.

Uptime monitoring checks externally every minute and alerts on outages, errors, or excessive load time. Know within two minutes rather than through clients, reducing lost forms and prospects seeing errors.

Patch vulnerabilities promptly. Monitor stack disclosures and respond quickly: automated exploits can follow within hours/days. Current security patching is essential, not optional.

Repair upstream breakage. Browser CSS/JavaScript changes, third-party API updates, and hosting configuration can break unchanged code after launch. Maintenance diagnoses and repairs these environmental failures.

The hidden degradation cycle

A site without active maintenance does not break dramatically on a specific date. It degrades on a timeline that is invisible until something tips over, and then the tipping is sudden and expensive. Here is how that cycle plays out in practice, with specific version dates and cost ranges so the math is visible.

Slow decline: an early-2022 PHP 7.4 site with annual SSL/no maintenance works, forms included, under two seconds. PHP 7.4 reaches announced November 28, 2022 EOL unnoticed. By mid-2023, CVEs for PHP 7.4 accumulate without future upstream patches for PHP 7.4, while pages look normal.

Early-2023 annual SSL expiry went unnoticed for three days until a client suspected hacking. Chrome's privacy warning looked like compromise; for 72 hours every visitor saw red warnings, with effectively zero conversions and unknowable lost leads.

Sudden failure: late-2023 hosts remove PHP 7.4 with 60 days' notice. Unsupported shortcuts crash; developers audit, rewrite, and test every file without staging. Emergency work takes 6-10 hours/$600-$1,200 for simple sites, more for complex code/plugins. Planned staging upgrades take 2-3 hours at a fraction of cost.

Exploit windows shrink to 24-72 hours for major CVEs. WordPress security patches/changelogs expose changes; reverse-engineering informs scanners within days. Bots indiscriminately probe unpatched sites continuously; exploitation depends on flaw type. Nginx, OpenSSL, and Linux kernel disclosures follow similar patterns.

Recovery costs: same-day SSL expiry, 1-2 hours plus losses; PHP emergency under 60-day deadline, $600-$2,000+; forensic files/database/log review, credential rotation, restore/verification, $500 with clean backups or $2,000-$5,000+ for persistent backdoors without them. Compare $60/month managed hosting.

The degradation cycle is not a feature of bad hosting or bad luck. It is the predictable output of infrastructure that runs on its own schedule (PHP EOL dates, SSL expiration dates, CVE disclosure timelines), independent of whether anyone is watching. Maintenance is the practice of watching and acting before the timeline catches up.

WordPress maintenance vs. custom PHP sites

The scope and burden of website maintenance differs significantly depending on whether a site is built on WordPress or on custom hand-coded PHP. This is not a minor operational difference. It affects how much ongoing work maintenance requires and how frequently security issues arise.

WordPress adds independent updates: core, themes, and plugins. Core security releases need prompt action; themes may conflict; plugin patches may be urgent once flaws become public and automated exploits appear.

Every plugin update needs theme/plugin compatibility testing. Broken forms require identification, rollback, diagnosis. Unpatched disclosed flaws require monitoring/replacement; abandoned installed plugins accumulate risk and must be identified/replaced by owners.

WordPress.org has 60,000+ plugins; WPScan tracks regular disclosures. Exploitation can follow within hours. Someone must monitor CVEs, urgently patch, and periodically audit abandoned/high-risk plugins.

Custom PHP maintenance has narrower scope. Its fixed codebase, dependencies, and server environment need no plugin management, theme updates, or WordPress compatibility testing. Maintenance covers current PHP, server patches, SSL renewal, backups, and uptime monitoring. Developer-maintained custom code avoids the update treadmill of a third-party plugin ecosystem and its vulnerability calendar.

For a small business that is not adding new functionality frequently, this difference in maintenance burden translates directly to a simpler, lower-risk, and more predictable ongoing cost. See the WordPress-to-custom migration guide →

What managed hosting covers

Managed hosting is how most small businesses get maintenance handled without needing to do any of it themselves. The term can mean different things from different providers, so it is worth being specific about what should be included.

• PHP version management. The provider monitors PHP release schedules, plans upgrades to current supported versions, tests the site on the new version before switching, and addresses compatibility issues. When PHP 8.3 releases a security patch, the server gets it applied. When a PHP version reaches end-of-life, migration happens on a controlled timeline before the hosting provider forces it.
• Server software patching. OS-level updates, web server software updates, and database software updates applied on a reasonable cadence. Security patches get prioritized and applied promptly. The underlying server stack doesn't languish unmaintained for months between updates.
• SSL certificate renewal. Automated where possible (Let's Encrypt via certbot on a cron job), with monitoring to catch renewal failures before they reach expiration. The goal is that certificate expiration never becomes a visitor-facing event.
• Offsite backups. Automated daily backups sent to a storage destination physically separate from the live server, with at least 30-day retention. Backup configuration is tested periodically rather than merely trusted to work.
• Uptime monitoring. External monitoring that checks the site continuously and sends an alert when something goes down or behaves abnormally. Alert response is prompt, not a ticket reviewed in 48 hours.
• Bug fixes from upstream changes. When a browser update changes rendering behavior, a third-party API the site integrates modifies its response format, or a server configuration change causes an unexpected interaction, managed maintenance covers diagnosing and fixing these. They're covered because they're not changes you made to the site. They're changes in the environment around it.

Core $60/month includes PHP/server updates, SSL, offsite backups, and uptime. Care $100/month adds upstream application fixes/content-edit hours. Covered work has no incident fees. Hosting → Maintenance →

DIY maintenance: where it breaks down

Technically, you can do your own website maintenance. Every task involved is learnable. But it requires specific technical access, knowledge, and consistent attention that most small business owners reasonably do not have and should not need to develop. Here is where DIY maintenance breaks down in practice.

PHP upgrades require access/testing. Know SSH, hosting configuration, and preproduction checks. Shared-host panels simplify switching, not compatibility diagnosis. Nondevelopers without staging struggle to do this safely.

SSL needs monitoring/DNS or filesystem access. Let's Encrypt/certbot cron jobs must be checked; three silent weeks can lead to expiry. Manual renewal may need DNS records or challenge files. Managed providers verify; DIY means reviewing logs.

Configure and test offsite backups. Set S3, Backblaze B2, or Rclone storage; configure scripts/cron; periodically restore into a separate environment and verify functionality. Existing files or apparently successful jobs aren't proof; silent errors create dangerous confidence.

Monitor externally. Server-based monitors die with the server. An outside-network service takes 20 minutes to configure; the challenge is responding at 3am Saturday.

The cost of deferred maintenance

Website maintenance is the kind of expense that's easy to defer because consequences aren't immediate. Nothing appears to break when you skip a month. Degradation stays invisible until it doesn't. It's worth examining actual costs that pile up when maintenance is deferred. They're almost always higher than the maintenance would have cost.

Emergency PHP upgrades. A host ends PHP 7.4 in 30 days while you're on PHP 7.4. Short-notice developers charge more to test PHP 8.x, fix compatibility, and deploy within 30 days. Time pressure reliably costs more than proactive maintenance.

SSL incident recovery requires renewal, possible DNS propagation/configuration changes, installation, and verification. Meanwhile visitors see security warnings, causing undeniable though hard-to-measure credibility loss.

Compromise recovery: restore clean backups, identify/close entry, rotate credentials, and monitor persistent access. Without backups, audit all files, database modifications, and access logs. WordPress cleanup ranges from hundreds for simple cases to thousands for multiple persistent backdoors.

Hidden revenue loss: four business-hour outage means four hours without forms; two days of warnings drive visitors away permanently. Lost leads depend on traffic/conversion and aren't fully recoverable.

The math for most small businesses is clear. Monthly maintenance costs a fraction of what any incident above costs to fix. The argument for deferring maintenance is always some version of "nothing has broken yet." That argument gets causality backward: maintenance is exactly why nothing has broken yet.

Common assumptions that are never in scope

Beyond the content-vs-infrastructure distinction covered earlier, there are several categories business owners regularly assume are part of maintenance that are not. These come up often enough that it is worth being direct about each one.

Domain/DNS are separate. GoDaddy, Namecheap, Cloudflare, or Google Domains renewal belongs to you/registrar, not server managers. Expiry resembles server outages but needs different repair. Launch includes initial DNS; later MX, nameserver, or CNAME changes require registrar access and separate work.

External services aren't infrastructure: Google Business Profile, Yelp, Facebook Business, Google Analytics, and email marketing. Search Console manual actions need Google's interface; changed email embeds need content updates; browser-blocked analytics need platform configuration. Maintenance covers server/application stacks.

SEO outcomes are separate. Maintenance preserves uptime, speed, crawler responses, and valid SSL, indirectly repairing ranking damage from PHP/server/certificate failures. It doesn't fix thin content, algorithm penalties, backlinks, or target-keyword rankings.

Original defects are warranty issues. Post-launch failures from browsers, servers, or API deprecation are maintenance. Distinguish these contractually before launch; waiting invites disputes over original promises.

Deeper performance work is separate. Maintenance preserves current PHP, patched stacks, and reliable hosting. Audits, Google health-check improvements, image compression, database tuning, and caching are scoped development. Maintaining good launch performance differs from optimizing toward perfection.

Key takeaways

• Website maintenance covers infrastructure — PHP version management, server software patching, SSL renewal, offsite backups, uptime monitoring, and bug fixes from upstream changes. It does not cover content updates or new development.
• A site's content can remain entirely unchanged while the infrastructure underneath requires active maintenance. PHP end-of-life dates and SSL certificate expiration dates run on their own schedules, independent of your content.
• Sites degrade on a slow-then-sudden timeline. The slow phase is invisible; the sudden phase (forced PHP upgrades, SSL expirations, security compromises) is expensive and disruptive.
• WordPress maintenance is meaningfully more involved than custom PHP maintenance, primarily because of the plugin ecosystem: dozens of plugins on independent update schedules, each with their own vulnerability history and required monitoring.
• Custom hand-coded PHP sites have a simpler, narrower maintenance scope: no plugin treadmill, no theme update lifecycle, no WordPress core update cycle. Maintenance reduces to server-level work.
• Offsite backups are your only reliable recovery mechanism when something goes wrong. A backup on the same server as the live site is not a real backup. Retention matters as much as frequency.
• The cost of deferred maintenance is reliably higher than the cost of regular maintenance, once an incident requires emergency response, forensic cleanup, or professional remediation of a compromise.

Website maintenance questions

See all FAQs →