The surprisingly untechnical challenges of a technical SEO audit
We’ve been writing technical SEO audits for clients for many years, and though the industry changes extremely quickly, one aspect of technical SEO has remained the same for many years: the untechnical side of technical SEO. Improving a site’s technical SEO is often more about understanding people, processes and organisations, than it is about understanding the complexities of hreflangs or canonical tags.
Here are some tips for delivering a technical SEO that is not only correct, but also interesting, useful, and likely to improve the technical SEO state of a website.
Learning the past, present, and future of a site
Before thinking about the report itself, you have to find out what has happened on the site in the past. Ask the following questions before you start writing anything and it could save you heaps of time down the road.
Firstly, find out how old the site is. An older site may have a few old dusty skeletons in the closet, and a newer site will have less authority. Use Searchmetrics or another similar tool to see how the site has performed historically and check traffic over the past few years to see if anything jumps out at you. Ask the webmaster about anything that looks strange. Knowing about any SEO penalties or on-site mistakes is always useful to know when making other recommendations on the site.
Early on in your fact-finding mission should be the question of whether you can access Google Search Console properties, Google Tag Manager accounts/containers, and Google Analytics accounts. If you are being paid to perform a report, then it is likely that you will have access to these tools; but if not, it is worth making the case for getting access, or stating that your report will suffer as a result of not having them.
It can often be useful to find out who has made previous versions of the site. Was it an in-house team? Was it an agency? Was it a web designer who lives abroad? Was it the CEO’s nephew? This information will give you clues of the kinds of things to look for before starting the analysis.
Find out who makes dev changes on the current site. It is sometimes different to the developer who developed the site originally.
As well as considering the history of development on the site, it’s important to check if any technical (or non-technical) SEO analysis been done on the current site in the past. If it has, don’t be afraid to ask for copies of these previous audits.
Understanding the recommendations of previous SEOs, even if you don’t agree with the audits, can be helpful for understanding why certain aspects of a site’s architecture are unusual or confusing.
You also need to look ahead to the future and find out whether any changes are planned on the existing site – or if a new site redesign is planned. If the current site will be binned in a year, then the recommendations you make must take this into account.
Even if the site is going to be around for at least a few years, it is likely that development work (new features & fixes) as well as general maintenance will occur during that time. Ask what projects are planned, so that you can a) make recommendations for these projects, and b) your recommendations don’t clash with their projects. Also ask if there is any work taking place on the site while you are doing the audit – it can be confusing to see the site change after you have written a section about one issue on the site that no longer exists!
If there are issues on a website that the client is already aware of that haven’t been fixed, make sure to note these down and comment on them specifically. Don’t be afraid of looking stupid, asking this question doesn’t mean you are asking the client for all of the answers – it just makes the report even more comprehensive because you could be able to comment on an issue that was troubling them, but in practice is not a problem.
About the technical setup
Making the most perfect recommendations in the world can mean little if your suggestions are impossible due to the technical limitations of the site.
Find out what application the current site runs. If the site runs on a common application like WordPress, you can recommend specific plugins to fix certain issues. If the site is bespoke, you know that changes will probably be harder to make.
Understanding who hosts the website can give you a deeper understanding of how easily changes can be made. If the site is hosted with an external agency, it is likely that they will be unable to relinquish direct access to the server for you to make changes yourself. Similarly, find out what OS the server runs on, and which server software. (If a site runs IIS, there is little point in mentioning .htaccess changes.)
The report itself
Knowing how a report will be used can make it infinitely more useful to the people who will end up reading.
Find out who will actually read the report. What is their technical ability? There’s no point in wittering on about server caching if the report is for a client who is not from a technical background.
What is the client hoping for from the audit? Do they just want a ‘state of play’ report, or do they want actions? Usually, a client wants to know how to improve their site – but occasionally, a report is needed just for a financial or strategic evaluation.
If the client wants a list of actions to take because of this report, include them in a neat table at the end of the report. List them in descending order of priority. This makes it easier for the client to see exactly what is needed, and makes it easier for a developer to mark the items as complete.
If the client wants to improve business performance with this audit, what are their expectations? Make sure you manage client expectations early on. Technical SEO is rarely a golden bullet on its own; make this clear from the start. Tell your client that even if they implement every suggestion in your report to the letter, they won’t suddenly find themselves dominating the SERPs. Make them aware that technical SEO is just one aspect of SEO, and other things like content optimisation, historical authority and link building are other important aspects of performance.
Getting changes made
If you will be tasked with assisting the webmaster or developers with implementing changes, it’s important to know what the current process that site changes must go through to be implemented.
Find out who you will be communicating with, and who ultimately has to sign off the changes. Before writing the report, it is a good time to be aware of what costs are involved with making major and minor changes. Is the developer paid on a monthly retainer for a set number of hours? Or are there one-off costs for the work that you suggest?
It’s a good idea to find out if when making large-scale recommendations it is realistic for them to be implemented. Alternatively, is it a better idea to stick to smaller, easier changes?
Getting the webmaster on side
If you are in direct communication with the developers or webmasters who will be making the changes that you suggest, you will be fighting an uphill battle if you start off on the wrong foot by offending a developer or being patronising.
Developers have extremely difficult jobs. They had enough on their plate – even before you showed up with a huge list full of extra work for them to do! The last thing they want is a ‘technical SEO expert’ telling them how to do their job in a condescending way. The lead developer or project manager you communicate with has complete authority over the site. Make them know you are aware of this early on, and make it clear that you are only there to help make the site perform even better than it currently does. This should allow them to lower their guard and allow you to work more closely and to greater effect.
Developers have spent half of their careers knee-deep in code, SSH windows, and technical manuals. Unless you have a technical background yourself, the developer probably understands systems and web applications better than you – and certainly their own application! Understand this fact and adapt the way you communicate so that you acknowledge the fact that the person you are talking to knows more than you. Apart from making the developer like you more, it can serve to prevent you from looking silly. Avoid making overly prescriptive actions to remedy a problem on a website. Instead of saying “You need to update your .htaccess file”, ask “Is it possible to prevent multiple URLs resolving?”
A final tip when talking to developers is to give the reason that the suggested change is important. We always communicate in this way with non-technical clients, but it should also be the case when talking to more technically minded people. “Please add canonical tags to every page on the site” is clear, but even more convincing to a developer is, “Canonical tags are important for preventing pages from being indexed multiple times. They should be added to every page on the site.”
