Red Web serves around 200 clients and operates more than 100 production and staging properties across nine managed servers. That wider responsibility shaped the repeatable maintenance approach described here.
Maintaining one website can be treated as a list of technical jobs. This note focuses on a bounded 20-site estate across two cloud environments, where the work requires a service: known scope, repeatable checks, controlled changes, evidence and reporting that another person can understand.
The problem
Updates alone do not prove that a website remains dependable. A maintenance cycle also needs to consider backups, certificates, errors, forms, security controls, performance and the practical consequences of changing shared components.
When those checks are performed inconsistently, the organisation cannot easily tell what was inspected, what changed or which risks remain.
The operating workflow
The quarterly process follows a consistent sequence:
- Confirm the estate and intended scope.
- Verify recovery arrangements before making changes.
- Inspect certificate, application and server health.
- Review available core and extension changes.
- Apply controlled maintenance and clear relevant caches.
- Test important user journeys, including forms.
- Review security findings and access concerns.
- Record changes, exceptions and follow-up work.
- Provide a client-readable report rather than an unexplained technical log.
The exact implementation varies between sites, but the evidence expected from each cycle remains consistent.
Technology used
- WordPress and WP-CLI for inventory, controlled updates, cache operations, account review and checksum verification.
- Ploi and SSH for hosting inventory, certificate state and server-level health checks.
- Cloudflare services for DNS, proxying and part of the recovery chain.
- The WordPress.org API for plugin maintenance information.
- The Google PageSpeed Insights API and Lighthouse for repeatable performance evidence and a fallback when API capacity is unavailable.
- The Notion API for scope records, internal evidence and client-readable reporting.
- Python and shell automation for repeatable checks across the estate.
The workflow uses APIs to gather consistent evidence, but every significant change is followed by a direct check of the live website.
Where automation helps
Automation is valuable for gathering version information, running repeatable checks, comparing state and preparing structured reporting. AI can assist with summarising evidence and identifying anomalies worth investigating.
Neither replaces technical judgement. A change can be technically available but inappropriate for a particular site. A green automated check can also miss a broken user journey. The workflow therefore combines repeatable tooling with direct verification.
Decisions I owned
I designed the operating sequence, the evidence required, the safety boundaries around changes and the reporting structure. I also retained responsibility for exceptions, remediation decisions and communication about risk.
The wider business scope and this maintenance example are deliberately separate: around 200 clients demonstrates breadth, while the 20-site estate demonstrates the operating model in detail.
What this project demonstrates
The project demonstrates service ownership, a repeatable operating model and risk-based decision-making. It also shows how automation can improve consistency without becoming a substitute for verification or accountable judgement.
It does not demonstrate enterprise AI deployment. Its relevance to AI operations is the underlying discipline: inventory, permissions, controlled change, verification, exceptions, recovery and evidence.
What is deliberately not published
This account excludes client credentials, domains not already publicly associated with the work, server addresses, administrative paths, scan output, vulnerability details and private reports.