The Monthly Client-Website Checklist Every Agency Needs
· 6 min read
A monthly client-website checklist for agencies covers domain and DNS, SSL expiry, live form tests, and hand-off ownership before a client calls first.
In short
A monthly client-website checklist should cover five things: the domain and DNS are pointed correctly, the SSL certificate has more than 30 days left, the contact form delivers a test message, outbound email is not landing in spam, and no exposed files or broken links have crept in. SiteHealth is plain-English website health monitoring that runs these checks automatically instead of an agency doing them by hand once a month. Skipping one item is how a client site quietly breaks between visits.
What should an agency check on a client site every month?
A monthly check is only useful if it tests the things that fail without an error message. A site can look fine in a browser while its contact form silently drops every submission, or while its SSL certificate is nine days from expiring. The check needs to go past "does the homepage load" and actually exercise each system.
- Domain and DNS. Confirm the domain has not lapsed, the nameservers still point where you expect, and there is no dangling DNS record left over from an old hosting migration.
- SSL certificate. Check the days remaining, not just whether HTTPS currently works — certificates that auto-renew can still fail silently and the site stays "green" right up until the day it expires.
- Contact form. Submit a real test message from a phone on mobile data, not office wifi, and confirm it lands in an inbox, not just that a thank-you page appeared.
- Outbound email. Spot-check that mail sent by the site is not landing in spam, which is usually an SPF, DKIM, or DMARC problem rather than anything wrong with the message itself.
- Exposed files. Look for a browsable
.env,.gitfolder, or backup file left in place after a deploy, since a plugin or theme update can quietly reintroduce one. - Broken links. Check internal links, image sources, and the social icons in the footer, since a rebrand or a deleted page turns any of them into a dead end without warning anyone.
- Security headers. Confirm headers like a Content-Security-Policy or Strict-Transport-Security are still present after the last deploy, because a server migration or a new CDN in front of the site can quietly drop them.
Running this list against ten or fifteen client sites by hand raises a second problem: which one do you check first. Sort by severity, not alphabetically — a client whose contact form is dead needs today's attention, while a client whose social icon links nowhere can wait a week. Treating every finding as equally urgent is how a real fire gets buried under a backlog of minor ones.
Who owns the domain and DNS, and what happens if nobody does?
The client should own the domain, registered in an account only they control, even when the agency manages it day to day. The registrant is whoever's name and payment method are on file with the registrar, and that party is the only one who can renew, transfer, or move the domain to a new registrar without a dispute.
Problems start when an agency registers a client's domain under the agency's own account "to make things easier." It works fine until the relationship ends, the agency shuts down, or a renewal payment fails on a card nobody is watching, and the client discovers they have no login to fix any of it. ICANN's registrant rights guidance is explicit that the domain holder, not whoever manages the site, is the party with contractual standing over the name. Put the client in that seat from day one, and add the agency as a technical or admin contact if the registrar's account structure allows it.
The same problem shows up smaller with DNS. An agency that manages DNS through its own reseller panel, rather than the client's registrar dashboard, becomes a required stop for every future change — a new subdomain, a mail provider migration, a second vendor's verification record — even years after the original project ended. When that agency is unreachable, the client is stuck waiting on someone who no longer has a reason to answer, over a record that takes five minutes to add.
What belongs in a website hand-off checklist?
A hand-off checklist fails when it lists systems without owners. "Hosting: yes" tells the next person nothing about who can log in. Write down who holds each of the following, not just whether it exists:
- Domain registrar login — who has the account, and is two-factor authentication tied to a person who still works there
- DNS zone access — which panel controls the records, and who can add or change one
- Hosting control panel — cPanel, a VPS, or a platform account, and who pays the bill
- SSL renewal ownership — automatic through the host, or something someone has to trigger by hand
- Contact-form test address — a real inbox someone checks, so a monthly test actually gets read
- Backup location — where the last known-good copy of the site and database live, and how old it is
A checklist with six rows and an owner for each survives a staff change. A checklist that just confirms the systems exist does not.
How do you report a broken site to a client who does not speak website?
Say what broke, what it cost them, and what you did about it, in that order, without jargon. A non-technical client does not need to know what DNS stands for to understand that their contact form stopped sending them leads for six days. Lead with the business impact, not the technical cause, and put the technical detail second for anyone who wants it.
This is also where a monthly report earns its keep on a retainer. A report that shows what broke, what got fixed, and what stayed healthy turns a quiet month into visible proof of work, instead of an invoice with nothing to point to.
Why the manual version stops happening around the third or fourth client
A checklist run by hand works for one client. By the third or fourth, the SSL check for client A gets pushed a day, then the week, then it is only checked when someone remembers or a client calls first — and that call is the one you do not want. SiteHealth's agency plan exists for exactly this point: one dashboard covers every client site with hourly checks instead of a person remembering to run each one, and findings are already written in plain English so nobody has to translate them before sending a client a report. You can see the full list of checks it runs on the features page.
The honest objection here is cost: another line item on top of hosting and tools already in use. But a checklist that quietly stops happening after client number four is not actually cheaper, it is just a cost that shows up later as a lost client instead of a monthly bill. Weigh it against the one call where a client tells you their form has been silently broken for three weeks and asks why nobody caught it.
Start checking your first client site free
Run a free check on any client's homepage right now at health.sitestats.dev — no account needed, and you will see exactly what an hourly check catches before deciding whether to put every client site on one dashboard.
Questions people ask about this
What should an agency check on a client site every month?
Domain and DNS pointing, days left on the SSL certificate, a live test of the contact form, whether outbound email is landing in spam, and a scan for exposed files or broken links. Each of these fails silently, so a monthly glance at the homepage will not catch it. The check has to actually submit the form and read the DNS records, not just confirm the site loads.
Who should own a client's domain name, the agency or the client?
The client, registered in an account the client controls, with the agency added as a technical contact if the registrar allows it. When an agency registers a client's domain under its own account, the client cannot renew, transfer, or point it elsewhere without going through the agency, which turns a routine renewal into a dependency. Registrant details are the client's business property.
How often should an agency check a client's SSL certificate?
At least monthly, and ideally on an automated schedule that warns before the 30, 14, and 7 day marks. Auto-renewal fails more often than people expect, usually because a DNS change broke the domain-validation step it depends on, and the failure produces no error until the certificate is already expired.
What belongs in a website hand-off checklist for a new client?
The domain registrar login, DNS zone access, the hosting control panel, who is responsible for SSL renewal, a working contact-form test address, and where backups live. Write down who holds each one, not just that it exists, because a hand-off checklist that lists systems without owners still leaves the same gap during a staff change or an offboarding.
How do you report a broken website to a client who does not know what DNS is?
State what broke, in one plain sentence, what it means for their business, and what you already did or need from them. A client does not need to understand DNS to understand "your contact form stopped sending you leads for six days, it is fixed now, and here is how we will catch it faster next time."