Website maintenance after launch: what it covers and why

After launch, a website or web application needs regular security and dependency updates, planned framework upgrades, backups that are tested by actually restoring them, and monitoring that tells you about errors and downtime before your customers do. On top of that come periodic checks of speed, content and search visibility. Skipping maintenance rarely causes a problem in the first month. It causes a larger one later, when an unpatched plugin is exploited or an upgrade has been postponed so long that it turns into a rebuild.

#Why a finished website still needs work

Your code may stay the same after launch. Everything around it keeps changing. The language runtime, the framework, the database server, the libraries, the browsers and the third-party APIs all release new versions, fix vulnerabilities and retire old features. A payment provider may deprecate an API version. A browser may change how it handles cookies. A plugin author may stop supporting the plugin altogether.

Maintenance is the work of keeping your product compatible and safe while that happens. It is easier and cheaper in small, regular steps than in one large catch-up every few years.

#Security updates and framework upgrades

Most attacks on small and medium sites use known vulnerabilities in outdated software: an old CMS core, an unpatched plugin, a library with a published security advisory. Updating removes the easy targets.

• Check dependencies regularly. Tools such as composer audit, npm audit and the dependency alerts built into GitHub and GitLab report packages with known vulnerabilities.
• Apply security fixes quickly, and routine updates on a regular schedule, such as monthly.
• Update in a copy first. Apply updates on a staging environment, run the automated tests and click through the key flows before production.
• Remove what you do not use. Every unused plugin, module or package is code that can still be attacked.
• Keep the server side current too: the operating system, PHP, Node.js or other runtimes, and the database server. On managed or shared hosting the provider handles part of this; on a VPS it is your job or your developer's.

Security certificates belong on the same list. Most are renewed automatically today, but automatic renewal can fail silently after a DNS or server change. Our article on how SSL certificates work explains renewal and what happens when a certificate expires.

Framework upgrades

Frameworks such as Laravel, Symfony, Django, Next.js and Rails release major versions on a regular cycle, and each major version receives security fixes only for a limited period. The same applies to CMS platforms and to language versions such as PHP. Look up the support policy for each part of your stack and write down when the version you use stops receiving security fixes.

Plan upgrades before that date. Moving up one major version at a time is usually a contained piece of work, especially with automated tests in place. Skipping several versions means handling all their breaking changes at once, often with dependencies that no longer have compatible releases.

#Backups and restore tests

A backup that has never been restored is an assumption. Many teams discover during a real incident that their backups were incomplete, that they missed uploaded files, or that nobody knows how to restore them.

• Back up everything that matters: the database, uploaded files and configuration. The code itself should already live in a Git repository.
• Keep copies in more than one place. A backup stored on the same server as the site disappears with the server.
• Keep several generations. If data is damaged and nobody notices for a week, yesterday's backup already contains the damage.
• Test a restore regularly. Restore a backup into a separate environment, check that the site works and the data is complete, and write down how long it took.

#Monitoring, errors and performance

You should hear about a problem from your monitoring, before a customer writes to you.

• Uptime monitoring checks the site from outside at short intervals and alerts you when it stops responding. Check the pages that matter, such as checkout or login, as well as the home page.
• Error tracking tools such as Sentry collect exceptions from the server and the browser, group them, and show which release introduced them.
• Scheduled job and queue monitoring confirms that background work, such as sending emails or syncing orders, still runs. These failures are silent unless something watches them.
• Performance checks with tools such as Google PageSpeed Insights and the Core Web Vitals report in Google Search Console show how real visitors experience your pages. Slow database queries tend to appear as data grows, so review them from time to time.
• Disk space and certificate expiry are simple to monitor and cause surprisingly many outages.

#Content and SEO checks

A site can be technically healthy and still decline in search because of content problems. A short periodic review covers most of it:

• Broken internal and external links, and pages that return errors.
• Indexing and crawl reports in Google Search Console, including pages excluded from the index.
• Redirects for any page you moved or removed, so old links and search results still work.
• Outdated content: prices, opening hours, team details, legal pages and product information.
• Titles and descriptions on important pages, and that the sitemap reflects the current site.
• Contact forms, which fail more often than people expect, usually because of email delivery changes.

#What a maintenance agreement should state

Whether maintenance is done by the team that built the product, another developer or your own staff, write it down. A good agreement answers these questions:

• What is covered: security updates, dependency updates, framework upgrades, backups, monitoring, content changes, small fixes. Say explicitly which items are not covered, such as new features.
• How often: for example, security fixes as soon as they are released, routine updates monthly, restore tests quarterly.
• Response times: how quickly an urgent problem, such as the site being down or payments failing, gets a response, and how quickly normal requests do.
• How to report problems: the channel, the contact, and what counts as urgent.
• How work is billed: a monthly fee for a set scope, a pool of hours, or billing per request, and what happens to unused hours.
• Access and ownership: which accounts the developer can use, and confirmation that they remain in your name. See who owns the code and accounts for what to check.
• Reporting: a short record of what was updated, which incidents happened and what is coming, such as an end-of-support date.
• Ending the agreement: notice period and what is handed over.

#How PN Scripts can help

At PN Scripts, support, updates and new features continue after launch for as long as the client wants, with automated tests on critical paths such as payments, logins and data, and documentation that is kept up to date. If you need a team to maintain a site or application, see our web development services.