How to Audit a Drupal Site: Performance, Security, UX

Most teams do not commission a Drupal site audit until something forces the question. In practice, the trigger is rarely the people who run the site day to day. It is usually the moment a new team inherits a site that nobody currently on staff built, or a support partner takes on a site that has not been updated in a while and needs to understand it before touching anything. The other common trigger is a deliberate one: recommending an audit so there is a backlog of defensible work to draw from, especially when a site is old, carries a lot of custom modules, or has drifted between updates.

A Drupal audit exists to answer one question before any work begins: what is actually here, and what is the risk of changing it. The harder truth, which we get to below, is that finding the problems is the easy part.

What a real Drupal site audit actually surfaces

A real Drupal site audit surfaces far more than performance, security, and UX. In a recent audit we ran on an enterprise Drupal site we did not originally build, the review produced 71 recommendations sorted into fourteen categories. Security was the single largest category at 18 recommendations, more than a quarter of the entire list. Behind security came performance, user experience, and AI and LLM readiness, with the remaining findings spread across SEO and content, general configuration, administration experience, theme architecture, code quality, multilingual management, accessibility, hosting infrastructure, DevOps, and database health.

Security dominates that distribution for a reason that has little to do with how well the site was built, and a lot to do with version posture. Drupal 7 reached end of life on January 5, 2025, and Drupal 10 will reach end of life on December 9, 2026, the same window in which Drupal 12 is due to release. A site that drifts between major versions accumulates exposure across core, contributed, and custom modules at the same time, which is exactly why a security pass tends to return the longest list.

Performance findings cluster around a similar pattern of drift. Google's Core Web Vitals now measure loading with Largest Contentful Paint, responsiveness with Interaction to Next Paint, which replaced First Input Delay in March 2024, and visual stability with Cumulative Layout Shift. On Drupal specifically, the performance findings in our audit were concrete rather than abstract: Fast 404 handling, cache configuration and cache lifetime, WebP and responsive image delivery, redirect and XML sitemap hygiene, and unused fields sitting in the database.

Why the distribution matters more than the list

The distribution of findings is itself the diagnostic, not just the findings. Two readings come out of it. The first is that security and configuration items cluster because hardening and update posture drift on any site nobody actively owns, and most of those fixes are configuration work rather than redevelopment. The second is that the shape of the list is consistent: a long tail of small, low-cost corrections sitting alongside a handful of high-reward structural items such as a dedicated search backend, a CI/CD pipeline, or a move to Single Directory Components.

That shape creates a trade-off. A 71-item list handed to a stakeholder is noise, and the longer it is, the less likely any of it gets done. The work that decides whether an audit changes anything is the work of turning that list into a sequence.

It is also worth noting which categories now carry weight that they did not a few years ago. Multilingual management and AI and LLM readiness were barely present in audit checklists in the past. In this audit, they accounted for eleven recommendations between them, covering hreflang and translation management on the multilingual side, and llms.txt, JSON-LD structured data, and clean heading structure on the AI side. For organizations running multilingual or public-facing content at scale, those are no longer optional categories.

Where we land: the audit is the easy part

Our view: the hard part of a Drupal audit is not finding the problems. It is getting access to act on them and sequencing them so that someone will fund the work. Most audit advice treats the audit itself as the deliverable. In our experience, the analysis is the most repeatable part of the whole exercise, and the two places audits actually stall sit upstream and downstream of the findings.

Upstream, the constraint is access. An audit is a manager-level decision, and when it is run without full administrative, codebase, and hosting access, it is run partly blind. The gaps do not disappear; they reappear later as surprises during the work itself. The most common reason an audit leads to no real improvement is simply that the team was never given the access needed to act on it.

Downstream, the constraint is translation. A technical findings list does not get funded. A cost-versus-reward picture does. We see this pattern most clearly on inherited public-sector, nonprofit, and multilingual sites that came into support without documentation, where the people who can authorize access are not the same people who understand the site. The reframe that matters: an audit is not a report, it is the input to a sequencing and funding decision, and it should be built to serve that decision from the first step.

A step-by-step Drupal audit framework

A Drupal audit framework works best as a fixed sequence that ends in a funding decision, not a document. The version below mirrors how the work moves through a delivery team, from the first access request to the summary a sponsor signs off on.

1. Scope the audit and secure full access first. Treat the decision to audit as a manager-level call made before work is committed, then get full administrative, codebase, and hosting access at the outset. If the audit proceeds without it, the missing context tends to resurface as risk during the engagement rather than before it.
2. Run the technical pass against a category checklist. Have a developer run the site against a standing checklist that covers security hardening, performance and SEO, general configuration, administration experience, theme architecture, code quality, accessibility, DevOps and deployment, hosting, multilingual management, and AI and LLM readiness. On Drupal, the performance items are specific: Fast 404, caching and cache lifetime, WebP and responsive images, redirects, XML sitemap, and removing unused fields from the database.
3. Add the security and crawl layer. Have DevOps review version posture across Drupal core, contributed modules, and custom modules, then add server-level hardening. Have QA run a crawl, for example, with Screaming Frog, to catch broken links and redirect chains. For accessibility, run the checker the site supports, such as Editoria11y, and remediate what it flags.
4. Score every finding red, amber, or green. Mark each observation by risk, where green is healthy, amber needs attention, and red is a live risk. Every amber and red item carries a specific recommendation for moving it to green. A finding without a recommendation attached is not finished.
5. Plot cost against reward. Place each recommendation on a cost-versus-reward matrix. The high-reward, low-cost quadrant is the backlog you start with, and the high-cost, low-reward items wait or get cut. This is the step that converts a flat list into a sequence a team can execute against.
6. Summarize for the sponsor by category, value, and risk. Build the deliverable around the decision, not the raw list. Group the recommendations by category, state the value and risk of each, and present them as the cost-versus-reward chart alongside the distribution of recommendations across categories. That summary is the artifact a non-technical decision-maker can fund, which is the only point at which an audit starts to pay for itself.

An audit earns its cost only when it ends in a sequenced, funded backlog rather than a PDF that ages on a shared drive. If you are inheriting a Drupal site, planning ahead of Drupal 10's end of life, or taking a site into managed support, the audit is where that work should begin. At Vardot, we run this framework as a standing practice across enterprise, nonprofit, and public-sector Drupal sites, and the output we hand over is the cost-versus-reward summary, not just the list of findings.