Use a serialized-data-aware WordPress tool when replacing an old domain in stored settings and content. Preview the exact replacement and table scope first. A broad SQL REPLACE can damage serialized values or change unrelated email addresses, logs and integration settings.
Define the replacement contract
Write down the old origin, new origin and any path change. Replacing https://old.example with https://new.example is narrower than replacing every occurrence of old.example. The broader string can also affect email addresses and historical records that should remain unchanged.
Create a database backup outside the public web root and confirm that it can be restored. Rehearse on an isolated copy with outbound email, webhooks and payments controlled. A staging database replacement should not start sending production integrations to new destinations by accident.
Preview a scoped command
Run commands only from the intended WordPress installation. This example is a preview, not a command to paste unchanged on production:
wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-run --report-changed-only
WP-CLI handles PHP serialized values. Its default table scope is not necessarily every plugin table. Multisite also needs explicit site and network scoping. Inspect the dry-run table list before deciding whether custom tables should be included; do not add --all-tables simply to maximize replacements.
Exact origins: Old and new values reviewed. Table scope: Intended site only. Dry-run report: Surprising matches investigated. Live pages: Content, assets and forms checked. Explanatory checklist, not a customer test result.
Review the surprising matches
| Match location |
Decision to make |
| Post content and builder settings |
Usually relevant to the rendered site |
| Payment/webhook configuration |
Review ownership and destination separately |
| Audit logs or old order notes |
Decide whether historical evidence should stay unchanged |
| Another site's tables |
Exclude unless that site is explicitly in scope |
Keep GUIDs out of a routine domain migration unless you have a separately justified plan. They identify feed items and are not ordinary links to repair. Avoid dumping matched private data into a shared terminal log merely to count replacements.
After the preview is approved, execute the same narrowly scoped replacement without the dry-run flag during the planned change window. Save the summary counts. Do not change the scope between review and execution without another preview.
Check what the database operation does not fix
Configuration files, generated CSS, caches and external integrations can retain URLs outside the selected tables. Rebuild only the relevant generated assets and purge affected caches after stored content is correct. For browser-blocked HTTP assets, follow the mixed-content guide.
Verify with actual page types
Open a normal page, a builder page, a media-heavy page and a form confirmation. Inspect links and asset requests, then rerun the original preview to find remaining matches. A zero count proves only that this exact string is absent from this exact scope, not that the entire migration is complete.
Keep the old-to-new mapping and the approved table list with the migration record. HandL WP can review the replacement scope before a change touches a busy production database.
Reference: WP-CLI search-replace options.
References reviewed October 4, 2026. Examples are explanatory; production changes require an appropriate backup and authorized access.