Update a page safely
Editing an existing page is riskier than creating one: the page is probably published, and a careless update replaces content rather than adding it.
The risk to understand first
An update tool writes the fields it is given. If an assistant sends the content field with a rewritten version of the page, the previous content is gone from the live record — recoverable only from a WordPress revision or a backup.
The danger is not malice; it is an assistant "improving" the whole page when you asked it to change one paragraph.
Before you start
- Allow content writes open.
- The acting user can edit that specific page.
- A backup exists.
- Preferably staging, if the page matters commercially.
Read the page first
Read page 88 and show me its title, status, slug and content.
wp_get_page returns the current record. Two things to confirm:
- It is the page you mean. Ask for the title back; IDs are easy to transpose.
- It is published. Editing a live page has immediate public effect.
For a builder page, also read the authoring context — see Build POM builder content. Rewriting builder content without reading its structure is the fastest way to destroy a layout.
Bound the change explicitly
Change only the opening paragraph. Leave the rest of the content, the title, the slug and the status exactly as they are.
Update the phone number in the contact section. Do not touch anything else.
Naming the fields that must not change is more effective than naming the one that should.
Use a dry run where the tool offers one
Use a dry run first and show me the before and after.
For update tools that support it, this returns a comparison without writing. It is the cheapest way to see whether the assistant understood "change one paragraph" the way you meant it.
Write, then read back
Now apply it, then read the page back and show me what differs from before.
The read-back is not ceremony. It catches content altered by a filter on save, a slug regenerated from a changed title, and a status that moved when it should not have.
Then look at the rendered page
Open the page on the front end. The stored record being correct does not mean the page renders correctly — particularly for builder content, where valid markup can still produce a broken layout.
Check it on mobile too, then purge the cache if the site uses one.
Changing the title
Be aware that the slug is derived from the title on creation. Changing a published page's title does not normally change its URL, but confirm the slug after any title change — a changed URL breaks inbound links and search results.
If the slug must change, plan the redirect before making the change, not after.
Updating several pages
List the pages in the "Services" section with their IDs, then stop.
Get the set first, then work through it in small groups:
Do the first two, show me the results, then stop.
Ask for the current value of each field before it changes, so the conversation holds your undo. See Recover from a failed write.
Common problems
| Symptom | Cause |
|---|---|
| The write is refused | Content write gate closed, or the user cannot edit that page |
| More changed than you asked | The instruction did not name what must stay the same |
| The layout broke | Builder content was rewritten without reading its structure |
| The URL changed | The slug was regenerated from a new title |
| The old content is gone | Check WordPress revisions, then the backup |
| The site still shows the old version | Cache not purged |