A website update is complete when the intended information is live, its dependencies work and someone has checked the reader journey. Use a short release record to keep preparation, approval and verification connected. This workflow fits routine content changes and can be adapted to the controls of your publishing system.
Define the change and its dependencies
Record the affected URL, the reader task, the requested change and the source of the new facts. Identify the content owner and a person who can publish and recover the previous version. Include images, downloads, forms, navigation, translations and shared content that the page depends on.
Inspect the public page before editing. Confirm that the requested change still applies, and record the version or file hash you started from. If another editor changes the source, reconcile the work before replacing it. This prevents a routine correction from discarding someone else's update.
Prepare a recoverable version and a preview
Save the prior source and affected assets using the platform's supported version or backup process. Record how to restore them and who has access. For consequential releases, test recovery in a safe environment before the deadline. Store private backups outside publicly served directories.
Work in a draft or staging area appropriate to the system. Use representative content and the real template. Check the narrow layout, long titles, image proportions and any table scrolling. Protect unpublished or private information according to the site's access policy.
Keep stable URLs where possible. If a URL changes, map the old destination to a genuinely corresponding replacement and update internal links. Record the intended redirect or removal behavior for verification.
Review the reader journey
| Check | What to do | Evidence |
|---|---|---|
| Facts | Compare consequential statements with approved sources. | Owner, source and reviewed version. |
| Navigation | Follow the route into the page and the next action. | Working links and expected destinations. |
| Accessibility | Check headings, link wording, image alternatives and keyboard use. | Problems fixed or assigned before release. |
| Assets and forms | Open downloads and test the permitted form workflow. | Correct version, readable file and intended result. |
| Metadata | Inspect title, description and sharing image. | Values match the content being published. |
The W3C Easy Checks offers a practical first accessibility review, while explaining that these checks are not a complete accessibility evaluation. Use deeper testing when the change affects interaction, templates or access to an important service.
Resolve review comments against the exact revision. If a late edit changes the facts or behavior that was approved, obtain the relevant review again.
Publish and inspect the public result
- Recheck the source version immediately before release and reconcile intervening edits.
- Place new assets where they will be served, then publish the page that refers to them.
- Open the public URL as an ordinary reader, without relying on an editor preview.
- Check the changed facts, links, downloads, responsive layout and any affected form behavior.
- Inspect the delivered title and description; confirm that templates and server includes rendered correctly.
- Record the release time, version, publisher and verification result.
A successful upload or HTTP 200 response only confirms part of the result. Open the actual content. If a cache serves the earlier version, investigate the site's documented cache process and verify again from the reader's route.
Decide whether to correct or roll back
Set release-specific triggers before publishing. A wrong contact route, missing required download or unintended disclosure may justify immediate withdrawal or recovery. A small wording defect may be safely corrected forward. Consider whether restoring the old version would itself reinstate inaccurate information.
Restore the coordinated set of affected content using the agreed procedure, verify the public result again and preserve the failure evidence. Record the cause and the repair that will make a retry safe. For an incident involving sensitive information, follow the organization's incident process as well as fixing the page.
Download the release checklist. Fill in scope, dependencies, recovery steps and acceptance criteria before the change; complete the release and verification fields afterward. Feed subsequent review dates and change triggers into the content lifecycle.