This SOP governs every monthly maintenance retainer engagement. It defines exactly what is done, in what order, on what schedule, and how it is documented. Following this SOP on every retainer client ensures consistent quality, a written record of all work performed, and protection against disputes about what was or was not done in a given month.
Run this SOP once per month per client, between the 1st and 10th of the month. Never batch multiple clients into a single session without documenting each site separately. What happens on one client's site should never be confused with another.
Time per client: Basic plan — 30–45 minutes. Standard plan — 45–75 minutes including content changes. Premium plan — 60–90 minutes including analytics review and content.
Before doing anything: Confirm the monthly retainer payment has been received. Per the maintenance retainer clause, services for a month are suspended if payment is not received by the 15th. Never perform maintenance work for a month that has not been paid.
1
Open the client record in Notion
Open the client's CRM row. Confirm: retainer tier, hosting platform, any notes from last month, and any content change requests received since the last maintenance session. Read the previous month's status note before starting work.
2
Verify the backup from last night
Log into the hosting dashboard (Kinsta MyKinsta or Pressable). Confirm a backup completed successfully within the last 24 hours. Note the backup timestamp. If no recent backup exists, trigger a manual backup before making any changes. Never apply updates without a confirmed backup in place.
3
Apply and test all updates on staging
See Section 02 for the full update procedure. Do not apply updates to the live site without staging testing first. This is the most time-consuming step and the most important.
See Section 04. Check Wordfence or Solid Security for any flagged items. Check the hosting platform's malware scan. Review failed login attempts. Note any anomalies.
5
Process content changes (Standard and Premium)
See Section 06. Work through any content change requests received during the month. Log time. Stop at the plan's hour limit and notify the client if additional requests remain.
6
Send the monthly status email
See Section 05. Send the status summary to the client. Include updates applied, backup status, security summary, content changes completed, and any recommendations. File a copy in the client's Notion row.
1
Create or refresh the staging environment
Kinsta: Log into MyKinsta → select the site → Staging → Push live to staging. This overwrites the staging environment with the current live site. Takes 2–5 minutes.
Pressable: Log into Pressable dashboard → site → Clone to staging. Same result.
Confirm the staging URL loads correctly before proceeding.
2
Apply all updates on staging
Log into the staging site wp-admin. Go to Dashboard → Updates. Apply in this order:
1. WordPress core (if available)
2. Plugins — all at once unless a plugin has a major version jump (e.g. WooCommerce 8.x → 9.x), in which case update it alone first
3. Kadence Theme and Kadence Blocks
After each batch, visually check the homepage, a service page, the contact page, and the booking integration. Open the browser console (F12) and check for JavaScript errors.
After all updates are applied on staging, systematically review:
- Homepage at mobile (375px) and desktop (1280px)
- Contact page — form submits and notification arrives
- Booking tool — embed loads and is functional
- Navigation opens on mobile
- Footer displays correctly
- Any page that uses custom Kadence blocks heavily
If anything is broken, identify the offending plugin by deactivating the most recently updated plugin and retesting. Roll back that plugin using WP Rollback if needed.
Kinsta: MyKinsta → Staging → Deploy staging to live. Select "Copy files and database" unless there is a reason not to. Review the deployment summary before confirming.
Pressable: Pressable dashboard → Deploy to live.
After deploying, clear the site cache immediately. Kinsta: MyKinsta → Cache → Clear all. Pressable: Pressable dashboard → Clear cache.
Verify the live site loads correctly and run a quick spot-check on the homepage and contact page.
5
Document what was updated
In the client's Notion row, add a note with the date and a list of what was updated. This becomes the content of the monthly status email and the record if a client ever asks "what changed last month?" Format:
2026-06-05 — Monthly updates
WordPress: 6.5.2 → 6.5.3
Kadence Theme: 3.2.1 → 3.2.4
Kadence Blocks: 3.1.8 → 3.2.0
Yoast SEO: 22.4 → 22.5
WP Rocket: 3.16.1 → 3.16.3
No issues found on staging. Deployed.
Both Kinsta and Pressable include automated daily backups. Your responsibility is to verify they are running and, quarterly, to confirm a restore actually works.
★
Monthly backup check — Kinsta
MyKinsta → Sites → select site → Backups. Confirm:
- A backup completed within the last 24 hours
- Backup type shows "Automatic" (not just manual)
- Backup size is consistent with prior months (a sudden size drop may indicate an issue)
Kinsta retains daily backups for 14 days on standard plans. If a client needs longer retention, upgrade to a plan that includes it or configure UpdraftPlus to an external destination (Google Drive, S3).
★
Monthly backup check — Pressable
Pressable dashboard → Sites → select site → Backups. Confirm daily backups are active and the most recent completed successfully. Pressable includes daily backups with 30-day retention on all plans, which is better retention than Kinsta's standard 14-day window. Note this as a client-facing advantage when recommending Pressable.
Once per quarter, restore a backup to the staging environment and verify the site loads correctly. This confirms the backup is actually usable, not just recorded.
Kinsta: Backups → select a backup from 7 days ago → Restore to staging.
Pressable: Backups → Restore → Restore to staging environment.
Log the date of the restore test in the client's Notion row. If restore fails, investigate immediately and notify the client that backup configuration needs attention.
1
Check Wordfence dashboard
Log into wp-admin → Wordfence → Dashboard. Review:
- Blocked attacks in the last 30 days — note volume, flag any spike above normal baseline
- Failed login attempts — if username "admin" is being targeted, flag for hardening
- Any malware scan results — Wordfence scans automatically; review any flagged files
- Firewall status — confirm "Extended Protection" is active, not "Basic WordPress Protection"
2
Check hosting platform security
Kinsta: MyKinsta includes an automatic malware detection tool under Security. Check for any flagged issues. Kinsta also blocks a large volume of attacks at the server level before they reach WordPress — you will see this reflected in lower Wordfence blocked-attack counts compared to shared hosting.
Pressable: Pressable includes Jetpack Security on all plans. Check the Jetpack Security dashboard for malware scan results, brute force protection status, and any plugin vulnerability alerts. This is one of Pressable's most significant value-adds — note it in the client status email.
Visit the live site in Chrome. Confirm the padlock icon appears in the address bar. If Chrome shows "Not Secure," the SSL certificate has lapsed or has a configuration issue — this is an urgent fix.
Both Kinsta and Pressable include free auto-renewing SSL certificates. If the certificate has lapsed, go to the hosting dashboard and force a renewal. SSL issues at renewal are rare on managed hosts but not impossible.
Both Kinsta and Pressable include uptime monitoring. Check the monitoring log for any downtime events in the past 30 days. If the site went down and you were not alerted, confirm the monitoring notification email is still correctly configured to your address. If a client's site experienced downtime, include it in the status email with the duration and cause (if known).
The monthly status email is the most important client-facing deliverable in your maintenance retainer. Many clients feel their maintenance fee is invisible because nothing visibly broke — the status email makes the work tangible. Clients who receive a consistent status email cancel retainers at a fraction of the rate of clients who hear nothing.
Monthly status email template
Subject: [Practice Name] — website update, [Month Year]
Hi [Name],
Here is a summary of this month's maintenance work on [their URL].
UPDATES APPLIED
[List each: plugin/theme name, old version → new version]
WordPress core: [version] → [version] (or "no update available")
BACKUP STATUS
Daily automated backups are running. Most recent backup: [date and time].
Backups are retained for [14 / 30] days.
SECURITY
[X] blocked attack attempts this month — all handled automatically.
No malware detected. SSL certificate active.
[Only mention failed logins if volume is abnormal.]
CONTENT CHANGES THIS MONTH
[List each change made, or "No content changes requested this month."]
[Standard plan: X of 1 hour used. Premium plan: X of 2 hours used.]
RECOMMENDATIONS
[Include only if there is a genuine recommendation — e.g. a plugin with
a known vulnerability, a PageSpeed regression, a form that has stopped
working. Leave this section out if there is nothing to report.]
Let me know if you have any questions or content changes for next month.
Charles Hardt
Hardt Web Development
charleshardt.com
Send between the 5th and 10th of the month for the prior month's work. Never send the same day you do the work — let the updates settle for 24 hours before reporting. If anything breaks in that window you want to catch it before the client sees the email.
Content change hours are the most frequently disputed element of maintenance retainers. The only protection against disputes is a written log. Log time to the nearest 15 minutes for every content change, including the change made, the time spent, and the running total against the plan's hour allowance.
1
Scope of included content changes
Included: Text edits, photo replacements, adding or updating staff bios, updating hours and contact information, publishing blog posts the client supplies, minor formatting adjustments, updating service descriptions with client-supplied copy, adding events to a calendar.
Not included (change order required): New page creation, new feature development, plugin customisation, design layout changes, new integrations, e-commerce changes, any work requiring more time than the plan's monthly allowance.
Log time in the client's Notion row:
Content changes — June 2026
06-03: Updated staff bio (Dr. Smith) — 0:15
06-10: Replaced hero image — 0:15
06-18: Added June events to calendar — 0:30
Total used: 1:00 of 1:00 (Standard plan)
If requests exceed the plan limit, email the client before starting the overage work: "I have used the 1 hour included in your plan. I have one more request from you — do you want me to complete it as a change order at $[rate]/hour, or hold it for next month's allowance?"
3
Quarterly extras — PageSpeed and broken links
Standard and Premium plans include a quarterly PageSpeed report and broken link scan. Run these in months 3, 6, 9, and 12 of the retainer year.
PageSpeed: Run pagespeed.web.dev on the homepage and primary service page. Compare to the launch baseline recorded in the handoff document. If mobile score has dropped below 80, investigate — a recently added plugin or unoptimised image is the most common cause.
Broken links: Run Broken Link Checker plugin on demand (do not leave it active permanently — it creates server load). Export any broken links. Fix internal broken links directly. Flag broken external links to the client for their decision.
| Task | Basic $150/mo | Standard $250/mo | Premium $400/mo |
|---|
| WP core, plugin, theme updates (staged) | ✓ | ✓ | ✓ |
| Daily backups verified | ✓ | ✓ | ✓ |
| Security scan and uptime check | ✓ | ✓ | ✓ |
| Monthly status email | ✓ | ✓ | ✓ |
| Content changes per month | None | 1 hour | 2 hours |
| Quarterly PageSpeed + broken link report | — | ✓ | ✓ |
| Monthly GA4 analytics summary | — | — | ✓ |
| Priority 24-hour response | — | — | ✓ |