The Handoff Standard

1. What this names#

A website is one of two things. It is an asset, which the owner can change, move, sell and hand to someone else. Or it is a rented capability, which works only while the original builder, the original tool, or the original account continues to exist.

The two look identical on the day they are delivered. The difference surfaces later, at the first moment somebody other than the builder needs to make a change.

“Lock-in” and “portability” name parts of this difference, but buyers have had no one word for the whole of it, so they have not known to ask. “Responsive” was once unnamed in the same way, and once it had a name it became something every buyer put in a brief. This standard names the property, defines a test for it, and lets anyone run that test themselves.

The property is transferability. A site that has it can be handed over. A site that does not cannot, and the owner usually finds that out at the worst possible moment.

2. Definitions#

Handoff. The moment anyone other than the original builder takes over the site. This includes handovers that were planned, and it includes the moment a handover becomes necessary and turns out to be impossible. A site that was never handed to anyone has still failed a handoff if nobody could take it over.

Transferable dependency. Something the site needs that anyone can obtain on ordinary commercial terms. A commercial plugin licence sold to the public is transferable: it costs whatever it costs, and a stranger eligible under its published terms can buy it.

Captive dependency. Something the site needs that only the original builder can supply. The original account, live credits on that account, a private API key, or context from a build session that no longer exists. A captive dependency is the mechanism by which a site stops being an asset.

Build-time scaffolding. Tooling whose only role was producing the site. Generators, converters, AI assistants, migration scripts, CLI helpers. Scaffolding is legitimate and this standard takes no position on how much of it you use.

Runtime dependency. Anything the delivered site needs in order to keep working or keep being editable. The whole of this standard turns on one distinction: scaffolding must not become a runtime dependency.

3. The acceptance test#

The $20k handover test. A stranger buys the site for $20,000. They log into the site’s administration interface and, within five minutes, with no code, no AI, no documentation and no help from whoever built it, they edit a headline, replace an image, and move one section above another.

If they can, it is a site. If they cannot, it is a scaffold.

The number is not about price, and “scaffold” is not a conformance verdict, as the last paragraph of this section says. The number is there to make the question concrete: $20,000 is enough money that the buyer expects to own something, and owning something means being able to take it away.

The test takes five minutes, needs no expertise, and anyone can run it. That is deliberate. A standard nobody can check for themselves is a marketing claim.

The test is the human, five-minute version of criteria 2, 3 and 5 below. It is the fastest way to find a site that will fail. It does not decide conformance on its own: the tests for C2, C3 and C5 do, and a failure here shows where to look. It is not the whole standard, because a site can pass the five-minute test and still be unmovable, undocumented, or built on dependencies nobody but the builder can buy.

4. The criteria#

A site conforms to this standard when all seven criteria are true of it, tested and recorded as section 5 sets out. Nothing else decides conformance. Each criterion states the outcome and the test that decides it.

5. Conformance#

Conformance is binary. A site conforms or it does not. There are no levels and no partial marks. Levels invite claims like “level 2 compliant”, which sound like conformance and mean nothing, and an unenforced standard has nothing to spend except the precision of its claims.

Anyone but the builder may run the test. There is no certifying body, no fee, no register and no badge you have to be granted. The test is designed to be self-administered, and a standard that requires an intermediary to confirm it will not spread.

The builder does not run the test. Somebody who knows where everything is cannot fail a test about finding things. The builder runs none of the tests in section 4 and not the acceptance test, and does not examine evidence for them. The client runs the tests by default. A colleague who is not the builder also qualifies. For a small studio or a solo builder this is the most expensive line in the standard, and the honest mitigation is that the bar is no build context, not a second employee. An AI session or automated check counts as whoever started it: started by the builder, it is the builder. It is never an independent tester on its own. The acceptance test and the tests for C1, C2 and C7 are run by a person. A session or check started by anyone but the builder may gather evidence for C3 to C6 and for the check of every entry below, and the person who records the result, who is not the builder, examines that evidence before recording it.

The whole site is tested, however it was built. The tests for C2 and C3 cover every page whose content was made for that page, such as a home, about or landing page, and each is tested on its own, whether or not a template frames it. For entries of one content type, such as posts or directory listings, one entry is edited and every other is checked for content that shows as editable parts, not one block of markup, by opening it in its editor or by an automated check of its stored content run with a positive control and examined by the person who records the result. Moving a section applies where the page’s own content sets the order. One page that passes does not stand for the others.

A conformance claim carries what was observed. Where the acceptance test was run, record the three changes made, where they were made and how long they took. For each of the seven criteria, record what was done to test it and what was seen: the accounts signed into, how each dependency is obtained, where the backup was restored, the change a successor made from the document. Record how the lists of accounts and dependencies were made complete, who ran each test, who started any session that gathered evidence and who examined it, whether it ran on the copy or the live site, the site’s version or state, the date, and the version of this standard. A criterion with no record has not passed. A claim with no record behind it is an assertion. This is the one discipline that decides whether the standard means anything, because every failing site can be described in language that sounds like a passing one.

Conformance is dated, not permanent. It is a property of a delivered site on a day. Re-run the affected tests after any change to how the site is assembled or who holds its accounts, when a page is built in a way the site did not use before, when a licence or a service it depends on lapses or changes hands, and when it moves host. Until then, the earlier result describes the site as it was, not as it is.

6. Proving that an AI-built site conforms#

AI-generated sites fail this standard in a specific and repeatable way, so they get a specific procedure. It is not harder than the general test. It is mostly a matter of testing the right artifact.

