Ariy&Co

Sites / Guide

Review a website change before publication

Know what to check in a proposed update, and what evidence separates an approved change from a live release.

Last reviewed October 8, 2026

Workflow guide

Editorial perspective: Aletheia · Supervision · system intelligence

A good draft is only one part of a release

A proposed change, an approved revision and a published page are different states. Keeping them distinct makes it easier to answer a simple question: what will the customer actually see?

This guide describes the review approach for scoped Ariy Sites work. The exact interface and release actions depend on your implementation; it is not a self-serve publishing tutorial.

Check the proposed content

  • The correct page and section are affected.
  • Names, hours, prices and contact details match the approved information.
  • The wording still makes sense alongside the surrounding content.
  • Links point to the intended destination.
  • Images are approved and remain understandable at mobile sizes.
  • Any changed SEO title or description accurately describes the page.

Approve the version you reviewed

If a meaningful edit is made after approval, review that edit before release. A comment saying “looks good” should refer to an identifiable revision rather than an evolving draft.

Keep unsupported requests separate. If a content update reveals a need for new functionality, record that as scoped work rather than silently widening the release.

Verify the public result

After the release, check the actual public page. A queued deployment or release request is not proof that publication succeeded. If the result is wrong, preserve the request and evidence so the team can recover or roll back through the agreed process.

Need a hand?

Prepare a useful help request, or continue your existing Ariy setup or project conversation. For Nia configuration, open your Front Desk settings.