How to Bulk Find and Replace Content in WordPress

This guide shows you how to find a piece of text, a link, or an image on your WordPress site and replace it everywhere at once, instead of opening and editing every post by hand. It is the tool you reach for after a rebrand (an old business name becomes a new one), after moving to a new domain, after switching your site from http to https, when a phone number or address that appears on dozens of pages changes, or when a single image used across the site needs swapping. The task goes by several names, including "search and replace", "find and replace", and "bulk replace"; they all mean the same thing. Because WordPress stores some of its settings in a special packed format called serialised data, a careless replacement can quietly corrupt a site, so this guide covers both the safe methods and the one trap you must avoid, and it shows you how to protect alt text and search rankings when you replace images.

Last reviewed: 27 July 2026, against WordPress 7.0.1 (latest stable). This guide is written for Noiz hosting and is kept current against WordPress. It complements, and does not replace, the official WordPress documentation linked below.

Official Documentation Reference

• wp search-replace (WP-CLI command reference): the official reference for the built-in command, including every flag used in this guide and its handling of serialised data.
• wp-cli/search-replace-command (source and readme): technical detail on how the command decodes serialised PHP and JSON, replaces the value, and re-encodes it with correct lengths.
• Migrating WordPress (Advanced Administration): the official guidance on changing a site's URL and moving a site, including its warning about serialised data during a blanket search and replace.
• Alt Text, alternative text for images (Accessibility Handbook): what alt text is for and how to write it, which matters when you replace images site-wide.
• Search and replace plugins (WordPress.org plugin directory): the neutral directory listing where you can compare reputable, serialisation-aware plugins.

Prerequisites

• Administrator access to your site. If you are not sure how to sign in, see how to log in to the WordPress admin dashboard.
• A fresh, tested backup taken immediately before any bulk change. This is not optional: a site-wide replace touches many rows at once, and a good backup is the difference between a five-minute fix and a rebuild.
• For the command-line method, SSH access to your hosting account with WP-CLI available. If your site is on a Noiz managed plan and you do not have shell access, the Noiz support team can run the command for you.
• The exact value you want to find, and exactly what to replace it with, written down. Precision matters: http://yourdomain.com and https://yourdomain.com are different strings.

Understand the Serialised Data Trap Before You Start

WordPress keeps your posts and pages as readable text, which is easy to change. But a large amount of configuration is stored differently. Widget contents, theme options, plugin settings, page-builder layouts, menu items, and many custom fields are saved as serialised data in tables such as wp_options and wp_postmeta. Serialised data is a compact text format that records the exact length of every string it contains.

Here is why that matters. The address http://oldsite.com is stored inside serialised data as s:18:"http://oldsite.com";, where s:18 declares "an 18-character string follows". If a blunt database replacement swaps that address for https://newsite.com, which is a different length, but leaves the s:18 marker untouched, PHP later tries to read 18 characters, reads the wrong number, and the entire setting becomes unreadable. The damage is usually invisible at first. It only surfaces later, when a widget, a theme option, or a page-builder layout suddenly fails to load.

The lesson is simple: never run a raw SQL REPLACE() query (for example directly in phpMyAdmin) against columns that might hold serialised data. The safe tools in this guide do something a raw query cannot: they deserialise the data, make the replacement, then re-serialise it with the length markers corrected. That single difference is what keeps your site intact.

Choose the Right Method

Pick the lightest method that fits the size of the job:

• A few posts: edit them directly in the block editor. This is built into WordPress and needs no plugin.
• Site-wide, no command line: use a reputable, serialisation-aware find-and-replace plugin.
• Site-wide, with SSH: use WP-CLI's built-in wp search-replace command. It is the safest and most capable option.
• Raw SQL: avoid it, except for a single column you are certain holds no serialised data, and only if you fully understand what that column contains.

Method 1: Edit Directly in the Block Editor (Built In)

