A Technical SEO Audit Should Find Problems, Not Issues

If you have ever paid for a technical SEO audit — SEO meaning search engine optimisation, the work of making a site findable in search — you may have received a PDF of forty or sixty pages. It had a red-amber-green dashboard on page three. It listed 1,847 issues. It said your site had a health score of 62 out of 100.

That document was almost certainly produced by running a crawling tool over your site and exporting the result. The tool did the finding. The agency did the exporting. You paid for the exporting.

A real technical audit is different in one specific way: it answers the question why is this site not getting the search traffic it should, and every finding connects to that question. Some of those findings come from a crawler. Many do not, because crawlers cannot see them.

Here is what should actually be in the report.

The questions a real audit answers

Before any tool runs, the person doing the audit should be able to state what they are trying to find out. There are roughly five questions, and they are in a deliberate order, because each one is pointless if the previous one has failed.

1. Can Google reach every page that matters? Crawling.
2. Once reached, is Google allowed and able to store the page? Indexing.
3. Does the stored version contain the content a human sees? Rendering.
4. Does the page make sense as an answer to a specific query? Relevance and structure.
5. Is the experience good enough that a click does not immediately bounce? Speed, layout, mobile.

A tool export is arranged by severity colour. A real audit is arranged by that order. If a report opens with meta description lengths and mentions your indexing problem on page thirty-one, the person writing it did not think about your site. Meta descriptions are not a ranking factor Google has ever documented as one; they affect click-through from the results page, which matters, but not before the page is in the index at all.

Crawling and indexing: the part that actually costs you traffic

This is where the expensive problems hide, and where the tool exports are weakest, because the definitive source is not a third-party crawler — it is Google Search Console, the free tool Google gives every site owner. Any audit that does not reference your Search Console data has not looked at what Google actually did with your site. It has looked at a simulation.

Specific things worth finding:

• Pages excluded from the index and the stated reason. Search Console groups these — "Crawled, currently not indexed", "Discovered, currently not indexed", "Duplicate without user-selected canonical", "Alternate page with proper canonical tag". These mean genuinely different things. "Discovered, currently not indexed" often means Google found the URL and decided not to spend the effort. "Crawled, currently not indexed" means it looked and was unimpressed. One is a discovery and priority problem, the other is a content quality problem. An audit that lumps them together as "indexing issues: 340" has told you nothing.
• A stray noindex tag. This is a one-line instruction telling search engines not to store a page. It gets left on after a staging site goes live. It gets applied site-wide by a plugin setting. It is the single most damaging thing that can happen to a site and it is invisible to anyone looking at the site in a browser.
• A robots.txt file blocking something important. That file sits at yoursite.com/robots.txt and tells crawlers where not to go. Blocking your CSS and JavaScript folders — which some older security plugins still do — means Google renders your page as an unstyled mess and judges it accordingly.
• Redirect chains and the wrong status codes. A 301 is a permanent move, a 302 is temporary. Sites migrated a year ago on 302s are still telling Google the old URL is the real one. A 404 is a missing page; a soft 404 is a page that returns a success code while displaying "nothing found", which wastes crawl effort and confuses everything.
• Canonical tags pointing somewhere wrong. A canonical says "this is the master version of this page". On a badly configured e-commerce site, every filtered product listing can canonicalise to the homepage, which quietly deletes your entire category structure from search.

One more that crawlers rarely surface properly: parameter and faceted URLs. If your site generates a unique URL for every combination of colour, size and sort order, you may have generated tens of thousands of near-identical pages. Google will crawl them. Every request spent on ?sort=price_asc&colour=blue is a request not spent on your new product page.

Rendering: what Google sees versus what you see

If your site is built on a JavaScript framework — React, Vue, Angular, or a page builder that loads content dynamically — then the HTML that arrives first may be nearly empty, with the actual content assembled in the browser afterwards. Google does render JavaScript, and Google has documented that it does, but rendering happens as a second pass and it is not guaranteed to capture everything.

The test is not complicated and takes two minutes. Use the URL Inspection tool in Search Console, request the live test, and look at the rendered HTML and the screenshot. If your main body copy, your product prices or your internal navigation links are missing from that rendered output, you have found something that no crawl summary would have told you.

Similarly: view the page source (Ctrl+U) and search for a sentence from the middle of your page. Not there? Worth investigating. This is the kind of check that separates someone who opened your site from someone who pointed a tool at it.

