Search “website maintenance checklist” and you get the same list every time. Update your plugins. Check for broken links. Run a backup. Renew your domain. It’s not wrong. It’s just the part everyone already knows, and it skips the checks that actually catch problems before they cost you a customer.
This is a different checklist. It’s the one we run on a website, grouped the way our own Website Health Check runs it. Every item includes what it is, why it matters, and how to check it yourself for free.
One thing to set up front, because it keeps the whole list honest: these checks read your public homepage and your public DNS records. They don’t log into anything, they don’t crawl every page, and they won’t catch a page that’s already been hacked behind the scenes. This checklist tells you whether the front door and the locks are sound. It can’t tell you if someone is already inside.
The checklist has two halves: security and trust, then speed and quality.
Part 1: Security and trust
Nine checks. The first two confirm the site and its email even exist. The middle five are about trust, mostly email, which is where small businesses quietly lose the most. The last two are about being reachable.
1. Is the site actually live?
The most basic check: does the domain resolve to a server at all? A single expired DNS record, and the site is simply gone, with no error to warn you. Load your homepage in a private browser window. If it doesn’t come up, nothing else on this list matters yet.
2. Can the domain receive email?
A domain needs an MX record to accept mail. Businesses lose this when they switch email providers and a record gets dropped. Suddenly every reply to your address bounces, and you find out from an angry customer. If you use email at your domain, confirm it can still receive.
3. SPF: who is allowed to send as you
SPF lists which servers may send email using your domain. Two things break it. Either there’s no record, or, more sneakily, there are two. Receiving servers throw out duplicate SPF records entirely, so “we have SPF” can be quietly false. Check that you have exactly one record and that it names every service you actually send from. Our free SPF checker shows you.
4. DMARC: what happens when a message fails
DMARC tells receiving servers what to do with mail that fails your checks: nothing (p=none), send it to spam (quarantine), or reject it (reject). As of December 2025, 83.9% of domains had no DMARC record at all. Two details most checkers miss: a subdomain policy set to sp=none leaves your subdomains spoofable, and a rua address that points nowhere means your failure reports vanish. The free DMARC checker reads all of it.
5. DKIM: are your senders actually signing?
DKIM is the signature that proves an email really came from you. SPF says who’s allowed to send. DKIM proves they did. The gap is common: a service is authorized in SPF but isn’t actually signing, so its mail is weaker than you think. A real check probes the default signatures for the services you use, like Google Workspace, Microsoft 365, SendGrid, Mailchimp, and Resend, and confirms they’re live.
6. CAA: who can issue certificates for your domain
A CAA record limits which certificate authorities are allowed to issue an SSL certificate for your domain. Without one, any CA can, which widens the door for a mis-issued certificate. It’s a small record most sites never set, and setting it is a quiet security upgrade.
7. SSL: is the certificate actually valid?
“Has a padlock” is not the same as “valid.” A certificate can be expired, cover the wrong hostname, or have a broken chain, and any of those triggers the full-screen “your connection is not private” warning that sends visitors back to search. A real check confirms the certificate validates in a browser, hostname and chain included, and how many days it has before it expires. Run the free SSL checker.
8. Mobile viewport: does the phone know how to render the page?
One small tag, the viewport meta tag, tells a phone how to lay out your page. Without it, mobile visitors get a tiny, zoomed-out desktop layout they have to pinch to read. Most give up. It’s a one-line fix that’s easy to lose in a redesign.
9. robots.txt and AI access: can crawlers reach you?
Your robots.txt file controls who’s allowed to read your site. Check that it exists, that Googlebot and Bingbot can reach your homepage, and, increasingly important, that AI crawlers aren’t blocked. When someone asks ChatGPT or Perplexity for a business like yours, the AI has to be allowed in first. Our AI crawler checker tests seven of them at once, including GPTBot, ClaudeBot, PerplexityBot, and Google-Extended, and the robots.txt checker covers the search crawlers.
Part 2: Speed and quality
The second half is about the experience once a visitor arrives. These come from Google’s own PageSpeed Insights, run on mobile, and you can get them from our free website speed test.
There are four scores out of 100:
- Speed (Performance): how fast the page actually loads on a mid-range phone.
- Accessibility: whether people using screen readers or keyboard navigation can use the page.
- Built correctly (Best Practices): whether the page follows the modern rules browsers expect.
- Search basics (SEO): whether the fundamentals search engines look for are in place.
Underneath the scores, three numbers tell you how the load actually feels:
- LCP (Largest Contentful Paint): how long until the main content appears.
- CLS (Cumulative Layout Shift): how much the page jumps around as it loads.
- TBT (Total Blocking Time): how long the page is frozen and unresponsive to taps.
Then the mobile usability flags, which are the ones that quietly cost you sales on a phone: tap targets placed too close together, text smaller than 12px, and content that runs wider than the screen so people have to scroll sideways.
The honest limits, again
Worth repeating, because it’s the difference between a useful checklist and a false sense of security. Everything above reads your public homepage and your public DNS records. It will not log into your site, crawl every page, or detect a page that’s already been compromised. Treat a clean result as “the front door is sound,” not “nothing is wrong anywhere.”
A few things also sit outside this core check on purpose, and have their own free tools if you want them: your redirects, your security headers, and your social preview tags. Useful, but separate from the health check above.
How often to run each
Maintenance isn’t a once-a-year event, because the things on this list fail on their own schedule:
- Certificate and DNS: monthly. Certificates expire on a fixed date, and a provider change can drop a record any time.
- Email (SPF, DKIM, DMARC): after any change to your email or sending tools, and monthly otherwise.
- AI and search access: monthly, and any time you touch robots.txt.
- Speed and mobile: after any redesign or big content addition.
If that sounds like a standing chore, that’s because it is. It’s a real one, and it’s the reason maintenance gets skipped.
Or hand the whole list off
You can run every check here yourself, for free, and you should at least once. The catch is next month, and the month after, because certificates expire, records drift, and crawler rules change whether or not you remember to look.
That ongoing work is what Surmado does. You don’t operate a checklist tool. Scout rebuilds your site on a foundation where these are set correctly from day one, then keeps them that way: certificate valid, email authenticated, AI crawlers allowed, speed in range. Nothing on this list becomes your Sunday-night problem. If you want the site itself handled, that’s Surmado Sites. If you want the ongoing upkeep specifically, that’s website maintenance services.
Related Reading: