An outdated WordPress site can carry avoidable security and reliability risk when core, plugins, themes, PHP, or server software no longer receive or have not applied current fixes. The safe response is not to click every update without preparation. It is to know what the site runs, create a restorable backup, test the change, update from trusted sources, verify critical functions, and monitor the result.

Product documentation checked September 8, 2026. We recommend the controlled process below for self-hosted WordPress sites; your host or maintenance provider may own some of these responsibilities.

WordPress says only its latest release is officially supported. Its Security Team may backport critical fixes to older releases as a courtesy, but site owners should not treat that as a long-term support promise. Plugins and themes have their own release and support cycles, so a current WordPress core version does not prove that the whole site is current.

What counts as an outdated WordPress site?

A WordPress site can be outdated in several different ways:

  • Core support. WordPress core is behind the current supported release.
  • Available updates. A plugin or theme has an available security or maintenance update.
  • Unsupported extensions. A plugin or theme is abandoned, removed from its source, or incompatible with the supported environment.
  • Server environment. The PHP version or other server software is below current recommendations.
  • Update configuration. Automatic updates are disabled, failing, or only partially configured.
  • Unused software. The site has unused plugins or themes that remain installed.
  • Recovery readiness. Backups exist, but nobody has verified that the site can be restored.
  • Custom code. The site depends on custom code that has not been tested against current core, plugin, theme, or PHP versions.

The Dashboard update count is only one signal. Use WordPress Site Health, hosting information, plugin and theme records, and an asset inventory to understand the full maintenance state.

Why WordPress security updates matter

WordPress core, plugins, and themes are software. Updates can correct security defects, compatibility problems, and functional bugs. See WordPress.org’s hardening guidance for its explanation of update-related risks. When a fix is released, information about the underlying issue may become public, which can make an unpatched version easier to target.

That does not mean every outdated site is compromised. It means the organization is carrying a known maintenance gap. The risk depends on the affected component, whether it is active or reachable, the severity of the issue, the data and functions on the site, and any compensating controls.

Updates are one layer of security. WordPress's hardening guidance also discusses trusted sources, access control, secure computers, file permissions, backups, logging, monitoring, and reducing unnecessary software.

Build a current inventory first

Before making changes, record:

  • Core. Record WordPress core version.
  • Plugins. Record active and inactive plugins.
  • Themes. Record active and inactive themes.
  • Server. Record PHP and relevant server versions.
  • Infrastructure. Record hosting and caching layers.
  • Customizations. Record custom code and child themes.
  • Critical functions. Record forms, ecommerce, memberships, search, and other critical functions.
  • Connections. Record integrations, webhooks, analytics, and consent tools.
  • Background work. Record scheduled jobs and background processes.
  • Recovery. Record backup location, frequency, retention, and last restore test.
  • Ownership. Record administrator accounts and update ownership.

Mark each component as current, update available, unsupported, unknown, or scheduled for removal. Do not assume an inactive plugin or theme is harmless simply because visitors do not see it. WordPress recommends deleting plugins that are not in use and limiting software to trusted sources.

Back up files and the database together

A useful WordPress backup includes both the database and the files that make the site work. The database holds posts, settings, users, and other stored content. The files include WordPress core, plugins, themes, uploaded media, configuration, and custom code.

WordPress’s backup guidance recommends keeping the database and files as one backup set created around the same time. Record where that set is stored and how it would be restored.

A backup is not fully proven until someone can restore it in an appropriate environment. Before a higher-risk update, confirm:

  • Completion. Confirm the backup completed without an error.
  • Consistency. Confirm the database and files belong to the same site state.
  • Access. Confirm the storage location is accessible to the recovery owner.
  • Credentials. Confirm credentials needed for restoration are available securely.
  • Restore instructions. Confirm the restoration process is documented.
  • Escalation. Confirm the team knows the rollback decision and escalation path.

Prioritize updates by evidence and impact

Not every update needs the same release plan. Prioritize using:

  1. Security evidence. Consider confirmed security relevance or an actively exploited issue.
  2. Exposure. Consider component exposure and privileges.
  3. Usage. Consider whether the component is active.
  4. Replacement. Consider availability of a supported replacement.
  5. Business impact. Consider critical business functions affected by the change.
  6. Compatibility. Consider compatibility notes and known conflicts.
  7. Recovery. Consider quality of the backup and rollback path.

An abandoned plugin can require replacement instead of a simple update. A major core, theme, or ecommerce change may need more testing than a focused maintenance release. A severe security fix may require a faster controlled release.

Avoid downloading WordPress, plugins, or themes from untrusted sites. WordPress states that official core releases come from WordPress.org, and its hardening guidance recommends trusted plugin and theme sources.

Decide where automatic updates fit

WordPress supports automatic background updates for many core maintenance and security releases. Administrators can also enable automatic updates for individual plugins and themes. WordPress says plugin and theme automatic updates run twice per day by default when enabled.

Automatic updates can shorten the time between a release and installation, but they still need monitoring and backups. They can also fail when hosting, permissions, WordPress Cron, or another configuration prevents the task from running.

