A simultaneous editing conflict in a CMS happens when two people have the same post open and the platform has to decide whose changes survive. Most platforms use one of three models: the last save wins, the post is locked to one editor at a time, or edits merge in real time. Find out which model yours uses with a two-browser test, then set a simple rule: one person edits a post at a time, and everyone else comments.
The complaint usually arrives after the damage: “We both had it open and one of us lost.” An editor tightened the introduction while the writer added a section at the end. The writer saved last, and the editor’s fixes vanished. On many platforms nothing warns anyone, so the loss is found days later, often by a reader.
This guide explains the three models, a quick way to test which one your platform uses, where conflicts slip through even on platforms that lock, and the handoff habits that make the whole problem rare. Platform behavior was checked against vendor documentation on September 24, 2026. This area is moving: WordPress’s real-time collaboration feature was pulled from its 7.0 release in May 2026, so treat any platform detail here as a snapshot from that date.
The three ways a CMS handles simultaneous editing conflicts
Every platform has to answer the same question when two people edit one post. The answer usually falls into one of three patterns, and each has its own failure mode.
| Model | What happens | A documented example | Main risk |
|---|---|---|---|
| Last save wins | Both people can edit; whoever saves second can overwrite the first person’s changes | Squarespace, for contributors editing at the same time | Quiet loss, discovered late |
| Lock with take-over | The second person is told someone else is editing and can go back or take over | WordPress post locking | Take-over clicked out of impatience |
| Real-time merge | Both edit at once and changes sync live | Sanity Studio | Two people rewriting the same sentence, with no clear owner |
Squarespace states the first model plainly. Its help page on inviting a contributor (updated September 14, 2026, read September 24, 2026) answers whether contributors can edit at the same time with: “Yes, but if multiple contributors edit at the same time, their changes can overwrite each other.” Its advice is to work with your team so you do not.
WordPress uses the second model. The notice text listed in the WordPress developer reference for its post-lock notice (read September 24, 2026) names the person who is currently editing the post and asks “Do you want to take over?”, with Go back and Take over buttons.
Sanity sits in the third group; its documentation describes Sanity Studio as “an open-source, real-time collaborative content workbench.”
Git-based platforms add a fourth shape: two people edit on separate branches, and the conflict appears later, when someone merges them. That model is covered in whether Git pull requests can work for content teams.
WordPress is a moving example
WordPress shows why the date on any of this matters. The WordPress core team announced on May 8, 2026 that real-time collaboration will not ship in WordPress 7.0 (read September 24, 2026), citing concerns around surface area, race conditions, server load, memory efficiency and recurring bugs found through fuzz testing. The same post says the feature can still be tested through the Gutenberg plugin and that a plan for broader testing would follow.
For a content team, the practical reading is simple. Do not build a workflow around a feature that has not shipped on your version. Check the release notes for the version you actually run, and run the test below after every major update, because the model your platform uses can change with a single release.
Find out which model your platform uses: the two-browser test
Documentation tells you what a platform intends. A short test tells you what it does on your site, with your settings. Never run it on a live post.
- Create a throwaway draft. Give it a few paragraphs, a tag and a featured image.
- Open it as two different users in two different browsers. A private window works for the second login. If your team sometimes shares one account, repeat the test with the same user in two tabs, since that can behave differently.
- Edit different parts at once. In browser A, change the first paragraph without saving. In browser B, change the last paragraph and save. Then save in browser A.
- Reload and read. Which edits survived? Did either browser show a warning, a lock or a take-over prompt?
- Repeat with the fields outside the body. Change the tag in one browser and the featured image or SEO title in the other.
- Test the stale tab. Leave one tab open for a few hours, make changes elsewhere, then save from the old tab and see what it overwrites.
Write the result in one line in your team’s process notes, for example: “Our platform: last save wins, including tags; no warning.” That line is worth more than any feature list.
Where conflicts hide even on platforms that lock
A lock protects the editing screen. Conflicts often come in through other doors.
- Metadata and settings panels. Quick edits, bulk edits and list views may change a post without opening the editor that holds the lock.
- Other surfaces. A mobile app, an import script or an automation that writes to posts may not respect a lock made in the browser.
- Stale tabs. A tab opened yesterday still holds yesterday’s version, and saving from it can overwrite today’s work.
- Take-over by habit. People click take over to “just fix one thing.” On WordPress, the same notice code includes the line “Your latest changes were saved as a revision” for the editor who was taken over. The work is not gone, but it now sits in revision history instead of the draft, and someone has to go and get it.
- Real-time editing without ownership. Live merging prevents overwrites, but it merges keystrokes, not intentions. Two people can still pull one paragraph in opposite directions, and nobody is clearly responsible for the result.
The handoff rule that prevents most conflicts
Technology reduces the damage. A handoff rule removes most of the cause, on any platform.
One owner per post, per stage. During drafting, the writer owns the post. During editing, the editor owns it. Ownership should be visible in the status or assignee field, not held in someone’s head; the setup in the editorial workflow for a team of two to five shows how small teams make this explicit.
Everyone else comments. Reviewers leave notes or suggestions instead of editing the text directly. Comments cannot overwrite anything.
Hand off out loud and close the tab. “Done with it, it’s yours” in the team channel, followed by closing the post. The closed tab matters as much as the message, because it removes the stale copy.
One person approves the final version. If two people each believe they have the last word, they will both edit at the end. Naming one final approver settles that before it becomes a conflict.
Split big jobs outside the post. If two people genuinely need to work on one long piece at once, divide it by section in a shared document and let one person paste the finished sections into the CMS.
If it already happened: recovering the lost edits
Recovery works best when you stop the damage first.
- Ask both people to stop editing and close their tabs.
- Copy the current version out of the CMS into a separate document and confirm it opened correctly. That copy is your rollback if the next steps go wrong.
- Look in the revision or history panel, if your platform keeps one, for the version that contained the lost edits.
- Re-apply the lost changes by hand. Restoring the older version wholesale would only swap who loses: it would bring back one person’s work and delete the other’s.
- Note what caused it and adjust the handoff rule, not just the post.
Frequently asked questions
Can two people edit the same CMS post at the same time?
It depends on the platform. Squarespace’s help page says contributors can, but their changes can overwrite each other. WordPress locks a post to one editor and offers the second person a choice to go back or take over. Real-time platforms such as Sanity Studio merge edits live.
What does “take over” mean when someone else is editing?
It means the second editor gets control of the post and the first loses it. In WordPress, the notice shown to the editor who was taken over includes the line “Your latest changes were saved as a revision,” so their unsaved work goes into revision history rather than disappearing.
How do I get back changes someone else overwrote?
Stop editing, copy the current version out, then look in the post’s revision history for the version with the missing changes. Re-apply those changes by hand instead of restoring the whole older version, which would delete the other person’s work.
Does real-time collaboration remove editing conflicts?
It removes overwrites, not disagreements. Two people can still edit the same passage in different directions at the same moment, so one owner per post is still the rule that keeps the final version coherent.
Is WordPress getting real-time collaboration?
The WordPress core team announced in May 2026 that it would not ship in WordPress 7.0 and could still be tested through the Gutenberg plugin. Check the release notes for the version you run before relying on it.
