A maintained website can break during the maintenance itself. An update is applied on the live site, a page breaks, and nobody wrote down what the site looked like an hour earlier.
At Grafica we look after WordPress sites hosted on Kinsta, our own blog among them, and client sites we maintain for an agency inside the agency’s own Kinsta account. This post is the routine we follow, in the order we follow it.
The hosting stays the owner’s
On white-label work the sites stay in the agency’s own Kinsta account and we work inside it. We think that is the right arrangement for any owner: the account in your name, and whoever maintains the site invited to it as a user.
Every change is classed before work starts
A change is one of two kinds.
Critical: it can take the site down or slow it, or it touches WordPress core, the theme, plugins, templates, DNS, caching or more than one page.
Non-critical: content, one element, or a setting that can be reversed in one step.
The class decides the route. A critical change is rehearsed on a staging copy first, whether a visitor could see it or not; where staging cannot reproduce it, the sheet says so. A non-critical change may go straight to the live site.
The backup comes before the first edit
Before a critical change we take a full backup with the host’s own tool and write its time on the sheet. The time has to be earlier than the first edit. A manual backup on Kinsta expires. On our own blog’s last fix pass we recorded the expiry date next to the backup time.
We also write the way back before we start: which revision to restore, which setting to put back, and what restoring the full backup would cost. On a site that takes enquiries or orders, a full restore loses everything that arrived after the backup was taken. We wrote that cost down before the first edit on our own blog, and it belongs on the sheet for any site that takes enquiries or orders.
Staging, and its limits
We use the site’s staging environment on Kinsta for plugin and theme updates, template changes and anything that touches caching.
Staging does not catch everything. Two examples from our own blog, which is hosted on Kinsta.
When we forced HTTPS on it, the staging rehearsal could not tell us anything: the staging address already redirected to HTTPS before we changed a thing. We reported the rehearsal as inconclusive instead of as a pass.
After the same change went live, the first check passed on a deep post while the home page went on serving the old version for five minutes. An edge cache was still handing out the page from before. We only saw it because we tested two addresses, one that skips the cache and one that does not.
The read that counts is the visitor’s
When a change is live we read every touched page logged out, from outside, and record the cache status the host reports. A logged-in administrator can see a fresh page while the public gets a stored one. If the public page does not show the change, the change is not done.
One check is broken on purpose
A check that has never failed tells you nothing when it passes. On each handoff we break one check deliberately on staging, for example by pointing a link at a page that does not exist, confirm the check catches it, then put it back. The sheet says which check and how.
Updates, and how fast
WordPress released version 7.1.2 on 22 September 2026 to fix a critical flaw that, under certain conditions, an attacker could use without logging in. The fix was backported to every branch still eligible for security fixes, as far back as 4.7. Within two days a security company was reporting traffic against the flaw at more than ten times the volume of the first evening.
Sites that accept automatic background updates start that update on their own. Where those are switched off, a release like that goes to the front of the queue, and the order does not change: backup, rehearsal on staging, then the live site.
What the owner receives
After each handoff the owner, or the agency, receives one sheet with eleven checks: layout at four widths, text contrast, links, forms, errors, speed and stability, plugins and licences, backup and rollback, the class of the change, the failure we provoked, and what visitors get. Above them, three lines: what changed, where, and how to roll it back.
For an agency the sheet carries no branding of ours.
What we do not do
We do not delete anything permanently on our own decision. Sign-ins go through a password manager. And we do not report a job as done because the dashboard says so.
If your developers are full
If you run an agency with client sites on Kinsta, our Agencies page sets out how we take overflow work under your name. Our work is on the Work page.
Book a 30-minute intro call and bring one site you would hand over first.
