In short: a site in production remains a living system. Serious maintenance combines inventory, tested updates, restorable backups, supervision, access management, certificate renewal and incident procedure.
The online publication does not freeze the project. The operating system, framework, extensions, libraries and external services evolve. Certificates expire, APIs change and new vulnerabilities are released.
The purpose of maintenance is not to promise the total absence of incidents. It is to reduce the probability, detect earlier and restore the service in a controlled manner.
Keep a usable inventory
List domains, DNS, certificates, servers, containers, databases, repositories, accounts, third-party services, and owners. For each element, note its role, its manager, its renewal method and its backup procedure.
An inventory prevents a domain from expiring with the address of a former collaborator or that a critical integration is based on a personal key. It also facilitates the evaluation of a safety advice: is the dependence concerned really used and exposed?
Establish an update policy
Classify the changes according to their criticality. An actively exploited security correction may require urgent action; a major version often requires a larger acceptance testing. Automate the detection of new versions, not their blind deployment in production.
The recommended stream goes through a controlled environment, tests, a backup and a backtrack possibility. Read the release notes and check for data migrations before the tick.
Manage the dependency chain
Direct dependencies are only a part of the supplied software. Lock versions, scan the tree, delete unused packages, and choose libraries that maintain. Automatic alerts must be qualified: version touched, function used, exposure and patch available.
Do not hide a critical opinion only because the build passes. Conversely, do not hastily replace an entire architecture without checking if the risk applies. Document the decision and the deadline.
Save to restore
A copy is not a reliable backup until it has been restored. Set the frequency according to the acceptable data loss, keep several generations and separate at least one copy of the main environment.
Protect backups with encryption and access control. Include the database, user files, essential configurations and secrets in a secure method. Document the restoration order and periodically test it on an isolated environment.
Monitor availability and errors
A simple verification of the home page does not guarantee that the contact, payment or customer area works. Create representative controls: service status, TLS expiration, disk space, server errors, email queue, and critical integrations.
Alerts must be actionable and have a recipient. Too many ignored alerts produce less security than a small number of reliable signals. Define levels, schedules and climbs.
Protect accounts
Apply any privilege. Each person has their own account; shared accounts are avoided. Multi-factor authentication protects administrative access when available. Departures and role changes trigger an immediate review.
SSH keys, API tokens and passwords remain out of the repository. Use an adapted manager, controlled rotation and access logs. A temporary key must have a withdrawal date or condition.
Harden the application and hosting
HTTPS, canonical redirection, secure cookies and adapted headers form a first layer. A Content Security Policy limits authorized sources; it must be tested so as not to block legitimate functions.
Server-side validation, authorization checks and injection protection remain essential. The OWASP Top 10 project provides an up-to-date awareness document on the major risks of web applications; it does not replace a system-specific analysis.
Separate authentication and authorization
Being logged in doesn't mean you can access all the data. Each sensitive request verifies the role, resource ownership, and server-side requested action. Hidden interfaces do not constitute a security barrier.
Test horizontal access: can one customer consult the identifier of another? And vertical: can an ordinary role call an administrator action directly? These scenarios must be part of the automated testing of the portals.
Journal without exposing
Logs record the events necessary for diagnosis: time, action, status, correlation identifier and component. They must not contain passwords, keys, complete numbers or unnecessary personal data.
Centralize what should trigger an alert and apply a retention period. A trace is only useful if it can be consulted during an incident and linked to other events.
Prepare the response to incidents
The procedure indicates who decides, how to isolate the problem, preserve useful elements, inform the parties concerned and restore. It distinguishes the unavailability, compromise, loss of data and defect of a supplier.
Prepare coordinates outside the potentially affected system. After resolution, write a factual feedback: chronology, cause, impact, correction and prevention. The goal is to improve the system, not to look for a convenient manager.
Maintain performance and accessibility
A new banner, font or extension can slow down the site and create a keyboard block. Add weight checks, functional tests and automatic audit on representative templates.
Follow the Core Web Vitals and the accessibility in time. Quality is not a fixed certificate on the day of launch.
Check the SEO after each structural change
An update can change canonicals, HTML rendering, URLs, or sitemap. The deployment process controls statuses, metadata, structured data, and priority links. During a migration, use a complete SEO redesign plan.
Keep the necessary redirects and watch for 404 errors. A content deletion requires an editorial decision, not just a file cleanup.
Define responsibilities and level of service
Who receives the alert? Within what time frame is she qualified? What hours are covered? What data loss and duration of unavailability are acceptable? These responses depend on the contract and the criticality of the service.
Avoid vague promises of availability or reaction. Document the scope, exclusions, channels and how incidents are prioritized.
A minimum monthly routine
A regular review may include: update status, vulnerability alerts, backups and scheduled recovery tests, certificates, accounts, errors, disk capacity, performance, forms, payments and external services.
The frequency increases for critical or very active systems. The results are kept in order to identify a drift and to demonstrate the actions actually taken.
BlackStone Digital offers support, maintenance and support of sites and applications. To define a realistic plan, indicate the current stack, hosting, critical routes and responsibilities.
