Start your first digest

Notes

One maintenance process for WordPress, Webflow, Squarespace, and custom sites

3 November 2026

The book is never one stack. A WordPress site the client is afraid to touch. A Webflow site their designer edits on Thursdays. A Squarespace site that was “temporary” in 2022. A small custom app you deployed yourself. The retainer question is the same on all four, and it arrives in the same inbox: what did you do this month? A process that only works inside wp-admin cannot answer that for the other three.

The product argument for a report that sits above the stack is already on reporting beyond WordPress and, for the agency shape, on reporting for agencies. I am not going to re-argue it. This note is the operating process: one roster, one outside pass, a short stack-specific pass, and one shape of letter. The letter’s blank form is the template. A filled sample digest shows the length I mean.

The roster is the process

Before the checklist, I want one row per site that a colleague could run without asking me. If the row is incomplete, the pass will invent answers, and invented answers are how a Webflow site gets a fake plugin line. I keep the row in a sheet, not in my head.

Client:
Public URL:
Money path: (checkout, booking, contact, donate)
Stack: WordPress | Webflow | Squarespace | custom
Who may edit content:
Who may deploy or update:
Registrar owner, and expiry date:
Certificate: platform-managed | proxy on our server | other, expiry if you have it
Backup owner, and where the copy lives:
Where the letter URL is:
Plan name: Watch | Care | Studio

The plan names are the packages in the pricing note. If you use different names, use those, but use them on every row. A stack column without a plan column is how you do Care work on a Watch price because the site happened to be WordPress and WordPress feels like it needs more.

“Who may edit” is the row that prevents the fight. On Webflow and Squarespace the client often edits. On WordPress they sometimes edit and sometimes they have been told not to. On a custom app they almost never edit, and if they can, you will find out via a broken layout. Write the name of the person, not “the client.” Clients are companies. People click publish.

Ownership split across four stacks. Content edits sit with the client on Webflow and Squarespace. Deploys and DNS sit with you on a custom app. WordPress updates sit with whoever the plan names.
Write the person’s name on the row. “The client” is not a login.

What is the same on every stack

The outside pass does not care how the site is built. I described the hour itself in the monthly pass. The shared part, so this note can stand alone, is short.

That list is the whole common process. If you add a sixth item, check that it is possible on Squarespace without a login you do not have. If it is not, it belongs in the stack-specific pass, not in the common one. The common list is what lets a mixed Monday finish.

One maintenance flow: a shared roster, the same outside checks for every site, a short stack-specific pass, and the same shape of client letter.
The stack-specific box is allowed to be small. It is not allowed to replace the letter.

What actually changes

I keep a matrix in the same sheet, one line per stack, so I do not rediscover it every month. The cells below are the ones I am willing to say in public, with the vendor docs next to the claims that need them.

Matrix of WordPress, Webflow, Squarespace, and a custom app. Columns are who can log in, where updates happen, who owns the backup, and where the certificate comes from.
Read across a row before the pass. The backup cell is the one people leave blank.

WordPress

You often have wp-admin, and the plan should say whether updates are yours. WordPress’s own upgrade guide splits core updates into development, minor, and major. Minor maintenance and security releases have auto-updated by default for years. From 5.6, a new installation also auto-updates major releases unless WordPress detects a version-control checkout. An existing site keeps the older behaviour, minor only, unless someone turned major updates on. I write down which of those this site is, because “updated WordPress” is only true when a person did it.

Backups and plugin fleet tools can stay in whatever operations product you already trust. ManageWP and MainWP are built for that job. I do not try to turn the client letter into that dashboard. The page that says so, including what those tools are good at, is the ManageWP client reports note. The 2026 list is ManageWP alternatives for agencies, and the MainWP version is MainWP alternatives for the client report. Care-plan wording, when the site really is WordPress, is care-plan reporting. The letter for this site still uses the same headings as the Webflow site next to it.

