Your Drupal site works, mostly. But you have a nagging feeling that something under the hood is quietly costing you: pages that load slower than they should, a security update nobody has applied in months, rankings that have been sliding since the last redesign. Drupal is powerful, and that power is exactly why problems hide. One unmaintained contributed module or an unpatched core version can sit untouched for a year before it turns into a breach, an outage, or a traffic drop you can't explain to your leadership team.
A Drupal website audit is how you find those problems before they find you. We're Takeoff, a website-first marketing agency for established B2B companies with long sales cycles. We've launched more than 70 B2B websites in the past two years across WordPress, Webflow, HubSpot, and Drupal, and we run a version of this audit before every redesign and ongoing support engagement. On one enterprise B2B project, that groundwork enabled Takeoff to lift SEO-sourced demo requests by 57.1% and organic traffic by 35.66% for our client. This guide walks through the same audit, step by step, so you know exactly what to check and what to fix.
A Drupal website audit is a systematic review of a Drupal site's security, performance, code quality, SEO, content structure, and accessibility to find what's broken, outdated, or holding back growth, and to prioritize what to fix first.
What makes it different from a generic website audit is that it accounts for how Drupal actually works. A generic audit checks page speed and hunts for broken links. A Drupal audit does that too, but it also asks Drupal-specific questions: Is your core version still supported? (Drupal 7 reached end of life in January 2025, and Drupal 10 reaches end of life on December 9, 2026.) Are your contributed modules still maintained and patched? Does your custom code follow Drupal's APIs and coding standards so it survives the next major upgrade? Is your content architecture (entities, fields, taxonomy, Views) helping the site or bloating it? Those factors don't show up in a standard crawl, and they're usually where the real risk lives.
A good audit doesn't mean rebuilding everything. It means working through each part of the site methodically, security, performance, code, SEO, structure, and accessibility, so nothing slips through and you finish with a clear, prioritized list of what actually needs attention. Work these six steps in order. Security comes first for a reason.
Security is the highest-risk area to get wrong on Drupal, so start here. Begin with the foundation: what core version are you on, and is it fully patched? An unsupported core version means no more security releases, which is a hard deadline, not a suggestion. Then inventory your contributed modules and check each one for security coverage. A module that's been abandoned by its maintainer, or one running a version with a known advisory, is an open door.
From there, review user roles and permissions. Most Drupal sites accumulate access over the years, so apply least privilege: strip permissions nobody uses, remove stale admin accounts, and make sure content editors can't reach configuration they shouldn't touch.
Don't stop at the application layer. Check the environment too: file and directory permissions, database access credentials, and HTTPS configuration across the whole site (including redirects from http). Modules like Security Review can flag misconfigurations and risky permissions automatically, and Security Kit (Seckit) lets you harden against clickjacking and cross-site scripting without writing custom code. Run those, but read the output critically. A tool tells you what looks wrong; judgment tells you what to fix first.
Once the site is secure, find out what's making it slow. Caching is where most Drupal performance lives or dies. Confirm Drupal's core caching is actually on and configured correctly (Internal Page Cache for anonymous visitors and Dynamic Page Cache for authenticated ones), because a surprising number of slow Drupal sites simply have caching misconfigured. For higher-traffic sites, look at external acceleration: Redis or Memcached for the cache backend, Varnish in front of the site, and a CDN for static assets.
Then check the mechanics that quietly drag load times down: database hygiene (bloated tables, unrun cron, watchdog logging filling up), and asset handling (uncompressed images, no WebP, CSS and JS aggregation switched off). On the front end, measure the metrics that reflect what users actually feel. Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift) plus server response time will surface the real problems faster than a general "the site feels slow." Lighthouse and PageSpeed Insights give you the Core Web Vitals picture, GTmetrix is useful for waterfall analysis, and New Relic helps when you need to trace a slow response back to a specific query or module.
This is the step teams skip most often, and it's the one that determines how painful your next upgrade will be. Start by taking inventory of contributed modules and removing anything unused or unsupported. Every extra module is more surface area to patch, update, and debug. If it isn't earning its place, uninstall it.
Then review your custom modules. Look for deprecated code and functions that won't survive the jump to the next major version, and check whether the code actually follows Drupal's coding standards and APIs rather than working around them. Custom code that ignores Drupal's patterns is the code that breaks on every update and costs you a developer sprint each time.
Finally, look at how the site is managed, not just how it's built. Are you using configuration management (config sync) so changes move cleanly between environments instead of getting clicked in on production? Are dependencies handled through Composer? Is there a proper .gitignore keeping settings files and vendor directories out of version control? Coder and PHP CodeSniffer will scan your codebase against Drupal's official standards and give you a concrete list of violations to work through. This is standard practice on every Drupal project we build, because it's the difference between an upgrade that takes a day and one that takes a month.
Now check whether search engines and AI answer engines can actually find, crawl, and trust the site. Work through the on-page and technical fundamentals: a correct robots.txt, a valid and submitted sitemap.xml, clean URLs (Pathauto handles this well on Drupal), unique meta titles and descriptions, a single logical H1 per page, structured data where it fits, canonical tags to head off duplicate content, broken internal and outbound links, and working analytics tracking.
Pay closest attention to redirects and URL mapping. This is the single area where B2B sites lose rankings during a redesign or migration, and it's almost always preventable. When URLs change and old ones aren't redirected properly with 301s, you lose the ranking equity you spent years building, sometimes overnight. This is exactly why our SEO migration process leads with a 55-point checklist and a complete redirect map covering every indexed URL, so organic traffic gets preserved and grown through a redesign instead of cratering at launch.
While you're here, add a short pass on Answer Engine Optimization (AEO), the emerging extension of SEO for tools like ChatGPT and Perplexity. Check whether your key pages use clean schema markup, whether your content has enough entity density and clear, extractable answers for an LLM to cite, and whether you've published an llms.txt. Most B2B buyers now research in AI tools before they ever reach your contact form, so being invisible there is lost pipeline you'll never see in your analytics.
Drupal gives you enormous flexibility in how you model content, and over the years that flexibility usually turns into bloat. Start with content types and fields: consolidate overlapping types that do nearly the same job, and remove fields that no longer hold data. Then move to taxonomy and vocabularies, where you'll often find broken entity references and unused terms that clutter the admin and confuse editors.
Next, look at Views and Layouts, which are common performance culprits hiding in plain sight. Heavy, unoptimized View queries, missing database indices, and pages rendering dozens of blocks can slow both the editor experience and the front end. The goal here is to reduce bloat so the site is faster to load and easier for your marketing team to actually use. Xray Audit is built for exactly this, giving you a clear map of your content types, fields, and how everything is structured, and Audit Export can turn that into a shareable report for the whole team. Cleaning this layer up is often what lets a marketing team run the site without a developer ticket for every change.
Accessibility is the step most teams treat as optional, and it's the one with the widest business impact. Work through the WCAG basics: image alt text, semantic HTML with a correct heading order, appropriate ARIA usage where native elements don't cover it, full keyboard navigation, sufficient color contrast, and a responsive display that holds up across devices.
WAVE and axe will catch a large share of automated accessibility issues, and Lighthouse includes an accessibility score as a quick starting point. Just remember that automated tools catch maybe half of real accessibility problems, so pair them with manual keyboard and screen-reader testing on your key flows. The reason this matters beyond compliance: accessibility overlaps heavily with SEO (semantic structure and alt text help both) and it carries real legal exposure for B2B companies. That makes it a business issue, not just a checkbox.
You don't need every tool below to run a useful audit, but knowing which one does what will save you time. Here are the tools and modules referenced in the steps above, grouped by what they're best at. Availability changes, so confirm the current release and your Drupal version's support on drupal.org before you install anything.
Plenty of this you can check yourself. Drupal's own status report at /admin/reports/status will surface unapplied updates, failed cron, and configuration warnings in a few minutes, and free tools like Lighthouse and PageSpeed Insights will give you a solid read on performance and basic SEO. If your site is relatively simple and your team is comfortable in Drupal, a self-audit will get you a long way.
Bring in a specialist when the stakes or the complexity climb. That usually means complex custom code you can't fully evaluate in-house, regulated or sensitive data where a security gap is a serious liability, pre-migration or replatform planning where a missed detail costs you rankings, or a sudden drop in performance or rankings after a change that you can't diagnose. In those situations, a second set of expert eyes is cheaper than the problem.
Sometimes an audit tells you something harder to hear: the site doesn't just need patching, it needs a redesign or a replatform. An accumulation of unsupported modules, brittle custom code, and a content model fighting your team is often past the point where more fixes make sense. When that's the honest read, the audit becomes the diagnostic that tells you what to build next.
Takeoff is a website-first marketing agency for established B2B companies with long sales cycles. Every person on your project has at least seven years of experience, so there's no junior B team learning on your site, and we're CMS-agnostic (WordPress, Webflow, HubSpot, and Drupal), which means our recommendation is based on what's right for your team, not what we prefer to build.
We audit against every layer covered above: security, performance, code quality, SEO, content structure, and accessibility. From there, the path depends on what we find. If the audit shows your site is past patching, we run the redesign or replatform with a structured SEO migration (that 55-point checklist and full redirect map) so your organic traffic is preserved and grown through the transition instead of dropping at launch. If it just needs tuning, an ongoing optimization retainer handles the fixes and improvements over time, with no lock-in and no obligation to stay longer than you want to.
We've seen how much is at stake when an audit gets skipped. One B2B SaaS company came to us after a previous agency's redesign dropped them from 298 ranking keywords to 15, taking most of their organic pipeline with it. We diagnosed the damage and recovered their rankings in about two to three months. The point of an audit is to catch that kind of problem before it happens, not after.
If your Drupal site is overdue for a real look under the hood, let's talk: https://www.takeoffnyc.com/get-a-quote.
Request a Quote or email lenny@takeoffnyc.com to start the conversation.
.avif)
