What maintenance is not
Start here—this is where most confusion lives.
Website maintenance is not content work. Adding a new service to your services page, updating your pricing, swapping out photos, writing a new bio, creating a landing page for a new location, updating your hours — none of that is maintenance. That is content work, and it is scoped and billed separately when you need it done. If you have regular content changes, a content retainer handles that. If you have occasional changes, they get quoted per request. Either way, they are not maintenance.
Maintenance is also not redesign work. Reworking the visual design, restructuring the layout, improving the user experience, updating the overall look of the site — that is a redesign project, which is a separate conversation with its own scope and pricing. Maintenance does not touch the design unless something specific breaks in a way that requires a design element to be adjusted to function correctly.
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.
The reason this distinction matters for budgeting is that maintenance is a predictable flat monthly cost while content or development work is variable. A business that has not changed a word on their site in twelve months still owes the same maintenance fee every month, because the infrastructure work happens regardless of content. A business that adds three new service pages in a month pays for those pages, but the maintenance fee stays the same either way. Treating them as one thing leads to either overpaying for bundled hours you never use, or assuming your maintenance plan covers things it categorically does not.
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 version management. PHP is the server-side language most websites run on, including every site ArdinGate builds. The PHP project releases major versions on a published schedule, and each version eventually reaches end-of-life: a date after which the project stops issuing security patches for that version. PHP 7.4 reached end-of-life in November 2022. PHP 8.0 in November 2023. The version your site runs on matters because hosting providers will eventually force an upgrade when a version becomes too old, and there is no guarantee your site survives that transition without breaking. The PHP update might change how certain functions behave, deprecate language features your site's code relies on, or conflict with third-party code. Maintenance means staying current proactively: updating PHP in a controlled environment, testing after the update, and fixing any compatibility issues before they hit visitors. An emergency same-day PHP upgrade forced by a hosting provider deadline is more expensive and more disruptive than a planned one done on your schedule.
Server software updates. Beyond PHP, your web server runs other software with its own security track record: the web server software (Nginx or Apache), the database engine (MySQL or MariaDB), and various system libraries. The operating system these run on also receives security patches on a schedule. Security vulnerabilities get discovered regularly across all of these. A server running unpatched software is a progressively more exposed one, regardless of how carefully the application code was written.
SSL certificate renewal. SSL certificates expire. A Let's Encrypt certificate expires every 90 days. A commercial certificate commonly lasts one year. When a certificate expires, every major browser immediately displays a security warning to visitors — a full-page block in Chrome, a "not safe" warning in Safari, a padlock with an X in Firefox. Many visitors will leave without proceeding. Some browsers block navigation entirely. Proper maintenance includes monitoring certificate expiration dates and renewing before visitors ever see a warning, using automated renewal tools where possible and manual verification where not.
Offsite backups on a defined schedule. Regular backups stored somewhere separate from the primary server. This is the recovery mechanism when everything else fails — a server compromise, a hardware failure, an accidental change that breaks the site. A backup stored only on the same server as the live site is not a backup. If the server goes away, so does the backup. Proper maintenance includes automated daily backups sent to a separate storage destination, with a retention window long enough to restore from before a compromise that sat undetected for a week. Thirty-day retention is standard.
Uptime monitoring. Active monitoring that checks your site from an external vantage point every minute and sends an alert when it stops responding, returns an error code, or takes too long to load. Without monitoring, a business finds out their site is down from a client who tried to visit it. With monitoring, you know within two minutes. The difference matters when a site going down also means contact forms are not being submitted and potential customers are seeing an error page instead of your business.
Security patching and vulnerability response. Watching for newly disclosed vulnerabilities in the software stack your site runs on, applying patches promptly when they appear, and responding quickly when something is flagged. The window between a vulnerability disclosure and automated exploitation can be hours to days. Staying current on the security patch cycle is not optional if you want the site to remain secure.
Bug fixes caused by upstream changes. Things that worked correctly at launch sometimes break later because something outside the site's own code changed. Browser updates change how certain CSS or JavaScript behavior works. Third-party services update their APIs. Hosting provider configuration changes affect server behavior. Maintenance covers diagnosing and fixing these as they occur, because they are not caused by anything in the site's codebase changing — they are caused by the environment around the site changing.
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 real version dates and real cost ranges so the math is visible.
The slow phase. Consider a small business site launched in early 2022 on PHP 7.4 with a one-year SSL certificate and no active maintenance plan. Everything works. Contact forms submit. The homepage loads in under two seconds. Nothing visible is broken. Meanwhile, PHP 7.4's end-of-life clock is running. The PHP project announced the November 28, 2022 EOL date months in advance—but if nobody is watching the PHP release schedule, that date passes unnoticed. After it passes, any newly discovered security vulnerability in PHP 7.4 goes unpatched by the PHP project permanently. By mid-2023, CVE databases are accumulating disclosed PHP 7.4 vulnerabilities with no upstream fix coming. The site continues rendering normally. Nobody knows.
The one-year SSL certificate expired in early 2023. The business owner noticed three days later when a client emailed asking if the website had been hacked. It hadn't. A Chrome "Your connection is not private" full-screen warning looks identical to a compromised site from a visitor's perspective. For those 72 hours, every visitor who landed on the site's homepage saw a red browser warning. How many left without contacting the business is unknowable, but the conversion rate during that window was effectively zero.
The sudden phase. In late 2023, the hosting provider announces PHP 7.4 will be removed from shared hosting infrastructure. Customers have 60 days to migrate. The developer the business contacts discovers the site relies on older coding shortcuts that the newer PHP version no longer supports, so parts of the site now crash outright. Fixing compatibility requires auditing every file, rewriting the outdated parts, and testing after each change without a safe practice copy of the site to work on. The emergency engagement takes 6-10 hours of unplanned developer time — typically $600-$1,200 for a simple site, more if the codebase is larger or the plugin dependencies are tangled. A planned PHP upgrade done proactively, on a schedule with a staging environment and no deadline pressure, takes 2-3 hours and costs a fraction of that.
The exploitation window. The time between a public vulnerability disclosure and the first automated exploit attempt has compressed dramatically. For high-profile CVEs in widely-used software, exploitation tools appear within 24-72 hours of public disclosure. WordPress plugin vulnerabilities follow a specific pattern: a patch releases, the changelog says "security fix," security researchers reverse-engineer the diff to identify what was fixed, and automated scanners start probing for unpatched installations within days. Sites running the vulnerable version during that window are being actively scanned—not targeted by a human attacker picking your business specifically, but swept up by indiscriminate automated bots that hit every site they can reach. Whether exploitation occurs depends on the vulnerability type, but the scanning never stops. Server-level CVEs in Nginx, OpenSSL, or the Linux kernel follow the same pattern.
What recovery costs. An SSL expiration caught same-day: 1-2 hours of developer time, plus whatever business was lost during the warning window. A PHP compatibility emergency under a 60-day hosting deadline: $600-$2,000+ depending on site complexity. A security compromise requiring forensic cleanup—identifying injected files, scanning the database for malicious content, reviewing access logs, rotating all credentials, then restoring and verifying clean—runs from $500 for a clean restore from a current backup to $2,000-$5,000+ when no clean backup exists and the attacker has been in long enough to add persistent backdoors. Against that: $30/month in managed hosting across the same time period. The math doesn't add up in favor of deferring.
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.
The WordPress maintenance burden. A WordPress site isn't a fixed codebase. It combines WordPress core, an active theme, and installed plugins—each maintained by different authors on independent schedules. WordPress core releases updates regularly; some are security releases needing prompt application. Themes release updates that sometimes conflict with plugins. Plugins release updates on their own cadence, and some of those updates are security patches needing immediate deployment because the vulnerability is already public and exploitation is automated.
The plugin treadmill is the specific mechanism that makes this labor-intensive. Each plugin update needs testing for compatibility with other installed plugins and the active theme, because plugin interactions cause conflicts. A plugin update breaking the contact form needs identification, rollback, and diagnosis. A plugin with a disclosed vulnerability waiting for the author to patch needs monitoring or replacement. A plugin the original developer installed and then abandoned (stopped maintaining but left installed) sits there accumulating security exposure with no incoming patches. The site owner must identify and replace it.
None of this is hypothetical. The WordPress.org plugin repository contains over 60,000 plugins. Vulnerabilities are disclosed regularly and tracked in databases like WPScan. The window between a vulnerability disclosure and automated exploitation can be hours. Sites running WordPress need someone monitoring plugin CVE feeds, applying updates urgently when security patches drop, and periodically auditing installed plugins for abandoned or high-risk dependencies. That is ongoing work.
Custom PHP maintenance has narrower scope. A custom site has a defined, fixed codebase: the code written to build it, the dependencies it uses, and the server environment it runs on. No plugin system to manage. No theme update lifecycle. No WordPress core updates to test for plugin compatibility. Maintenance reduces to server-level work: keeping PHP current, patching server software, renewing SSL, running backups, monitoring uptime. The application code itself doesn't generate an ongoing update treadmill because it's custom-written and maintained by the developer who built the site, not a third-party plugin ecosystem with its own 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, not just 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.
ArdinGate managed hosting covers all of these. Pricing starts at $30 per month for simpler sites and scales with complexity and hosting tier. There are no per-incident charges for things that fall within what maintenance covers. See managed web hosting details → See maintenance plans →
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 version management requires server access and testing discipline. Updating PHP isn't clicking a button in a dashboard. It requires SSH access to the server, knowledge of the hosting environment's configuration, and a testing process before switching production over. On shared hosting, you might change the PHP version through a control panel, but you still need to test the site afterward and know what to look for when things break. If you're not a developer and don't have a staging environment, this is hard to do correctly.
SSL management requires monitoring and access to DNS or file systems. Automated SSL renewal (Let's Encrypt/certbot) needs a cron job configured correctly and monitored for failures. A renewal job failing silently for three weeks, then failing again, means the certificate expires before anyone catches it. Manual renewal, depending on certificate type, may require creating DNS records or placing challenge files in specific server locations. On managed hosting, someone confirms these work. On your own, you're checking cron logs and crossing fingers.
Backups require off-server destination setup and testing. Setting up automated offsite backups means configuring a storage destination (S3 bucket, Backblaze B2, Rclone to cloud storage), writing or configuring the backup script, scheduling it as a cron job, and periodically testing that backups restore. A backup job appearing to run but silently erroring is worse than no backup—it creates false confidence. Testing a restore means actually restoring a backup to a separate environment and verifying the site works, not just confirming that backup files exist on the storage destination.
Uptime monitoring requires an external service. You can't monitor uptime from the server itself—if the server is down, any monitoring tool on that server is also down. Effective uptime monitoring needs an external service that probes your site from a different network. Setup takes about 20 minutes. The DIY problem isn't setup—it's whether someone is actually reading alerts and acting on them at 3am Saturday when servers tend to go down.
The compound attention problem. Each task individually is manageable if you're technical. The problem is that they all demand ongoing parallel attention on a timeline that doesn't align with your business's natural work rhythm. PHP end-of-life dates don't coincide with slack periods between projects. SSL certificates don't expire during business hours when you're checking server logs. The maintenance calendar runs on its own schedule, and missing any task compounds: skip a PHP update and your site stays on an unsupported version. Future security patches for that version won't exist, meaning risk exposure grows every week.
The real 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 upgrade. A hosting provider announces PHP 7.4 support ends on their platform in 30 days. Your site is on PHP 7.4. This is now an emergency—not because the codebase changed, but because you're out of time to do it carefully. A developer needs engagement on short notice (which costs more than scheduled work), the site needs testing against PHP 8.x, compatibility issues need identification and fixing, and all of this must happen in 30 days or the site breaks. If compatibility issues exist, they need resolution under time pressure. Total cost depends on how many issues exist, but it's reliably more than the maintenance that would have kept PHP current all along.
SSL expiration incident. An expired SSL certificate is recoverable, but recovery takes time. The certificate needs renewal, DNS changes may need propagation, server configuration may need updating, and the certificate needs installation and verification. During that window, every visitor sees a security warning. For a small business where reputation rests on trust, having every visitor see a browser warning that the site isn't secure carries a credibility cost that's hard to quantify but undeniable.
Security compromise recovery. When a site is compromised through an unpatched vulnerability, recovery is more involved than most owners expect. If a clean backup exists from before the compromise, recovery is faster but still requires: restore from backup, identify and close the vulnerability, rotate all site-related credentials, and monitor after recovery to confirm the attacker doesn't have a persistent foothold. If no clean backup exists, recovery means manually auditing every file in the document root for injected code, scanning the database for modifications, and reviewing access logs to understand what the attacker accessed and how they got in. Professional malware cleanup for a WordPress site ranges from a few hundred dollars for a straightforward case to several thousand when a persistent attacker added multiple backdoors.
The downstream costs. These don't show on any invoice but measure up in lost revenue. A site down for four hours during business loses contact form submissions that entire time. Depending on traffic and conversion rate, those are real missed leads. A site showing a security warning for two days gets visitors leaving immediately who won't return. These downstream costs pile up quietly and are never fully recovered.
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 registration and DNS management. Your domain name is held through a registrar (GoDaddy, Namecheap, Cloudflare, Google Domains, etc.). Domain renewal is entirely your responsibility and your registrar's. A lapsed domain causes a site outage that looks identical to a server outage but has a completely different cause and resolution. A developer managing your server can't renew your domain because the registrar account belongs to you. DNS records (those pointing your domain at the server) fall into a similar bucket. Initial DNS setup is part of site launch, but ongoing DNS management—adding MX records for email, updating nameservers, adding CNAME records for third-party tools—needs registrar access and is a separate task, not an infrastructure maintenance item.
Third-party service integrations that live outside your site. A Google Business Profile, a Yelp listing, a Facebook Business page, a Google Analytics property, an email marketing platform—these are services your business uses, not components of your site's infrastructure. Maintenance covers the server and application stack your site runs on. If Google Search Console flags a manual action, that needs a response through Google's interface, not a server-level fix. If your email marketing platform changes its embed code, updating the embed in your site is a content task, not maintenance. If Google Analytics stops receiving data because a browser change blocks the tracking script, that's also outside maintenance scope—it's a configuration change in the analytics platform.
SEO performance and search ranking. Website maintenance keeps the infrastructure that search engines look at working: the site stays up, loads quickly, responds correctly to Google, and doesn't trigger browser security warnings that send negative signals to search engines. What maintenance doesn't do is improve organic search rankings, fix thin content, address a Google core algorithm update that penalized the site, or build links from other sites. Technical problems from an infrastructure failure—a server throwing errors during a PHP outage, a site dropping out of Google's results because the SSL certificate lapsed and Google saw a security error—are indirectly addressed by maintenance. But maintenance isn't an SEO service, and it won't improve a site's ranking for target keywords.
Bugs in the original build that existed at launch. There's a meaningful distinction between a bug that appeared after launch because something outside the site changed (a browser update, a server configuration change, a third-party API deprecation) and a bug that existed on day one because something was never implemented correctly. The first type is maintenance-covered: the site worked, then something external changed, and now it doesn't. The second type is a warranty issue with the original build. This distinction should be established in the original development contract. Bringing it up for the first time during a maintenance conversation typically creates disagreement about what the original build was supposed to do. Much easier to settle that before the site launches than after.
Performance optimization beyond baseline infrastructure health. Managed maintenance keeps a site running on current PHP, a patched server stack, and reliable infrastructure. It doesn't include deeper speed work: detailed performance reviews, passing Google's page-speed and stability health checks, shrinking image file sizes, tuning the database, or adding systems that remember files so repeat visits load faster. Not because those things are unimportant, but because they're development work scoped per project rather than included in a flat monthly infrastructure fee. A site that scores well on Google's speed test at launch stays at that level; pushing it from good to near-perfect is a separate performance optimization engagement.
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.