Use automatic updates when the component, rollback plan, and monitoring fit the risk. Use a staged or supervised release when a component has deep customizations, fragile dependencies, payment or form impact, or a history of compatibility issues.

WordPress's plugin and theme auto-update guide explains the native controls and recommends regular automatic backups. Site Health can show background-update problems that need attention.

A controlled WordPress update process

1. Capture the starting state

Record versions, update notices, Site Health results, recent errors, critical journeys, and the current live response. Save a current backup set before the change.

2. Review release information

Read the release notes or changelog for WordPress core and each affected component. Confirm compatibility requirements, support status, database changes, and known issues. For a security release, use the official project or vendor source where possible.

3. Test in an appropriate environment

Use a staging or other controlled environment that reflects the live site closely enough to expose compatibility problems. Keep sensitive production data protected. If staging cannot reproduce a live dependency, document the gap rather than treating the test as complete.

4. Update in a traceable sequence

Change one component or a small, documented group at a time when practical. Record the versions before and after. A traceable sequence makes it easier to identify the cause if a regression appears.

5. Verify critical journeys

Test the pages and actions that matter to the business, including:

  • Core pages. Test homepage, navigation, search, and key landing pages.
  • Lead capture. Test contact and lead forms.
  • Transactions. Test ecommerce, payment, login, or membership flows when present.
  • Responsive design. Test responsive layout on representative mobile and desktop widths.
  • Measurement. Test consent, analytics, and conversion events.
  • Delivery. Test email or webhook delivery.
  • Caching. Test caching and content delivery behavior.
  • Background work. Test scheduled jobs.
  • Access. Test administrator access.

Check browser and server logs for errors instead of relying only on a visual spot check.

6. Release and monitor

Repeat the required checks after the live update. Monitor error logs, uptime, forms, conversions, performance, and support reports for a defined period. If the result fails an agreed acceptance check, use the documented rollback or repair path.

Use WordPress Site Health as a signal

WordPress Site Health reports critical issues, recommended improvements, and passed checks. It can identify concerns such as outdated software, unsupported PHP, inactive themes, or background updates that are not working as expected.

Site Health is useful, but it is not a complete security audit. It does not prove that custom code is secure, backups are restorable, access is appropriate, or every integration still works. Combine it with release records, logs, hosting data, and functional testing.

Remove software that no longer has a purpose

Every installed component adds maintenance work. Remove unused plugins and themes after confirming that the site does not depend on them and a rollback record exists. Keep the active theme, any required parent or child theme, and a current default WordPress theme for fallback. WordPress Site Health’s theme check makes this distinction.

For an abandoned active plugin, identify the business function, data model, shortcodes, templates, and integrations it controls before replacing it. Deactivation without a migration plan can remove visible content or break a workflow.

Monitor after the update

A maintenance process should produce evidence, not only a checked box. Retain:

  • Ownership. Retain the update date and owner.
  • Versions. Retain the versions before and after.
  • Recovery. Retain the backup and restore-test result.
  • Source evidence. Retain the release notes reviewed.
  • Staging. Retain the staging result and known gaps.
  • Live checks. Retain the live QA result.
  • Regressions. Retain the errors or regressions found.
  • Response. Retain the rollback or repair actions.
  • Next review. Retain the next review date.

Website maintenance should include regular updates, backups, security monitoring, and performance checks so issues can be identified and addressed before they disrupt the site.

Frequently asked questions

Does WordPress update itself automatically?

Many sites automatically apply WordPress core maintenance and security updates. Administrators can separately enable automatic updates for individual plugins and themes. Hosting or site configuration can change this behavior, so verify the actual settings and update history.

Should every WordPress plugin update automatically?

Not necessarily. Automatic updates can be appropriate when the component and recovery process are well understood. Plugins that control critical transactions, custom functions, or fragile integrations may need staged or supervised testing.

Should I back up WordPress before updating?

Yes. WordPress’s update guidance recommends a backup before updating. Preserve both the database and files, and know how to restore the set.

Is an inactive plugin a security risk?

Deactivating a plugin is different from deleting it. Its files can remain installed, so include it in the maintenance inventory. WordPress recommends deleting plugins that are not in use. Confirm dependencies and keep a recovery record before removal.

Is the latest WordPress core version enough?

No. Core is only part of the system. Plugins, themes, PHP, server configuration, accounts, backups, logging, and custom code also affect security and reliability.

Does an update prove the site is secure?

No. Updates correct specific software issues. A secure operating process also needs access control, trusted sources, backups, monitoring, configuration review, and response planning.

Turn updates into a repeatable maintenance process

The goal is not to update blindly. It is to reduce known maintenance gaps without creating an avoidable outage or data problem. A reliable process combines inventory, trusted sources, a restorable backup, controlled testing, live verification, monitoring, and clear ownership.

Selworthy can help assess a site within a broader website design and development, technical SEO, and operations plan. Talk with Selworthy about the current WordPress environment and the business functions an update must preserve.

If you are deciding whether to keep WordPress or change platforms, use our WordPress and HubSpot Content Hub comparison to separate platform ownership from routine maintenance.

Sources and checked dates