How to Audit a Drupal Site: Performance, Security, UX
Most teams do not commission a Drupal site audit until something forces the question. Usually, a new team inherits a site nobody currently on staff built, or a support partner takes one on that has drifted between updates and needs to understand it before touching anything. The audit exists to answer one question before any work begins: what is actually here, and what is the risk of changing it.
Key Takeaways
- One enterprise audit produced 71 recommendations across fourteen categories, with security the largest at 18.
- The distribution of findings is the diagnostic, not the findings themselves.
- Finding the problems is the easy part. Access upstream and sequencing downstream are where audits stall.
- Score every finding red, amber, or green, then plot cost against reward. High-reward, low-cost is where the backlog starts.
- An audit is not a report. It is the input to a funding decision, and it should be built for that from step one.
A Drupal site audit is a structured review of a site's security, performance, user experience, code quality, and configuration that produces a prioritized list of recommendations. A complete audit runs a technical pass against a category checklist, adds a security and crawl review from DevOps and QA, scores each finding by risk and reward, and sequences the fixes so the highest-value, lowest-cost work comes first.
Want an expert to run this for you? Book a free AI Readiness Audit →
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.
- 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.
- 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. - 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.
- 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.
- 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.
- 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.
Inheriting a Drupal site, or planning ahead of Drupal 10's end of life?
FAQs
A Drupal site audit is a structured review of a Drupal site's security, performance, user experience, configuration, and code quality. It produces a prioritized list of recommendations, each scored by risk and reward, so a team can decide what to fix first. A complete audit covers more than a dozen categories, not only the three most visible ones.
You should audit a Drupal site when a team inherits a site it did not build, when a site moves into managed support, or ahead of a migration such as the move off Drupal 10 before its December 2026 end of life. Audits are also worth running on older sites, sites with many custom modules, and sites that have drifted between updates.
A Drupal security audit checks version posture across Drupal core, contributed modules, and custom modules, since outdated versions are the most common source of exposure. It also reviews server-level hardening, access controls, and configuration. Security is consistently the largest category in a Drupal audit, often accounting for a quarter or more of all findings.
A Drupal performance audit includes Core Web Vitals review for loading, responsiveness, and visual stability, plus Drupal-specific checks. Those checks cover Fast 404 handling, cache configuration and lifetime, WebP and responsive images, redirect and XML sitemap hygiene, and unused fields left in the database. The aim is concrete, fixable items rather than a generic speed score.
You prioritize Drupal audit findings by scoring each one on a cost-versus-reward matrix, then starting with the high-reward, low-cost quadrant. Each finding is also rated red, amber, or green by risk, and every amber or red item carries a recommendation to move it to green. The result is a sequenced backlog rather than a flat list.