There are a lot of different reasons why people need a site audit. For example, you may be transferring a project from an old team to a new team that needs to understand the project that they're taking over.
Or maybe there's an internal management change inside a large organization.
For example, in an audit I'm doing now, the site was managed by one team and now they're splitting up the company and that team is not going to manage the site anymore. The people taking over have no experience with the site and they want to find out what they're dealing with.
Was it Done Right?
They might have specific concerns like security or performance that they want to audit. They might be planning a whole new phase of their project and they would like to understand where they're at with their site beforehand.
Sometimes an audit is requested to validate a hunch. Sometimes a manager doesn't think a site was built well, and wants an audit to show that. On the other hand, there are times when a developer wants an audit to show their boss that they did do things right. For example, we had somebody who wanted an audit because his boss kept on telling him that he built the site wrong because he used multiple content types and his boss was sure that you should only ever have one content type. So he wanted an audit that would back him up and say he did a good job, and he did actually do a great job.
Update to Drupal 8
Another reason you might have an audit in 2015-16 is that you're considering upgrading to Drupal 8 and nobody can give you a good estimate of how much it's actually going to cost you to upgrade because nobody knows what your site does or even what problems it has. You might need an audit just to help you evaluate that.
Here Comes Judge Jody
At work, they call me Judge Jody. Being judgmental is one of those personality traits that’s both positive and negative. But when it comes to doing certain types of tasks, being judgmental is very useful. You might have some people on your team that are very open and accepting who say, "Oh, that's an interesting idea" to just about everything. They don't disagree strongly with much of anything. These folks are not necessarily the best ones to do an audit because they'll go through and all they can come up with is, "Oh, that's interesting." Someone who really has strong opinions can go faster and decide what looks problematic.
One Judge...Or Many?
You could have just one of your top people doing an audit, but you can also split it up into multiple domain experts. I also like to have an assistant when I'm doing the auditing, someone more junior who can help me write up the document, do the document formatting and learn while we're going along. As you're working on an audit you're not just learning how to do a site audit, you're also learning a lot about Drupal and the different issues people can get into making sites. I've learned more from looking at all of the awful sites that we inherit and rescue than I would have just building sites on my own because you see the consequences of all the different bad common practices that people make, where it leads, and how much work it is to clean it up. It makes me feel more strongly when I say, 'we never do this this way and this is why. We've seen what happens.’
It's also good if someone on the auditing team will potentially continue working on this site if this becomes an ongoing project. No matter how much people write in their reports, they're also putting a lot in their heads getting to know this project. That's really valuable and you want them to continue working on the site. It actually takes a long time to really get to know a project if it's a pretty complicated site, or just a particularly troubled one.
Manual or Automated?
There are parts of an audit where you should use automated tools. But it’s also important to do a lot manually and just look everywhere. I'll look from the top left pixel all the way across to the bottom right. Then I'll look at the server, the code and every page I can. I'll look at the HTML, the CSS, the navigation, and the content itself. One of the amazing things I take away at the end of some site audits is that after a week of looking at some sites I still have very little idea of what the organization does, or perhaps how to purchase a product from the company. Noticing that the site does not serve its primary mission is something automated tools will not do for you.
Document Everything
I start an outline in a Google Doc, and I follow my curiosity around the site. Productive procrastination is my main mode. When I don't feel like looking at the permissions, I go look at the design, and keep jumping around until the outline starts to fill itself out.
The first step is to get access. If it is a problem to access the server, the code base, or get a copy of the database, that in itself can be a finding of the audit. If the people you're working with don't know how to get you a copy of the database or access to the server, or they don't have SSH keys, that is part of the environment that the site is living in. It could itself be a finding. These sites don’t exist in a vacuum.
If the client refuses to give you access because they have some security reasons and nothing you can sign is going to do anything about it, you'll be really limited so you'll have a smaller scope to your audit.
Ideally, work locally and get a local copy of the site set up. That way you can click around everywhere, run all the automated reports you want, and not have to worry about messing anything up. As an auditor, you change nothing. Click everywhere, but never hit save.
Typically in an audit the more you find, the better. You're not going to lose points for looking at things that people didn't think you were supposed to be looking at. Take notes the entire time you're looking so you can eventually write those up into a proper document.
Talk it Over
It’s critical to set up a series of meetings as part of the audit. First, have a kick-off meeting to get basic background information: a little about the organization, how this site came to be, what it's supposed to be doing, and who's involved. Confirm the boundaries of the audit- for example should you be auditing everything at one subdomain, or more. Also make sure you have access to everything you need. There’s no need to get into too much detail at that kick-off meeting other than a basic situational awareness.
After a day or two of digging into the site, I like to have another meeting because then I have some questions and I'm very focused on the project at that point. Then I like to really dig in and ask questions about their specific concerns and odd things I’ve started to uncover.
You want to make sure that you're auditing and paying special attention to things that that the client is focused on and concerned about. It's also important to have these meetings to get a sense of the client’s technical vocabulary and background and whom you're actually addressing in this audit. It's easy to make an audit that makes you look really smart, and they will not use it at all because they don't understand what you're talking about and you’re not making your points clearly enough. Then we just have this huge, intimidating pile of paper. It’s about clear communication and not being pedantic.
Keep reading Part 2 of this series: Top Concerns of A Drupal Site Audit.