Is your WordPress site out of date? The risks and what to do

WordPress core is the main software. Themes control much of the site's appearance. Plugins add features such as forms, bookings and online selling. Each has its own updates, so a current WordPress version can still sit alongside an outdated plugin.

There is also software underneath the website, including PHP, the language WordPress runs on, and the database service that stores its information. These are normally checked with your host or maintainer. Updating a plugin does not update the hosting environment.

An old copyright year or dated page design tells you nothing reliable about these versions. Check the dashboard and hosting records rather than judging by appearance.

Sign in through your usual trusted WordPress address. If you do not have administrator access, ask the person maintaining the site for an update report instead. Do not share passwords by email or ask for access you do not need.

No visible update notices is useful information, not a guarantee of security. Ask about components that are no longer maintained or cannot reach their update service. A plugin's age alone does not prove it is unsafe, but an unresolved vulnerability or lack of a supported update path needs attention.

• Open Dashboard, then Updates. Record the installed WordPress version and any available core, plugin or theme updates.
• Open Plugins and record which add-ons are active, which have updates and which have automatic updates enabled.
• Open Appearance, then Themes, to check the active theme and any installed themes with updates. Your permissions may affect which screens you can see.
• Open Tools, then Site Health, and note warnings about the hosting environment or failed scheduled tasks.
• Ask the maintainer about paid plugins and themes. Check whether their subscriptions or licences still provide updates and whether a supplier needs a separate update process.

WordPress.org's security guidance recommends keeping WordPress and plugins current. When a security fix becomes public, attackers can learn about the weakness it closes. Leaving vulnerable software installed can leave that route into your website open.

Not every update fixes a security flaw, and being behind does not prove that the site has been hacked. Read the update notes or ask your maintainer which changes are security-related. Prioritise known vulnerabilities rather than treating every update notification as equally urgent.

Old software can also become incompatible with a newer plugin, theme or hosting environment. That can break a form or a page even without an attack. WordPress.org's requirements page warns that end-of-life PHP and database versions may expose a site to security vulnerabilities. Ask your host to confirm supported versions rather than relying on a remembered version number.

WordPress.org recommends backing up before an update. A full WordPress backup needs both the website files and its database. Files include images, themes and plugins. The database holds content and other stored information. A downloaded folder on its own is not a complete recovery plan.

• Confirm that a recent backup completed successfully, and take a fresh one before starting.
• Keep a protected copy somewhere separate from the live website, not only inside the hosting account you may need to recover.
• Confirm who can restore it and ask for a test restore on a separate copy of the site.
• Decide how orders, bookings or enquiries received after the backup will be protected if you need to roll back.

An example shop makes a backup before updating its checkout plugin. New orders arrive afterwards. Restoring the earlier database would remove those order records, so the maintainer needs a recovery plan that protects them before starting the update.

For a maintained, straightforward site, the dashboard update tools may be enough, provided you have a usable backup and can check the result. WordPress.org describes one-click updates as the easiest method for most people. Read any supplier instructions before starting.

If the site has missed many releases, contains custom code or handles important bookings and payments, ask your maintainer to update a staging copy first. Staging is a separate test version of the site. Protect it from public access and make sure it cannot send real customer emails or take live payments during testing.

Agree the order of updates from the software suppliers' compatibility guidance. Keep a record of what changes so a failure can be traced. Do not attempt manual file replacement unless you understand WordPress.org's procedure. Its guidance warns that updates overwrite changes made directly to core files.

If an update fails, stop and record the error. Ask the maintainer to check the failed update and recovery options rather than repeatedly clicking the same button. A rollback can provide temporary recovery, but the vulnerable or incompatible component still needs a proper resolution.

A dashboard saying the update finished is not the same as a tested website. Check the public pages on a phone as well as a computer. Look at menus, images and the pages where customers enquire, book or buy.

• Use clearly fictional details for an agreed enquiry test and confirm the message reaches the right inbox.
• Check booking and shop functions through a supplier-approved test process. Do not create real charges or customer bookings by accident.
• Check that sign-in, editing and any important integrations still work. An integration is a connection to another service, such as a booking tool.
• Clear the relevant website cache if needed. A cache is a saved copy that can show an older page after an update.
• Record the new versions and test results, then check that scheduled backups are still completing.

Automatic updates can reduce the time vulnerable software stays installed. They are useful, but do not assume they are enabled for everything. Check the settings for WordPress core and for each plugin and theme. WordPress.org documents separate controls for plugin and theme automatic updates.

The same guidance says that a host or plugin can disable those controls and that scheduled updates may fail. Check Site Health for scheduling problems and make sure update emails reach someone who acts on failures. An automatic update setting is not evidence that the last update succeeded.

Choose settings to suit the site. Keep backups and a recovery plan whether updates happen automatically or through a maintainer. If a complex component needs a manual test before release, name the person responsible and agree how security updates will be dealt with promptly.

WordPress.org advises deleting plugins you do not use. First check whether each one supports something less obvious, such as a form, backup or reporting tool. Switching a plugin off and forgetting it is not the same as removing its files.

For a plugin or theme that has stopped receiving needed fixes, check the supplier's support position and plan a supported replacement. A well-maintained WordPress site does not need rebuilding just because one component needs changing. Ask for the smallest change that fixes the actual problem.

Agree who handles core, plugin and theme updates, who checks the hosting software and who tests recovery. Put failed-update alerts and backup results in front of that person. If you see unauthorised accounts, redirects or malware warnings, investigate a possible compromise as well as updating. Updates alone do not clean a hacked website.