How often to update WordPress plugins and themes, and how to roll back when it breaks

There is no one-size-fits-all interval for updating WordPress plugins and themes. To keep a site patched and running smoothly, follow a fixed cadence, order of operations, and have a tested rollback ready. Here is the recommended schedule to put on your calendar along with what happens during the maintenance window.

The cadence consists of three key components: frequency, timing, and the subjects of updates. Updates whose changelogs indicate security fixes should be applied within 24-72 hours, prioritized straight after a backup. Routine plugin updates are performed once a month on the same day and hour. This is done first in a staging environment before being applied to production.

Plugins that handle sensitive data, such as payments, checkout, tax, or shipping, should also be updated once a month, but again, tested in staging and later in production. Major version bumps (when the first number changes) are handled quarterly, staged first, with a thorough review of the changelogs before proceeding. Theme updates are done quarterly, or when a specific fix is required.

Customizations should live in a child theme to prevent loss during updates. WordPress core security and minor releases are applied as they are released, while major releases occur quarterly after staging, with staging updates taking precedence.

In addition to the cadence, there are two important points to note. First, enabling auto-updates for everything is not a reliable cadence, as it applies changes at a time of your choosing and on a site you are not watching. Auto-update is only suitable for small, single-purpose plugins dealing with security matters. Second, updating whenever the dashboard turns orange is also not a reliable cadence, as it leads to updates being applied just before a demo, which is an undesirable time.

Instead, allocate a 15-minute weekly check to review updates and apply them during the scheduled maintenance window.

Once a week, perform a 15-minute check to see if there are any security release updates. If so, prioritize them. Also, review the list from the previous month to ensure no updates were skipped. Identify any plugins that have not been updated for an extended period, have inactive support threads, and are still in use. These plugins should be replaced with new, active projects rather than updated.

Before initiating the maintenance window, follow these five pre-flight steps in order. If any step fails, cancel the window altogether. First, confirm that the site is functioning correctly by loading the homepage, submitting a form, and logging in. This establishes a known-good baseline to compare against. Next, check the error logs for any existing issues.

Take note of the count of PHP and web server errors for later comparison. Back up the site thoroughly and verify that the backup is readable. Lastly, document the current plugin and theme installations, including their versions, to facilitate a smooth rollback if necessary.

During the maintenance window, update one component at a time and test the site between each update. This approach prevents a batch of changes from hiding the root cause of any issues. Start by removing deactivated plugins, as they provide no additional security benefits. Move on to low-risk utility plugins, such as admin tweaks and log viewers, before tackling anything that interacts with the front end.

Perform a test order in the payment gateway's sandbox mode to ensure payments are functioning correctly. Update the theme last, ensuring that any customizations have been moved into a child theme to avoid losing them during the update process. WordPress core major releases should always be performed after all other updates, never in the same window as a theme update.

If you are using a page builder, update the builder and its addons together to avoid half-broken layouts.

After each step, purge the caches, including object cache, page cache, and CDN caches, in that order. Stale caches can introduce unforeseen bugs that are difficult to trace. Finally, conduct a smoke test to verify the site is functioning as expected. This includes checking the homepage, page builder outputs, form submissions, checkout processes, login functionality, search results, mobile responsiveness, and error logs.

If the site passes this smoke test, the update has been successful. If not, rollback to the previous stable state using the smallest level that resolves the issue, starting with level one, which involves rolling back only the updated files.