Search Quality Assurance (SQA-200): the 200-point site governance framework

What Search Quality Assurance (SQA-200) is

Search Quality Assurance (SQA-200) is a deterministic 200-point quality control and site governance framework for organic search. It replaces the open-ended SEO audit with a fixed matrix: six pillars, a published point budget for each, and a set of itemized checkpoints that each carry a weight and a single written pass condition.

The word deterministic carries the whole claim. Two auditors applying SQA-200 to the same website are expected to arrive at the same number, because no checkpoint asks whether something is good. Each one asks whether a named threshold is met, a named file exists, a named declaration is present, or a named activity happened within a stated interval.

The framework governs a site rather than optimizing a page. Its output is a score with a denominator, a remediation order derived from the weights, and a rubric that says when a deployment is finished. What it deliberately does not produce is a ranking forecast.

The core formula and the operating axiom

The core formula of SQA-200 is an addition with six terms: Technical Cleanliness at 40 points, plus Entity Verification at 40, plus Topical Authority at 40, plus AI-Ready GEO Extraction at 30, plus UX and CRO Alignment at 25, plus Digital PR and Off-Page Trust at 25, totaling 200 points of sustainable organic growth.

The operating axiom is shorter and does more work: a single technical or entity bottleneck creates lead leakage that compounds, and quality assurance must therefore be audited and iterated in seven-day data loops. The axiom explains why the formula is written in that order rather than any other.

Read together, the formula says the six pillars are not equally weighted and the axiom says they are not independent. A score of 160 out of 200 means something quite different depending on which 40 points are missing, which is why the framework reports a score per pillar and never only a total.

Why a scored matrix instead of a prioritized list of findings

A scored matrix differs from a conventional audit in what it produces when it finds nothing wrong. A prioritized list of findings is silent about everything it did not mention, so a short report means either a healthy site or a shallow audit, and the reader cannot tell which. A matrix has a fixed denominator, so a passing checkpoint is recorded as explicitly as a failing one.

The second difference is comparability over time. Findings lists from two different quarters cannot be subtracted from one another, because each reflects what the auditor happened to look at. Two matrix scores can, because the checkpoint set did not change between them, and the difference identifies exactly which items moved.

The cost of this design is rigidity, and it is a real cost. A matrix cannot report a problem it has no checkpoint for. SQA-200 accepts that trade because an unnamed problem in a matrix is at least a gap someone can see in the specification, while an unnamed problem in a findings list is invisible.

The six pillars and the 200-point distribution

The six pillars are audited in the order below, and the order is causal rather than alphabetical or convenient. Each pillar assumes the one before it has passed, which is why the point budgets alone do not determine where remediation starts: a failure in pillar one discounts points already earned in pillars three and four.

The distribution puts 120 of the 200 points into the first three pillars, which is the framework stating that infrastructure, identity and content architecture are where sustainable organic growth is won or lost. The remaining 80 points are distributed across extraction formatting, conversion alignment and off-page corroboration.

The anatomy of a checkpoint

Every checkpoint in SQA-200 has four parts, and the fourth is what makes the framework deterministic. The parts are an item code such as P1.34, a checkpoint name, a point weight, and a verification and execution standard written as a condition that is either met or not met.

The item code exists because it is what an auditor writes in a report. Recording that P1.34 failed is shorter and less ambiguous than restating the checkpoint, and it survives translation, so a Vietnamese and an English report on the same site refer to the same items.

The verification standard is the part that has to be written before the audit, not during it. A standard written while scoring will be written around what the site already does, which is the failure mode that turns every quality framework into a description of the status quo.

The 30-day deployment roadmap

The deployment roadmap runs the six pillars as four weekly sprints, and it follows the audit order for the reason the axiom gives: work done on an unreliable foundation cannot be measured. The roadmap is a sequence rather than a schedule, so a team that needs eleven days for the first sprint runs a longer first sprint rather than skipping items.

Sprint 1, days 1 to 7: technical cleanliness and the measurement layer

The first sprint audits the forty technical items and, critically, stands up measurement before anything is changed. Key events are configured in analytics, a Search Console baseline is recorded, and delivery and caching are deployed. Establishing the baseline first is what makes every later sprint attributable rather than coincidental.

Sprint 2, days 8 to 15: entity disambiguation and schema

The second sprint fixes identity. Organization, Service and FAQ schema are deployed, the about and contact pages are built as entity anchors, and the sameAs links are aligned with the profiles they claim. This sprint changes little that a reader will notice and most of what a machine will.

Sprint 3, days 16 to 23: the topical hub and answer-first restructuring

