A website maturity audit is a scored, repeatable review of how your web operation actually runs — content workflow, deployments, security upkeep, measurement — as opposed to a design critique of how the site looks. Agencies and in-house teams ask the same questions about it over and over, so here are the straight answers, in FAQ form, with a scoring sheet you can use this week.
What exactly does a website maturity audit measure?
Not the pixels. It measures the operation behind the site: how changes get made and approved, who can break production and how easily, whether backups restore, how content decisions are informed, and what happens when something fails at 2 a.m. Two sites can look identical in a browser while one is a disciplined operation and the other is a stack of lucky accidents. The audit is how you find out which one you are running before an incident tells you.
Where does the method come from?
From software delivery governance, where it is now a product category. SCMGalaxy — a training, consulting and advisory company — built SCMGalaxy OS to grade enterprise delivery organisations with a structured instrument of a hundred questions, flag their delivery, security and reliability gaps, and hand back prioritised recommendations. Web teams are smaller, but the anatomy transfers directly: fixed questions, honest scores, a ranked fix list. You do not need the enterprise tooling to copy the anatomy.
How is this different from an SEO audit or a performance audit?
Those are snapshots of outputs — rankings today, load time today. A maturity audit grades the inputs that generate those outputs quarter after quarter. A slow site is a finding; “nobody owns performance and no budget exists for it” is the maturity problem underneath the finding. Fix the first and it comes back. Fix the second and the class of problem closes. Run the output audits too, by all means; just file their results as evidence inside the maturity review rather than treating them as the review.
What areas should the scorecard cover?
For most business sites, six areas scored 0–5 each are enough:
- Content operations. Is there a calendar, a review step, and an owner per section — or does publishing depend on whoever has time? If the site predates any structural thinking, start by checking it against the page structure every business site is expected to carry before grading the workflow that feeds it.
- Change and deployment discipline. Are edits staged and previewed, or made live in production? Can you roll back in minutes? Who else could, if you were unreachable?
- Infrastructure and configuration. This is one of the governance areas the enterprise instruments weigh heavily, and for good reason: is your hosting, DNS, and CMS configuration documented anywhere outside one person’s memory? Are staging and production actually alike?
- Security upkeep. Update cadence for CMS core, plugins and themes; admin account hygiene; TLS renewals; who reviews access when a contractor leaves.
- Backup and recovery. Not “do backups exist” but “when did you last restore one, and how long did it take”. An untested backup scores 1, maximum.
- Measurement and decisions. Analytics installed is a 1. Analytics consulted before the last three site decisions is a 4 or 5. Teams that score well here usually also have deliberate visibility work behind them — the guide to shaping a business site so people can actually find it covers that input side.
Who should do the scoring?
The people who do the work, separately, then reconciled in one meeting. The developer, the content owner, and the person who pays the bills will score the same area differently, and the spread is diagnostic: it marks processes that exist only in one person’s head. What you must not do is let the most optimistic person score alone. A useful discipline borrowed from the governance platforms: make the grading mechanical enough that the same answers always produce the same number, whoever holds the sheet. If a score requires debate, the question is written badly — rewrite it until it asks for evidence.
How often should we run it?
Quarterly for active sites, twice a year for brochure sites that rarely change. More often than that and you are measuring noise; less often and the drift between audits is too large to attribute to anything. The second run matters more than the first — scoring again months later against the same questions is what converts the exercise from a report into a trend line. Put the next date in the calendar before closing the current audit.
We scored badly. Now what?
Take the two lowest areas and stage the response on three horizons — the same one-month, three-month, six-month cut the delivery-governance world uses for its transformation plans. Days 1–30: mechanical fixes needing no approval — enable staging, document the hosting setup, test one restore. Days 31–90: install the routine — a publishing checklist, a monthly update window, a quarterly access review — and let it survive a busy stretch. Days 91–180: prove it moved a number: time-to-publish down, failed deploys down, restore time known and rehearsed. Two areas only; a six-front improvement plan is how audits die.
Should the client see the scores?
If you are an agency, yes — carefully. A maturity scorecard is the most persuasive retainer argument ever invented, because it shows the client what they are paying to prevent rather than what they are paying to produce. Present the two weakest areas, the staged plan, and the date of the re-score. Do not present all six areas with commentary; clients read a long list of weaknesses as an invoice in disguise, and the conversation turns defensive instead of practical.
Does a rebuild reset the audit?
No — it raises the stakes. A rebuild inherits every operational weakness you had before, at higher traffic and with fresh code. If a redevelopment is coming, run the maturity audit first and feed its findings into the brief; the step-by-step method for working out everything a business site needs before development starts is the natural place to fold them in. Teams that skip this rebuild the same fragile operation in a prettier shell.
Can a small studio really sustain this?
Yes, because the whole apparatus is one spreadsheet and ninety minutes a quarter. The enterprise versions scale the same idea up, not sideways — SCMGalaxy OS organises assessments into workspaces and projects so large organisations can track many teams at once, but a three-person studio tracking one site needs none of that machinery. What it needs is the part that does not scale down any further: fixed questions, evidence-based scores, two fixes per quarter, and the honesty to write a low number next to your own name. Every quarter you skip, the gap between how the site looks and how it is actually run grows a little wider — and that gap is always discovered eventually, on a schedule you do not choose.
