Publishing back
Accepting fixes only changes the draft inside OptimizeCamp. Publishing is the deliberate, separate step that sends those changes live — with safety checks that make sure you're never pushing over someone else's changes.
What publishing does
Every accepted fix and inserted passage builds up inside your page’s draft in the editor — nothing reaches your live site until you publish. The editor’s document pane always shows you exactly what you’re about to ship: it’s the same view you’ve been reviewing fixes in, with every accepted inline fix already applied and every inserted passage already in place. There’s no separate staging screen — what you see is what publishes.
What “publish” actually does depends on where the page came from:
| Page source | Publish button does |
|---|---|
| Synced from WordPress | Publish to WordPress — updates the live post in place. |
| Imported by URL, or written/pasted, with a WordPress site connected | Push to WordPress as draft — creates a new WP draft; you publish it yourself from wp-admin. |
| No WordPress connection | Save snapshot — records the current document as a local published snapshot inside OptimizeCamp. Because it never updates a live URL, no before/after impact is claimed — the result is labeled Inconclusive rather than opening a real verification window. |
Publishing as a WordPress update
For a page already linked to a WordPress post, publishing sends a direct update to that post’s content and title. It deliberately sends nothing else — the post’s status is never touched by an update, so a live post stays live and a draft stays a draft.
Conflict check first
Before anything is sent, OptimizeCamp checks the post’s current state on WordPress against what it looked like the last time you synced. If the post changed on the WordPress side since then, publishing is blocked — see the conflict guard below.
Content goes out
The update is sent to WordPress. For most pages this is your edited document, re-serialized cleanly. For a small number of pages that didn’t round-trip losslessly on import (“patch-only” pages — see the audit & editor page), only the accepted inline fixes are replayed as exact text replacements against the original WordPress markup, so nothing about the page’s original formatting is disturbed.
Your library updates
Once WordPress confirms the update, the page’s status flips to Synced and its stored “last known WordPress state” is rebased to what you just pushed — so the next conflict check compares against this publish, not the one before it.
The conflict guard
WordPress is a live site someone else might also be editing — directly in wp-admin, or through another integration. If the post’s modified time on WordPress is newer than what OptimizeCamp has on record, publishing refuses to proceed rather than risk clobbering a change it doesn’t know about.
What you'll see
The page is marked Conflict — in the inventory table, and as a banner in the editor: “This post changed on WordPress after your last sync — publishing is blocked.” From there you re-import the current WordPress version to see what changed; note that this replaces your local document with the WordPress copy, so any fixes you’d accepted since the last sync will need re-applying afterward.
This guard only ever blocks a publish — it never merges or picks a winner silently. The conflict clears the moment you re-import.
Drafts are always drafts first
A page with no WordPress post behind it yet — imported by URL, written from scratch, or generated — never updates a live post directly. If you have a WordPress site connected, it publishes as a new WordPress draft: unpublished, sitting in wp-admin, waiting for a human to actually publish it there. Once that draft goes live on WordPress and a sync picks it up, later publishes from OptimizeCamp switch to updating that post in place, following the same conflict-checked path described above.
Note
Generated articles are held to this rule even more strictly: an AI-generated draft can only ever reach WordPress as a draft, never as a direct update to a live post — a human has to publish it from wp-admin first. That mandatory-review step can’t be skipped from OptimizeCamp.
The safety net: snapshots before every publish
Immediately before any publish — WordPress update, new draft, or local — OptimizeCamp saves a complete snapshot of the document exactly as it stood at that moment. That snapshot is the record any rollback would restore from if a publish turned out to be wrong. On top of that, when publishing updates an existing WordPress post, WordPress keeps its own native revision of the previous content on every update, giving you a second, independent safety net directly in wp-admin.
Entering the Verification state
Publishing isn’t the finish line — it’s the point where OptimizeCamp starts measuring what happens afterward. The moment a page publishes, it enters a Verification window: your next tracking runs on that page’s matched prompts are watched specifically for a before/after comparison.
Verification window
A live WordPress update freezes the page’s current prompt scope and last two qualifying real baseline batches before the remote write. It then waits for the first 2 comparable tracking batches started after the successful publish, for up to 14 days and never past a newer publish. The editor shows both baseline and after-batch evidence progress until it is ready.
While a page is verifying, republishing it — say, after accepting a few more fixes — caps the older window and opens a new one. A local snapshot, WordPress draft, missing baseline, or window without comparable evidence is labeled Inconclusive; it is never presented as improvement, decline, or even “no change.”
What comes after: the Impact Card
Once a verification window is ready, OptimizeCamp compares what your tracking runs saw before the publish against what they see after: was the page cited that wasn’t before, did mention rate move, did prompt-level visibility change. That comparison becomes an Impact Card — a receipt for what tracking observed in fixed cohorts, not proof that the publish caused the movement. See Impact Cards & wins for how to read one.
Impact Cards & wins
Fixed before-and-after observations following a live publish — and how labels are decided.
Connecting WordPress
Set up the connection publishing depends on.
Key takeaways
- Publishing is a separate, deliberate step — accepted fixes only change your draft until you publish.
- WordPress-linked pages update in place (content and title only, status untouched); everything else publishes as a new WP draft first, including all generated articles.
- A conflict guard blocks publishing outright if the post changed on WordPress since your last sync — it never silently overwrites.
- Every publish snapshots the document first, and WordPress keeps its own native revision on updates — two independent safety nets.
- A live WordPress update with 2 real baseline batches opens Verification; 2 comparable after batches within 14 days resolve it, while missing evidence is labeled Inconclusive.
Next step
See what the receipts actually look like in Impact Cards & wins — the before/after measurement screen this verification window feeds into.