You may have heard the term ‘technical audit’ mentioned as part of an SEO pitch or you may have been asked to perform one as a budding SEO trainee taking their first step into the wonderful world of audits.
We’ve previously written an article on SEO audits but in this article, we’ll go through more specifically what a technical audit consists of, how that feeds into overall technical SEO, some of the tools that we use and maybe even a few little tips if you’re lucky. If you’re not an SEO, you can definitely pick up some tips and help gain an understanding but it’s definitely a task that’s better left to a professional SEO.
So what is a technical audit?
A technical audit is often done either as a standalone process or part of an overall SEO audit of a website. Like many things in SEO, what is reviewed in these audits varies from SEO to SEO as they may have particular expertise or interests in certain areas compared to others. Regardless of who is performing this, a typical audit breaks down various aspects of the website from crawlability and indexability, site architecture and data tracking to on-page aspects. The goal of this audit is to identify how do machines perceive your site, is the site healthy and stable from a coding aspect and does it offer a positive user experience for users.
What do I need to perform a technical audit?
Performing a technical audit is a fairly intermediate level task and therefore requires a good toolset to perform. There are a variety of tools out there both paid and free that can help you perform this but here’s a few we just can’t live without.
Crawlers
In order to audit a site, you need a crawling tool such as Sitebulb and Screaming frog. This will become a bit of a reoccurring theme throughout this section but the answer to “Which do I pick” is down to personal preference. Whilst Screaming frog is great for diving deeper into the granular data, Sitebulb is my personal preference because I believe its UI is much friendlier to view and digest with far more automation options. For example, using Sitebulb we have created automatic monthly crawls that will crawl our clients sites and update the findings to a shared area that the whole team can review at any time. Without a crawler, you simply won’t be able to gather the data you need to perform an in-depth audit across the site.
Google Search Console & Google Analytics 4
Before you kick off a crawl with your crawling tool, it’s always preferred that you have access to Google Search Console and Google Analytics 4. Not only can you connect these to your crawler, therefore providing more insight, but you can also manually review these yourself. You can find out if the website has Core Web Vital issues, and if so, for how long and is it a sudden spike that can be attributed to a developer change? You can also see if Google is struggling to connect to the site (therefore signaling an unstable server or server outage issue) by following steps:
- Open up Google search console and select the correct property
- Click on ‘Settings’ in the left hand side menu
- Click on ‘open report’ in the Crawl stats area
- Click on the correct host (You may have only one option in this area)
- Click on the ‘host status’ bar and open up ‘server connectivity’
If you find that there are high or consistent levels of failed requests, this could be an indicator of a struggling server that needs to be raised with the developers.
Pagespeed Insights
Pagespeed Insights an amazing free tool that will quickly become your best friend. It allows you to quickly review the Core Web Vitals of an individual page alongside a Lighthouse test that highlights potential performance issues and opportunities to improve the user experience. One thing that’s important to remember is that the aim isn’t necessarily to chase a perfect score of 100 as a website can still perform perfectly well without reaching that magical green number. Instead, use the tool to identify genuine issues such as slow-loading images, content moving around whilst the page loads or elements taking too long to respond when a user interacts with them.
Javascript extension
Having an extension that allows you to disable javascript is a must have as it gives you a very simple way of understanding how reliant a website is on JavaScript and what happens when it isn’t available. Disable Javascript, refresh the page and have a look around then ask yourself “Does the main content disappear entirely” or “Does the navigation stop working” the goal here is to see if there is anything not working or not visible that you absolutely want a crawler to see.
Redirect Path
This is another extension that has become a personal favourite. Redirect path allows you to see the full chain of the page should you land on a redirect which helps identify any urls behaving in a way that they shouldn’t be alongside discovering potential chains and redirect loops.
Chrome DevTools
Chrome DevTools can look a little intimidating the first time you open it, particularly if you aren’t a developer, but you really don’t need to understand every section to get plenty of value from it during an audit. Right-clicking anywhere on a webpage and selecting inspect gives you access to the HTML behind the page alongside useful areas such as the Network and Console tabs. The Network tab is particularly handy because you can refresh the page and see all of the images, scripts, fonts and other files being requested by the browser alongside how long each one is taking to load and whether any have failed entirely. DevTools will take some time to get to grips with but your confidence will grow as you use it.
Schema Validator and Rich Results test
In order to see if the website is using structured data otherwise known as SCHEMA, we use both Schema.org’s Schema markup validator alongside Google’s Rich Results Test as they test for slightly different things. The Schema Markup Validator essentially reviews if structured data is actually present and if there’s any missing or incorrect details. Rich Results test is more focused on whether the structured data can be used by Google for featured snippets such as product information. Though this only tests one page at a time, it’s good to test a number of pages to understand if structured data is being used at all, and if there’s any trends such as no product pricing on all product templates.
So what is actually looked at in a technical audit?
With your shiny new toolset and your completed crawl, you’re likely going to be faced with a long list of scary looking errors and warnings which is where the auditing part comes in. It’s now the SEO’s job to manually review all of these to separate the genuine issues and opportunities from the false flags and low impact items. A crawling tool may tell you something is deeply wrong or isn’t present, but just like us mere humans, it tends to make mistakes. Here’s just a few things we recommend you look at.
Crawlability and indexability
One of the first things we want to establish is whether search engines can actually find and access the important pages on the website and, once they find them, whether those pages are able to be indexed. This means reviewing areas such as the robots.txt file, XML sitemap, internal links, canonical tags and noindex directives alongside the indexing information available within Google Search Console. You may find that an important page has accidentally been marked as noindex, that Google is being directed towards the wrong canonical URL or that thousands of low-value URLs are being generated through filters, parameters or other website functionality. Not every URL on a website needs to be indexed and in many cases Google choosing not to index things such as feeds, account pages or certain filtered URLs is perfectly normal. What we are trying to establish is whether the pages that actually matter are easy for search engines to discover and whether Google is spending its time crawling useful pages rather than getting lost in areas of the site that offer very little SEO value.
Broken pages and redirects
Broken pages are another area you will almost certainly come across during an audit, but it’s important not to fall into the trap of assuming that every 404 error automatically needs fixing. If a page has genuinely been removed and there is no suitable replacement, returning a 404 can be completely appropriate, but problems start to appear when important pages disappear without any thought being given to what should happen to the old URL. That page may still have internal links pointing towards it, external websites linking to it or users finding it through old bookmarks and search results, so simply removing it can create a poor experience and potentially throw away value that the URL has built over time. This is where redirects become important, but again they need to be used sensibly rather than sending every deleted page back to the homepage. Where a relevant replacement exists, redirect the user there, and whilst you’re doing that make sure you aren’t creating unnecessary redirect chains where a URL passes through several different pages before eventually reaching the correct destination.
Site architecture and internal linking
Site architecture is one of those areas where technical SEO starts to overlap quite heavily with user experience because a website that is easy for a search engine to navigate will usually be easier for a person to navigate as well. Important pages shouldn’t be buried away several layers deep with very few links pointing towards them, particularly if those pages represent the services, products or areas that are most valuable to the business. As part of the audit, review how the website is structured and how easily you can move between related areas, looking at navigation menus, breadcrumbs, category structures and contextual internal links within the content itself. Internal linking is particularly useful because it helps search engines discover pages and understand how different topics relate to each other whilst also giving users a natural route towards the next piece of information they might need. If you’ve written several useful articles around a particular service but none of those articles link back to the main service page, you’ve missed a fairly simple opportunity to bring those areas of the website together.
JavaScript and content accessibility
Earlier we talked about disabling JavaScript and this is where that check starts becoming particularly useful because it allows you to understand whether important parts of the website are being delivered in a reliable way. Modern websites rely on JavaScript for a huge range of things and there is absolutely nothing wrong with that, but if disabling it causes the main content, internal links, navigation or essential product information to disappear completely then it’s worth investigating how those elements are being delivered. Google can render JavaScript, but rendering adds an additional step compared to information being immediately available within the HTML, so we generally want the most important content and links to be as accessible as possible. This becomes even more important if the content relies on several different scripts or third-party services all successfully loading before it appears, because every extra dependency introduces another potential point of failure.
Site speed and Core Web Vitals
Site speed is another major part of most technical audits, although it’s important to look beyond simply reporting the score that PageSpeed Insights gives you. Core Web Vitals are designed to measure parts of the real user experience, such as how quickly the main content becomes visible, how responsive the page is when somebody tries to interact with it and whether elements unexpectedly move around whilst everything is loading. When you identify a problem, try to understand what is actually causing it rather than simply telling a developer that the website has failed Core Web Vitals, as that doesn’t give them a huge amount to work with. The issue could be an oversized hero image, too many scripts running before the main content appears, fonts causing the layout to shift or the server simply taking too long to respond. The more you can narrow down the likely cause and explain what is happening, the more useful your audit becomes to the person who eventually has to fix it.
Mobile usability
Mobile usability sounds like something that should be taken for granted nowadays, but you’d be surprised how many issues can still slip through unnoticed until somebody actually starts using the website properly on a smaller screen. Rather than simply resizing your browser and deciding that everything looks alright, spend some time navigating the site as a real user would by opening menus, clicking buttons, completing forms, using filters, viewing products and trying any other functionality that is important to the site. Sometimes an element technically works on mobile but is frustrating to actually use, such as buttons being too close together, filters covering the screen or content shifting around as the page loads. Google primarily uses the mobile version of the site for indexing, but even putting SEO aside, if a large proportion of users are visiting from mobile devices then a poor experience can have a very real impact on enquiries, purchases and overall performance.
Structured data
Structured data is another area worth reviewing during an audit because it provides search engines with clearer information about what the content on a page represents. Depending on the website, you may come across Organisation, Product, Article, Breadcrumb, LocalBusiness and a whole range of other schema types, and part of the audit is making sure that what has been implemented is accurate and actually reflects what users can see on the page. Ecommerce websites are a good example because product schema can quickly become more complicated once you introduce different variations, prices, stock levels and reviews, so it’s worth checking that the information being supplied to search engines matches the actual product. Schema isn’t about covering every page in as many different types as possible, it’s about helping machines understand the content and entities already present on the site in a clearer and more structured way.
Tracking and analytics
Tracking is one of those areas that can easily be forgotten during a technical audit because it doesn’t always feel like traditional technical SEO, but there isn’t much point improving a website if you can’t reliably measure whether those improvements are actually doing anything. Review the GA4 and Google Tag Manager setup and make sure the important actions on the website are being recorded correctly, whether that is purchases, enquiries, form submissions, downloads, phone calls or any other action that matters to the business. Look for obvious issues such as duplicate events, missing conversions or revenue figures that don’t seem to match what the business is actually seeing. If you’re going to use analytics data to help prioritise recommendations or report on the impact of your work later on, you need to have confidence that the information you’re basing those decisions on is accurate in the first place.
Don’t blindly follow your crawler
This is probably one of the most important lessons when performing a technical audit because a crawler is there to provide information, not make the final decision for you. You might finish a crawl and be presented with hundreds of warnings ranging from missing meta descriptions through to canonical issues and broken internal links, but those problems aren’t necessarily equal just because they appear in the same report. A missing meta description on an old article that receives virtually no traffic is unlikely to be as important as a canonical issue affecting every product on an ecommerce site, even though both technically need attention. When you review each issue, think about how many pages it affects, whether those pages are commercially important, whether it prevents crawling or indexing, what impact it has on users and how difficult it is likely to be to fix. A good audit doesn’t simply tell somebody everything that is wrong with their website, it helps them understand what needs fixing first and why.
Use the website yourself
One of the easiest mistakes to make when performing an audit is spending all of your time staring at crawling tools, spreadsheets and dashboards without actually using the website yourself. Spend some time browsing around like a potential customer would, use the navigation, search for things, apply filters, complete forms, view the site on mobile and click through important journeys from start to finish. Crawlers are excellent at identifying technical patterns but they don’t always tell you that applying a filter sends a user to a completely different section of the website, that an important button disappears at a certain screen size or that a form technically loads but is incredibly frustrating to complete. Some of the most useful issues you will find during an audit often come from simply spending time on the website and asking yourself whether everything behaves in the way you would expect it to.
Compare what your crawler finds with what Google finds
Another useful exercise is comparing the URLs your crawling tool discovers with what Google Search Console tells you Google has actually found because the numbers can sometimes be very different. If your crawler finds 5,000 URLs but Google has discovered 30,000, that immediately gives you something to investigate because those additional URLs have to be coming from somewhere. You may uncover historic URLs, filters, feeds, parameters, old site sections or functionality that is generating large numbers of unnecessary pages that aren’t obvious when following the normal internal linking structure. The opposite can also be useful, as you may have pages that your crawler can easily access but Google appears to be ignoring or rarely crawling, which could point towards internal linking, crawl priority or indexing issues. Looking at the same website through several different sources of data often gives you a much clearer picture than relying on a single tool.
Speak to the people who manage the website
Finally, don’t forget that technical SEO rarely happens in isolation and there are usually developers, marketing teams or internal staff who understand parts of the website far better than you do when you first arrive. If you find something unusual, speak to them before immediately deciding it is wrong because there may be a perfectly sensible reason why something has been implemented in a particular way, or they may already be aware of the issue and have a fix planned. Developers can also tell you whether a recommendation is relatively simple or whether changing it would require a significant rebuild, which can completely change how you prioritise the work. The best technical SEO work usually comes from collaboration rather than throwing a huge audit over the fence and expecting somebody else to work through it, so involve the people who actually build and manage the site and make sure your recommendations are realistic, understandable and tied back to what the website is trying to achieve.
So, is that everything?
Not even close. Technical SEO can go incredibly deep and depending on the website you may end up looking at everything from server logs and international targeting through to faceted navigation, ecommerce platforms, migrations, rendering and huge enterprise websites containing millions of URLs. The important thing when you’re getting started is not trying to learn everything at once, but understanding the fundamentals and becoming comfortable asking why something is happening rather than simply accepting what a tool tells you. Every audit you perform will introduce you to something slightly different and, more often than not, you’ll come across an issue you haven’t seen before which sends you down another technical SEO rabbit hole. That’s part of what makes technical SEO interesting, although you may not feel quite as enthusiastic about that when you’re three hours into trying to work out why Google has discovered 400,000 URLs on a website that only has 5,000 actual pages.
Leave a Reply