Technical SEO: why an audit is different from a list of crawl and indexing errors
A technical SEO audit isn't a tool export of 4xx, 5xx and missing metas. It's understanding the site, prioritizing by business impact and talking to the people who build it. In 2023, in Berlin, Google showed it on a slide: tools are one step of four. The rest is judgment, and it's what almost nobody delivers.
A technical SEO audit is not a tool export with the 4xx, the 5xx and the missing metas dumped onto a sheet. It's what you do with that. And most of what I received over the years did nothing with it.
Technical SEO: what Google showed on a slide in Berlin
In September 2023 I was at SMX Advanced Europe, in Berlin, and I photographed this slide by Martin Splitt, from Google. It was called "Your path" and it sums up a technical audit in four steps: Understand, Examine, Evaluate, Explain.
First you understand the site: stack, setup, resources, dependencies. Then you use the tools to crawl and spot indicators. Next you use your brain: focus on what's relevant, talk to stakeholders, check whether the problem is measurable, prioritize. Finally you explain it to decision makers, with metrics and expectations.
Notice where the tools sit. In step two. One of four, wedged between "understand the site" and "use your brain". On stage, Google drew what I saw ignored every single day: the tool is not the audit, it's the middle third of a single step.
What most technical SEO audits handed me
For years I received audits on a monthly cadence, and almost all were the same thing: an export with 4xx and 5xx, missing metas, and the serious mixed in with the trivial as if they weighed the same. I worked directly with teams at an advertiser with hundreds of sites across dozens of countries, and that added nothing.
In digital since 1998, in SEO and SEA since 2007, and I've rarely seen so much useless reporting in one place. At headquarters, the global problems had long been identified. The report brought no news. It brought wasted time and distraction from the deployment cycle. The external agencies ran the same dump and, on top, attached an Excel or a PPS with their own "prioritization". Noise, with a coat of varnish on top.
The dump that mails your own problems back to you
The most absurd case kept repeating: senders mailing problems that were theirs to the central team. Broken links they had broken. Redirects they had misconfigured. Search Console set up wrong by them. They handed headquarters a portrait of their own mistakes without realizing it.
And the punchline came weeks later: a request for the central team to "fix" what in fact belonged to whoever reported it. Headless behaviour, running in circles. An audit that doesn't grasp who owns what is not an audit. It's a photocopy with anxiety.
At scale, a problem isn't one site's, it's hundreds'
When you manage hundreds of sites, the right question changes. A wrong status code in a template isn't one page's problem: it's the problem of every page that uses that template, in every market. It calls for a global, central answer, not a local ticket for each place the symptom shows up.
That's why a well-documented problem, with an estimated revenue impact, is worth more than a thousand lines of export. One tells me where I'm losing money and why. The other tells me there are 1,400 pages with a warning that, for the most part, is harmless. To be clear: I love Screaming Frog and recommend it to everyone. The tool isn't the problem. The problem is handing over what it spits out as if it were finished work.
Beyond crawl and indexing: the whole stack
The step almost nobody integrates is the first on the slide: understand the site. And a site today is a technology stack, not an FTP with HTML. A serious audit follows the path of the request: from the CDN entry point, through routing and load balancing, through cloud services, through front-end rendering, through the CMS, through the DOM, through static assets.
And through the way the layout is built, which decides what the engine even gets to see. A PWA with client-side routing serves an almost empty shell and fills it with JavaScript the AI crawler won't run. A site built from components can render on the server or in the browser, and that choice changes everything: the same site, to Googlebot, can be rich or can be a blank page.
From this comes the rule I use and that puts me on the hook: if what I propose isn't possible on the technology the client has, and there's no budget to change it, the recommendation is worth nothing. The SEO work fails. And that's on me, the specialist, not on the developer who told me upfront it couldn't be done.
The skill tools don't have: talking to the people who build the site
An audit nobody implements is worth nothing. And whoever implements it isn't the SEO: it's the developers, the software architects, CloudOps, UX, product. The skill that decides an audit's fate isn't in any tool. It's knowing how to talk to each of them in the right language, and it's half the job.
I worked side by side with teams of developers, software architects, CloudOps and UX to improve the technical SEO of international sites. I learned there what no crawl taught me: a badly communicated issue is an issue that doesn't get fixed. It sits in the backlog, quarter after quarter, proving right whoever says SEO "brings nothing".
Speak the language of whoever writes the code. Martin Splitt built Google's JavaScript SEO series, in his words, to give SEOs "the vocabulary and the backing to actually talk to developers confidently". And he leaves a warning that saved me mistakes: an SEO who dismisses a technique just because they don't understand the JavaScript loses credibility in front of whoever wrote it. Start from common ground, and "good developers and SEOs want websites to be fast".
Turn the issue into a testable ticket. Not "improve speed". The file, the element, the acceptance criterion. Describe the outcome, not the implementation: tell the chef what you want to eat, not how to cook it. And validate feasibility with a developer before you submit, not at the retro.
Prioritize with the business, not with the tool. Aleyda Solís has a name for this: SP2, for Strategic, Prioritized, Solutions-focused, Proactive. It prioritizes by impact and effort in three passes, from the ideal (impact only) to the validated, once you've reviewed with the client what's feasible on the technology they have. Reporting ranking gains instead of revenue impact is the shortest path to losing the room.
Get in early, not at the end. SEO belongs in the product cycle, not in QA after everything is decided. If the choice of framework, routing or URL structure was already locked when the SEO saw it, you arrived late. Splitt makes the point: product managers, writers, UX and developers shape rankings long before the content ships.
Put a name on every cross-cutting decision. When everyone owns the site, nobody answers for it. Canonicals, hreflang, URL structure: every decision that crosses teams needs a named owner, not a committee. It was the absence of this that filled my inbox with problems that belonged to no one.
A tool finds the problem. Only a person fixes it.
The technical SEO checklist is a starting point, not a strategy
Checklists are useful, and I have one. My technical SEO checklist says what to check and in what order of impact. But a checklist is the floor, not the building: it keeps you from missing the obvious, it doesn't decide the strategy. It adapts to each site. An international site needs to audit hreflang; a single-language site doesn't.
It's not only me saying it. In November 2025, in a Search Lightning Talk, Splitt himself asked you to "don't follow your tools blindly" and warned that it takes "experience and expertise to adapt these guidelines and checklists to the site you audit". Google is saying what I saw in Berlin on his slide: the checklist and the tool are the start of the conversation, not the end.
What to demand from a technical SEO audit
Next time you receive a technical SEO audit, measure it by this: each problem comes with the context of your site, with an estimate of business impact, with confirmation that it's feasible on your technology, and prioritized by effort and return. If it comes without that, you received an export, not an audit.
And what you lose isn't the price of the report. It's the quarter your development team spends closing harmless warnings while the problem draining your revenue stays there, documented nowhere. How many of the reports your company pays for would pass this test?
See the method in Google's own words
Martin Splitt details the same logic in this Google Search Lightning Talk, from November 2025. Just over ten minutes that confirm the Berlin slide.
Sources
- Martin Splitt - How to perform a technical SEO audit (Google Search Central, 2025)
- SMX Advanced Europe
- Aleyda Solís - How to Develop Actionable and Impactful SEO Audits
- SEOs and developers: why they are better together (Search Engine Land)
- How to write engineering tickets for SEO work (The Gray Company)
Frequently asked questions
Have SEO tools stopped being useful?
No, and I use them every day. Screaming Frog, Search Console and a good crawler are indispensable for gathering data. What they don't work as is a finished product: an export of issues is not an audit. The tool finds; prioritization, context and communication with whoever implements are what make the work worth anything. Technical SEO audit →
What is a testable SEO ticket?
It's a request to the development team that describes the expected outcome, the file or element to change, and an acceptance criterion anyone can verify. Not improve speed; it's what, where, and how you confirm it's done. Without that, the fix is left to interpretation and rarely leaves the backlog. See how I work →
Is a technical SEO checklist enough?
No. The checklist is the starting point that keeps you from missing the obvious, but it adapts to each site and doesn't replace judgment. Google itself warns that it takes experience to adapt checklists to the site you audit. Use it as a base, not as a strategy. See the checklist →