The stack-specific pass is: updates you are responsible for, users you do not recognise, whether the backup job succeeded, then the public site again while logged out. That is the pass. A plugin changelog in the letter is optional and usually worse than one outcome line.

Webflow

There is no server for you to enter, and there are no plugins to update. Publishing is the deploy. Webflow’s help on custom code says the head and body areas, and the embed element, take HTML, CSS, and JavaScript. They do not run server-side languages. Each of those areas is capped at 50,000 characters. Their support policy, stated on that page, is that they will not troubleshoot the custom code. If the site depends on a script you pasted, you own that script. The monthly line is not “updated Webflow.” It is “published the footer change,” “form notifications now go to the studio manager,” or “the custom script in the footer is still the one we added in May, and the form still submits.”

Backup, said honestly, is an export or a duplicate of the project inside their product, on the cadence their plan allows. I do not tell a Webflow client I have a server snapshot. I tell them what I can actually restore, and I have tried the export once so the sentence is true.

Squarespace

Same constraint, different panel. Squarespace’s help article on custom code, updated 27 August 2026, says adding code is an advanced change outside the scope of their support. Code injection, for HTML and scripts, is available on the Core, Plus, and Advanced plans, and on some legacy plans. If the site is not on one of those, you do not have that lever, and the roster should say so. I check that injection I added is still the injection I added. I check the domain connection and the form or commerce path. I do not SSH. I do not write “patched the server” because there is no server of mine to patch.

When something breaks inside their platform, the letter can say “Squarespace’s hosting had a problem, here is what visitors saw, here is when it cleared.” It should not say “we fixed the data centre.” You did not.

Custom, on a box you run

Here you do have a server, a health URL, a deploy log, and a volume. The pass is the one in the hosting stack note: health endpoint, certificate attached in the proxy, backup copied off the machine, a restore you have actually done. The letter still does not mention the container name. “Checkout emails arrive again” is the line. The from-address bug is a second sentence only if they asked how.

A custom site in a mixed book is where people accidentally build a second process, with its own report format, because the other three sites “do not have deploys.” Resist it. The deploy is the work. The headings stay. Otherwise you are maintaining two businesses, and only one of them gets a letter.

One checklist, with a column that changes

I run this top to bottom. The third column is the only one I am allowed to skip, and only when the cell says “not our login.”

StepEvery siteOnly if this stack gives you the lever
1. RosterURL, money path, both dates, plan, editor’s nameFill any blank before you touch the site
2. OutsideHomepage, HTTPS, redirect, money pathA safe form submit
3. DatesCertificate and domain, even if platform-managedOpen the registrar if you hold it and a date is inside 30 days
4. StackNothingWordPress updates and users. Webflow publish state and script. Squarespace injection and plan. Custom health, deploy, backup drill
5. LetterSame headings, sent the same dayOne outcome line per real change. No version dump

Step 4 being “nothing” on the every-site column is deliberate. The moment a WordPress-only chore creeps into the every-site column, the Webflow rows start collecting apology text, and the Monday gets longer without getting more honest.

The lines change. The headings do not.

Four invented sites, so you can see the difference without borrowing a client. None of these numbers are measurements.

North mill (WordPress, Care)
Work: Contact form submissions arrive again. Routine plugin updates on Tuesday. Public site checked afterwards.
Watched: Homepage up through the month. Certificate renews on its own, next date 2 June. Domain expires 14 November, auto-renew on, you own the registrar.

Harbour (Webflow, Watch)
Work: No content edits. That stays with you. Form notifications now go to the studio manager instead of the old founder address.
Watched: Homepage and the booking page answered. Certificate is on Webflow’s side. Domain expiry 9 January, card is in your Webflow account.

Field office (Squarespace, Watch)
Work: Removed the code injection that was loading a chat widget you no longer pay for. The page is quieter and the widget is gone.
Watched: Homepage answered. Code injection remains available on your current plan. Domain expires 3 April at the registrar named in the roster.

