Synthetic acceptance exercise, not a live infrastructure diagnosis. Names, release IDs and evidence labels below are fictional. No DNS, account, certificate or existing website is changed.
Accept the business address, not just the preview
When a website supplier sends a working provider URL, ask which business hostname and approved release the handover covers. A successful preview proves only that something is available at that address. It does not by itself show that the intended public domain reaches the same release, has completed platform association or has usable HTTPS.
An owner described a provider address working while the custom domain returned 522 in an older Cloudflare community discussion. That original report establishes a historical problem, not this site's diagnosis or a universal repair. Do not adopt a forum reply as authorisation to change DNS.
A three-state evidence register
Use the fictional host shop.example.test, the declared platform Cloudflare Pages and the supplied teaching release identifiers. Each row represents a separate acceptance record, not stages measured on a real domain. Download the filled CSV register.
| Case | Evidence supplied | Decision | Next responsible role |
|---|---|---|---|
| DEMO-A | DNS label and demo-build-17; no approved project association; HTTPS unknown | Blocked: project association evidence missing | Authorised project owner |
| DEMO-B | Project association label, DNS label and demo-build-17; HTTPS unknown | Blocked: HTTPS evidence missing | Authorised domain owner |
| DEMO-C | Teaching labels for project, DNS, certificate and demo-build-18 | Ready for human scope review only, not live delivery proof | Website acceptance owner |
A DNS observation is not a substitute for the missing project evidence in A. Adding association evidence in B does not resolve its unknown HTTPS state. C has a newer release label, so the reviewer must still establish that demo-build-18 is the release the buyer actually approved. A complete row of typed labels cannot authenticate itself.
Use the register in a supplier handover
- Write the intended hostname, platform, approved release and acceptance time. Distinguish apex, www and other subdomains if they are in the agreed scope; do not assume one proves the others.
- Ask the authorised owner to supply the platform association record and DNS observation. Keep record time, relevant host and redacted evidence reference together.
- Inspect HTTPS and the actual content served at the business hostname. Compare an agreed visible release marker or other approved content evidence, not merely an HTTP 200.
- Record each missing item and the role responsible for verifying it. Retest the same host and release after an authorised correction. Leave unrelated records and old pages alone.
The evidence register is a procurement acceptance method, not a DNS migration script. Do not paste private control-panel tokens, account IDs, personal information or customer files into a public register. The actual owner keeps original evidence in an appropriately restricted location.
One platform-specific fact, not a universal diagnosis
Cloudflare Pages custom-domain documentation, checked 15 October 2026, treats adding the domain to the Pages project as distinct from manually creating a CNAME. It documents a 522 risk when the CNAME is created without that association. Its apex and externally managed subdomain requirements differ. These are Pages-specific conditions, not instructions for every Worker, Sites deployment or hosting provider.
That documented condition does not establish the cause of any particular 522, and it does not prove that the forum poster's records matched this exercise. Verify the current platform, actual domain state and authorised change scope before proposing a technical fix. A website acceptance guide is not permission to alter nameservers or security settings.
Keep other acceptance decisions separate
A domain passing these checks does not prove the contact form is delivered, the pages are indexed or the site is commercially successful. For a bilingual launch, a recorded language-pair check can examine a different part of the handover; a separate form-state demonstration explains why accepted and delivered are different.
Bring the business hostname, approved release description, a redacted error and a record of what is known or missing to a website delivery discussion. The useful output is a bounded verification brief, not an invented uptime guarantee or a promise that changing DNS will improve rankings. This resource performs no TLS security audit, ownership transfer, live infrastructure test or recovery.