A useful Drupal site audit ends with decisions a team can assign, sequence, and verify. A long inventory of modules, templates, warnings, and screenshots may look thorough while leaving the next sprint unchanged. Before opening developer tools, write the decision the audit must support: a redesign estimate, an accessibility repair, an upgrade, an editor-workflow improvement, or a performance budget.
That purpose changes the evidence worth collecting. A redesign audit needs to connect fields and view modes to visible components. An upgrade audit needs custom-code ownership and compatibility risk. An editor-workflow audit needs observation of real publishing tasks. Mixing every possible concern into one undifferentiated report usually hides the dependencies that determine cost.
Begin with the change the audit must enable
Choose one representative page and trace it end to end. Record the content type, fields, media references, Paragraphs or Layout Builder structure, view mode, preprocess logic, Twig templates, attached libraries, cache contexts, and permissions involved. This vertical slice exposes how Drupal decisions combine in production instead of treating each subsystem as an isolated checklist.
Repeat the trace for an edge case: an empty optional field, a long title, a translated item, an unpublished reference, or an editor without administrative permissions. The contrast often reveals brittle assumptions that a perfect sample page conceals. Capture the exact route and role so another person can reproduce the result.
Trace one page from content entry to rendered output
Classify each finding by ownership. A missing field constraint is not a CSS defect. A component whose markup changes across view modes may require content-model and frontend agreement. A slow page can originate in an uncached render array, an oversized image derivative, a View, or third-party JavaScript. Naming the owner prevents the theme backlog from becoming a dumping ground.
Use Drupal’s documentation to confirm platform behavior before labeling it a defect. Record the relevant documentation link beside the finding, the installed Drupal version, and any site-specific override. This matters because configuration, contrib modules, and custom code can deliberately change defaults that an auditor remembers from another project.
Authoritative reference: Drupal documentation.
Separate configuration debt from theme debt
For accessibility, test the rendered interaction as well as the template. Keyboard order, focus visibility, accessible names, validation messages, heading hierarchy, and responsive reading order cross component boundaries. Describe the user action that fails and the expected result. A bare WCAG reference without the observed behavior is hard for a developer or tester to act on.
For caching, document the variation the page genuinely needs. A block that changes by role, language, route, or query argument should declare that context; a block that does not vary should not fragment the cache unnecessarily. Include the request or user state used for the observation so the team can reproduce both the symptom and the fix.
Turn findings into an ordered decision log
A practical decision log has five fields: finding, evidence, owner, dependency, and acceptance test. For example, “article cards expose decorative image alt text” is evidence-based; the owner may be the content model and theme leads; the dependency is the image-field policy; the acceptance test is a screen-reader pass on three card variants.
Order work by dependency and user impact, not by how easy the screenshot is to understand. Content-model changes usually precede template cleanup. Permission and workflow decisions precede editor training. Component API changes precede visual polish. This sequence reduces rework and makes the audit useful for estimation.
Define evidence for the follow-up audit
Close the report with a small verification sample. Name the pages, roles, languages, breakpoints, and cache states that will be checked after repair. If an item cannot be verified, it is still an observation rather than a completed requirement. That distinction keeps “fixed” from meaning merely “code changed.”
The audit is finished when the team can explain what changes first, who owns it, what it depends on, and how success will be observed. Everything else—module lists, screenshots, exports, and automated scans—is supporting evidence for those decisions.
Drupal Site Audits Build Readiness Worksheet: use the worked scenario above to record the evidence, decision, owner, boundary, and review point.
For the adjacent question, continue with Drupal Theme Accessibility Checks Before QA Gets Expensive; it covers a different part of the same-site topic cluster.