← WordPress Security for High-Stakes Sites
How do you apply WordPress updates without breaking the site?
Apply them to a test copy first, check that the site still works, and release to the live site on a schedule. Keep a backup you can restore so a bad release can be reversed. This is a release process with a named person responsible for it, not a button in the dashboard.
It manages two risks at once: an unpatched site is exposed, and an update applied blind can take down a checkout or a login.
What belongs in the update scope?
Everything that runs the site, not only WordPress. Our Website Security service defines tested patching as covering “WordPress core, plugins, and themes, application dependencies, and server packages, tested before deployment.”
- Core, plugins, and themes. The three layers of WordPress itself.
- Application dependencies. Libraries a custom theme or plugin pulls in, such as packages managed through Composer or npm.
- Server packages. PHP, the web server, and the database. Fixes here can matter as much as fixes in WordPress. Our post on who owns your website’s security describes two severe PHP vulnerabilities patched in October 2026 that let an attacker run code remotely without logging in.
If nobody is assigned the layers under WordPress, they go unpatched.
What does a test copy prove, and where does it fall short?
A test copy proves the update works with your code and settings as they were when the copy was made. It does not prove the live site will behave identically.
Pantheon’s staging guide notes that a plugin update can conflict with a theme and a PHP upgrade can expose compatibility problems, and a staging copy lets those surface before visitors see them. It is also direct about the limits: a staging site’s value “depends on how closely it mirrors production and how thoroughly the team tests changes.”
It adds that a copy may not hold the latest production content, and that a cloned webhook can keep sending staging events to a production service. To get value from a test copy:
- Refresh the copy from production before each round of updates so it matches.
- Turn off anything that sends real email, payments, or webhooks, or point it at test endpoints.
- Check the flows that earn or protect money: login, forms, checkout, and each third-party integration.
- Record what was checked and the result, so someone other than the person who ran it can repeat it.
Who should be able to change the live site?
Nobody should change it directly, and as few people as possible should be able to release to it. Every edit made straight on the live site skips the test copy, so each person with that ability is a way for an untested change to reach visitors.
On one financial services platform, we set it up so that “All updates are tested and verified before reaching the live site, with scheduled releases on a predictable cadence.” See a security and uptime program for a financial services platform. A cadence only works if the live site cannot be changed outside it.
When releases happen on a known schedule, an unexpected file change also stands out, which gives file change monitoring fewer false alarms. The wp-config.php constants that block installs and updates from the admin enforce this; see hardening.
What about a security release that can’t wait?
A cadence needs an emergency path, with its own written rules. Decide in advance what triggers it, such as a security release for core or for a plugin the site runs, and what a shortened version of testing includes.
WordPress 7.0.2 fixed a serious flaw in WordPress itself, not a plugin, and according to that post the WordPress team enabled forced updates through the auto-update system to push it out. A site locked down with DISALLOW_FILE_MODS does not receive those automatic updates, so on that site the emergency path is the only way the fix arrives.
A shortened path still includes the parts that matter most: a fresh backup, the update on a test copy, a quick check of the critical flows, and a release with a named person approving it. It skips the full check of the site, and the release record says so.
Should automatic updates be turned on?
Yes for core security releases, except on a site locked down with DISALLOW_FILE_MODS. Start by checking what is already on. Per the WordPress upgrade documentation, “new installations have automatic updates enabled for both minor and major core releases by default,” while plugin and theme updates only happen automatically “in special cases.” Setting WP_AUTO_UPDATE_CORE to 'minor' keeps the security and maintenance releases automatic and leaves major releases for your tested release process.
The WordPress hardening handbook notes that “Since version 3.7, WordPress has featured automatic updates” and recommends using them, and our post on the 7.0.2 release lists automatic updates “turned on where it makes sense” as one of the things that keeps a site safe.
The trade is control for speed. Automatic updates skip the test copy, so they fit changes with low risk of breakage and a high cost of delay. Decide the split per site, write it down, and make sure an update applied automatically still shows up in the release record.
How should plugins be chosen and kept?
Vet a plugin before you install it, and remove the ones you no longer use. Our post on choosing WordPress plugins says to look at its code quality, its security-response history, and its maintenance track record. Every installed plugin is one more thing to patch.
The reason is where vulnerabilities turn up. Patchstack’s State of WordPress Security in 2026 reports that “91% of new vulnerabilities were found in plugins, and 9% were found in themes,” and that “There were only 6 vulnerabilities reported in the WordPress core.”
Plugins are written by many different developers, with varied review and maintenance, and they change hands. A vetted plugin can still turn malicious after a change of owner; see hardening.
Why confirm a backup before every release?
A backup taken just before a release is what makes a rollback a short task. Before a release, confirm that a recent backup exists, that it is stored off the server, and that a restore has been tested. Tested backups are also the starting point in an incident; see planning a WordPress security incident response.
Already compromised?
If the site has been hit, updating comes after finding out how the attacker got in. Start with fixing a hacked WordPress site.