The third sprint restructures content into silos along the Decision Ladder Navigation rungs, rewrites H2 and H3 headings into answer-first form, and embeds comparison tables. It is the longest-running work in practice, because it touches every page rather than a configuration.

Sprint 4, days 24 to 30: conversion friction and the weekly loop

The fourth sprint cuts contact forms to four fields or fewer, places proof above the fold on the pages that convert, and starts the seven-day iteration loop. The loop is the deliverable here: the sprint ends with a cadence running, not with a list of completed tasks.

The 100-point Definition of Done rubric

The Definition of Done rubric is a second and separate score of 100 points across five evaluation domains, each worth twenty. It answers a different question from the audit matrix: not what does this website have, but is this particular deployment finished.

The five domains compress the six pillars into the things a deployment must demonstrate, and the fifth domain is the one that has no pillar of its own. Tracking and iteration is scored here because a deployment that changed the site without standing up measurement cannot be shown to have worked, however well it scores on the other four.

Why the audit matrix and the Definition of Done are two different scores

The 200-point matrix and the 100-point rubric are not two halves of a 300-point total, and keeping them apart is the most common reading error this specification has to prevent. The matrix scores a website as it stands, item by item, and can be run on a site nobody is currently working on.

The rubric scores an engagement. It is run at the end of a deployment to decide whether the work is complete, and its criteria are deliberately coarser: 100% of H2 headings answer-first, key events active, a live dashboard, a maintained log. A site can score 180 on the matrix and fail the rubric, because the rubric asks whether the loop is running.

Reported together, the pair says both things a stakeholder needs: where the site stands, and whether the team is done. Reported as a sum, they say neither.

The seven-day iteration loop

The operating axiom requires quality assurance to be iterated in seven-day data loops, and the loop is four steps: review, backlog, execute, log. It starts the day the fourth sprint ends and does not stop, because the matrix describes a state that drifts as soon as anything is published.

Review reads the dashboard for three specific gaps: pages with views and no key events, pages gaining impressions while click-through stays low, and pages holding traffic while conversions stay flat. Backlog commits three to five items with the evidence attached. Execute ships them in the order committed. Log records what changed, on which URL, on which date.

The log is the step teams drop and the one that makes the rest work. Without a dated record of what changed, the following week cannot distinguish a result from a coincidence, and the loop degrades into a weekly meeting about numbers nobody can attribute.

The canonical JSON-LD graph

The specification includes a machine-readable graph linking the Organization node to a DefinedTerm node for the framework itself, to be deployed on primary brand landing pages. It declares which framework a site is being governed by, in a form a search engine or a language model can read without inferring it from the prose.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://danhnolan.com/#organization",
      "name": "danhnolan.com",
      "url": "https://danhnolan.com/en/",
      "logo": "https://danhnolan.com/logo-google-512.png",
      "sameAs": [
        "https://orcid.org/0009-0007-7906-5091"
      ]
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://danhnolan.com/en/sqa/#sqa200",
      "name": "Search Quality Assurance (SQA-200) Framework",
      "description": "A 200-point site governance and quality control system for organic search and AI extraction.",
      "inDefinedTermSet": "https://danhnolan.com/en/sqa/"
    }
  ]
}

Anyone deploying this graph should replace the organization name, URL, logo and sameAs entries with their own, and keep the DefinedTerm node pointing at this specification, since that node is what identifies which framework the site is being governed by.

How SQA-200 relates to the other frameworks on this site

SQA-200 depends on two other published frameworks rather than competing with them, and two of its checkpoints name that dependency directly. Checkpoint P3.06 maps every URL onto a decision stage, and checkpoint P5.02 places internal links at decision points, both using the five rungs of Decision Ladder Navigation: Orientation, Comparison, Proof, Price and Action.

The relationship to the Website Growth System is one of function rather than hierarchy. The Website Growth System is an operating loop that runs growth week to week across four pillars; SQA-200 is the quality gate that says whether the site that loop is running on meets a standard. A team can run the loop on a site that scores 120, and the loop will spend most of its weeks rediscovering the missing 80 points one symptom at a time.

Stated plainly: SQA-200 answers where the site stands, Decision Ladder Navigation answers what a reader needs at each rung, and the Website Growth System answers what to do on Monday. They share vocabulary deliberately so that a finding in one is actionable in the others.

Where this specification came from

The content of SQA-200 originates in a Vietnamese article published on this site on 9 January 2026, which introduced the framework to operators under the name it still carries in Vietnamese. That article remains the explanatory text for a Vietnamese-speaking audience and is available in full.

