A WordPress architecture audit is often sold as a list of outdated plugins, security warnings and performance scores. Those checks are useful, but they do not explain whether the website is an understandable and governable system. The most expensive failures usually occur between components: a content rule encoded in a template, a form that owns business logic, a scheduled task that no one monitors or a plugin that is technically optional but operationally impossible to remove.
Start with the operating model
Before reading code, identify what the system must do for customers and staff. Which journeys create revenue or service? Which data is authoritative? Which workflows are time-sensitive? Who can change content, configuration and code? Technical evidence becomes meaningful only when connected to these responsibilities.
1. Architecture and runtime boundaries
Inventory the active theme, plugins, must-use plugins, custom code, external APIs, scheduled jobs and infrastructure services. For each component, record its responsibility, data, runtime surface and dependency. A diagram should reveal overlap and hidden central components, not merely show boxes.
2. Contenuto and information architecture
Review post types, taxonomies, fields, reusable blocks, templates, canonical URLs and multilingual relationships. Look for business concepts represented only through page titles or duplicated free text. A content model is part of the application architecture because it determines what can be reused, validated and changed safely.
3. Plugin lifecycle and governance
A plugin is more than its frontend feature. Examine activation, upgrade, deactivation, uninstall, multisite behaviour, background work, privacy exports, permissions and asset loading. Determine who approves updates, how regressions are detected and whether rollback is possible.
4. Data ownership and integrations
For every important record, establish the source of truth and the systems that copy or transform it. Inspect authentication, retries, idempotency, rate limits, failure queues and manual recovery. A webhook without a recovery model is not a reliable integration.
5. Frontend and admin performance
Measure public pages, but also inspect the administration surfaces people use every day. Attribute assets and queries to features. Check whether plugins load globally, whether repeated requests are bounded and whether the system has performance budgets that can detect regression.
6. Security, privacy and access
Review roles, capabilities, upload boundaries, sensitive data, logging, retention and external processors. The objective is not a ceremonial compliance list. It is to know where data enters, where it is stored, who can access it and how it leaves.
7. Delivery and recovery
Document environments, deployments, backups, configuration differences and emergency access. A maintainable system has a known path from change to production and a tested path back when the change fails.
The audit output
A useful result contains a system map, evidence, a risk register, a target architecture and a sequenced roadmap. Findings should distinguish immediate defects from structural debt and optional improvement. The team should be able to act on the output without hiring the auditor to translate every sentence.
See the WordPress Systems Consulting service for the commercial structure of this work.