Change your site’s domain safely with AI
Move to a new domain by replacing the old URL everywhere in your database, with a dry run first and a backup before the real run.
Prerequisites
A connected site and a full backup taken before the real replacement runs.
Help me move [your site] from [https://olddomain.com] to [https://newdomain.com] by replacing the old URL across my database. I have taken a full backup. 1. First run a dry run only. Search for the old domain across all tables, handle serialized data safely, and show me the per-table count of what would change. Do not write anything yet. 2. Let me review the report. 3. After I approve, run the real replacement across all tables, still handling serialized data safely, and skip the guid column so feeds do not break. Then confirm my siteurl and home settings point to the new domain and tell me how many rows changed. Do not run the live replacement until I have seen the dry-run report and told you to proceed.
Already connected to WPVibe?
Skip the copy-paste. Just ask your AI for the “Change your site’s domain safely with AI” recipe, or describe the task, and WPVibe runs these steps on your own site.
Moving a WordPress site to a new domain is more than pointing DNS at a new server. The old URL is baked into hundreds of places in your database: post content, widget settings, image links, plugin options, and serialized arrays you would never find by hand. Miss a few and you get mixed-content warnings, broken images, and redirect loops that are miserable to chase down. A plain find-and-replace corrupts the serialized data, so the nervousness people feel about this job is well earned.
Your connected AI runs the same search-and-replace that WordPress developers trust, and it handles the serialized data correctly instead of shredding it. The important part is that it runs a dry run first. It counts every place the old domain appears, table by table, and shows you that report before touching a single row. The real replacement is a separate step, and WPVibe holds it behind an explicit approval, so nothing is written until you have read the numbers and said go.
Take a full backup before you start. The dry run is safe to repeat as often as you like, but the live replacement is irreversible without that backup. Paste the prompt, read the dry-run report, and approve the real run only once the counts look right. The guid column stays untouched on purpose, because rewriting it re-breaks feed readers, and leaving it alone is the correct default rather than an oversight.
Outcome
Every reference to your old domain rewritten to the new one across the database, previewed as a dry run and approved before it commits.