Skip to content
SiteBienfait
Free website check
The workflow

How a change reaches your live site

Eight steps, one approval boundary and a rollback target that outlives the change. This page describes the mechanics; it makes no promise about a search outcome.

The eight steps

From a plain-language request to a recorded verdict

The same sequence applies to a title rewrite, a redirect and a page rebuild. No step can be skipped, and the order is the safety property.

  1. 01

    Request

    A finding from the audit or the weekly report becomes one plain-language change: what changes, why, and the evidence behind it.

  2. 02

    Sandbox

    The change is prepared on an isolated git branch against the site's own source. Production is not edited while the change is built.

  3. 03

    Preview

    The branch gets a private preview URL, so the change is read at the real viewport before anything ships.

  4. 04

    Gates

    The SEO contract, internal links, schema and the performance budget are checked in CI, against the previous build.

  5. 05

    Review

    A person reads the change on the preview and approves or rejects it. By default that is the SiteBienfait reviewer; an owner who prefers can approve every change personally.

  6. 06

    Deploy

    An approved change set deploys to production. The previous deployment stays addressable as the rollback target.

  7. 07

    Measure

    A measurement window agreed before the deploy opens, and the weekly report reads it against the baseline.

  8. 08

    Verdict

    At the end of the window the change is kept or rolled back. The report records which, with the data behind it.

The flow

The same path, drawn

The diagram marks the approval boundary, because it is the one step that cannot move: nothing publishes without it.

The change-set flow A request becomes a sandbox branch, a private preview, a set of gates, a human approval, a deploy, a measurement window and a keep-or-rollback verdict. No step can be skipped. 01 Request Plained-language change 02 Sandbox Isolated git branch 03 Preview Private URL 04 Gates SEO, links, vitals 05 Approval A person decides 06 Deploy To production 07 Measure Window opens 08 Verdict Keep or roll back NOTHING PUBLISHES WITHOUT YOU
Fig.A request becomes a sandbox branch, a private preview, a set of gates, a human approval, a deploy, a measurement window and a keep-or-rollback verdict. No step can be skipped.
  1. 1. Request: Plained-language change
  2. 2. Sandbox: Isolated git branch
  3. 3. Preview: Private URL
  4. 4. Gates: SEO, links, vitals
  5. 5. Approval: A person decides
  6. 6. Deploy: To production
  7. 7. Measure: Window opens
  8. 8. Verdict: Keep or roll back
The gates

A gate fails the change; it does not warn

A warning that can be clicked past is a suggestion. Each gate below stops the change set, and the failure is recorded against the change.

SEO contract

URLs, titles, descriptions, canonicals and structured data are compared before and after. A lost URL, a missing title or a broken canonical is a failure, not a warning.

Failure: the change set does not ship.

Visual diff

The preview is compared with the live page at the same viewport, so a layout regression is seen rather than inferred.

Failure: the preview is rejected and the diff is attached.

Internal links

Every internal link in the build is resolved to a built file or an in-page anchor. A dead link fails the gate.

Failure: the change set does not ship.

Performance budget

The page has to stay inside the site's JavaScript and Core Web Vitals budget. A regression in the delivered page fails the gate.

Failure: the change is reworked in the sandbox.

The rollback target

The previous release stays addressable

Rollback is not a reconstruction; it is a return to the deployment that was already serving production. That is why the target is created before the deploy, not after a problem.

  • 01

    One known-good release

    Every production change keeps the last good deployment addressable as its rollback target.

  • 02

    One action from the console

    Rollback runs from the console, without anyone editing a database by hand or rebuilding the site from memory.

  • 03

    Recorded, not hidden

    A rollback is recorded against the change set and its measurement window, so the next proposal starts from what happened.

The owner's controls

What the owner can control

The owner is not a spectator in the workflow. These are the decisions that stay in their hands at every step.

  • Approval, when you want it

    You read the pages once before launch. After that a person approves every change on its preview, and you can ask to be that person — for one change or for all of them. A rejected change does not ship in another form.

  • Scope

    A change set stays one change. An owner can reject a bundle that mixes unrelated edits rather than approving it whole.

  • Timing

    The owner decides when an approved change deploys, including holding it until a quieter period.

  • Rollback

    The owner can return the site to the previous deployment after any deploy, not only when an agent proposes it.

  • Ownership

    The domain, the source repository and the hosting account stay in the owner's name, and the repository can be exported at any time.

What is not promised

What this page does not claim

A workflow makes changes safer and reversible. It does not decide what a search engine or an answer engine does with the page afterwards.

A safer change is not a ranking.
The gates protect what exists. They cannot make a search engine choose the page.
Passing every gate is not proof of an outcome.
The evidence is that the change did not break the contract. The measurement window is where a direction is read.
No step is silently skipped.
If a gate cannot run, the change does not ship. A missing check is not treated as a passed one.

Start with a free website check

The check is read-only and costs €0. A person reviews the report, and nothing is prepared until you ask for it.

Get my free check