A Technical SEO Audit Should End in a Decision, Not a Score Edikka has introduced an open technical SEO protocol with 44 replayable checks across 13 domains, designed to make audit conclusions falsifiable and release decisions explicit. The protocol rejects simple health scores in favor of six harder questions, separating evidence levels and applying a governance rule that treats 'Not tested' as distinct from 'Compliant'. 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: 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. It does not predict rankings, traffic, rich results, or AI citations. Every applicable check needs two separate classifications: Then apply a rule that people can challenge: IF an applicable Blocking check is Non-compliant OR an applicable Blocking check is Not tested THEN NO-GO ELSE IF a Major non-compliance remains THEN ARBITRATION REQUIRED ELSE GO WITH RESERVATIONS 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. The uncomfortable part is intentional: Not tested is not the same as Compliant. Technical audits often merge facts observed from outside a site with private states that only the site owner or search engine can reveal. Keep them separate. | 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: “SEO-friendly” is too vague to debug. A URL passes through distinct stages: | 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. A sitemap declares candidate URLs. It is not an indexation certificate. Do not rely on a HEAD request alone. Applications, CDNs, and firewalls can handle HEAD and GET differently. Record the final status, complete redirect count, effective URL, and duration: TARGET URL="https://example.com/important-page" curl --location --silent --show-error --output /dev/null \ --write-out 'status=%{http code}\nredirects=%{num redirects}\nfinal=%{url effective}\ntime=%{time total}s\n' \ "$TARGET URL" Replay more than the happy path: 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 | Google's robots directives documentation https://developers.google.com/search/docs/crawling-indexing/robots-meta-tag explicitly notes that crawlers must be allowed to access a page to read its noindex rule. The Robots Exclusion Protocol https://www.rfc-editor.org/rfc/rfc9309 also defines crawling rules, not a security boundary. Avoid arguments such as “React is bad for SEO” or “SSR solves SEO.” Framework labels are not evidence. For every priority template, compare at least: This small Playwright probe records a few invariants from the rendered page: js import { chromium } from "playwright"; const url = process.argv 2 ; if url throw new Error "Usage: node inspect-page.mjs