01
A deployment is one step in the launch
A successful upload means the platform accepted an artefact. It does not establish that the customer's domain serves the intended version, old links work, forms submit or the owner has the necessary access. Agree what acceptance means before treating a deployment badge as completion.
For a small business, the acceptance list should cover the public pages, contact journey, search-facing URLs and ownership. The implementation can be technical, but the owner should receive a plain explanation of what was checked and who handles the next change.
02
Use a preview for review and identify the release
A preview lets the business review content and behaviour before production changes. It should be clear which URL is a preview and which is the public website. Availability and creation of preview URLs depend on the project's deployment workflow; a Git-integrated example is not a promise that every upload creates the same review path.
Record the source commit or equivalent version, build result, intended production project and deployment identifier. Project Monet's public deployment marker and production check compare the exact deployed commit. That reduces the risk of reviewing one build and certifying another.
- Approve the actual pages and media in the agreed review environment.
- Test relevant forms and integrations with authorised test data.
- Keep production canonicals and preview indexing controls appropriate.
- Record the exact version selected for launch.
03
Check redirects and error responses on the real domain
Review the old URL map before launch. Equivalent permanent redirects should land on useful replacements; removed content without an equivalent should return a genuine error. Cloudflare Pages documentation describes extensionless route behaviour, custom 404 pages and SPA fallback when no top-level 404 exists.
Pages Functions and static redirects also need an intentional relationship. Cloudflare documents that _redirects rules do not apply to requests served by Functions. This site's routing excludes its merge redirects from the handler and handles retired blog routes before asset lookup. That is a specific design choice, not a checklist item to copy blindly.
Ask for response-level verification. A page that visually says not found but returns 200 has different behaviour from a true 404. Test the domain the customer will actually use, including relevant legacy variants.
04
What this site's release evidence shows
On 6 October 2026, Project Monet's strict production run verified the prior cleanup commit bc2f0f514b98ecadf60b00da311a389577521b5b. It checked 252 retained blog pages and their 1200×630 OG PNGs, core canonicals, 302 total sitemap URLs, merge redirects and the removed URL responses. This guide batch adds new pages after that dated checkpoint.
The earlier cleanup had 102 purged article slugs and 13 equivalent merge mappings. The test checked 306 removed clean, .html and OG paths, and both clean/.html merge redirects. Those counts document a release scope; they are not ranking, conversion or uptime guarantees.
05
Make the handover usable
- Domain/DNS: who controls the account and renewals?
- Source: which repository holds the website and who can access it?
- Hosting: which Pages project serves production and who can administer it?
- Integrations: who owns Analytics, Search Console and the form/booking service?
- Content: who changes hours, prices, project pages and policies?
- Support: what is included, how are incidents reported and who approves changes?
- Recovery: where are the source, deployment history and agreed rollback instructions?
Transfer or grant the agreed account access securely; a screenshot of the dashboard is not ownership. Document third-party subscriptions and responsibilities accurately without putting secrets in the public website or an ordinary handover document.
Avoid changing DNS or deleting fallback hosting simply to make a normal content release look complete. Hosting changes and rollback retirement should follow the separately agreed migration and ownership plan.
06
Agree launch evidence before paying for completion
A good launch report names the release, tested URLs, failures resolved, remaining limits and responsible owners. It should be short enough to use and detailed enough to investigate a future issue. Indexing and ongoing performance monitoring belong to their own evidence, not a deployment badge.
Read website ownership and maintenance scope, then discuss the launch and handover requirements. Project Monet should scope those responsibilities alongside the build.
Sources
Primary and supporting sources
Use the linked documentation and labelled build examples to check the evidence. Business examples are planning tools; they do not establish customer outcomes or guarantee search visibility.