A Drupal site that nobody on your side fully understands is hard to budget for, hard to upgrade and hard to hand to a new team. A site audit, which some teams call a technical audit or a health check, is one fixed-price review of what is actually there: the modules and their versions, the custom code, the configuration, security, accessibility, hosting and speed. It ends in a report that says what to keep, what to change, and which deeper audit, if any, is worth paying for. The report is yours, whoever does the work.
Who this is for
- You have inherited a Drupal site. A new role, a merger or an agency that has gone quiet, and nobody can say what the site is built from or who holds the keys.
- A deadline is coming. Drupal 10 security support ends on 9 December 2026, and you need to know whether the move to Drupal 11 is an upgrade or something larger.
- You need a budget before you choose a vendor. A board, a funder or a procurement rule wants a figure, and quotes built on a guess are only different guesses.
- Something is wrong and nobody knows where. Pages are slow, editors work around errors, or a security questionnaire came back unanswered.
- An agency has taken on a client's Drupal site. You need a picture of the codebase before you price the support, delivered under your name if you want it through white-label support.
If you already know the question is security alone or accessibility alone, go straight to the Drupal security audit or the accessibility audit. Each goes further in its own area than a site audit does.
Which audit fits your situation
Most requests start from a situation rather than from the name of an audit. The table maps the usual ones to the audit that answers them, and to what you hold at the end.
| Your situation | Audit | What you receive |
|---|---|---|
| You have taken over the site from another team | Takeover audit of code, configuration, hosting and access | What is missing from the handover, and what to fix first |
| Drupal 10 support is ending | Module compatibility audit | Every module marked Port, Replace, Drop or Decide, ahead of the upgrade |
| The site runs on Drupal 7 or another CMS | Content and module audit | What moves, what is rebuilt and what is retired, before a migration is priced |
| An insurer, a board or a buyer asks about security | Security audit | Findings ranked by severity, each with the effort to fix it |
| A complaint or a tender asks about accessibility | Accessibility audit | Findings against WCAG 2.2 success criteria, located by component |
| Pages are slow, or fail Core Web Vitals | Performance audit | Where the time goes on each page type, and a budget to hold it |
| Hosting is changing, or nobody knows how it is set up | Environment audit | How the site is built, deployed, backed up and restored, written down |
A site audit covers every row at the depth needed to tell you which rows matter. Where one needs more, the report says so, and the deeper audit is quoted on its own.
What you get from a site audit
- One report, written for a developer who was not in the audit and for the person who signs the budget
- An inventory: Drupal and PHP versions, every contributed and custom module, the theme, patches, integrations and scheduled jobs
- Every component marked Port, Replace, Drop or Decide, with the reason
- Findings on security, accessibility, hosting and speed, each ranked and each with an effort estimate
- A record of who holds what: the repository, the hosting account, the domain and third-party keys
- A recommended order of work, and which deeper audit, if any, is worth commissioning
Sample Site audit: what to keep example.org · Drupal 10.2 · PHP 8.1
| Component | Area | Recommendation | Reason |
|---|---|---|---|
grants_portal Custom module | Code | Port | The logic is sound; it calls APIs that Drupal 11 removes. |
custom_cache Custom module | Performance | Replace | Switches the page cache off for every visitor; core cache tags do the job it was written for. |
backup_migrate Contributed | Hosting | Replace | Writes backups inside the web root; server backups with a tested restore belong outside it. |
devel Contributed | Security | Drop | A development module enabled on the live site; it belongs on local copies only. |
home_carousel Theme component | Accessibility | Decide | Autoplays with no pause control; removing it changes the home page, which is a business call. |
The same labels are used for modules and for everything else in the codebase, and they match the module audit on the upgrade page, so a report reads the same whichever audit it came from.
An engineer reads it and replies within one business day.
How a Drupal site audit runs
How a Drupal site audit runs
- Scope The site, its environments and the question behind the audit, agreed in writing. You keep the scope statement
- Copy We work on a copy: the repository, a sanitised database and read access to configuration. Production stays untouched
- Review Modules, code, configuration, security, accessibility, hosting and speed, each at the depth the question needs.
- Report Every component marked, every finding ranked, each with the effort to fix it. You keep the report
- Walkthrough We take your team, or the team you hire, through anything they want explained. You keep the order of work
What the audit looks at
- Versions and modules. Drupal core, PHP and the database, and every contributed module against its current release and its readiness for Drupal 11 and 12. Modules abandoned upstream are listed apart, because their remedy is different.
- Custom code. Read against Drupal coding standards and scanned for deprecated API calls, so the cost of the next upgrade is counted rather than guessed.
- Configuration. Whether configuration lives in the repository, what differs between environments, and which roles hold which permissions.
- Security. Open security advisories, exposed paths and accounts nobody owns. A full review of code and permissions is the security audit.
- Accessibility. An automated scan and a keyboard pass over the main templates. A criterion-by-criterion review is the accessibility audit.
- Hosting and deployment. How code reaches production, whether a backup has ever been restored, and who is alerted when the site fails.
- Speed. Core Web Vitals on the main page types, the cache configuration and the slowest database queries.
- Ownership. Who holds the repository, the hosting account, the domain and every third-party key the site depends on.
Release histories and issue queues are part of the module check, because abandonment shows there first. We maintain modules on drupal.org ourselves, among them WE Mega Menu, now released for Drupal 10.3, 11 and 12, so we read those signals as maintainers do.
Volume is measured too, because it changes the price of whatever comes next. When we moved the Apex Embroidery Designs store off Drupal 7, 20 million items came across; a figure like that belongs in the audit, not in a surprise halfway through the work.
What a Drupal site audit costs
The audit is priced from the size of the site: the number of contributed and custom modules, the amount of custom code, and the environments and integrations in scope. It is one piece of work at a fixed price, quoted before it starts, and nothing in it depends on hiring us afterwards.
Work that follows from the report is quoted separately, against the findings. On the pricing page, the audit sits under maintenance and support, as one piece of work rather than a monthly fee, and so do the fixes that follow it. An upgrade or migration the report leads to is priced as a project, in whichever tier its scope matches, usually Small to Large on the project tiers.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
We do not know which audit we need. Where do we start?
Here. Tell us what prompted the question: a handover, an upgrade, a budget, a complaint. The site audit goes wide enough to show which areas need depth, and the report says which deeper audit, if any, is worth paying for. Often none is.
Is a site audit the same as a website audit from an SEO tool?
No. A website audit from an SEO tool crawls the public pages and reports on titles, links and load times. A Drupal site audit also reads what a crawler cannot see: the modules and their versions, the custom code, the configuration, the permissions and the hosting. The public checks are one input to it, not the whole of it.
Can you audit a site that another company still maintains?
Yes. We need read access to the repository and a copy of the database, and we do not contact the current vendor unless you ask us to. The report describes the site, not the people who built it, and it goes to you alone.
What access do you need, and do you touch the live site?
The repository, a sanitised copy of the database and read access to the hosting configuration. Checks such as TLS, response headers and page speed are made from outside, against the public address, which needs no access at all. Any account we are given is removed when the audit ends.
Will the audit tell us to rebuild the site?
Only if the evidence points there. Most findings are fixed in place: a module ported, a permission corrected, a cache setting changed. A rebuild is recommended when the content model itself is the problem, or when the site is still on Drupal 7, and the report shows why.
Can another company do the work the report recommends?
Yes, and the report is written for that case. Each item says where it is, what to do and roughly how much effort it takes, so any Drupal team can quote from it. If they have questions, the walkthrough is open to them.
Do you audit sites that are not built on Drupal?
When the question is whether to move the site to Drupal, yes: a WordPress, Joomla or bespoke site gets the content and module audit described on Drupal 7 and legacy CMS migration. For a site that will stay on another platform, tell us what it runs and we will say plainly whether we are the right team for it.
What happens after the audit?
Nothing, unless you want it to. You keep the report and decide what to do with it. If you want us to do the work, each item is quoted at a fixed price, and keeping the site current afterwards is Drupal support and maintenance.
Not covered here? Ask us directly.
Request a site auditAn engineer reads it and replies within one business day.
Migrate & Audit
Related services
Tell us about the site and what is changing
Send the address and what prompted the question: a handover, an upgrade, a budget or a complaint. We will say which parts of the audit apply and quote a fixed price for them.
An engineer reads it and replies within one business day.