The deposit is a separate publication rather than a translation of it. It adds what an explanatory article does not have: a version number, a license, an author identifier, an itemized matrix with weights, and a persistent identifier that other work can cite. The two are paired by language annotations and kept as distinct documents.

The deposit also records its own lineage. Zenodo lists SQA-200 as derived from the SEO Master framework, deposited under DOI 10.5281/zenodo.22857812, which is the systemic framework this quality matrix operationalizes.

When SQA-200 applies, and when it does not

SQA-200 applies to a website that already exists and has something to govern: published pages, a business identity to declare, and enough traffic that a dashboard is not empty. It was written for business sites, commerce systems and content platforms operating over quarters rather than campaigns.

It does not apply to three situations, and saying so is cheaper than a failed engagement. A site with no content yet cannot score pillar three, and running the matrix against it produces a low number that measures nothing but earliness. A campaign landing page with a two-week life has no use for governance designed to compound. A site whose problem is that nobody wants the product will pass every checkpoint and still not sell.

There is also a limit inside its own scope. SQA-200 scores what a site has and does; it does not predict a ranking, promise a position, or estimate traffic. A site at 195 of 200 in a market with better-resourced competitors is a well-governed site in a hard market, and the framework says so rather than implying otherwise.

Rights, licensing and how to cite this specification

The SQA-200 specification is published under the Creative Commons Attribution 4.0 International license. The deposit of record is DOI 10.5281/zenodo.22888333, authored by Danh Nolan, ORCID 0009-0007-7906-5091, and this page is the canonical web rendering of that deposit at version 1.0.

Under CC BY 4.0 the framework may be used, adapted and applied in commercial and client work without permission, including inside a paid audit, provided attribution is given. Attribution means naming Search Quality Assurance (SQA-200) and its author and linking either to this page or to the DOI.

• Recommended citation: Nolan, D. (2026). Search Quality Assurance (SQA-200): A 200-Point Quality Control and Site Governance Framework for Sustainable Organic Growth, Entity Verification, and AI Search Extraction. Zenodo. DOI 10.5281/zenodo.22888333.
• Version: 1.0, published 22 September 2026 on Zenodo.
• What is protected: the name, the wording and the priority date. Copyright covers expression rather than ideas, so nobody needs permission to build a six-pillar scoring matrix of their own and call it something else.

Framework specified by <a href="https://danhnolan.com/en/sqa/">Danh Nolan (Search Quality Assurance, SQA-200&trade;)</a>. DOI: <a href="https://doi.org/10.5281/zenodo.22888333" target="_blank" rel="noopener noreferrer">10.5281/zenodo.22888333</a>. ORCID: <a href="https://orcid.org/0009-0007-7906-5091" target="_blank" rel="noopener noreferrer">0009-0007-7906-5091</a>.

Frequently asked questions about SQA-200

These are the questions asked most often about the framework itself rather than about applying it: what separates it from an audit, why the abbreviation collides with two better-known ones, how a new site should read its score, and how often the matrix should be rerun.

Does SQA-200 replace a conventional SEO audit?

It replaces the format rather than the work. A conventional audit and SQA-200 examine much the same territory, but an audit returns a prioritized narrative while SQA-200 returns a score against a fixed denominator with a per-item pass condition. The second can be compared with itself three months later; the first cannot.

Why does the abbreviation SQA collide with Software Quality Assurance?

Because three-letter abbreviations are scarce and Software Quality Assurance claimed this one decades earlier, as did the Scottish Qualifications Authority. The framework is always written as SQA-200 with the numeral attached for that reason, and its canonical page carries an explicit disambiguation statement so that machines resolving the string have something to resolve it against.

Can a brand new website be scored with SQA-200?

It can be scored, but the score will mostly measure how new it is. Pillar three requires a content map that a new site has not built yet and pillar six requires corroboration that takes time to earn, so a new site typically scores well in pillars one, two and four and near zero in the other two. The useful output at that stage is the roadmap, not the number.

Is a score of 200 out of 200 the goal?

No, and treating it as one distorts the remediation order. Several checkpoints are conditional on the business model, such as the opening hours and local listing items for a company with no premises, and the framework scores those zero rather than excusing them. A realistic target is a stated threshold per pillar, with the conditional items named in the report.

How often should the 200-point audit be repeated?

Quarterly for the full matrix, weekly for the loop. The full audit is too heavy to run every week and the site drifts too fast to leave it a year, while the seven-day loop watches the handful of numbers that move between audits. Checkpoint P3.14 sets the quarterly interval for content refresh, and the matrix cadence follows it.