A brand name changes, a product gets renamed, a URL you reference everywhere finally moves, and now an old phrase is scattered through years of posts and pages. Opening each one to fix it is the definition of tedious, and the search-and-replace plugins that reach into the whole database are the ones people are most nervous about running, because a bad match there can corrupt serialized data you never see.
This stays narrow on purpose. It edits the readable content of posts and pages, shows you every hit first, and does the replacement literally.
I need to change [old phrase] to [new phrase] everywhere it appears in myposts and pages. Start read-only: search the content for [old phrase] andshow me every post and page it turns up in, with the surrounding line so Ican see the context. Change nothing yet.
Wait for my go-ahead. Only after I approve, run a literal find-and-replaceof [old phrase] with [new phrase] in each post and page body, in smallbatches, showing me each batch before it saves. Edit only the body text,leave the status alone so nothing republishes, and keep it reversiblethrough each post's revisions. When you finish, list every post and page youchanged.Why this is safe to run, and exactly how far it reaches
The first pass is a read. The search shows you every post and page the old phrase lives in, with the surrounding line, so you approve the real list before anything saves. The replacement is literal, one exact string for another, so it will not fuzzy-match its way into text you meant to keep, and each edit saves as a revision without touching the status, so nothing republishes and any change rolls back from the editor.
Be clear on the scope, because this is where the honest limit sits: this edits the content body of posts and pages only. It does not reach into the database directly, site options, widgets, navigation menus, theme or plugin settings, or values stored as serialized data. If your phrase lives in a widget, a theme option, or a page-builder’s stored layout, this recipe will not find it or change it, and that is by design, since those are exactly the places a blunt database replace does its damage. The content write ability stays off until you enable it, every call is checked against the bound user’s capability, and each edit is written to the Activity Log with the post or page it changed.
Already connected? Skip the paste. Ask your agent for the “find and replace across your posts and pages” recipe, give it the old and new phrase, and it runs the same search-approve-replace flow on your own install.