WordPress has no native, site-wide find-and-replace feature, but for a small, exact set of pages you do not need one. Open each post in the block editor, use your browser's own Find (press Ctrl and F, or Cmd and F on a Mac) to jump to the text, and edit the block by hand. This keeps you in full control and touches nothing else. It stops being practical beyond a handful of pages, at which point move to Method 2 or Method 3.

Method 2: Use a Find-and-Replace Plugin (No SSH Needed)

When you need a site-wide change but do not have or want command-line access, a find-and-replace plugin is the practical route. Several exist in the WordPress plugin directory; the important thing is to choose one that clearly states it is serialisation-aware (it handles serialised data safely) and that offers a dry run or preview. Noiz does not endorse a particular plugin, so compare a few reputable options and read recent reviews before installing.

The general flow is the same whichever you choose:

1. Take a fresh backup first.
2. Install and activate the plugin.
3. Enter the exact text or URL to find, and exactly what to replace it with.
4. Select which database tables to include. Prefer the specific tables you actually need over an "all tables" option; a narrower scope is safer and faster.
5. Leave the guid column out of the replacement. The guid is a permanent identifier used by feed readers, not a link to update, and changing it causes problems (see the URL section below).
6. Run a dry run or preview first, and read the number of matches it reports. If the count is wildly higher or lower than you expected, stop and refine your search string before running for real.
7. Run the replacement, then review the site.

If the plugin exists only to perform this one job, deactivate and remove it afterwards to keep the site lean.

Method 3: Use WP-CLI search-replace (Built Into WP-CLI)

The most reliable method of all is wp search-replace, a command built into WP-CLI. It understands serialised data natively, walks every table for you, and can preview its work before making any change. It needs SSH access to your hosting account. On a Noiz managed plan, if you do not have shell access, ask the Noiz support team to run the command.

Always preview with a dry run first:

wp search-replace 'old-text' 'new-text' --dry-run --report-changed-only

This walks the tables, decodes any serialised values, and reports exactly what it would change, without writing a single row. When the report looks right, run it for real and protect the guid column:

wp search-replace 'old-text' 'new-text' --skip-columns=guid

The flags you are most likely to use, in plain terms:

• --dry-run: preview only. Runs the whole operation and reports, but saves nothing.
• --skip-columns=guid: never rewrite the guid column. Use this on almost every real run.
• --report-changed-only: show only the fields that actually change, which makes the report far easier to read.
• --precise: force WordPress to use PHP rather than a raw database query for the replacement. It is slower but the most thorough for complex serialised data.
• --recurse-objects: also replace values inside serialised PHP objects. This is on by default; you would only pass --no-recurse-objects to turn it off.
• --all-tables-with-prefix or --all-tables: widen the search beyond the tables WordPress registers itself. Use these only when you know a custom or plugin table holds the value you are changing.
• --regex: match using a regular expression for advanced patterns. It is considerably slower, so reach for it only when a plain string will not do.
• --export=changes.sql: write the transformed data to an SQL file instead of touching the live database, so you can inspect it or apply it elsewhere.

As a belt-and-braces step, take a database snapshot you can restore instantly before the real run:

wp db export backup-before-replace.sql

Replace URLs Across the Whole Site (Domain Change or HTTP to HTTPS)

Changing a URL everywhere is the most common bulk replace, and also the one most exposed to the serialised data trap, because themes, widgets, and page builders love to store full, absolute URLs. Handle it with care:

• Match the full URL, including the protocol. For an SSL switch, replace http://yourdomain.com with https://yourdomain.com. For a domain move, replace the old domain with the new one. (yourdomain.com is an example; use your real domain.)
• Use a serialisation-aware method (Method 2 or Method 3). Never do a URL change with a raw SQL replace.
• Always skip the guid column with --skip-columns=guid. The guid uniquely and permanently identifies each post to feed readers. If you rewrite it, subscribers can suddenly see every old post as brand new.
• Watch for variants. A URL can appear with and without www, as http or https, and with or without a trailing slash. Replace the most specific form, and repeat the run for each variant that genuinely exists on your site.

