The two checklists say what "good" is. This page says how a project actually gets through the gate, so nobody has to guess.
The two documents
| For | When | |
|---|---|---|
| The checklist | The developer building the project | Read at the start, then again at the end of each stage |
| Production gate | The review before go-live | Once the project is feature-complete on a stable URL |
| Per page | Whoever is checking a template | Once per template, not once per project |
They are the same rules under the same ids, ordered differently: the first by the order the work happens, the second by how each item is verified. Both are generated from one source, so they cannot disagree with each other.
Say what the project has before you start. Around a fifth of the rules only apply to a project with filters, pagination, more than one language, video, a modal, or a site it is replacing. The toggles at the top of the checklist switch those off, and the count follows.
What I need to review a project
Send these together. Missing items do not stop a review, but they turn checks into unverified,
and unverified never counts as a pass.
| Config key | What to send | Why | Without it |
|---|---|---|---|
url |
A stable URL, staging or production | Almost every check runs against a live page | No review is possible |
repo |
Repository access | Bundle budgets, build output, source-level checks | Those rules come back unverified |
templates |
The list of templates | So the sample covers every template rather than every page | I sample by guesswork |
languages |
For a multilingual site: one root per translation | Per-language 404s, lang attributes, and that no language redirects to another | Per-language rules come back unverified |
regions |
For a geo-split site: one root per region | A region is one language reached by a different edge, so it is read by sitemap and hreflang rather than by a switcher | A region root could only be read as a language |
hosts |
Every host the site answers on | Sibling hosts must not be indexable | The sibling-host rule comes back unverified |
inventory |
For a relaunch: the old site's URL list | Redirect mapping | The redirect rule comes back unverified |
admin |
An admin or editor login | Empty states, editable content, form submission | Content rules come back unverified |
ssh |
Read-only SSH to the host, and the WordPress path on it | Scheduled tasks, the fatal-error mailbox, wp-config constants, post-type flags and the core fields of every published item, none of which a page shows | Those rules come back unverified |
third_parties |
Each third-party service the site loads, and what it is for | The third-party rule wants every origin to have a stated purpose | Every third party reads as unexplained |
critical_css |
The stylesheets the site deliberately blocks rendering on | The render-blocking rule allows the site's own critical CSS and nothing else | Every render-blocking request reads as a finding |
largest |
For each sampled template, its largest page (node bin/largest-pages.mjs <slug> finds them) |
A page over the element budget passes only on the largest page's main-thread time | That page-weight case comes back unverified |
probe |
The name of an environment variable holding a gate-probe secret the staging site also holds, and the form routes it may POST to | A form route that recognises the probe answers it like a real submission and stores nothing, so a redirect after a submit can be followed | POST forms' redirects are not followed, and the no-PII rule comes back unverified |
handover |
The path, inside the repository, of the handover document with its table of public REST routes and what bounds each | Every public route has to be listed with its bound | The REST authorisation rule comes back unverified |
rest_namespaces |
The project's own REST namespaces | Tells the project's live routes from core's and every plugin's | The REST authorisation rule comes back unverified |
production |
The production URL, and read-only SSH to it | Staging has to match production's PHP, server, compression and HTML caching, or the handover names each difference | The staging-parity rule comes back unverified |
The URL must be stable for the duration of the review. Deploying into a review invalidates it, and we start again.
Turnaround
Two business days from receiving everything above, for a first review. One business day for a re-review, because the second round only diffs against the first.
This sits inside the five business days the framework agreement allows for accepting a deliverable, so a project reviewed on receipt still leaves time to act on the result.
The verdict
One of three, plus the reasons.
| Verdict | Means |
|---|---|
| PASS | Ship it |
| CONDITIONAL | Ship it once the listed waivers are signed, or once the unverified items are verified |
| FAIL | A blocker is open. Not production ready |
The report lists, in order: blocking items, required items, waived items, items that could not be verified and why, and advisory notes. Each line carries the rule id, what is wrong, the measured value, and the fix, so it can be handed straight to a developer.
Rounds, and who fixes
Round one is a full review. I report; the project's developer fixes.
Round two diffs against round one and reads as "3 fixed, 1 regressed, 1 still open". That is what keeps a second round cheap, and it is why the review can be priced per project rather than per hour.
If you would rather I did the fixing on a given project, that is separate work and I quote it separately. It is not inside the review.
Waivers
A required item that cannot be met can be waived. A waiver needs a written reason from Colibrity,
gets an id, and is recorded in the report. It expires at that project's next release, so it is a
decision rather than a permanent exemption.
blocker items are not waivable. They are the ones with legal exposure, a broken index, or a
violated house rule.
If the same rule gets waived on two different projects, I will say so. It means either the rule is wrong and should change, or the starter theme should absorb it so it stops being failable.
Scope
- Front-end and technical SEO: markup, styles, scripts, media, the head, indexation, and what the server sends with all of it. It was front-end only when Michael asked for it in August 2026; the SEO section opened later that month and more sections follow. See the open questions.
- New projects. Work already delivered is not retroactively in scope.
- Review time is scoped per project, agreed in that project's purchase order alongside the build.
When the rules change
The rules live in a git repository, so every change is dated and visible. A rule added after a project's build started applies to that project's next release, not to the one in flight. A rule that is widened counts as a new rule for that purpose: the added clause applies at the project's next release, and the record says which clause it is.