A website maturity audit is a scored, repeatable review of how your web operation actually runs \u2014 content workflow, deployments, security upkeep, measurement \u2014 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.<\/p>\n
Not the pixels. It measures the operation behind<\/em> 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.<\/p>\n From software delivery governance, where it is now a product category. SCMGalaxy \u2014 a training, consulting and advisory company \u2014 built SCMGalaxy OS<\/a> 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.<\/p>\n Those are snapshots of outputs \u2014 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.<\/p>\n For most business sites, six areas scored 0\u20135 each are enough:<\/p>\n 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 \u2014 rewrite it until it asks for evidence.<\/p>\n 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 \u2014 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.<\/p>\n Take the two lowest areas and stage the response on three horizons \u2014 the same one-month, three-month, six-month cut the delivery-governance world uses for its transformation plans. Days 1\u201330: mechanical fixes needing no approval \u2014 enable staging, document the hosting setup, test one restore. Days 31\u201390: install the routine \u2014 a publishing checklist, a monthly update window, a quarterly access review \u2014 and let it survive a busy stretch. Days 91\u2013180: 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.<\/p>\n If you are an agency, yes \u2014 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.<\/p>\nWhere does the method come from?<\/h2>\n
How is this different from an SEO audit or a performance audit?<\/h2>\n
What areas should the scorecard cover?<\/h2>\n
\n
Who should do the scoring?<\/h2>\n
How often should we run it?<\/h2>\n
We scored badly. Now what?<\/h2>\n
Should the client see the scores?<\/h2>\n
Does a rebuild reset the audit?<\/h2>\n