A security warning may concern WordPress core, a plugin, theme or PHP. Each updates differently and may have a different owner. “The website is updated” does not resolve that distinction. We inventory the actual installation and match applicable advisories to establish priorities and avoid changes that miss the problem.
Core and extensions
Core provides content management, while themes and plugins add capabilities with their own release histories. Checking core alone leaves gaps. Record names, vendors, versions, purposes and custom modifications. Otherwise an automatic fix may change a critical operation that nobody included in release verification.
Applicability can depend on permissions, settings or an exposed interface. A flaw in one plugin cannot be generalised to every WordPress site. Conversely, no visible use does not prove a route is unreachable. Verify configuration and record the conclusion. Remove unnecessary components with their service endpoints and settings, rather than merely hiding menu items.
Themes are code too
Themes can contain request handlers, libraries and administrative functionality. Their sources and updates matter, especially unknown archives and undocumented edits. Separate visual assets from executable code during migration. Design can survive without retaining every technical dependency, giving the customer a familiar appearance and a new implementation.
| Component | What to establish | Possible action |
|---|---|---|
| Core | Version and applicable fixes | Update and verify |
| Plugin | Purpose and vulnerability conditions | Fix, remove or replace |
| Theme | Source and embedded functions | Review or reimplement |
| PHP and server | Production environment condition | Administrator remediation |
Beyond the dashboard
A WordPress update does not automatically update its entire environment. Assess PHP, web server and operating system with the infrastructure owner. Clarify managed-hosting responsibility; assign administration explicitly on a VPS. Confirm production instances, including containers, backup sites and subdomains that may retain old publicly accessible components.
Prioritising action
Consider reachability, required rights, valuable data and consequences. Public critical operations deserve attention based on confirmed conditions. Suspected compromise requires incident response, not updating alone. Preserve evidence and assess credential replacement. Uncertain warnings first need applicability checks. Explain why some actions are immediate and others scheduled.
Automated reports identify components and omissions, but cannot establish every business rule. Access to another customer’s order may not relate to a published CVE. Verify rights and important operations after updates. Completion means a corrected component and relevant scenario, not simply a warning disappearing. This leaves a result another maintainer can understand.
- WordPress component inventory → Review advisories
- Review advisories → Applicable issue?
- Applicable issue? → Prioritise and remediate (Yes)
- Applicable issue? → Document reasoning (No)
- Prioritise and remediate → Check functions and rights
- Check functions and rights → Update inventory
What to ask the maintainer
For each warning, ask whether production is affected, which action is selected and when the result will be confirmed. Delayed updates need a specific incompatibility explanation and interim plan, not a claim of completed remediation. Replace abandoned functions or remove them with owner approval. Even a small site can have a clear action list instead of unresolved warnings accumulated over years.
Update the inventory and release checks after remediation. Track dependencies introduced by replacements immediately. Handover should explain update ownership, verification and recovery. Retain the same discipline after migration: removing WordPress does not eliminate component accounting, access reviews or release rules.
Agree periodic comparison of the inventory with the live environment. Investigate components added outside the normal process. A small team needs concise records of function, owner and update verification, without unnecessary bureaucracy or unjustified maintenance expansion.
A component’s visible presence is not the whole assessment. A feature may still expose a request handler even when editors no longer use its menu item. Conversely, a warning may depend on conditions not enabled in the actual installation. We verify those conditions and retain the reasoning, allowing the next maintainer to understand why an action was selected or why a particular finding was not applicable.
Custom theme and plugin changes also need to be accounted for. A standard package update may replace them, while leaving them untouched may retain an unknown dependency. The proposal therefore identifies necessary business behaviour separately from the files that happened to implement it. This makes it possible to replace a vulnerable component without losing a required operation.
After changes, perform the agreed business checks and confirm the production environment. The owner should not have to infer completion from an automated email or a screenshot of a version number. A concise record of the action and result is a stronger handover.
When replacement makes more sense
If incompatible plugins repeatedly block updates while their functions remain essential, reimplement those functions. Migration need not reproduce every extension. Separate publishing, enquiries, catalogues and orders, then select Go, Node.js and suitable editing. Static pages can reduce dynamic delivery. Confirm a full PHP exit separately: a new frontend over WordPress retains the runtime and its obligations.
Send the address and essential capabilities. We map components, identify urgent action and propose migration when it resolves accumulated limitations. The quote includes acceptance criteria. The new solution still needs maintenance, but its composition is clearer, allowing systematic vulnerability management rather than another protective plugin with unclear purpose.
Sources
WordPress: security hardening. PHP: official 2026 advisories. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