Structure, internal links and the shape of the site

Tools count internal links. They do not evaluate whether the structure makes sense.

The things worth a human eye:

• Click depth from the homepage. If an important service page takes five clicks to reach, it is being treated as unimportant, both by Google and by your visitors. Fixing this often means changing the navigation, not adding a link.
• Orphan pages. Pages that exist in the sitemap but have no internal links pointing at them. Common after a redesign, when old content survives but the menu that pointed to it does not.
• Cannibalising pages. Three pages all attempting to rank for "CRM software for small business". They split the signals and none of them wins. A crawler flags them as duplicate-ish content. A human works out which one should survive and where the other two should redirect. This is a judgement call about your business, not a tool output. Sorting the information architecture out is usually a web development job as much as an SEO one.
• Anchor text. Two hundred internal links saying "click here" or "read more" carry no information about the destination.

Speed, mobile and the things that are genuinely measurable

Google publishes the Core Web Vitals thresholds, so these are checkable rather than a matter of opinion. Largest Contentful Paint — the moment the biggest visible thing finishes loading — should be under 2.5 seconds to be rated good. Interaction to Next Paint, which measures how quickly the page responds when someone taps something, should be under 200 milliseconds. Cumulative Layout Shift, the amount the page jumps around while loading, should be under 0.1.

The useful distinction, and the one most reports get wrong: lab data versus field data. A Lighthouse score generated on a fast connection in an office is lab data. The Core Web Vitals report in Search Console is field data — real visitors, real phones, often a 4G connection in a place with two bars. Field data is the one that reflects your customers. If the audit only shows you a Lighthouse score out of 100, it has measured a simulation.

What a real speed section finds is causes, not scores: an uncompressed hero image that is 3.8 MB straight off someone's phone, six separate font files, four analytics scripts loading before anything visible, a slider plugin that ships 400 KB of JavaScript to render three photographs.

What I would not pay for

Being direct about this, including about things an agency could happily sell you:

• A "site health score". It is a proprietary number invented by a software vendor. It has no relationship to traffic. A site can score 94 and be invisible; it can score 41 because of trailing-slash warnings and rank fine.
• An issue count as a deliverable. "We found 1,847 issues" usually means one templated problem repeated across 1,800 pages, plus a handful of real things. The count inflates the invoice and hides the thinking.
• Keyword density analysis. Not a thing. Has not been a thing for well over a decade.
• A monthly recurring audit. Technical problems are mostly discrete events — a migration, a plugin update, a developer change. Ongoing monitoring is worth having. A fresh sixty-page audit every month is a subscription to a PDF generator.
• Schema markup applied to everything. Structured data helps Google understand specific things — a product's price, an event's date, a business's address. Bolting FAQ schema onto every page because a tool flagged "no structured data" achieves nothing and can be actively messy.
• An audit with no fix list. If the report does not say who does this, in what order, and roughly how hard is it, you have bought a diagnosis with no prescription. That is the most common failure of all.

How to test the audit before you buy it

Ask three questions before you commission the work.

"Will you need access to my Search Console?" If the answer is no, they are not looking at what Google did. Walk away. If you do not have Search Console set up, that is finding number one and it is free to fix.

"What will the deliverable look like?" The right answer describes a prioritised list of specific problems, each with what it costs you and what fixing it requires. The wrong answer describes a number of pages.

"Who fixes these things?" Some findings are a content decision, some need a developer, some need server access. An audit that hands you a list without indicating this is a list you will not act on. Whether that work sits with your own team, with us, or with an existing technical support arrangement matters less than someone saying it out loud.

One further test, once you have the report: pick the top three findings and ask what each one is costing you. If the honest answer to any of them is "nothing measurable", it should not have been in the top three.

What to do next

Do this yourself this week, before spending anything. Open Search Console and look at the Pages report. Note how many pages are indexed versus how many are not, and read the reasons given. Run one important page through URL Inspection and look at the rendered HTML. Open your robots.txt file. Those three checks take under an hour and will tell you whether you have a real technical problem or a content and authority problem — which is a completely different piece of work.

If what you find is confusing, or the numbers do not match what you expected, that is a reasonable moment to bring someone in. You can read more of how we think about search on the SEO services page, or get in touch and tell us what you saw in Search Console. That conversation is more useful than any PDF.

Questions we get asked