WordPress revisions give you a free change log for guest posts: every saved draft and published update is recorded, you can see what was added, kept or removed, and you can restore an earlier version. They are not a complete audit trail, though. Revisions can be capped, they do not carry approval notes or rel decisions, and the interface has no way to delete them. Treat the revision history as the "what changed" record and keep a separate log for "why" and "who approved".
The short recommendation: leave revisions on, give every editor a personal account, tie each approval to a specific revision in your approval note, and if you cap revisions, set the number high enough to survive every correction round a post goes through.
What the documentation says revisions are
The basic mechanism
The WordPress revisions documentation (Opens in a new tab) says the system stores a record of each saved draft or published update. Dragging a slider shows what changed in each revision: what was added, what stayed the same and what was removed. Added or removed lines are highlighted, individual character changes get further highlighting, and a Restore button brings back a revision. The labels below are the English interface names; if your dashboard is set to another language, the menu names will look different.
Which fields are tracked
By default, the documentation says, WordPress tracks changes to title, author, content and excerpt. It does not mention categories, tags, the featured image or custom fields, so nothing in the documentation promises that those are tracked. For a guest post where the category or a field holding a rel decision matters, test your own install rather than assuming.
Where revisions live
Revisions are stored in the posts table as children of the post they belong to, with a post_status of inherit and a post_type of revision. For an editor this means revisions sit in the site database and travel with its backups. If your backup plan leaves them out, or you do not back up at all, the change log has no backup either.
| Feature | What the documentation says | What it means for an editor |
|---|---|---|
| Coverage | Each saved draft and published update | Pre- and post-publication edits are recorded |
| Tracked fields | Title, author, content, excerpt | No promise for other fields |
| Storage | Posts table, as child records | Travels with the database backup |
| Deletion | An API function exists, no interface | Cleaning up revisions is not a casual task |
Reading the revisions screen
Reaching it
To view revisions you open the Settings sidebar, pick the Page or Post tab and click the number next to Revisions. According to the documentation, from WordPress 7.0 that opens a new revisions screen, while WordPress 6.9 and earlier open the classic screen. Version details in documentation change, so check your site's version and the current page before you write procedures for your team.
Colors and patterns
On the new screen, colored markers next to the scrollbar show where changes happened and how large they are. Added blocks are solid green, removed blocks are red with forward-slanting diagonal stripes, and modified blocks are yellow with backward-slanting diagonal stripes. A Show changes icon toggles the highlighting. The stripe patterns mean the difference does not depend on color alone, which helps a reviewer who cannot tell the colors apart.
Comparing any two versions
The classic screen shows a side-by-side comparison of the HTML version of the content. Its Compare any two revisions mode gives the slider two handles, one for the version you compare from and one for the version you compare to. For guest posts this is the quickest way to see everything that changed between the approved text and the current text. The documentation adds that comparison diffs are currently rendered in text or HTML view, not as rendered output.
| Task | How | Use in guest post review |
|---|---|---|
| See the latest edit | Drag the slider back one step | Check the editor's last pass |
| Compare two versions | Classic screen, two-handle mode | Approved version versus current |
| Undo a bad edit | Select the version, click Restore | Reverse a mistaken change |
| Read clean text | Turn off Show changes | Proof the final wording |
Autosave: what it is and is not
The documentation says there is at most one autosave per user for any given post, that a new autosave overwrites the old one, and that in multi-user setups one autosave is stored per user. Autosaves do not overwrite published content; they are stored as a special type of revision and are marked with an Autosave label in the timeline. If a browser crashes or a connection drops, WordPress warns you on return that it holds a backup and offers a restore link.
The consequence for an editor is simple. An Autosave row is not an approval. Because one user's autosave replaces the previous one, intermediate states do not pile up, but they also vanish when the next autosave arrives. Mark the approved version by an explicitly saved revision, and name that revision in the approval note.
Capping revisions: the trade-off
How the cap works
The documentation names two ways to limit stored revisions: the wp_revisions_to_keep filter for developers and a WP_POST_REVISIONS definition in wp-config.php. For WP_POST_REVISIONS, true (the default) or -1 stores every revision, false or 0 stores none apart from one autosave per post, and an integer above zero stores that many revisions plus one autosave per user. The documentation also says old revisions are deleted automatically when the post is updated again.
That last sentence is the editorial risk. With a cap, early versions disappear as later corrections pile up. If you will ever need the first approved version for a dispute or a comparison, it may no longer be in the list.
| WP_POST_REVISIONS | Meaning in the documentation | Editorial risk |
|---|---|---|
| true or -1 (default) | Every revision kept | The table grows; the record stays whole |
| false or 0 | None kept, apart from one autosave | No change log at all |
| Integer above 0 | That many revisions plus autosaves; older ones deleted | First approved version can vanish |
Decision rule: should you cap revisions?
Practical suggestion: do not cap unless database size is a real problem. If you do cap, choose a number that covers every round a guest post can go through (author draft, editor pass, author reply, final approval and post-publication fixes) and write the number into the policy. Whatever the cap, store a copy of the approved text and the approval note outside WordPress. The documentation recommends no number, so this is a judgement call.
Separate accounts, separate trails
The documentation says the author field is tracked by default, but it does not describe how a revision shows which user saved it. The surest way to leave a trail is therefore a personal account for each person. If editors share one login, nobody can tell from a revision who made a change. Whether to add guest authors as users depends on your policy; if you do not, an editor uploads the draft and the approval note should say so.
A revision also never records why a change was made. Practical suggestion: at the end of each correction round, leave a note line next to the revision: round number, who asked for the change, and the reason. The revision then holds the "what" and the note holds the "why".
| Information | In the revision? | Where to keep it |
|---|---|---|
| Text difference | Yes | Revisions screen |
| Reason for a change | No | Approval note or change log |
| rel decision and its reason | No promise in the documentation | Link table |
| Approver and approval date | Not stated | Approval note |
| The author's request | No | Request log |
Where an outside record is needed
Revisions are a text ledger, not a decision ledger. You need an outside record for approval notes, rel decisions and their reasons, author correspondence, request and dispute history, and versions lost to a revision cap. And since the documentation says there is no interface for deleting revisions, a bulk clean-up becomes a developer task; take a backup first.
To confirm that the live page matches the approved text, use the steps in sponsored content draft versus published version check alongside the revisions screen. A revision does not tell you which version went live; you compare the live page with the approved one yourself.
Dates and revisions
A revision's timestamp and the dateModified on the page are not the same thing. Google's Article structured data page (Opens in a new tab) defines dateModified as the date and time the article was most recently modified, in ISO 8601, and recommends including timezone information. The WordPress revisions page does not say how revisions affect that field. Whether your theme or plug-in derives dateModified from the revision record is something to confirm on your own install.
Link to the editorial calendar
A post with many revisions is a flag on the editorial calendar, because a long run of correction rounds can push the publication date. Add a "rounds" column to your editorial calendar and topic ownership sheet so revision counts become something you can manage.
Policy lines for revisions
- Everyone works under a personal account; no shared editor login.
- Every approval round closes with a note that names a revision.
- If a revision cap exists, its value and reason are written in the policy.
- A copy of the approved text is kept in an outside record.
- Every post-publication change goes into the change log with its reason.
The wider frame for these lines is in how to write a guest post policy page.
Testing your own install
The documentation describes default behavior; your theme, plug-ins and version may differ. A ten-minute test on a scratch post shows what is tracked. Do it on a dedicated draft, not on a live guest post.
- Create a scratch post, write two paragraphs and save.
- Change the title and save; confirm the revision screen shows the title difference.
- Add a link with a sponsored rel value and save; see whether the link and its attribute appear in the comparison.
- Change the category and featured image and save; see whether those changes show. The documentation makes no promise for them.
- Open two revisions in compare mode.
- Restore one revision and check that the link attribute survives in the restored version.
- Write the findings into your policy: which fields revisions track and which need an outside record.
Repeat the test after major updates, since the documentation notes screen changes between versions.
| Test step | Expected result | If it differs |
|---|---|---|
| Title change | Visible in the revision (title is tracked) | Check settings and plug-ins |
| Link and rel change | Appears as part of content | Make the link table the primary record |
| Category and image | No documentation promise | Keep an outside record for these |
| Restore | Selected version becomes a new record | Log the restore in the change log |
Restoring without losing work
A restore returns an older version, which means discarding every correction made after it. Two risks follow for a guest post: a post-publication factual fix can be undone, and a link carrying a rel value can lose it in the older text. Practical suggestion: check the request log before you restore, check the link table afterwards, and log the restore in the change log.
| Action | Risk | Safeguard |
|---|---|---|
| Restore an older revision | Later corrections are lost | Compare first, then restore |
| Restore an autosave | An unapproved draft state goes live | Use only on drafts |
| Lower the revision cap | Old revisions are deleted | Copy the approved text out first |
| Bulk-delete revisions | The change ledger disappears | Only after a backup |
A round-by-round approval trail
A guest post can pass through several correction rounds, and each round deserves a revision and a note. The flow below is the simplest way to attach the revision history to a decision log. The documentation describes no such flow; it is a practical suggestion.
- The author's draft arrives. The editor saves it and confirms the first revision exists. The note reads "Round 0: author draft".
- The editor applies the checklist. Removed or changed sentences are recorded. Note: "Round 1: two factual sentences removed, reason and source attached."
- The author replies; the corrected text is saved. Note: "Round 2: author reply folded in."
- Link decisions are made and applied. Note: "Round 3: rel values applied, link table updated."
- At final approval the editor selects the last saved revision in the timeline and names it in the approval note with its time and the account that saved it.
- Every post-publication change gets a new note line with the requester and the reason.
| Round | What the revision shows | What the note must hold |
|---|---|---|
| 0: Author draft | The first text | Source of the file and the uploading account |
| 1: Editor check | Removed and changed sentences | Reason and source |
| 2: Author reply | The new text | Date of the reply |
| 3: Link decisions | Link attribute changes, if tracked | Each link's value and reason |
| Approval | The final saved version | Version time, approver, date |
| After publication | Each change | Requester, reason, date decision |
Naming a version
Revisions have no names of their own; they are told apart by time and by the account that saved them. In the approval note, cite a version by its time and account. Avoid relative wording such as "the latest version": a week later "latest" points at a different record. If you need more certainty, keep a copy of the approved text in an outside record and put the date in its file name.
Should the guest author be a site user?
Adding the author as a user makes the revision trail richer but adds security and administration work. The documentation gives no recommendation either way.
| Approach | Effect on the revision trail | Cost |
|---|---|---|
| Author is added as a contributor-level user | The author's saves may appear under their own account; test on your install | Account management, permission limits, password security |
| Author emails the draft; the editor uploads it | Every record sits under the editor's account | The author's input must be separated in the note |
Practical suggestion: write the permission boundary down. An author account, if you create one, should reach only that author's own drafts and have no publishing rights. Without an account, put the author's name and the date of submission into the note at upload.
Revisions and the date readers see
Readers do not see the revision list. They see the date on the page and, if you add one, an update note. So a policy has to decide how revision counts relate to what is shown. If every save moves the date, the date loses its meaning; if no save ever moves it, an important correction never reaches the reader. Practical suggestion: tie the date decision to the effect of the change on content and log that decision with the change. Google's Article page gives no update threshold for dateModified, so the threshold sits in your policy.
Dates after a restore
When you restore a revision, the modified date on the page may also change; whether it does depends on how your theme or plug-in produces the value, and the documentation does not say. After any restore, check the visible date and the structured data, and fix them if they no longer match the true state of the content.
Misconceptions to clear up with the team
| Misconception | What the documentation says |
|---|---|
| "If revisions exist, everything is recorded" | By default title, author, content and excerpt are tracked |
| "A revision means approval" | A revision is a record; approval is set by a note |
| "An autosave is a saved version" | An autosave is a special revision type and the next one overwrites it |
| "A cap keeps the old versions" | Older revisions are deleted automatically as the post is updated |
| "I can delete revisions easily" | There is no interface for deleting them |
Settings checklist
- Are revisions on? WP_POST_REVISIONS is not false or 0.
- If there is a cap, does it cover the number of correction rounds?
- Does each editor use a personal account?
- Is access to the revisions screen limited to authorised editors?
- Does the database backup include revisions?
- Does the approval note carry the revision's time and account?
- Are link decisions in a separate table?
- Are post-publication changes entered in the change log?
Revision history versus a version comparison
The two ideas are easy to confuse. The revision history is the edit history of the post inside the site. A version comparison checks whether the approved text and the live text are the same. The history shows what happened inside; the comparison shows what is outside. Neither replaces the other: a revision list can be complete while the live page differs from the approved text because of a plug-in or a cache. So the approval flow lists two separate steps, the record of the revision and the comparison of the live page.
| Question | Answered by |
|---|---|
| How did the text change inside the site? | The revisions screen |
| Which version was approved? | The approval note |
| Does the live page match the approved text? | The live page comparison |
| Why was a change made? | The change log |
Example scenario: a photography blog
Example scenario: A photography blog accepts a guest post from a camera-strap maker's founder titled "Carrying weight on long walks." The author sends the draft by email, so the editor uploads it under her own account and states that in the approval note. Round one removes two unsupported claims about comfort. Round two folds in the author's reply. Round three adds sponsored to the shop link and a disclosure sentence at the top. After each round the editor writes the round number and the revision's time into the note. The site caps revisions at a small number, so after two post-publication fixes the first version disappears from the list; the copy attached to the approval note and the outside record cover the gap. When a fix later has to be reversed, the editor checks the request log first, restores a revision and confirms the sponsored value is still on the shop link.
| Round | Change | Record |
|---|---|---|
| One | Two comfort claims removed | Approval note: reason and source |
| Two | Author reply folded in | Revision time and request log |
| Three | sponsored added to the shop link | Link table |
| After publication | Two small fixes | Change log; first version kept outside |
Frequently Asked Questions
Are WordPress revisions enough as a change record for guest posts?
They cover the text difference. They do not carry the reason for a change, a rel decision or an approval note. The documentation says title, author, content and excerpt are tracked by default, so keep decision records outside.
What happens if I cap the number of revisions?
According to the documentation, an integer above zero stores that many revisions plus one autosave per user, and older revisions are deleted automatically when the post is updated again. The first approved version can disappear.
Does autosave change published content?
The documentation says autosaves do not overwrite published content. They are stored as a special type of revision, and there is at most one per user per post.
Can I delete revisions from the dashboard?
The documentation says there is an API function for deleting revisions but no interface for it. Bulk cleanup may need a developer, and you should take a backup first.
Can I compare two non-adjacent revisions?
Yes, in the classic revisions screen's Compare any two revisions mode, which gives the slider two handles. From WordPress 7.0 the new screen opens first, and you can reach the classic one from the sidebar. Version details can change.
Does a revision decide the dateModified value?
The WordPress revisions page does not say. Google's Article page defines dateModified as the most recent modification date and time. Confirm how your theme or plug-in produces the value on your own site.
Conclusion
Keep revisions on, give each person a personal account, tie every approval round to a named revision and a note, and keep decisions that revisions cannot hold (reason, rel, approval) in an outside record. If you cap revisions, make sure the first approved version survives.
If you want a ready workflow for guest post placements, the guest post service page lists the options and publishing terms.
Post a comment
Please log in to leave a comment. Login