After a migration where anything about your site’s address changed — a new domain, a move to HTTPS, or even a temporary URL — your database will still contain the old URLs, buried in settings and content, quietly pointing your migrated site back at the old location. The fix is a search-and-replace on the database, swapping every old URL for the new one. But there is a serious trap: WordPress stores some data in a ‘serialised’ format that a naive find-and-replace corrupts, so this must be done with the right tool. This guide shows you how, safely.

You will learn why URLs get stored in the database, what a search-and-replace does, the critical danger of serialised data, the safe tools and methods to use, exactly what to search and replace, and how to verify the result. By the end you will be able to fix the stored-URL problem correctly, avoiding the corruption that a careless approach causes.

Why URLs get stored in the database

WordPress and similar systems store a surprising number of URLs inside the database, not just in the files. Your site’s home and site URL are stored as settings; links within your posts and pages are saved as full URLs in the content; image references, widget settings, theme and plugin options, and configuration all commonly contain absolute URLs pointing to your site. The database is full of references to your own address.

This is fine while your address stays the same, but the moment anything about your URL changes in a migration — a new domain, a switch from http to https, or even accessing the site temporarily via a different URL — all those stored references still point to the old address. The result is a migrated site that pulls images from the old host, links back to the old location, or misbehaves, because internally it still thinks it lives at the old URL.

So the reason a search-and-replace is needed is that URLs are baked into the database, and a migration that changes the address leaves those baked-in URLs stale. Simply changing the site’s main URL setting is not enough, because the old URL persists in countless other places throughout the content and settings. A thorough search-and-replace across the whole database is what updates every one of those stale references to the new address.

What a search-and-replace does

A database search-and-replace does exactly what it sounds like: it searches through all the data in your database for every occurrence of a specified string (your old URL) and replaces it with a new string (your new URL). Run across the entire database, it updates every stored reference to the old address in one operation — the home and site URL settings, the URLs in your content, image references, plugin and theme options, everything.

This is the comprehensive fix for the stale-URL problem, because it reaches all the places the old URL is stored, not just the obvious main setting. After a correct search-and-replace, your database no longer contains any references to the old address; everything points to the new one, so the migrated site loads its images, follows its links, and behaves as if it had always lived at the new URL.

So a search-and-replace is the tool that makes a URL-changing migration actually work internally. Changing the visible site URL is easy; the search-and-replace is what catches all the hidden old URLs throughout the database that the visible setting misses. It is a standard, essential step whenever your address changes in a migration — but the way you run it matters enormously, because of a trap in how some of that data is stored.

The critical danger: serialised data

Here is the trap that catches the unwary: WordPress stores some data in a ‘serialised’ format, and a naive find-and-replace on serialised data corrupts it. Serialised data is a way of storing complex structures (like arrays of settings) as text, and part of that format records the exact length of each stored string. If you change a URL’s length with a blind replace — and a new URL is almost always a different length than the old — the recorded length no longer matches, and the serialised data breaks.

When serialised data breaks, the settings or options stored in it become unreadable, which can break plugins, themes, widgets, and configuration in confusing ways — a far worse problem than the stale URLs you were trying to fix. This is why you must never run a simple find-and-replace directly on a raw database dump (the .sql file) or with a naive SQL query: it will silently corrupt any serialised data containing your URL.

So the single most important rule of a database search-and-replace is: use a tool that understands serialised data and updates the recorded lengths correctly as it replaces. Such tools replace the URL and fix the serialisation so nothing breaks. Understanding this danger is what separates a safe search-and-replace from a destructive one — and it is why the choice of tool, covered next, is not optional but essential.

The safe tools and methods

Because of the serialised-data danger, you must use a serialisation-aware tool for a database search-and-replace. Several safe options exist:

• A dedicated search-replace script: a well-known standalone PHP script exists specifically for safe, serialisation-aware search-and-replace on WordPress databases — you upload it, run it, replace, then delete it.
• A migration or utility plugin: reputable migration plugins and dedicated search-replace plugins handle serialised data correctly as part of their operation.
• WP-CLI: if you have command-line access, WordPress’s command-line tool has a search-replace command with a flag to handle serialised data safely.
• Migration tools’ built-in handling: full migration tools (like Duplicator or All-in-One WP Migration) do the URL search-and-replace safely as part of their deployment, so you may not need a separate step.

Any of these safely handles serialised data; what you must not do is a naive find-and-replace in the raw .sql file or a plain SQL UPDATE query, which corrupts serialised data. If you used a full migration tool that already did the URL replacement during deployment, you may not need a separate search-and-replace at all. Otherwise, pick one of these safe tools — the standalone script and WP-CLI are common choices for a manual migration — and you can replace URLs throughout the database without any risk of corruption.

What to search and replace

With a safe tool chosen, you specify what to find and what to replace it with — and precision here matters. The ‘search’ is your old URL and the ‘replace’ is your new URL, entered in a consistent format. Use the full URLs without a trailing slash (for example, searching the old domain’s base URL and replacing with the new domain’s base URL), so the replacement catches URLs throughout the content and settings consistently.

Be mindful of the exact form of the URLs. If you are only changing the domain, search the old domain and replace with the new. If you are moving from http to https on the same domain, search the http version and replace with the https version. Match the protocol and format of how the URLs are actually stored, so the replacement finds them — searching for the wrong form (with or without www, or the wrong protocol) can miss stored references.

