This is Part 2 of a series on "How to do a Site Audit". You may want to start with Part 1.

"We should change it like this because it’s a best practice" is not a convincing argument to most business people. Organize your site audit by the types of concerns you find, rather than the layers of the stack you found them on or which module they relate to. You should be able to articulate how addressing each concern would have ROI for your client. For example, a section on Performance concerns could begin with an introduction explaining how page load time relates to e-commerce conversion rate or SEO.

Depending on the client’s concerns, the purpose of the site, the state of the site, and your own domain expertise, the concerns you focus on in an audit will vary. The top concerns I always include are:

• Maintainability

• Security

• Performance

• End-user experience

• Content editor experience

Other concerns you may include could be SEO, Design, Information Architecture and Content.

Focus on the Future

Maintainability is usually the longest section in my audits. As with homes and cars, a lack of quality becomes more and more expensive over time. Almost any team will have succeeded in making a Drupal site that basically looks and functions the way the client desires, but few will have prioritized maintainability. If the project was fixed bid, under-estimated, or the vendor does not maintain its own projects, they are not incentivized to deliver quality software which will be easy to maintain. Even if they are not disincentivized, knowing what makes a more maintainable system is a level of advancement and experience beyond being able to build a site that works.

Sites with poor maintainability tend to be replaced after a few frustrating years, while maintainable sites with good care can be expanded and used indefinitely. (This site, zivtech.com, has been in use since its origin in 2007, going through many upgrades and redesigns without ever needing a rebuild.) Many of the items you may want to call ‘best practices’ you can reframe as maintainability issues. Maintainability issues can include uncommented custom code, hacked contributed modules, lack of documentation, poor deployment workflow, lack of automated testing, spaghetti CSS, ‘creative’ use of contributed modules, inconsistent approaches, unused code, etc. etc.

Security is your Responsibility

Regardless of whether the client tells you that they are concerned with security, it is your responsibility to check on security in every site audit. The Security Review module is a great tool to catch common Drupal security mistakes like poorly configured input formats, use of core PHP module, permissions that are too open, and insecure file permissions. This section of your audit is also where you will point out that it is a big process problem if they are currently behind in security updates. I also take a look at the privileged user accounts and point out if there are many of them which are not in regular use which may no longer be needed, and recommend using Password Policy module to enforce secure password use (but remember that secure password use is really an education issue; there’s no code that will prevent someone from e-mailing their password). This is also where you will explain the dangers of session hijacking if the site does not enforce SSL. Review custom modules and themes for security holes: if the site allows any input from untrusted users look for it being output without being sanitized. Depending on the hosting of the site, the security of the server configuration is also critical.

Performance is about Bottlenecks

Get a sense of how concerned your client is about their site’s performance, and any specific concerns. Many audits will point out dozens of performance ‘improvements’ that ‘should’ be made to a site without any indication of how much relative impact each change would have. This might make your audit look smart and thorough and generate busy work for you, but it’s a disservice to your client. Focussing on anything other than the largest performance issues is a waste of time and money. It’s not a ‘small improvement’, but rather a harmful distraction from the real work.

Performance issues can easily be divided between front-end and back-end and you should be able to see the relative importance of each in the page load time. Most big Drupal sites have an audience of mainly unauthenticated users and cache the server requests with Varnish. In these cases the front-end is the main issue: it’s common that using a CDN, ensuring images are optimized, and reducing external Javascript requests are main points of advice. Webpagetest.org is a good tool for looking into front-end problems. XHProf is great for PHP/MySQL level performance inspection, but often beyond the scope of a site audit.

Be the First-time Visitor

When I first get a whiff of a new site audit project coming my way, I like to get a first impression look around the site as a first-time visitor and observe what I learn and feel coming to the site before I find out any inside information. Many times I find that my impressions are wildly at odds with what the stakeholders will later explain as the purpose of the site. Often it’s not just my first visit that leaves me not getting their message: I often spend an entire week looking at their website for an audit and still cannot tell you the purpose of it, what the company is selling, or what the call to action is. It’s common that people get caught up in features, bugs, and design of their website and lose sight of the main purpose of their site (typically communicating a message to visitors).

Try doing everything and looking everywhere you can on the site in the mindset of a site visitor. If the client can give you personas and user stories that describe their intended audience, try acting these out on the site.

One role at a time

Take a look at how the site is configured in the Drupal backend. Experience using the site as a user with each available role. What is confusing or overly complicated? What’s it like to actually add and edit content? Is there an appropriate content workflow? Do all the buttons in the WYSIWYG work correctly, or does your some of your formatting get removed when you view the content? Are there fields in content types that aren’t being displayed? Is there a vocabulary called "Tags Deprecated (delete me)"?

Drupal makes site building easy: many sites will have the appearance that the content model was designed by an intern, or just grew organically. Unfortunately fixing a bad content model is not easy at all once there is a lot of content which will need to be migrated to a new model. There are easy fixes, like removing unused fields, reordering and grouping fields to add clarity, or adding help text. But the deep architecture problems found in this part of the audit are typically the most time-consuming to fix.

The Product is Process

I focus a lot on process. That can be difficult to see in an audit because process involves the whole organization, and you might not get enough access to see the big picture. For example, I did an audit recently where the client told me that they were having constant bugs and problems, and that's why they needed an audit.

Every time I tried to press them to give me a list or any examples of specifics, they didn't have any. I thought, "Well the lack of a list is the biggest bug of all. All your managers are reporting to you that they have problems but you're not keeping a list?" Process is the first thing you need to improve before you can efficiently tackle anything else. Don’t be afraid to address process issues in a site audit: the site is just an artifact of the process.

Tune back in for part 3 in which we’ll have auditing tips for each layer of the stack.