A technical SEO audit can report 97% health and still miss the one defect that should stop a release.
An accidental noindex on a key template, an empty application shell, a canonical pointing at a redirect, or a production firewall blocking required resources does not become less serious because 43 other checks are green.
That is the problem with audit scores: they compress different risks, evidence levels, and unknowns into one reassuring number.
I would rather have an audit that answers six harder questions: What exactly did we test? What evidence did we observe? What remains unknown? Which failure blocks the release? Who owns the correction and the decision? When will we replay the check?
This article presents the decision model behind an open technical SEO protocol we use at Edikka. It contains 44 replayable checks across 13 domains, but the number is not the point. The point is to make every conclusion falsifiable and every release decision explicit.
Every applicable check needs two separate classifications: Status: Not tested, Compliant, Non-compliant, or Not applicable. Severity: Blocking, Major, Minor, or Information.
This is an Edikka governance rule, not an industry standard. A team may choose stricter thresholds. What matters is that the rule is written before the result is known.
Technical audits often merge facts observed from outside a site with private states that only the site owner or search engine can reveal.
| Evidence level | Examples | What it can establish | What it cannot establish | |---|---|---|---| | Public | HTTP response, robots.txt, source HTML, rendered DOM, sitemap, JSON-LD | What a documented client observed at a documented time | What Google crawled, selected, or indexed | | Search Console | URL Inspection, Google-selected canonical, Pages and Core Web Vitals reports | The state reported for the property and inspected sample | The single cause of a ranking change | | Server logs | Verified crawler requests, response codes, frequency, bytes | An interaction received by the infrastructure | How the fetched content was subsequently used | | Configuration | CDN, WAF, CMS, deployment and routing rules | The configured intent, once tested | That every edge, cache key, and route behaves identically |
A public audit can establish that a page declares a coherent canonical. It cannot honestly claim that Google selected that canonical without Search Console evidence.
That boundary improves the audit. It turns “Google has indexed the right page” into two testable statements: Public: the page, sitemap, redirects, and internal links converge on the intended URL. Private: URL Inspection reports the intended Google-selected canonical.
| Stage | Diagnostic question | Useful evidence | |---|---|---| | Discovery | Does a public path lead to the URL? | HTML links, sitemap, referring URLs in logs | | Crawling | May the crawler request it? | robots.txt, HTTP response, verified logs | | Rendering | Does critical content exist after execution? | Source HTML, rendered DOM, URL Inspection | | Indexing | Which URL and content did the engine retain? | URL Inspection and indexing reports | | Serving | Is the page selected for this query and context? | Search performance and observed results |
A 200 response proves that the server returned a successful representation. It does not prove discovery, indexation, or selection for a query.
Do not rely on a HEAD request alone. Applications, CDNs, and firewalls can handle HEAD and GET differently.
Replay more than the happy path: the canonical URL; an HTTP or host variant; an old redirected URL; a removed resource; a URL that never existed.
The expected result is not “everything returns 200.” The expected result is that each case returns the status and destination intended for that resource.
Many technical SEO failures begin with the right intent and the wrong mechanism.
| Intent | Primary mechanism | Evidence to retain | Dangerous shortcut | |---|---|---|---| | Reduce crawling | robots.txt for compliant crawlers | Parsed rule plus logs | Treating it as access control | | Remove a page from an index | Accessible noindex directive | Source/header plus URL Inspection after recrawl | Blocking the page before the crawler can read noindex | | Consolidate duplicates | Redirect or rel="canonical", depending on the case | Converging signals plus selected canonical | Canonicalising genuinely different pages | | Protect private data | Server-side authentication and authorisation | Anonymous request denied with no sensitive body | Publishing the data and hiding it from robots |