Drupal Site Audit

An independent, fixed-price review of a production Drupal site: whether the tests catch real bugs, where the custom code is costing you performance, and what search engines and AI crawlers actually see. You get a severity-rated report with the fixes named, at a price agreed before I start.

Why an independent Drupal audit

Fixed Price

A price and a delivery date agreed up front. Overrun risk sits with me, not your project margin.

Independent

The review carries weight precisely because I did not write the code. Your own team cannot be that for itself.

Measured, Not Guessed

Test blind spots are proven by fault injection. Performance claims come with before and after numbers.

Security Credentials

Drupal Security Team advisory credit and two published payment gateway modules on Drupal.org.

What the audit covers

Four passes over the same site, each producing findings you can act on independently. A short engagement can take any subset; most sites benefit most from the first two.

1. Do your tests actually catch bugs?

Reviewing test code tells you what it was meant to check. Fault injection tells you what it really catches. Known faults are inserted into the custom modules and theme one at a time, and the existing Playwright or Behat suite is run against each. The faults it misses are your measured blind spots. On the last site I ran this on, half the injected faults went undetected, including a broken global.js that killed every Drupal behaviour on every page and produced zero test failures.

2. Custom code and performance

A line-by-line read of every custom module and theme file, not just a Lighthouse score. The recurring findings are preprocess hooks setting max-age to zero and silently disabling the page cache site-wide, referencedEntities() called inside loops, and configuration objects loaded fresh on every request. These accumulate over years and rarely surface as a bug report, because nothing is broken; the site is just slow and nobody can say why.

3. Security posture

Contrib and custom module review against the same standards I apply when reporting to the Drupal Security Team: access checks, unsanitised output, unsafe queries, file handling, and stale dependencies with known advisories. Severity-rated, with patches where remediation is in scope. Useful as evidence at ISO 27001 surveillance or Cyber Essentials renewal.

4. Search and AI crawler readiness

What Google and the AI crawlers can actually see, and why Drupal is producing it. On Drupal an empty meta description is usually a theme template overriding the Metatag module, not a content problem, so the fix belongs in code and lands on every page at once. Covers structured data, Open Graph and Twitter Card output, canonical handling, sitemap and robots directives, plus llms.txt and crawler policy for GPTBot, Google-Extended, Claude-Web and PerplexityBot.

What you get

A severity-rated report

Every finding with its evidence, its impact, the file and line it lives in, and the fix. Written to be read by a technical lead and skimmed by whoever signs off the budget.

Before and after numbers

Fault detection rate, PageSpeed and Core Web Vitals figures, query counts. Claims that can be checked rather than asserted.

A prioritised remediation list

Ordered by impact against effort, so the first afternoon of work is the one that matters most. Remediation is quoted separately as a fixed price once the findings are known, and nothing in the audit price depends on you buying it. Hand the list to your own team if you prefer.

A real example

A corporate Drupal 11 site with Commerce needed a thorough quality review before a busy trading period. The findings were typical of a site that had been healthy for years and quietly drifting:

  • Five of ten injected faults went completely undetected. The suite was blind to every JavaScript error.
  • Two preprocess hooks on site-wide blocks were setting max-age to zero, disabling Drupal's Internal Page Cache across the whole site.
  • A sponsor block ran the same entity query once per taxonomy term; slider pages made twenty-plus individual entity loads for five images.
  • Sixteen uncached configuration reads per page request, each one hitting the database.
  • A hardcoded empty meta description in the base theme was overriding the Metatag module on every page, and no structured data existed anywhere on the site.

Fault detection went from 50% to 70% with four new tests and a browser error collector. The cache, query and configuration fixes went in alongside. The full write-up, including the fault injection table and the measured results, is published here: how the Drupal 11 site quality audit was run, step by step.

How it works

1

Tell me about the site

Drupal version, roughly how much custom code, whether there is a test suite, and what is worrying you. No formal spec needed. I will tell you honestly if an audit is not what you need.

2

You get a fixed price and a date

Scope named in writing, price fixed, delivery date you can commit to a client. No hourly billing and no scope-creep surprises.

3

I audit a copy, not your production site

Work happens against a database copy and a local build. Fault injection in particular never touches anything your users can reach.

4

Report delivered, remediation optional

You get the report and the prioritised list. Fixes are quoted separately, and you are free to take the report to your own team instead.

Verifiable, not just claimed. In June 2026 I reported the Drupal Commerce Core cross-site scripting issue published as SA-CONTRIB-2026-041. It is public on Drupal.org in my name, alongside my contrib work and two published CyberSource gateway modules.

Common questions

What common issues do teams uncover during a Drupal site audit?

The recurring ones are preprocess hooks setting max-age to zero and silently disabling the page cache site-wide, N+1 entity loads inside loops, uncached configuration reads repeated on every request, a test suite that cannot see JavaScript errors at all, and meta output hardcoded in a theme template that overrides the Metatag module. Most of these accumulate quietly over years and never show up as a bug report.

How is a Drupal site audit different from an SEO audit?

An SEO audit looks at what a crawler sees. A Drupal site audit also looks at why the site produces that output: the theme templates, the module configuration, the cache metadata and the custom code. On Drupal, an empty meta description is usually a template bug rather than a content problem, so fixing it at the source fixes it on every page at once.

How do you know whether the existing test suite actually works?

By fault injection. Known faults of different kinds are inserted into the custom modules and theme one at a time, and the existing suite is run against each. Whatever the suite fails to notice is a real, measured blind spot rather than an opinion about test coverage.

Do you fix what you find, or only report it?

The audit itself is a report. Remediation is quoted separately as a fixed price once the findings are known, so you are free to hand the report to your own team instead. Nothing in the audit price depends on you buying the fixes.

Can the audit be delivered white-label under an agency's name?

Yes, and agencies often do. See white-label Drupal overflow capacity for agencies for how that works. An independent review also carries more weight with the end client precisely because the author did not write the code.

What Drupal versions do you audit?

Drupal 11 and Drupal 10. I also audit Drupal 7 and Drupal 9 sites, though on those the report usually doubles as a migration case; see Drupal support and upgrade services.

Not sure what is slowing the site down?

Tell me the Drupal version and what is worrying you. I will come back within a working day with a fixed price and a date.

Get in touch