A WordPress maintenance checklist for the new year covers nine jobs: confirm backups work by restoring one, audit user accounts, remove unused plugins and themes, move off PHP 8.2, renew licences, test forms and email, set up uptime and security scanning, fix broken links and clear Search Console errors. The quiet days between Christmas and mid January are a good time to work through it.
The timing matters this year. PHP 8.2 stops receiving security fixes on 31 December 2026, so a site still on 8.2 starts 2027 on an unsupported version.
1. Backups, and a restore test
A backup you have never restored is a hope, not a backup. Check three things:
- What is backed up: both the database and the
wp-contentfolder (uploads, plugins, themes). - Where it is stored: at least one copy away from the hosting account. If the account is suspended or compromised, backups stored inside it go with it.
- How long it is kept: enough history to go back before a problem you noticed late.
Then do the restore test. Restore last night’s backup to a staging site or a local copy and click through it: home page, a few posts, a form, and for WooCommerce, a product page and the cart. Write down how long it took and every step: that note is your recovery plan.
2. User and admin account audit
Open Users in wp-admin and filter by role. Old staff, past agencies and one-off contractors often keep Administrator access for years.
- Remove or downgrade anyone who no longer works on the site. When deleting a user, attribute their content to an existing account rather than deleting it.
- Keep the number of Administrators small. An editor who writes posts needs the Editor role, not Administrator.
- Investigate any Administrator account you do not recognise. It can be a sign of a past compromise.
- Open each remaining admin profile and review Application Passwords. Revoke any that belong to integrations you no longer use.
- Turn on two-factor authentication for admin accounts with a plugin you trust, and confirm every admin has set it up.
Repeat this for the hosting panel, SFTP, DNS registrar and CDN.
3. Unused plugins and themes
A deactivated plugin is still code on your server, and deactivated usually means forgotten, so it stops getting updated.
- List every plugin and write next to it what it does and who asked for it. Anything nobody can explain is a candidate for removal.
- Delete, do not just deactivate, plugins you no longer use. Test on staging first, because some plugins leave shortcodes or blocks in content that show as raw text once removed.
- Check the plugin’s page on WordPress.org or the vendor site. A plugin with no update for a long time, or one closed in the directory, needs a replacement plan.
- Keep your active theme, its parent theme if you use a child theme, and one default WordPress theme for troubleshooting. Delete the rest.
4. PHP version check
Go to Tools > Site Health > Info > Server to see the PHP version. According to the PHP supported versions page (checked 26 October 2026):
- PHP 8.2: security support ends 31 December 2026.
- PHP 8.3: security fixes only, until 31 December 2027.
- PHP 8.4: active support until 31 December 2026, security fixes until 31 December 2028.
- PHP 8.5: active support until 31 December 2027, security fixes until 31 December 2029.
For most sites in January, 8.4 is the sensible target, as long as your plugins and theme work with it on staging. I covered the testing steps and rollback plan in what to do about PHP 8.2 end of life on WordPress, so I will not repeat them here.
5. Licence renewals and accounts
Premium plugins and themes usually need an active licence to receive updates. An expired licence means the plugin keeps working but stops getting security fixes, which is easy to miss.
- List every paid plugin, theme and service (backups, CDN, email sending, forms, SEO) with its renewal date and which email address owns the account.
- Move licences off personal or ex-staff email addresses onto a shared business address.
- Check the domain name and SSL certificate renewal dates. Turn on auto-renew for the domain.
6. Form and email delivery test
Forms fail silently. The visitor sees “thank you”, and the email never arrives. Test every form on the site, not just the contact page:
- Submit each form with a real address you can check, and confirm the notification reaches the right inbox, not the spam folder.
- For WooCommerce, place a test order and check the customer and admin emails.
- Check that the site sends email through a proper mail service (SMTP or an email API) rather than the server’s default mail function, which is more likely to be filtered as spam.
- Check the domain’s SPF, DKIM and DMARC DNS records with your email provider’s documentation. Missing records are a common reason for site email landing in spam.
7. Uptime and security scanning
- Uptime: set up an external uptime monitor that checks the home page and one deeper page (for a shop, a product page) every few minutes and alerts a phone, not only an inbox nobody reads at the weekend.
- Security scanning: use a security plugin or your host’s scanner to check for changed core files and known vulnerable plugin versions.
- Updates: decide who applies updates and how often. Automatic minor core updates are sensible; plugin updates on a busy shop are better tested on staging first.
8. Broken links and Search Console errors
Broken links
Run a crawler over the site and export every internal link that returns a 404 or redirects more than once. Fix internal links at the source instead of adding redirects on top. For pages that were deleted but still have external links pointing at them, add a 301 redirect to the closest equivalent page.
Search Console
In Google Search Console, work through:
- The Pages indexing report: look at “Not found (404)”, “Server error (5xx)” and “Redirect error”. Fix what should be indexed; ignore what you meant to exclude.
- The Core Web Vitals report: LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1 count as good, measured at the 75th percentile of real visits.
- Security issues and Manual actions: both should say no issues detected.
- Sitemaps: confirm the sitemap submitted is the one your SEO plugin currently generates.
Maintenance timeline for the new year
- Before 25 December: confirm backups and uptime alerts work, so the holiday period is covered.
- 27 to 31 December: user audit, licence list, plugin list. On staging, test PHP 8.4 if you have not already.
- By 31 December 2026: PHP 8.2 security support ends. Aim to be on 8.3 or 8.4 by then, or have a firm date in early January.
- First two weeks of January 2027: restore test, form and email tests, broken links, Search Console review.
- Before 26 January 2027 (Republic Day): Indian stores running a Republic Day sale should finish PHP and plugin changes well before it.
For a sense of what ongoing care looks like on a real site, see the Nneihaa Vvikas WordPress site development and maintenance project. If you would rather hand the whole list over, you can hire a WordPress developer for yearly maintenance and updates.
Frequently asked questions
Is my host’s backup enough?
Often not on its own. Check what it covers, how long it keeps copies and whether you can restore without opening a support ticket. Keep one extra copy stored outside the hosting account.
Should I delete deactivated plugins?
Yes, if you do not plan to use them again. Test the removal on staging first and search your content for leftover shortcodes.
What happens if I stay on PHP 8.2 after 31 December 2026?
The site keeps running, but PHP itself gets no further security fixes. Your host may also move you to a newer version on its own schedule.
If you want a second pair of eyes on your plugin list or Search Console reports, send me your site URL and what you have already checked.