The short answer
Website maintenance with Claude Code is a recurring, read-only inspection that produces a report with evidence, followed by separate, small, reversible changes for anything the report found. The agent reads the repository and the configuration and tells you what it observed; the checks that can only be made from outside — does the form deliver, is the certificate valid, does the backup restore — are made by you, from a phone or a scratch host, and written into the same report. The checklist below is daily, weekly and monthly. Most sites need the weekly column and one hour a month.
The failure this guide is built around is the quiet one. Nothing on a small business site announces itself when it breaks: the form shows "Thanks!" and delivers nothing; the certificate renewal is "enabled" and has failed three nights running; the backup job says SUCCESS with zero bytes uploaded. Each of those is in the controlled example further down, because each one was found on a real site by someone who thought it was fine.
What maintenance is, and what it is not
Four kinds of work get called maintenance, and mixing them is how a weekly check turns into an afternoon of unplanned changes.
- Maintenance is inspection on a schedule, plus the small corrections it produces: a dependency update, a broken link, a stale redirect. Its output is a report and a short list of changes, each reversible.
- Development is new capability. It has a branch, a review, a test plan, and it does not happen inside the maintenance window, because a change that arrived "while I was in there" has no record.
- Emergency response is when something is down or leaking. It has its own discipline — stop the bleeding, preserve evidence, communicate — and it is not made better by a checklist designed for Tuesday mornings.
- Deployment is the act of putting a change live. Maintenance depends on it (a dependency update has to ship) but is not it. The deployment pipeline guide covers the gates and the rollback; this guide assumes you have one, or that your platform is the pipeline.
The practical rule: the weekly check changes nothing. It observes and writes down. Changes happen afterwards, one at a time, each with a way back. This is the same separation the website audit and the technical SEO audit insist on, for the same reason: an audit that also fixes things leaves no record of what was wrong.
Prerequisites
- Claude Code installed and working in the site's repository, with a CLAUDE.md that names the real commands and the things that must never be done.
- A recorded baseline: the redirects, the DNS records, the security headers and the platform settings as they are today. If you do not have one, the first weekly check produces it.
- Somewhere off the server to put the reports. A
reports/directory in the repository is fine. - For your own hosting: shell access, the certificate tooling's logs, and the backup job's log. For a hosted platform: admin access and the export functions.
- Python 3.8 or later if you want to run the small outside-in checker in the download; it has no dependencies.
The checklist: daily, weekly, monthly
The cadence is a starting point. Move items between columns as the site's risk changes: a site that takes bookings tests its form weekly; a brochure site that changes twice a year can test monthly and spend the weekly minutes on links.
Daily, two minutes or automated
- The homepage and the one page that earns money return 200 from outside. An uptime monitor does this for you; if you do not have one, a phone on mobile data does.
- No incident overnight.
Weekly, fifteen to thirty minutes
- Every form that matters: one marked test submission, confirmed where a human reads it, with the send and arrival times written down.
- Navigation and footer links resolve to the page their label names.
- Broken links on the key pages; new entries in the 404 log.
- Certificate valid with more than fourteen days to expiry.
- Security headers unchanged from the baseline.
- Analytics still receiving events (the real-time view, not the monthly graph).
Monthly, one to two hours
- Dependencies: platform, plugins or packages, theme — reviewed; updates applied on staging first, then production, with a rollback point.
- Configuration drift: settings, redirects, DNS compared with the baseline.
- Backup: restore one somewhere and open it.
- Rollback readiness: the previous release still exists and the steps are written down.
- Performance on the key pages against last month.
- The report, written from evidence.
Adapt it in the file, not in your head. The download has the checklist as Markdown with an evidence column; if a line does not apply to your site, delete it there so the next person does not tick it anyway.
Forms, navigation and links
The form test is the most valuable line on the list, and the one most often skipped because "it worked last time". A form has two halves: the half a visitor sees, tested every time anyone fills it in, and the half that matters — the message arriving — tested only when someone checks deliberately. Between checks it fails silently. Plugin updates, a changed SMTP password, a spam filter learning a rule, a hosting move that dropped an environment variable: all of these leave the visitor looking at "Thanks!".
The check is: a unique marker (WK-2026-09-17-1412), submitted from a phone on mobile data, found in the inbox, with the time between send and arrival recorded. Then the failure case: a required field left empty should produce a visible error, not a success message. The Conversion Functionality Lab has a form that fails exactly that way, and the first Weekly Website Fix is this test, step by step.
Navigation and links are two different checks. "Resolves" — every link returns a 200 — can be scripted, and the checker in the download does it for the same-host links on the pages you name, within a budget. "Goes where its label promises" cannot be scripted: a link labelled Book that lands on a generic contact page resolves perfectly. That one is a person on a phone reading labels, and the second Weekly Fix.
Dependencies and configuration drift
Dependencies are the monthly item that most often becomes an emergency. The read-only inspection prompt below asks the agent to compare declared versions with available ones and to run the audit tooling the project already has — npm audit --omit=dev, composer audit, pip-audit — in read-only mode and report what it says. It does not update anything. Updates are applied on staging, tested with the same marked form submission and the same link check, and then applied to production with the previous version kept as the rollback. On WordPress that is the staging-first workflow with the database left alone; on a static site it is a branch and a preview deploy.
Configuration drift is the quiet cousin. Redirects get "tidied", a DNS record is changed for an email tool, a header is dropped during a CDN change. None of it is visible until something depends on it. The defence is a baseline — a file in the repository that records what the redirects, the DNS zone, the security headers and the platform settings were on a known date — and a monthly comparison against it. The first time you run the inspection there is no baseline; the prompt says so, and the report becomes it.
Certificates, and the renewal that says "enabled"
If your certificate is managed by the platform (Shopify, most managed hosts, Cloudflare in front of anything), this section is a weekly glance at the expiry date and nothing more. If you run your own, it is the item most likely to take the site down on a date you could have known in advance.
Let's Encrypt's default certificates are valid for 90 days and the project recommends renewing every 60; there is also an opt-in six-day certificate renewed every three. Automatic renewal is the norm, and "auto-renew: enabled" is what every dashboard says, including on the day the certificate expires — because enabled describes the timer, not the outcome. The check is the number of days to expiry (the checker in the download reads it from the live TLS handshake), and, when it is under about 30 for a 90-day certificate, the renewal log. Three consecutive "challenge failed" lines mean the timer is running and the renewal is not.
The next step is a diagnostic, not a fix: fetch the challenge path from outside and run the tooling's dry-run mode. Both are read-only and both tell you what is blocking the challenge — usually a firewall rule or a blanket redirect to HTTPS that fires before the challenge path. Forcing a renewal repeats the same failure and can consume rate-limited attempts. The Website Operations Lab walks through this exact case on a fixture.
Backup success is not restore success
A backup job reports on itself. "STATUS: SUCCESS" means the process exited without an error it recognised. It does not mean the files were the right files, that the database was included, or that the archive can be opened. Two failure patterns turn up often enough to name:
- The empty success. A source path with a typo. The job copies nothing, uploads zero bytes, and reports success every night for months.
- The half backup. The files are copied and the database step is skipped because the dump tool is missing — inside a job that still says SUCCESS. On WordPress and most CMSs the database is the site; the files are furniture.
The monthly item is therefore not "check the backup log". It is: restore one backup somewhere that is not production, open it, and look at a page and a recent record. Then read the log for the two patterns above. On a hosted platform where you cannot restore, the equivalent is an export you can open: the theme download, the data CSVs, the content export — taken on a schedule and kept off the platform.
Rollback belongs next to backup in the report because it answers the other half of the question: not "can we get the data back" but "can we get the previous version back, quickly, without losing what happened since". The third Weekly Fix rehearses it on the last deployment you made.
Reader-controlled versus hosted platforms
The checklist marks items (host) where a hosted platform runs them for you. The distinction matters in both directions.
On a platform you control — a VPS, a static host with your own pipeline, self-hosted WordPress — everything on the list is yours, and the agent can read most of it from the repository and the server: renewal timers, backup scripts, header configuration, dependency manifests. The inspection prompt is written for this case.
On a hosted platform — Shopify, managed WordPress, Webflow, Squarespace — certificates, headers, platform updates and infrastructure backups are the host's. What remains yours is smaller but not nothing: apps and their scripts (the equivalent of dependencies; the Shopify guide covers the leftover-app problem), theme code in your repository, redirects and settings that drift, the forms that still have to deliver, and exports you can actually open. The agent reads the repository half; you read the admin half. The report template has rows for both and does not let "the host does that" stand in for a check you could have made.
The two prompts, kept apart
One prompt inspects and changes nothing. A second prompt fixes exactly one finding from the first prompt's report. They are never merged, and the second is never run without the first's output in front of you. Both are in the download as prompts.md; the inspection prompt in full:
Read-only weekly inspection of this website's repository and configuration. Do not edit any file, run any command that writes, deploys, installs or updates, or submit any form. If a fix seems obvious, write it as a recommendation. Check and report, with evidence (file:line, command output, URL) for each: 1. Dependencies: declared versions vs latest available where a lockfile or manifest exists; advisories the tooling reports (npm audit --omit=dev, composer audit, pip-audit — run read-only). 2. Configuration drift: compare deploy/redirect/robots/security-header configuration in the repository with docs/BASELINE.md (or say the baseline does not exist). 3. Forms: each form's delivery path and every place a failure would be silent. Do not submit anything; say that delivery must be tested by hand with a marked submission. 4. Certificates and DNS: what the repository/config says about renewal — not whether it worked; that is checked from outside. 5. Backup and rollback: what the repository says exists (scripts, workflows, documented steps) and what evidence of a successful RESTORE exists. "Job succeeded" is not restore evidence. 6. Output: a table (check · observed · pass/fail/unknown · evidence), then findings by priority with a recommended change and its rollback, then "Not checked" with reasons. Do not invent numbers.
Running it in plan mode (claude --permission-mode plan) adds a second guarantee: Claude reads files and proposes but makes no edits until you approve, so even a prompt that drifted could not write. The remediation prompt takes one pasted finding, states the change, the files, the verification and the rollback before touching anything, works on a branch or the development theme, runs the project's checks and shows the output, and ends with what was verified and what was not.
The report template is the third piece. Its Evidence column is the whole point: a row that says "Forms deliver — PASS" with an empty evidence cell is not a pass, and the template's last section, "Not checked (and why)", exists so a blank is never read as one.
A controlled example: the check that failed
The outside-in checker in the download (weekly_check.py, standard-library Python) was run against a small fixture site built for this guide — a homepage with navigation and a contact page — with two faults planted: a navigation link to a page that does not exist, and a contact page whose form had been removed. The run is reproduced by scripts/test-weekly-check.py in this site's repository; the output below is from that run, not typed from memory.
Checks: 8 · passed: 6 · failed: 2 | Check | Subject | Result | Evidence | |-----------------------------|--------------------------------|--------|---------------------------| | page 200 | http://127.0.0.1:8080/ | PASS | 200 | | page contains 'Harbourline' | http://127.0.0.1:8080/ | PASS | found | | certificate | 127.0.0.1 | PASS | skipped (http) | | link resolves | http://127.0.0.1:8080/services | PASS | 200 | | link resolves | http://127.0.0.1:8080/contact | PASS | 200 | | link resolves | http://127.0.0.1:8080/team | FAIL | 404 | | page 200 | http://127.0.0.1:8080/contact | PASS | 200 | | page contains '<form' | http://127.0.0.1:8080/contact | FAIL | not found in first 400 KB |
Two findings, each with the evidence beside it. The resolution followed the remediation prompt: one change per finding — the link removed from the navigation, the form restored to the contact page — each verified by re-running the same check. The second run: seven checks (the dead link is gone, so it is no longer checked), seven passed, exit status 0. That is the whole loop: a check that can fail, a failure with evidence, a change small enough to describe in a sentence, and the same check passing afterwards.
Note what the checker did not do, because it cannot from outside: it did not tell you whether the restored form delivers. That row in the report was filled in by hand, with a marker and an inbox timestamp. The report template lists the four things the script cannot check so that nobody mistakes a green run for a maintained site.
How you know it worked
- Every row in the report has evidence: a URL, a timestamp, a command's output, a file and line. A row without one is moved to "Not checked".
- The form test has a marker in the inbox with a time. The certificate has a day count. The backup has a restored page someone opened.
- Every change made after the inspection is a separate commit or a separate platform action, each with the previous version still available.
- The check that found a fault was re-run after the fix and passed. If it was never seen failing, treat it as untested — the technical SEO audit guide makes the same rule for crawlers, and it holds here.
- Next month's report can be compared with this one, line by line.
Download the checklist and report template
The kit contains the daily/weekly/monthly checklist with an evidence column, the report template, both prompts, and the outside-in checker with an example configuration. No account, no email address.
Next action
Run the weekly column once, today, on one site, and write the report — including the rows you could not check. That report is the baseline for next week. Then take the Website Operations Lab, which hands you a health report with six findings and asks you to choose what comes first, and put the form test on your calendar as the first Weekly Website Fix. The generator above writes the checklist for your platform and adds the tasks to My Projects, so next Monday starts with "continue" rather than "where was I".