A typical WP-CLI run for an SSL switch looks like this:

wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --dry-run

Remove --dry-run to apply it once the report looks correct. Note that the site's own WordPress Address and Site Address are set separately under Settings > General; a full domain move updates those two fields as well as the content.

Replace Images Site-Wide Without Losing Alt Text or SEO

There are two very different jobs here, and confusing them is exactly where accessibility and search rankings get damaged. Decide which one you actually want before you touch anything.

Option A: Swap the File, Keep the Same Address

If you want the same slot to show a new picture everywhere it appears, replace the underlying media file so that its URL, its media title, and its alt text all stay identical. Media-replace plugins are built for this, and some let you keep the original file name. Because nothing in your content markup changes, every link, every alt attribute, and your existing search rankings are preserved untouched. This is the SEO-safe choice. Afterwards, clear your caches and CDN, and if the new file has different dimensions, regenerate the thumbnails so the resized copies match.

Option B: Point Content at a Different Image URL

If you instead find-and-replace one image URL with a different one across your posts, only the image source (the src) changes. Alt text is stored separately and is not carried along by the swap. The attachment's alt text lives in a field called _wp_attachment_image_alt, and a copy of it is written into each post's markup at the moment the image is first inserted. So a URL swap leaves the old alt attribute sitting in your content. That is fine if the new image means the same thing as the old one, but if the subject has changed, the description no longer matches the picture, which harms both accessibility and SEO. In that case you must update the alt text too.

Two gotchas catch people out:

• Editing alt text in the Media Library does not reach back into old posts. Those posts keep the copy of the alt text that was made when the image was inserted. Updating the Media Library only affects future insertions.
• A careless replace on raw <img> markup can strip the alt attribute entirely. Target the image URL itself, not the surrounding tag, so you never accidentally delete the alt text.

Whichever option you use, run a dry run first and then spot-check a few real pages before you consider the job done.

After Replacing: Verify and Clear Caches

• Purge every cache. Clear the object cache, the page cache, and any CDN. Old text or images very often persist only because a cache is still serving them.
• Regenerate thumbnails if you replaced image files whose dimensions changed, so the resized copies are rebuilt.
• Re-save your permalinks after a URL change: go to Settings > Permalinks and click Save Changes to refresh the rewrite rules.
• Spot-check the serialised areas. Look at the homepage, a couple of inner pages, a page built with your page builder, your widgets, and your menus. Those are the places most likely to reveal a problem, because they are where serialised data lives.
• Search the live front end for any leftover instances of the old value to confirm the change was complete.

Troubleshooting

• The report says zero replacements. Your search string does not match exactly. Check the protocol (http versus https), www versus non-www, a trailing slash, or HTML-encoded characters. Copy the exact string from the source rather than typing it.
• The site shows errors or a blank page after a raw SQL replace. This is almost certainly serialised data corruption. Restore your backup, then redo the change with a serialisation-aware method (Method 2 or Method 3).
• Some instances changed but others did not. The untouched ones are usually inside serialised settings that a non-aware tool skipped, or they are being served from a cache. Re-run with a serialisation-aware method and then clear all caches.
• Feed subscribers suddenly see every old post as new. The guid column was changed. Restore the guid values from your backup, and never include guid in a replace again.
• Images still show the old picture. It is cached. Purge the page cache and CDN, then hard-refresh your browser.
• Alt text is missing or wrong after an image swap. Re-enter the alt text in the affected posts, and set it in the Media Library for future insertions. Remember that old posts keep the alt text embedded at insert time.
• Far too many things changed. Your match was too broad. Scope the search to the full, specific string (include the protocol and the domain), and run a dry run again before applying.

If you would rather not run a site-wide change yourself, the Noiz support team can take a verified backup and carry out a safe, serialisation-aware search and replace for you. Open a support ticket with the exact text or URLs to change, note whether it involves your domain or your images, and a technician will make the change and confirm the result.