Central Perk: What You Need to Know Before Conducting a Technical Website Audit

joi, 27 iunie 2013

What You Need to Know Before Conducting a Technical Website Audit

Posted: 26 Jun 2013 01:57 AM PDT

You have just spent the last week knee-deep in data and technical issues whilst crawling through a website. You have identified a large number of technical issues, and a major blocker that will drastically help improve search engine rankings. You have put together the document, talked the client through it, who thanked you for putting it together and said that it looks great, and can’t wait to see the results of the changes.

A couple of days later, you get the call. Oh don’t you hate it when you get THE call! We can do the implementations no problem, but! Oh no, not the dreaded but. It’s going to take some time, the IT team have said they need to spec out the requirements, work out how to do half of it, and it’s probably going to take six months to implement the basic recommendations. Head, smack!, desk!

How many times have you heard that story? But whose fault is it? Is it the IT team, who didn’t inform you of what is required for each change, or is it yours because you didn’t ask about the process to get website changes made, no matter how simple they may be?

Below I have provided five key questions to ask before you start your technical audit.

Who are the key stakeholders?

This for me is an essential first question. Who is responsible for the website? When I say who is responsible, I mean who is going to make all the technical changes that have been requested, who is going to be uploading content, title tags and meta descriptions that are provided if you are not doing them?

From experience there could be multiple stakeholders within the business who deal with different aspects of the website that you are working on, as well as possible 3rd party agencies. You need to know everyone, from the project manger to the person implementing your title tags and making the technical changes to the infrastructure. I’d recommend using this spreadsheet to collect a complete list of all people who would be involved.

Timescales

Understanding how long changes take and when they have been requested is great knowledge to possess. There are some key questions that I feel that you need to ask:

Does the web development team work in sprints?
How long does it take to implement each task?
Does the website go through any code freezes during any time of the year? Peak seasons tend to have code freezes.
How long would it take to add/edit/delete content if required?

These are just a few questions that you should be asking, and will help manage your expectations of how long each of your recommendations would take to implement.

Involvement

By now I would hope that you have an understanding of who the key stakeholders are. Now you need to understand what is involved in making those changes happen. You should look at this from both agency and client side. Here are some initial questions that you should be asking:

What is involved in making each change?
Business case
Conference calls
Face-to-face meetings
Site visits
3rd party agency timetables
Is any documentation required?
Instruction guides
Examples

This research phase is about understanding what you need to provide to the client to make the process as smooth as possible. Once you have made the recommendations, you don’t want to go back and forth editing documentation to ensure it is in the right format to be progressed and implemented.

Internal Processes

It is easy to assume that when you make recommendations, it simply goes straight to the development team and they implement it. On most occasions this is true, but there are times (mainly in large businesses) when it needs to go through an internal sign-off process.

The internal sign-off process could include a number of people, all of whom have to sign off different aspects. Does it affect marketing? Does it affect operations? Does it affect user journey? Get an early understanding of who is involved in the internal process and get to know them. These are the people that are going to get your recommendations signed off, and signed off quickly. Make sure that you note them down on the Key Stakeholders spreadsheet, and ensure that you spend time building those relationships.

Once you clearly know (create a flow chart) what the internal process is, you can cross-reference them with estimated timescales, providing a much better idea of time required.

Technology:

Each website we work on is generally run on different technology. This maybe the same for you, unless your agency solely works with the same CMS platform, but even then you may have additional bespoke plugins to improve the website.

With rich media types evolving, and the content that you are creating becoming more and more advanced, it is important to understand if any of your future recommendations will be compatible. Having the knowledge of what technology is behind the platform, and what can be added, is a great place to start. Here are some of the questions that I would start with:

What type of server is running the website?
What language is the website coded in?
What CMS is being used?
Can the website handle HTML5?
Is there any tag management in place?

You are more than likely going to come across a range of CMSs whilst working in an agency. To ensure that you are efficient, you should create a matrix to ensure that you don’t go over old ground. Here is a basic example of a CMS matrix that I have already created – feel free to add to it. When you come across a new CMS that you haven’t used before, I would suggest adding them to your matrix.

Limitations

You don’t want to be wasting your time, or the client’s time, trying to implement fixes that just can’t be fixed. Identifying the limitations of the platform should come at the same time as you are understanding what technology is behind the website. With most of the more common platforms, there are either add-in modules or enough good developers that allow you to fix most issues. However, there are also companies that are using old platforms that are not built to be as SEO friendly as most platforms are now.

Speak to those involved with developing and enhancing the platform to see what is possible and what isn’t. This may sound like a standard item, but I have come across platforms that have either been unable to implement the basics (including title tags) or everything that you want to change comes at a cost. Knowing this allows you and the client to determine the best course of action, what resource is required, and more importantly, what the cost is.

Some questions that I generally ask are:

Can I edit the basics? (Titles, Metas, H1)
How frequently can changes be made?
Is there a reason that you don’t have a sitemap? Or is out of date by two years?
How easy is it to make technical changes?
How many templates is the site running on, if any, and can they be altered?

Above are five areas that I feel you need investigate before starting an audit for any website, and these should form part of any kick-off meeting that you have with your clients.

Do you ever come across any of these issues? What impact have they had on your project and the results? I’d be interested to hear your thoughts below in the comments or at on Twitter @danielbianchini.