What a University Drupal Platform Audit Should Actually Cover: A 9-Point Scope Template
A real Drupal platform audit covers nine areas: version exposure, content model, governance, platform estate, integrations, accessibility, security posture, performance, and AI visibility. The test of whether you got one is simple. If the deliverable only makes sense to the vendor who wrote it, you were sold a proposal, not a diagnosis.
Type “free website audit” into a search bar and a hundred agencies will offer you one. Most will send a PDF within 48 hours. It will have a score out of 100, a red-amber-green table, and somewhere around page four, a recommendation that you rebuild your website.
That document is not an audit. It is a sales instrument wearing a diagnostic costume, and it costs the sector real money, because institutions use it to make decisions it was never built to support.
The distinction matters more in higher education than almost anywhere else. A university does not have one website. It has a platform estate assembled over fifteen years by departments that procured independently, running on software whose original architects have all moved on, wired into systems nobody has documented since 2019. An audit that examines the homepage has examined roughly two percent of the problem.
The nine areas below are the other ninety-eight percent.
The 9-point scope template
| # | Audit area | What must be enumerated | Evidence to demand |
|---|---|---|---|
| 1 | Version and end-of-life exposure | Major version per property; every contributed module and its upgrade status | Full module inventory with release status per module |
| 2 | Content model | Content types, fields, taxonomies; whether programs are queryable entities | Entity and field structure export |
| 3 | Governance and permissions | Roles, users holding publish rights, workflow states, multisite architecture | User and role report with last-login dates |
| 4 | Platform estate | Every responding subdomain and the platform behind it | Subdomain inventory with CMS and certificate status per host |
| 5 | Integrations | SIS, CRM, SSO, catalog, notification; failure modes and alerting | Integration map with named owners |
| 6 | Accessibility | WCAG 2.1 and 2.2 AA at component level; third-party and PDF scope | Scan export plus component-level trace |
| 7 | Security posture | Patch currency, advisory response history, admin access hygiene | Patch log and access review |
| 8 | Performance | Real-user metrics on funnel pages, not lab scores | Field data segmented by page template |
| 9 | AI and search visibility | Crawler access, structured data coverage, rendering method | robots.txt analysis and schema audit |
Copy that table into your RFP. Any agency quoting an audit should be able to say yes to all nine rows, or explain precisely which one they exclude and why.
The one test that separates a diagnosis from a sales call
There is a faster way to judge an audit than reading it end to end, and it has nothing to do with price.
A real audit produces a document you could hand to a competing vendor, and they would know what to quote. Version numbers, module names, user counts, query times, file paths. It is useful whether or not you hire the people who wrote it.
A sales audit produces a document that only makes sense if you hire the author. Scores, severity colors, and recommendations pitched at a level of abstraction that requires a follow-up call to interpret.
Ask for a sample deliverable before you agree to anything. Any agency that has done real audit work has one it can redact. Hesitation is the answer.
1. Version and end-of-life exposure
Which Drupal major version each property runs, which modules block an upgrade, and which have no upgrade path at all. Everyone claims this one. Almost nobody does it properly, because doing it properly means enumerating every contributed module and checking each against its current release.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your site is running an outdated version of Drupal and should be upgraded.” | “You are on Drupal 9.5.11, unsupported since December 2023. Of 47 contributed modules, 41 have Drupal 11 releases, 4 need patches that already exist in the issue queue, and 2 are unmaintained and need replacing. Here are the two, and here is what replaces them.” |
The second lets you budget. The first lets someone sell you a rebuild.
2. Content model and information architecture
How content types, fields, and taxonomies are structured, and whether the things you need to query are actually queryable. In higher education this reduces to one question: are academic programs modeled as entities, or typed into body copy?
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your content structure could be improved.” | “Your 312 program pages are basic pages, with degree type, credit hours, and start dates typed into the body field. Nothing can query them. A program finder, structured data, and any catalog sync are all blocked by this single decision.” |
Modeling decides what you can build later. Programs stored as prose cannot be filtered, sorted, syndicated, or marked up, which silently caps enrollment growth and yield no matter how much you spend on the marketing above it.
3. Governance, roles, and editorial workflow
Who can publish what, who reviews it, and whether the permission structure reflects anyone’s intention or fifteen years of accumulated exceptions.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “You should implement a content governance model.” | “214 users can publish directly to production. 61 have not logged in for over a year. Three roles hold overlapping permissions nobody can account for. There is no review state: publish is one click.” |
Governance is where university platforms actually fail, and it is an architecture question rather than a policy document. The choice between Drupal multisite, the Group module, and Domain Access should fall out of who is accountable for which content, which is what a Drupal consulting engagement exists to settle.
4. The platform estate
Not the main site. Everything. Athletics, the library, forty department sites, the conference microsite from 2018 nobody has touched since.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your web presence is fragmented across multiple platforms.” | “Certificate transparency logs show 340 subdomains. 47 respond. Of those, 12 run Drupal, 9 run something else, 3 could not be identified, and 4 return an expired certificate. Two run software with no owner listed anywhere in IT.” |
Most institutions estimate this number low, often by a factor of five. You cannot secure, patch, or make accessible a property you do not know exists, and the forgotten ones reliably run the oldest code.
5. Integrations
The student information system, the CRM, single sign-on, the course catalog, emergency notification. What connects to what, how, and what happens when it breaks.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your integrations should be reviewed and modernized.” | “The Banner feed runs on a cron job written in 2019 by a developer who has left. It has no error handling. When it fails, program pages silently display last year’s data and nobody is alerted. It failed twice in the last six months.” |
Integrations are the least documented layer in most estates and the first to break during peak enrollment traffic. Any audit that lists integrations without describing their failure modes has inventoried them, not assessed them.
6. Accessibility conformance
Against WCAG 2.1 and 2.2 AA and Section 508, covering your own content and the third-party content embedded inside it: application forms, athletics feeds, video captions, and the legacy PDF backlog.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your site has 1,247 accessibility errors.” (a scanner export, presented as an audit) | “Automated scanning surfaced issues across five categories. 89 percent trace to three theme components: the card, the accordion, and the main navigation. Fixing those three removes roughly 1,100 issues across every page at once. The remainder need manual review, and here is that list.” |
A count tells you nothing about effort. Automated tooling detects roughly a third of WCAG criteria, and the issues it does find usually collapse into a handful of components, which is where remediation actually happens. An audit that scopes only what the agency would build has covered a fraction of the real surface.
On April 20, 2026, four days before the original deadline, the Department of Justice issued an interim final rule extending ADA Title II compliance by one year.
| Institution type | Deadline | Standard |
|---|---|---|
| Public, jurisdiction of 50,000 or more (nearly all public universities, because population is calculated at state level) | April 26, 2027 | WCAG 2.1 Level AA |
| Public, jurisdiction under 50,000, and special district governments | April 26, 2028 | WCAG 2.1 Level AA |
The standard and the underlying obligation did not change, and the DOJ stated it fully anticipates implementing the regulation at the new deadline. Current dates are published on the Department of Justice Title II guidance page. Many guides published since April still cite the superseded April 2026 date, so institutions planning against those figures believe they missed a deadline they did not, or stopped planning for one still ahead. The same pattern runs across the public sector, which we covered in our government and public sector ADA analysis.
7. Security posture
Patch currency, advisory response history, admin access hygiene, and whether anyone is accountable at 2am.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your website has security vulnerabilities that need attention.” | “The last core security update was applied 11 months ago. Three advisories have shipped since, one rated highly critical. Applying them requires a developer not currently on retainer, and there is no documented escalation path for an out-of-hours advisory.” |
A good security finding never names the specific unpatched vulnerability in a document that will be forwarded around a university. That is a target list, not a diagnosis. Patch status, response history, and access hygiene tell you everything you need without publishing the attack.
8. Performance under real conditions
Not a lab score. Real-user data, on the pages that matter, at the times traffic actually arrives.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “Your PageSpeed score is 42 out of 100.” | “Field data shows the program finder at 4.1s largest contentful paint on mobile, against 1.9s for the homepage. The gap is 14 uncached Views queries on a page 60 percent of prospective students land on first.” |
A homepage that scores well while the application funnel crawls is a well-optimized brochure. Performance work belongs on the pages where enrollment happens.
9. AI and search visibility
Whether AI assistants can reach your content, and whether they can make sense of it when they do.
| A sales finding sounds like | A real finding sounds like |
|---|---|
| “You should optimize your content for AI search.” | “Your robots.txt blocks OAI-SearchBot and PerplexityBot under a rule added in 2024 that nobody currently owns. Your program pages carry no EducationalOccupationalProgram schema. Both are fixable in days rather than months, and neither requires a platform change.” |
Prospective students build shortlists through AI answers before they reach your homepage, which makes crawler access and structured data an enrollment concern rather than a marketing one. One Drupal education portal lifted organic visibility 45 percent through answer engine optimization alone, without touching the platform. It sits inside digital and AI readiness, and AI personalization and intelligent search can be layered onto an existing Drupal site without a rebuild.
What the deliverable must contain
Findings need a shape. Ask for four things:
| Element | Why it matters | Reject if |
|---|---|---|
| Prioritized remediation plan | Sequence tells you what to do Monday. Severity only tells you how bad things are. | Findings are sorted by severity color rather than by risk and effort |
| Named owners per finding | Findings without an owner do not get fixed | Every item is assigned to “the vendor” |
| Effort ranges, not fixed prices | “12 to 20 weeks” is honest before discovery closes | A precise figure appears before scope is settled |
| Raw evidence attached | Makes the document portable to another vendor | You are given conclusions with no underlying data |
Portability is the entire test. If a second agency could pick up the document and quote from it, you were given a diagnosis.
How to judge a free audit
Free audits have a poor reputation and mostly deserve it, though not for the reason people assume. The problem is not the price. It is that the deliverable is a scorecard, engineered so the only sensible next step is a call with whoever sent it.
Price is a weak signal in both directions. A free audit that hands you a portable diagnosis is worth more than a fifteen-thousand-dollar audit that hands you a traffic-light table.
Apply the portability test regardless of what you paid, including to ours. Ask for the sample deliverable before you commit to a conversation. Check whether it names modules, users, and query times, or whether it names colors. Check whether you could hand it to a different agency and get a sensible quote back. If you could not, the audit did not do its job.
Timeline and cost
A platform audit of a mid-size institution takes two to four weeks. Larger estates with heavy integration take longer, mostly because documenting integrations means interviewing people whose calendars are full.
| Engagement | Typical range |
|---|---|
| Platform audit | No charge |
| Hourly engineering rate | $75 to $300 per hour, varying by project and role |
| Drupal 10 to Drupal 11 upgrade | 8 to 12 weeks |
| Drupal 7 to Drupal 11 migration, mid-size | $75,000 to $150,000 over 12 to 20 weeks |
| Drupal 7 to Drupal 11 migration, enterprise or multisite | $150,000 to $240,000 |
Auditing first tells you which end of those ranges you sit at before you commit to anything, and it gives every agency you approach the same scope to quote against. That is the only way to compare bids meaningfully.
Frequently asked questions
What should a Drupal platform audit include?
Nine areas: version and end-of-life exposure, content model, governance and permissions, the full platform estate, integrations, accessibility conformance, security posture, real-user performance, and AI and search visibility. The deliverable should carry a prioritized remediation plan, named owners, effort ranges, and the raw evidence behind every finding.
What does a Drupal platform audit cost?
BinaryWorks platform audits are free. Cost is not a reliable quality signal in either direction, so judge the deliverable rather than the price: ask whether it names specific modules, user counts, and query times, and whether a competing agency could quote from it. The engineering work that follows an audit runs $75 to $300 per hour depending on project and role.
How long does a university Drupal audit take?
Two to four weeks for a mid-size institution. Larger estates with deep student system integration take longer, because documenting integrations requires interviewing staff rather than reading code.
Should we audit before or after selecting an agency?
Before. An audit run by the agency that wants the implementation work has an obvious interest in the findings, which is exactly why the deliverable should be portable enough to check. Auditing first also means every agency you approach quotes against the same scope.
Is a platform audit the same as an accessibility audit?
No. A platform audit covers accessibility as one of nine areas and establishes exposure. A dedicated accessibility audit goes deeper: manual testing against WCAG 2.1 and 2.2 AA, assistive technology verification, and remediation planned at component level. Institutions working toward April 2027 usually need both.
Can you audit a Drupal site your team did not build?
Yes. Most institutions inherit code from a prior vendor, so this is the normal starting point rather than the exception. BinaryWorks takes over existing Drupal platforms through maintenance and support retainers, typically beginning with a platform audit.
Does an audit commit us to a migration?
It should not, and that is the test. An audit whose only possible conclusion is “rebuild with us” was scoped as a proposal. A real audit sometimes concludes the platform is fine and the problem is governance, which costs far less to fix.
What is the ADA deadline for university websites?
April 26, 2027 for public institutions in jurisdictions of 50,000 or more, which covers nearly all public universities, and April 26, 2028 for smaller jurisdictions, measured against WCAG 2.1 Level AA. The April 2026 Department of Justice extension moved the date only.
About BinaryWorks
BinaryWorks, formerly Drupal Partners, is a Drupal specialist founded in 2009 and headquartered in Atlanta, Georgia. The original name was literal. Drupal has been the primary engineering discipline for sixteen years, and it shows in the public record: Drupal Certified Partner status, 256 organization contribution credits on Drupal.org, 29 team members holding individual contributor profiles, Acquia Certified Partner status, Drupal Association membership, and DrupalCon sponsorship in 2024, 2025, and 2026.
The team is 50-plus certified engineers, designers, accessibility specialists, and growth marketers who have delivered more than 500 projects since 2009, rated 4.9 on Clutch. Higher education clients include MIT, Georgia State University, and Creighton University, whose Drupal modernization lifted enrollment conversions 30 percent while cutting security incidents 40 percent.
Higher education is where Drupal depth compounds hardest, because WCAG obligations, decentralized governance, and student system integration all land on the same platform at once. That combination also appears in government, healthcare, and financial services, which is why BinaryWorks works across eight regulated sectors rather than one. Explore the higher education practice, including operational efficiency and governance, risk, and compliance, or read the higher education case studies.