Start with the confirmed page version
Give the release a plain boundary: one page, a defined set of pages or a named content change. Record the public URL, the confirmed copy or asset version, the person who confirmed it and the person who will publish it. If a material edit happens after sign-off, send that version back for the relevant review.
A content workflow may cover request, drafting and review, while a platform deployment checklist covers hosting and technical checks. This page-level release record starts after the relevant review: it helps an editor confirm that the confirmed change is what visitors can actually see.
Two public posts illustrate this verification problem. In a Webflow community post, a user says the live page still showed an old photo after publishing its replacement. A hobby developer separately describes manual checks missing breakages across hundreds of pages and testing sitemap routes on staging before production. These are limited self-selected examples, not detail of typical business practice, UK demand or demand for 760 Studios.
Check the preview against the confirmed change
Open the preview route and compare the changed parts with the confirmed version. For a copy edit, check the final wording and any links it changes. For an image replacement, check the image and its text alternative. Confirm that the preview is the page and destination intended for publication, then note anything that still needs attention.
Keep this check proportional to the change. A complete redesign or an altered form needs broader design and functional QA; use the relevant technical checklist for those risks. A routine content update still needs a specific comparison between the confirmed version and the rendered page.
Publish, then inspect the public URL
After the platform reports publication, open the public URL in a fresh browser session. Check the changed content or asset, the page address and any changed destination link. If the release includes a group of pages, check every affected URL or use an agreed route list; a successful CMS action alone does not confirm each public result.
If the old version appears, record what you can see and when you checked. Confirm the page and publishing destination, then ask the site or platform owner to investigate the release path. Avoid repeating a publish action without knowing whether the first action failed, reached a different destination or is awaiting a separate deployment.
Keep detail of the result
Record the page, confirmed version, approver, publisher, publication time, public URL, check time and result. If the page is wrong or unavailable, assign a next owner and leave the entry open until the correction is checked. This turns ‘published’ into a traceable result rather than an assumption.
The example below is fictional. It shows a small content release record; it does not describe a 760 Studios production change or promise that every platform records these fields.
| Record field | Example entry | What it helps confirm |
|---|---|---|
| Page and change | /services/example; hero image replaced | The affected public route and intended change |
| confirmed version | Copy v4; service owner confirmed at 10:30 | Which version was authorised |
| Published by and time | Site editor; 11:00 Europe/London | Who made the change and when |
| Public-page check | 11:08; copy v4 and new image visible; pass | What a visitor could see after publication |
| Open issue and owner | None; the new image is visible in the public-page check | The recorded result is consistent with the successful check |