WordPress maintenance checklist
What a care plan must actually test.
A maintenance report that only lists updated plugins tells you very little. Useful maintenance shows that a recovery point existed before each change, that the important parts of the website still work afterwards, and what was checked. This guide lists those checks so you can compare plans or review your own routine.
Start with outcomes
Decide what the website must keep doing.
List the journeys that matter: key pages load, enquiries reach the right inbox, editors can log in, search engines can read the sitemap and, for a shop, orders and payments complete. Each check in a care plan should protect one of these outcomes.
Write down how each outcome is checked and what counts as a pass. “Website works” is not a test result. “All sitemap URLs return HTTP 200 and the contact form handler responds” is.
In this guide: before an update, after an update, checks that are easy to miss, the checklist and what a checklist cannot promise.
Before an update
Create a recovery point you could actually use.
01
A current copy, not last night’s
A scheduled backup from this morning does not include changes made since. Take a database copy immediately before the update and confirm that it contains the most recent content you expect.
02
A copy of the component you are changing
Keep the current plugin or theme folder outside the public web directory. Reverting one component is usually faster and safer than restoring the whole website over newer enquiries or edits.
03
A reason for each update
Read the changelog. A security fix deserves prompt attention. A fix for a feature the website does not use can wait for a planned window. Record the decision either way.
04
A snapshot to compare against
Save the status code, title, canonical and language links of important pages before the change. Without a baseline, “nothing changed” is an assumption rather than a finding.
After an update
Check results, not just the word “Updated”.
Request every URL in the sitemap and confirm the expected status. Compare titles, canonical tags and language alternates with the snapshot taken before the change. Open a URL that should not exist and check that the error page still returns 404 with the right title.
Check forms without sending real messages to customers or staff. A request the form handler must reject, or a test in a separate environment, confirms that the code loads. A real test submission needs the inbox owner’s agreement.
Read the PHP error log and compare its size and latest entries with the state before the update. If the update introduces a new cookie or an external request, the privacy policy may need to change too.
If the form starts receiving spam after a change, stopping contact form spam without a CAPTCHA describes what to check first.
If the update itself came from a compromised plugin, what to do when a plugin you use was compromised lists the first steps.
Want help applying this to your website? See Website security or tell us about your project ↗
Easy to miss
Look behind the green status screen.
01
Scheduled tasks
Find out what triggers WP-Cron on the website: visitor traffic or a server schedule. A “late scheduled event” warning can simply reflect an hourly server schedule. Read what is queued and when it last ran before forcing anything to run.
02
The visitor’s real address behind a proxy
With a CDN in front of the server, WordPress may see the CDN’s address instead of the visitor’s. Form rate limits then group unrelated visitors together. Trust a forwarded address only from the proxy’s published ranges.
03
Security rules and checking tools
Bot protection can block some scripts while allowing browsers and search engines. A single 403 from a test tool is not proof that the sitemap is broken, and a 200 from your own browser is not proof that it is reachable for everyone. Test with an identified agent and confirm in Search Console.
04
Search Console status
Check that the sitemap has been submitted and read, and inspect important URLs. A newly launched website can be technically sound and still unknown to Google.
05
Cookies and external requests
Record which cookies and third-party resources an anonymous visitor receives. Plugins and core features can add requests without a visible change, and the privacy policy should describe what the website actually does.
Security headers can disappear after a change to the server, CDN or theme without any visible error; security headers for a business website lists which ones to check and where they are set.
The checklist
Questions to ask about any care plan.
- Is a database and file copy taken immediately before each update, and where is it kept?
- Can a single plugin or theme be reverted without restoring the whole website?
- Which pages and functions are checked after each update, and against what baseline?
- How are forms tested without sending real messages?
- Who reads the error log, and how often?
- How are scheduled tasks, Search Console warnings and security alerts reviewed?
- When was a restore last tested, and where is the written result?
- What does the monthly record include: date, change, checks, result and open issues?
Our backup restore test shows how to record a recovery check, and the hosting selection guide covers what the hosting provider should handle.
Limits
What a checklist cannot promise.
No routine guarantees uninterrupted availability or an instant response to every incident. Hosting, third-party plugins and external services all affect the result. A good plan states its response times and boundaries in writing.
Checks reduce the chance that a problem goes unnoticed and shorten the path back to a working state. Their value comes from being done every time and recorded.
Want these checks done for your website?
Our WordPress care service starts with a review of the current setup and an agreed scope. Send your website address and tell us what matters most.
More guides
Keep reading.
Last updated:
Related services: Website security · WordPress care · Website development