So enter the old and new URLs precisely, in the form they are stored, to catch all references. It is often wise to run the replacement for the base URL, which cascades to every longer URL built on it (since replacing the domain portion updates every URL containing it). After running it, the tool typically reports how many replacements it made across which tables — a useful confirmation that it found and updated the stale references. Getting the search-and-replace strings right ensures the operation actually catches the old URLs it is meant to fix.

Verifying the result

After running the search-and-replace, verify it worked and that nothing broke, because this operation touches data across the whole database. The first check is the tool’s own report: a good search-replace tool tells you how many replacements it made and in which tables, confirming it found and updated the old URLs — a report of zero replacements when you expected many suggests you searched for the wrong form of the URL.

Then check the site itself (privately, before cutover, via a hosts-file preview): load the migrated site and confirm that images now load correctly (from the new location, not the old host), internal links point to the new URL, and everything displays properly. Missing images or links back to the old site would indicate the replacement did not catch some references, prompting you to re-check the URL forms you searched for.

Crucially, also confirm nothing was corrupted — check that plugins, widgets, and theme settings still work, since these are where serialised data lives and where a bad replace would show damage. If you used a serialisation-aware tool, they should be fine; verifying confirms it. So verify at three levels: the tool’s replacement report, the site’s URLs now pointing to the new location, and the settings-heavy features still working. All three confirming means your search-and-replace succeeded — the stale URLs are fixed and nothing broke, completing the URL half of your migration’s reconnection.

FAQs

How do I run a search-and-replace on my database?

Use a serialisation-aware tool — a dedicated safe search-replace script, a reputable migration/search-replace plugin, or WP-CLI’s search-replace command — never a naive find-and-replace in the raw .sql file or a plain SQL query. Enter your old URL as the search and your new URL as the replace, in the exact form they’re stored, run it across the whole database, then verify the tool’s report, the site’s URLs, and that settings-heavy features still work.

Why do I need a search-and-replace after migrating?

Because WordPress stores URLs throughout the database — the site’s home/site URL settings, links in content, image references, and plugin/theme options all commonly hold absolute URLs. If your address changed (new domain, HTTP to HTTPS, or a temporary URL), those stored URLs still point to the old location, making the migrated site pull images from the old host or link back to it. A search-and-replace updates them all.

What is the danger with serialised data?

WordPress stores some data (like arrays of settings) in a ‘serialised’ format that records the exact length of each string. A naive find-and-replace changes a URL’s length without updating that recorded length, breaking the serialised data — which corrupts plugins, themes, and settings in confusing ways. That’s why you must use a serialisation-aware tool that fixes the lengths as it replaces, never a blind find-and-replace.

What tools safely do a database search-and-replace?

A dedicated standalone search-replace PHP script (serialisation-aware), reputable migration or search-replace plugins, or WP-CLI’s search-replace command (with its serialisation-safe handling). Full migration tools like Duplicator or All-in-One WP Migration also do it safely during deployment, so you may not need a separate step. Never use a plain find-and-replace on the .sql file or a raw SQL UPDATE — those corrupt serialised data.

What exactly should I search and replace?

Your old URL as the search, your new URL as the replace, in the exact form they’re stored — matching protocol and www usage. If only the domain changed, search the old domain and replace with the new; for HTTP to HTTPS, search the http version and replace with https. Use the base URL (no trailing slash), which cascades to every longer URL built on it. Searching the wrong form can miss references.

How do I verify the search-and-replace worked?

Check three things: the tool’s report (how many replacements it made and where — zero when you expected many means you searched the wrong URL form); the site itself (images loading from the new location, links pointing to the new URL, everything displaying); and that settings-heavy features (plugins, widgets, theme options) still work, since those hold serialised data where a bad replace would show damage. All three confirming means it succeeded.

The bottom line

A database search-and-replace is the step that fixes the hidden-URL problem every address-changing migration creates: because WordPress stores URLs throughout the database — in the home and site settings, in your content’s links, in image references, and in plugin and theme options — a migration to a new domain, to HTTPS, or even via a temporary URL leaves all those stored references pointing at the old location, so the migrated site pulls images from the old host and links back to it. A search-and-replace across the whole database updates every stale reference to the new address in one operation, which is what makes a URL-changing migration actually work internally, since changing only the visible site URL misses the countless hidden ones.

The one thing that makes this step dangerous rather than routine is serialised data: WordPress stores some settings in a format that records each string’s exact length, and a naive find-and-replace changes a URL’s length without updating that recorded length, corrupting the data and breaking plugins, themes, and settings in confusing ways. That is why you must never run a plain find-and-replace on the raw .sql file or a bare SQL query, and must instead use a serialisation-aware tool — a dedicated safe search-replace script, a reputable plugin, or WP-CLI’s search-replace command — that fixes the lengths as it replaces (full migration tools do this during deployment, so you may not need a separate step). Enter the old and new URLs precisely in the form they are stored, run the replacement across the whole database, and then verify at three levels: the tool’s replacement report, the site’s URLs now pointing to the new location, and the settings-heavy features still working. Use the right tool and verify, and the stale-URL problem is cleanly fixed with no corruption — the reconnection half of a URL-changing migration, done safely.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A database search-and-replace updates the old URLs WordPress stores throughout its database (settings, content links, image refs, plugin/theme options) after an address change. The critical rule: WordPress’s serialised data breaks under a naive find-and-replace, so use a serialisation-aware tool (a safe search-replace script, a reputable plugin, or WP-CLI), never the raw .sql file or a plain SQL query. Enter old/new URLs precisely, then verify URLs and settings still work.