1. Test the delivered site, not the build environment. The environment the site was built in has the tooling in it, by definition. It cannot answer the question. The copy restored for C6 counts. It carries the site’s files and data, not its host, so anything that lives at the host is checked on the live site.
2. Disconnect first, then test, on a copy. On the copy restored for C6, remove the generator, its plugin or extension, its API keys and any live connection to it. Then run the test on the copy. A test run with the tooling still attached is measuring the tooling. Removing the tooling from the live site and revoking its access are owner changes, made with a backup, after the copy has passed.
3. Test every page, not a sample. Section 5 requires this for C2 and C3 on every site. It is repeated here because AI builds fail unevenly. One page is native and complete and the next is a single undifferentiated block, and nothing about the first page predicts the second.
4. Verify absence with a positive control. Before reporting that a dependency is gone, run the same check against something you know still has it, and confirm the check reports it. A wrong path, a mistyped pattern and a genuinely clean result all look identical.
5. Do not accept the generator’s own report. A build tool reporting that its output is complete is the tool grading itself. The same applies to an AI assistant summarising its own work: a description of a passing test is not a passing test.
6. Record the version and the date. Both the site’s and the standard’s.

The general principle behind all six: a description is not an observation. Every one of these steps exists because a plausible sentence was accepted in place of a thing somebody looked at.

7. WordPress conformance profile#

The criteria in section 4 are technology-neutral, which costs them specificity. This profile applies them to WordPress and adds checks the criteria do not make. Conformance to this standard is decided by sections 4 and 5 alone. Conformance to this profile is a separate claim: it names the profile, and it requires the standard and every item below. Profiles for other stacks can be written the same way, and the criteria are the part that does not change.

Front end

• Every page is complete. All sections present, verified page by page, no orphan heroes.
• Visual QA passed at desktop and mobile widths.
• No horizontal overflow at any breakpoint. Check document.documentElement.scrollWidth against the viewport width at 390 as well as at desktop. A page wider than its viewport is the highest-signal sign that a breakpoint was never built.
• Forms, SEO and analytics wired the conventional way for the platform, not bespoke.

Back end (C2 and C3, and the part most often missing)

• Every page opens cleanly in the site’s own editor. No invalid-content warnings, no broken or foreign blocks.
• Sections are discrete, labeled, reorderable and editable in place, without code.
• Header, footer and navigation are real template parts or templates, not markup baked into PHP.
• How the navigation’s items are stored is a deliberate choice, recorded in the handoff document. Menu items in the CMS database, items inline in a version-controlled template part, or a referenced navigation record are all defensible. Stumbling into one of them is not.
• A non-technical owner can edit text and swap an image. A developer can read the structure and extend it.

Standalone (C5 and C7)

• Build scaffolding removed. The AI tooling used to produce the site is deactivated and uninstalled, any code-execution bridge is gone, and there is no live connection back to the tool. The delivered site is native output of its own platform.
• One-page handoff document: which builder, where design tokens live, how to edit and add a section, plugin inventory with what each is for.
• The $20k test run and passed against the delivered site, with any step that has nothing to act on recorded as C2 allows, by a person who did not build it, as section 5 sets out, before it is called finished.

Two method notes that stop this profile producing false failures. A page-builder that has no per-element label field satisfies “labeled” through semantic wrapper classes plus reorder on the canvas, not through a naming panel it does not have. And confirm the editor genuinely loaded by checking that the editor’s own body state is active and its preview frame contains elements, rather than by searching the page source for an error string: several builders pre-embed their error strings on every editor page, so searching for one reports failure on a perfectly good site.

No exemptions. There is no lane for sites that are “only” a directory, a throwaway, or an internal tool. If a directory listing is a form in the admin that anyone can fill in, and it is, then nothing is exempt on grounds of being simple.

8. What this standard does not say#

• It does not say how the site was built. AI, no AI, agency, freelancer, template, hand-written. A site built entirely by an AI can conform. A site built entirely by hand can fail. The criteria describe the artifact.
• It does not grade design, performance, accessibility or search visibility. Those are other standards’ work. A conformant site can be bad at all four. The WordPress profile’s additional items bind only a claim made against that profile.
• It does not require open source, running your own server, or any particular CMS. It does require that the owner can take the site’s code and data and run them, editor included, away from the original host. Sites on hosted platforms where the owner cannot take the code and data, such as Wix, Squarespace and Shopify, cannot pass C6, and so cannot conform.
• It does not certify anyone. There is no body, no fee and no register.
• It does not say a non-conformant site is worthless. A rented capability is a perfectly sound purchase when the buyer knows that is what they are buying. What this standard is for is the case where somebody believes they bought an asset and did not.

Author’s interest, disclosed. The author sells website builds and hosting, and therefore sells conformance. That is a conflict. The conflict reaches into the rule on hosted platforms above: the author sells hosting on which a site can pass C6, so the rule that sites on those platforms cannot conform works in the author’s favour. The mitigations are that the criteria are technology-neutral, the test is self-administered, the text is CC BY 4.0 and so is free to use, modify and fork, and each released version is published at its own address, so anyone can check the standard against their own experience and fork it if the author’s interest ever bends it. None of that fully escapes the fact that a vendor wrote it. It is disclosed here rather than buried.

9. Versioning#

This is version 1.0, dated 2026-09-16. Its permanent address is https://www.handoffstandard.org/1.0/. Changes ship as dated versions. Each released version is published at its own address in the same form and is not edited there, so a conformance claim can cite the version it was tested against and a reader can find that text after the next version ships. Proposals and corrections go to the author.

Licence. This specification is published under Creative Commons Attribution 4.0 International (CC BY 4.0). Quote it, translate it, teach from it, write a conformance profile for a platform it does not yet cover, or fork it outright, commercially or otherwise. Attribute it to Ryan Davis, handoffstandard.org.