Approved in a screenshot. Changed before release.

A screenshot captures one moment. Keep approval attached to the version that will actually reach the public website.

Approve a version. Release that version. Verify that version.

Keep approval attached to the version that will actually be published. If an important fact changes after review, check that change before release. Then confirm that the public website matches the accepted version, with a way to recover if something goes wrong.

Which version did everyone approve?

You approve a screenshot showing a new service page. Before publication, someone adjusts an inclusion, changes a link and replaces an image. When the website goes live, everyone remembers that the page was approved, but they are remembering different versions.

That confusion is avoidable. A useful publishing process makes the current version and the outstanding decisions visible, without turning every minor correction into a large administrative exercise.

Separate writing from deciding

The person preparing a draft may be different from the person who can verify the service facts. A designer can check layout while the business owner checks an offer. The release itself may need a final decision once those reviews are complete.

Name the relevant responsibilities and identify the version being reviewed. Comments such as 'looks fine' are less useful when there are several files, previews and message threads in circulation. A shared reference prevents a later draft from accidentally inheriting an earlier approval.

Suppose you approve a page explaining what a website service includes. An editor later adds an integration that has not been agreed commercially.

Where it goes wrong

The page is released under the original approval because the overall layout still looks the same.

What to do instead

Review the changed inclusion with the factual owner, identify the accepted revision and check that the public page contains that version.

Approval remains connected to the actual promise made to a customer. The example introduces no new service terms.

Make meaningful changes visible

A corrected comma and a changed price are not the same kind of edit. Neither are moving a photograph and expanding what a service includes. When a change affects the meaning of the offer or a customer action, bring it back to the person who can approve that part.

The review should remain proportionate. The aim is to prevent important facts or functionality from slipping past their owner, rather than require every participant to approve every detail repeatedly.

Finish with the public result

Publishing in an editor and releasing the website can be separate steps. Ask the team to explain when the approved content becomes visible to customers and how they check it. The final record should identify what went live, not merely that someone pressed a button.

Keep the previous working version recoverable for meaningful releases. If the new page serves the wrong information or breaks an action, correct or restore it and verify again. Clear ownership is most useful when it helps the team respond calmly to a real problem.

Questions to ask your agency

  • Which version is currently approved?
  • Who can verify the important business facts?
  • Has anything meaningful changed since review?
  • Who checks the public result and recovery path?

Common questions

Does every edit need another full approval round?

Use a proportionate process. Revisit the decisions affected by a meaningful change, especially commercial facts and customer actions, rather than repeating unrelated reviews.

Why is an editor's Published status not always the end?

Some websites release approved editor content through a separate build or deployment. Confirm the actual publishing route and verify what the public website serves.

From explanation to implementation

This guide is published by NAVIFLARE, a website, CRM and AI workflow practice. Source notes identify the platform guidance; worked examples explain a method rather than claim a client result.

Explore website design and development

Tell us how your team currently requests, reviews and publishes changes. We can discuss a simpler process that makes the current version and responsibilities clear.

Discuss your website publishing process

Keep reading.

Back to all insights

Let’s talk about
your website.

A couple of details are enough to get started.