Website maintenance checklist: daily to yearly tasks

Daily tasks

Daily tasks should take minutes, because software does most of the work. Your part is to read the results and act on them.

• Check that uptime monitoring is running and that alerts reach a person who can act. An alert sent to a mailbox nobody reads is the same as no alert.
• Read the alerts from the last 24 hours. A short outage at 03:00 still counts as downtime.
• Confirm that last night's backup finished. Look at the job log, the file's timestamp and its size. A backup much smaller than yesterday's is a warning.
• Read the security announcements for the software you run: your CMS, plugins, framework, language runtime and server packages. Critical releases do not wait for your monthly window. A serious vulnerability in a runtime such as PHP, or in a popular plugin, can leave you choosing between patching at once and taking the site offline until you can.

Weekly tasks

• Apply routine updates to the CMS core, plugins, themes and dependencies. Test them on a staging copy first. On a busy site, update one item at a time so you know what broke if something does.
• Use the pages that earn money or collect data: sign-in, search, the contact form, checkout, a test payment. A broken page can still return a 200 status.
• Read the error and access logs for new 404 errors on pages that used to work, a rise in 5xx errors, and repeated failed logins.
• Check free disk space, memory and database size. A full disk is a common cause of a sudden failure.
• Clear spam from comments, forms and sign-ups.
• Make sure a copy of the backup exists away from the server. A backup stored only on the server is lost together with it.

Monthly and quarterly tasks

These tasks need more time, so schedule them in your calendar.

Every month:

• Restore the latest backup into a scratch environment and open the site. A backup you have never restored is untested.
• Crawl the site for broken links, redirect chains and missing images. Fix internal links first.
• Measure the speed of your most important pages and compare the result with last month. The website speed guide explains the numbers. Look for oversized images and plugins that load scripts on every page.
• Calculate uptime for the month and read the list of incidents. The uptime calculation guide has the formula.
• Review user accounts. Remove people who left, check the admin accounts, turn on two-factor sign-in where it is available, and rotate shared passwords and API keys.
• Check whether your domain or server IP address is on a blacklist. A listing can block your email or trigger browser warnings.
• Look at the search engine reports for crawl errors, indexing problems and security warnings.
• Read your content for outdated facts, expired offers and wrong prices. Check that the sitemap and robots.txt still list and allow the pages you want in search results.

Every quarter:

• Review the DNS records (A, CNAME, MX and TXT) and remove records for services you stopped using.
• Check the email records for your domain. The SPF, DKIM and DMARC guide shows how.
• Compare disk, bandwidth, memory and traffic trends with the limits of your hosting plan.
• Delete unused plugins, themes and old staging sites. Each one adds update work and a way in for attackers.
• Run a recovery drill: assume the server is gone, rebuild the site from backup using your written steps, and time it.
• Check who receives alerts. People change jobs and phone numbers. The alert channels guide lists the ways to reach them.

Yearly tasks

• Renew the domain registration, or confirm that auto-renew is on. Check that the registrant email address is one you read, because the renewal warnings go there. An expired domain takes the whole site offline. The guide on expired domains and expired certificates shows how to tell the two apart.
• Renew every TLS certificate that does not renew itself. For certificates that renew automatically, confirm the last renewal really ran. The certificate expiry guide shows how to read the date.
• Check that the versions of PHP, Node.js, Python, your database and your CMS are still supported by their maintainers. Plan the upgrade before support ends.
• Review your hosting: plan size, server location, support quality and how long backups are kept.
• Do a full security review: file permissions, admin users, stored keys and unused services.
• Look back at the year's incidents. List what broke, what you found out about late, and what you can automate.

How to run planned maintenance without hurting visitors or rankings

Updates, migrations and server changes sometimes need the site to be unavailable. Do it in this order:

1. Pick the quietest period in your traffic statistics, and keep the window as short as the work allows.
2. Announce it in advance: a banner on the site, an email to users, and a scheduled maintenance entry on your status page. The maintenance message guide has copy-ready wording.
3. Tell your monitoring about the window, so expected failures do not wake anyone. HostTracker maintenance windows pause alerts for planned work and appear on the status page.
4. Serve the maintenance page with HTTP status 503 and a Retry-After header. A 503 tells search engine crawlers the outage is temporary. A page served with 200 can be indexed as if the maintenance text were your content, and redirecting every URL to one maintenance page makes crawlers see the same page at every address. The 503 guide explains the header.
5. Keep robots.txt reachable. Google advises against returning 503 for robots.txt, because that blocks all crawling.
6. Test before you reopen: the main pages, status codes, forms and the certificate. Then end the window and post an update.

Keep the outage short. Google describes a 503 page as the right tool for an urgent shutdown of one or two days. It warns that disabling a whole site should last a few days at most, because a longer outage has significant effects on the site in search results.

Letting monitoring do the daily work

Most items on the daily and weekly lists are repetitive, and software can do them on schedule without anyone remembering. HostTracker has monitored websites since 2004, and more than 500,000 websites are monitored with it. It checks from 300+ checkpoints in 158 cities and sends alerts by email, SMS, voice call, Slack, Telegram and more. A status page shows each monitor as operational, degraded, partial outage or under maintenance, publishes incidents with timestamped updates, and shows scheduled maintenance, so customers can read the plan instead of writing to support.

For the yearly items that are easy to forget, look at the certificate first. The SSL check reads a certificate's expiry date, issuer and chain as seen from many locations, which also catches a CDN edge that serves an older certificate in one region. The SSL expiry alert guide and the domain expiry guide show how to be warned before either date passes.

Frequently asked questions

How often should a website be maintained?

Some tasks are daily, usually automated: uptime checks, backup confirmation and security notices. Updates and log reviews are weekly. Restore tests, speed checks and access reviews are monthly. A site that takes payments or has many plugins needs more attention than a small brochure site.

How long should a maintenance window be?

As short as the work allows, and announced with an end time. Plan for the task to run longer than expected and write the end time with that margin. If the work overruns, post an update instead of staying silent.

Does planned maintenance hurt SEO?

A short window usually does not, if the maintenance page returns 503 with a Retry-After header. A maintenance page that returns 200, a redirect of all URLs to one page, or an outage that lasts for days can cause problems.

Which task matters most?

In most cases, tested backups. Many other problems on this list can be repaired, but a site without a working backup may not be recoverable after a hacked server, a deleted database or a failed update.

Do I need a maintenance page for every update?

No. Most plugin and content updates take seconds and do not need one. Use a maintenance page for work that makes the site return errors or changes the database structure, such as a migration or a major version upgrade.

Sources and further reading

• Google Search Central: Pause or disable a website: when to use a 503, what to put on the page, and the robots.txt warning.
• RFC 9110, HTTP Semantics: the definitions of 503 Service Unavailable and the Retry-After header.
• MDN: Retry-After: the header's two formats, with examples.