Site Audit

Do you know what your website is running?

Most organisations know what their website does for them. Fewer can say what it runs on, which parts are out of date, or what would happen if the person who built it moved on. That's normal. Websites tend to outlast the teams that build them, and the knowledge of how one fits together rarely gets written down.

It starts to matter when a decision is coming. A Drupal version is nearing the end of its support, or your security team has questions. Someone needs a budget for the next 3 years that they can defend. You've taken over the site from another team and need a clear starting point. Or something keeps going wrong and nobody can say why.

A site audit turns that uncertainty into facts, so you know what you have, what needs attention, how urgent each thing is and what your options would cost.

How we run a site audit

Every audit follows the same 4 steps. The first needs nothing from you except your website's address.

1. We check your site from the outside

We start with our website health check: 100 automated checks across 12 areas, run against your live site. It looks at what your site sends to any visitor, and it also asks for a short list of well-known files and paths that should never be public.

Each result is marked passed, failed or needs review, and a few are simply noted for your information. Every check comes with a short note on why it matters. The whole check uses ordinary read-only requests and takes a few minutes.

The check sees what any visitor can, so it can't reach your code, anything behind a login or the way the site is put together. The second step covers those.

2. We review it from the inside

With read-only access to your code repository and hosting, we look at how the site is built:

• Drupal core, PHP and every module, and how far each one is from a supported version
• Your custom code: its quality, its security, and how closely it follows Drupal's coding standards and current APIs
• Patches, dependencies and configuration
• What the site does: its content types, views, roles and search, and the systems it connects to, such as single sign-on and analytics
• Hosting, environments, deployment pipelines and automated tests

If you'd prefer not to grant access yet, we can still learn a good deal from the outside. We label each finding as something we observed, something we inferred, or something only access can confirm, so you can see how firm each conclusion is.

If the work needs your data, for example to measure how much content you have, we use a copy sanitised with our own tooling.

3. We work out what matters

We sort the findings by what they mean for you: what puts the site or its data at risk, what costs you time or money, and what can safely wait. When the right answer is to leave something as it is, we say so.

4. We walk you through it

You get the reports in writing, and we go through them with your team on a call, so the people who have to act on the findings understand them. Where something can only be settled by your team, the report asks, and your answers go into a revised version.

If you'd like help with any of the work, we quote it separately, and you approve the scope and cost before anything starts.

What you get

The health check is a technical report, written for whoever looks after your site day to day. Most of the people who make decisions about a website aren't technical, so a site audit produces more than 1 document, each written for the people who'll use it.

The website health check report

It holds the results of all 100 checks, grouped into the 12 areas, with a summary of how many passed, failed or need review. Your developers or your hosting provider can work through it line by line.

The site audit report

This is the main document: a branded report in plain language, written to be read by your leadership and checked by your developers. It covers:

• An executive summary you can read in a few minutes
• An overview of your site and what it does
• The technical findings: versions and support, hosting, dependencies, code quality and security
• What the findings mean for your organisation, in business terms
• Your options, our recommendation, and what it would take in time and cost
• What's out of scope, the questions only your team can answer, and a glossary of the technical terms

When an upgrade or a rebuild is on the table, the options section matters most. It covers the realistic paths from the version you're on, from a stepwise upgrade to a fresh build, and the recommendation comes with a timeline.

The in-depth audit goes further, with a detailed code quality and security review, a technical debt summary and risk register, an integration map, an analysis of your automated test coverage and 2 rounds of questions and answers.

Reports for specific questions

Some questions need a report of their own, and we scope those with you first. We've written:

• Performance investigations that show why a site is slow, back every finding with evidence and order the fixes from cheapest to most involved
• Readiness reports on whether a site will hold up under a sudden surge in traffic, and what to put in place before it has to
• Removal impact reports that set out what changes, and in what order, when an old module or integration is retired
• Feature comparisons of 2 related websites, so you know what to bring across and what a straight copy would break
• Platform reviews of whether to stay, modernise or move to a different system, with costed options
• Whole-estate health checks that rate every system a business runs on, from the website to its integrations, hosting and analytics, for security, stability and recoverability, with a risk register and a plan to fix what matters most
• Analytics summaries of what visitors do on your site, so a redesign starts from evidence

What we usually find

We've run the health check on more than 200 websites in 2026. A handful of results come up again and again, and they're worth knowing about before we've even looked at yours:

• About 3 in 4 had no Content Security Policy, the header that tells browsers which scripts and other resources a page may load.
• Half had no HSTS, which tells browsers to always connect over HTTPS.
• On about 3 in 5, anyone could see which version of Drupal the site runs.
• 1 in 5 had no DMARC record, which helps stop other people sending email in your organisation's name.
• More than 9 in 10 had no skip link for people who navigate by keyboard, and more than a third had images without alt text.
• Close to 9 in 10 served no modern image formats such as WebP or AVIF, which usually means heavier pages than necessary.

None of this is unusual, and most of it is straightforward to fix once someone knows it's there.

What it costs

Bigger or more specific work, such as a whole-estate health check or a performance investigation, is scoped and quoted before we start, at our published rate of $185 an hour plus GST. You approve the scope and cost before any work begins.

Whichever you choose, the reports are yours to keep and share, whoever ends up doing the work.

Where an audit leads

Most audits point to a next step: a Drupal upgrade, a migration, an ongoing support plan or a move to managed hosting. Sometimes the answer is that your site is in good shape and the best plan is to keep looking after it.

FAQs

Is the health check the same as a site audit?
The health check is the first step of every audit: 100 automated checks from the outside, and it's free. The audit adds the review from the inside, the analysis and the written reports.

Do you need access to our code?
Not to start. The health check needs only your website's address, and we can learn a good deal from the outside. Read-only access to your code repository and hosting is what lets us confirm findings and go deeper. We'll tell you what access we need and why, and when we're finished, what to remove.

Will the health check affect our live site?
It makes around 50 to 70 ordinary read-only requests, one after another, which is a light load for any live site. Some of those requests ask for files that should never be public, such as settings files and backups, so a web application firewall may block them. That's the firewall doing its job. If your site sits behind bot protection, the automated check can't get through at all, and we start from the inside with read-only access.

Will you fix things during the audit?
The audit ends with the reports. If you'd like help with what they find, we quote that work separately, and you approve the scope and cost before anything starts.

Can we share the reports?
Yes. They're yours to keep and to share with your leadership, your security team, your developers or another agency.

How do you handle security issues?
The report describes each security issue by its kind and severity, so it's safe to circulate inside your organisation. Anything sensitive, we talk through with the people you nominate.

Is it only for Drupal websites?
The health check runs on any website, and 30 of its 100 checks are specific to Drupal. The audit goes deepest on Drupal, which is what we build and support, and we've also audited websites built on other systems for organisations deciding where to go next.

Does it cover accessibility?
The health check includes 5 automated accessibility checks, which pick up common problems such as missing alt text and skip links. They're a starting point. A full review against the WCAG standard is separate work, which our accessibility page covers.

How long does it take?
The health check takes a few minutes. For a site audit, we agree a delivery date with you before we start, counted from when access is in place.