For a single site owner, update order is a preference. For an agency running dozens of client sites, it is a governance protocol with real liability attached. The right sequence depends on release type: security patches move fast with core first, major core releases stage slowly across the fleet, and plugins always trail core in a well-run operation. This post gives you the runbook logic to apply that sequence consistently, including protocols for the scenarios that most often break the rule.
At fleet scale, update order is not a preference; it is a governance protocol with real liability attached. For a single site owner, updating core before plugins is a judgment call they make once and rarely revisit. For an agency managing 40 client sites, every ad-hoc decision that touches live production is a liability exposure. If a plugin conflict takes down a client’s e-commerce checkout at 2 a.m., “I update things in whatever order feels right” is not a defensible answer to a client paying for managed WordPress maintenance.
The shift from preference to protocol happens the moment you have more sites than one person can manually verify in an afternoon. At that scale, you need a sequence any team member can follow, a staging logic that catches regressions before they reach production, and a documented escalation path for the cases where the standard sequence breaks down.
Update sequencing is part of your operating layer. It belongs in a runbook, not in someone’s head.
The default rule for a well-run fleet is core first, then plugins. WordPress core sets the API surface that plugins depend on. When a plugin update assumes a function or hook that does not yet exist in your installed version of core, you get a fatal error. Updating core first eliminates that dependency mismatch before it can surface in production.
There is one significant exception: a new major version of WordPress core that ships significant architectural changes. Pushing core immediately to all sites creates a different risk, because plugins that have not yet released a compatibility update will break in production. The protocol for major releases is not “skip core first” but “stage core first,” which is a distinct approach covered in the next section.
For minor releases (e.g., 6.6.1, 6.6.2) and security releases, core-first is clean and fast. Apply it without hesitation across the fleet. For major releases, move to the staged rollout protocol and hold the fleet until your canary results are clean.
Security releases warrant the fastest possible response, and the sequencing question is essentially already answered: core first, then plugins, as quickly as your process allows. The standard sequence for a minor or security core release across a fleet runs as follows.
The log is not bureaucracy. It is the audit trail that lets you reconstruct what happened when a client calls and reports a broken form they noticed sometime last week. For a complete picture of how this sequencing fits into a broader monthly WordPress maintenance routine, that cadence post covers the full operating rhythm.
Major core releases require a deliberate pause before fleet-wide deployment, because plugin compatibility lags are common and the blast radius of a bad push is high. The staged rollout protocol runs in four steps.
First, designate a canary site. This is a lower-stakes client site or an internal site that you update immediately when the major release ships. Run it on the new version for at least 48 to 72 hours before touching the rest of the fleet. Monitor error logs actively during this window.
Second, audit your plugin inventory before the core update, not after. For each site, identify which plugins are flagged as incompatible with the new version. Most plugin authors publish compatibility notices in the WordPress.org repository or their own changelogs before a major release ships. If a critical plugin on a site has not confirmed compatibility, hold that site back from the major release until it does. Running a fleet-level plugin risk audit before a major release is how you find those conflicts before they find you.
Third, segment the fleet by risk tier. Sites with complex plugin stacks (WooCommerce, membership plugins, custom Connectors) update last. Simple brochure sites update early in the staged rollout.
Fourth, define a rollback threshold before you push. Establish what a bad outcome looks like and how you will detect it: a broken checkout flow, a fatal error in logs, a visual regression on a critical page. If you see that signal within 24 hours of the update, roll back the site to the prior snapshot immediately. Do not wait to investigate first.
The block editor regression that shipped in a recent major release is a clear example of why this protocol exists. Agencies that staged their rollout caught the regression on a canary site and held the fleet. Agencies that pushed all sites at once spent the weekend on client calls.
A plugin that prevents a core update is a risk signal, not just an inconvenience. When a WordPress core update is not showing in the admin, or the update is blocked with a compatibility warning, treat it as a diagnostic prompt rather than something to override.
Overriding a core update block without understanding why it exists is how you get a site-down call at an inconvenient hour. The diagnostic steps take minutes; recovery from a bad override can take hours.
The goal of a fleet-level update runbook is to remove yourself from the critical path. If every update decision requires your personal judgment, you have not built a system; you have built a dependency.
A minimal update runbook for a WordPress agency covers these elements:
Store the runbook where your team can access it. Update it when a scenario arises that it does not cover. The first time a junior team member handles a fleet-wide minor release without incident, you have evidence the system works.
For agencies running a formal monthly maintenance cadence, the update runbook is one module within that larger routine. The sequencing logic here slots directly into that cadence as a defined step within the operating layer you already run, not as a separate process to manage alongside it.
For minor and security releases, yes. Update core first, then plugins. Core sets the API surface that plugins depend on, so updating core first eliminates the most common source of compatibility errors. The exception is a major core release where plugin compatibility may lag; in that case, stage the core update starting with a canary site and hold the rest of the fleet until your highest-risk plugins have confirmed compatibility.
If the expected core update is not appearing in the WordPress admin, the most common causes are: a plugin or server configuration that has disabled automatic update notifications, a PHP version that does not meet the new release’s requirements, or a maintenance mode setting that blocks the update check. On a fleet, this is also a signal to audit which sites have update notifications suppressed and confirm those suppressions are intentional rather than the result of a forgotten configuration.
Treat it as a diagnostic signal, not an obstacle to override. First, confirm whether the block is a hard compatibility error or an advisory warning. Check the plugin’s changelog to see if a compatible version is available. If the plugin is unmaintained and essential to the site, escalate to the client before taking action. Never override a core update block on a live site without first testing the update on staging with the plugin active.
The answer is a documented, repeatable sequence rather than per-site ad-hoc decisions. Define a risk tier for each site, apply updates in batched groups rather than all at once, and run a standard pre- and post-update checklist each time. A fleet-level update runbook turns a complex governance problem into a repeatable protocol any team member can execute, and the log it generates is your audit trail when something unexpected surfaces days later.
Security releases warrant a response within days, not weeks. Minor core and plugin updates fit naturally into a monthly maintenance cadence applied in a defined window. Major core releases require more deliberate staging; a 48 to 72 hour observation period on a canary site before fleet-wide deployment is a reasonable minimum. The key is a defined cadence rather than ad-hoc updates triggered by client requests or noticed vulnerabilities.
200 free credits. Just describe what you need.
See It In Action