Ledger (custom, Care)
Work: Checkout receipts arrive again. The sender address had been the old one.
Watched: Homepage and /checkout answered. One 11-minute gap on 4 March, recovered on its own. Certificate on our proxy, renews automatically. Backup restore drill passed on 2 March, off-site copy.

Same skeleton. A reader who only sees one of them still knows where the work is. A reader who sees all four, because they are the same client’s group, does not have to learn four report styles. That is the whole courtesy.

Handoffs, so the pass is not a blame meeting

Mixed books fail in the gap between “they edited” and “you were supposed to notice.” I put three sentences in the proposal, not in a later argument.

When a publish on Thursday breaks the booking page, the letter says the page was restored and what the visitor saw. It does not say “your designer broke it,” even when that is what the log shows. I will say that to the named person, in a direct note, if it keeps happening. The monthly page is a record, not a weapon. Their board may read it. Write it that way every time, including the months you are annoyed.

Tools stay in their lane

I am allowed to have more than one tool. I am not allowed to have more than one client-facing story. WordPress operations can live in a fleet dashboard. Uptime, if the contract really says “within a minute,” can live in a dedicated monitor. The host you run for the custom app can have its own panel. The client opens one page.

The page is allowed to be boring. Boring is the same headings, the same link, the work in their words. A public status page, if they want a URL they can hit on a Sunday without emailing you, is a smaller object and it does not include the work. That split is white-label status pages. Do not promote the status page to “the report” because it was easier to automate. The report is the part with the sentences.

A Monday for a mixed book

This is a schedule for twelve sites, as an order of work. It is not a census of my clients, and it is not a claim that twelve is a magic number. If you have four, do four. If you have thirty, the order still holds and the day does not. Split the day before you split the process.

Order for a mixed book of sites: domain and certificate dates first, money paths second, stack-specific updates third, and the client letters last.
Dates first, because a domain inside the week changes the rest of the day. Letters last, because they should describe a pass you finished.
  1. Sort the sheet by domain expiry, then certificate expiry. Anything inside 30 days is today’s real work. Do those tasks, or send the ask to the person who holds the login, before you open a design tweak.
  2. Outside pass on every row, money path included. Take notes in the ugly list. Do not write the letter yet. You will be tempted. You will write it twice.
  3. Stack pass only on rows where the plan gives you the lever. WordPress updates together, so you are in that mindset once. Then the builders. Then the custom apps, which need the deploy log and not the design canvas.
  4. Translate and send. One letter per site, same day as the pass. If you ran out of afternoon, send the ones you finished and put the rest on tomorrow morning. A letter about a pass from last week describes a different week.

I do not context-switch per client, doing one site from roster to letter before the next. That feels tidy and it is slow, because you reopen four products twelve times. Batching the outside pass is also how you notice that three sites share one expiring domain and you almost wrote three calm letters about it.

The custom apps still get the hosting checks from the stack note, including a restore drill on its own calendar, not inside this Monday. A restore does not fit between two Webflow publishes. Pretending it does is how the drill gets skipped. The Monday confirms the drill’s last date is recent. The drill itself has a slot.

When the book should stop being one process

Almost never for the letter. The letter stays one shape. Split the work underneath when a site’s risk is genuinely different: a checkout that takes money every day, a membership site with accounts, anything with personal data you agreed to treat as such. That site can have a tighter probe and a named on-call window. It still gets the same headings in the letter, plus the extra sentence the tighter promise requires. What it does not get is a second vocabulary. The day you have “digests” for brochure sites and “QBR decks” for the shop, you will update one of them, and it will be the deck, late, badly.

If a client wants a login to a fleet dashboard, they can have a conversation about whether they are still a care client or whether they want to be in the operations tool. Those are different products. I would rather keep the care letter and decline the dashboard seat than teach them a UI I will then have to explain at every renewal. The renewal is easier when the only URL they needed all year is the one in the letter. That URL, for the way we build it, looks like the sample.

Sources