How to Fix Broken Image URLs After a WordPress Migration

You migrated your WordPress site to a new host, a new domain, or a new CDN — and now images are broken everywhere. Thumbnails missing, wrong domains hardcoded into posts, stale filenames from resized images that no longer exist. This is one of the most common problems after a WordPress migration, and the usual fix — running a SQL find-and-replace on your database — is risky enough that most guides warn you to back up first and pray second.

There’s a better way. StaticQ Media’s Post Content Scanner inspects every post in your database, identifies exactly which image URLs are broken and why, and fixes the ones it can automatically. No regex, no raw SQL, no guessing.

---

Why Images Break After Migration

WordPress stores image URLs as plain HTML inside your post content — the post_content column in wp_posts. When you write a post and insert an image, WordPress saves something like:

<img src="https://oldsite.com/wp-content/uploads/2025/03/photo-300x200.jpg" />

That URL is now baked into your content. WordPress doesn’t update it when things change. So after a migration, several things can go wrong:

Domain change. You moved from oldsite.com to newsite.com but every image URL in every post still says oldsite.com.

CDN switch. You were using a CDN like cdn.oldsite.com or a push CDN service, and those URLs are now dead.

Protocol change. You moved from HTTP to HTTPS (or vice versa) and mixed-content URLs are blocked by browsers.

Resized filenames. WordPress embeds the specific size in the filename (photo-300x200.jpg). If your new theme registers different sizes, or you regenerated thumbnails, those exact files may no longer exist — even though the original photo.jpg is fine.

Deleted and re-uploaded files. During migration cleanup, some images were deleted and re-uploaded with new attachment IDs. The old URLs in posts now point to nothing.

---

The Manual Approach (and Why It’s Dangerous)

The standard advice for fixing WordPress broken images after migration is a database search-and-replace using WP-CLI, a plugin like Better Search Replace, or raw SQL:

UPDATE wp_posts SET post_content =
  REPLACE(post_content, 'oldsite.com', 'newsite.com');

This works for simple domain swaps, but it has real problems:

• Serialized data. WordPress stores serialized PHP arrays in wp_options and wp_postmeta. A naive find-replace changes string lengths without updating the serialization headers, which corrupts the data. Tools like WP-CLI’s search-replace handle this, but not everyone uses WP-CLI.
• Partial matches. Replacing site.com also matches mysite.com or site.com.au. You need exact matching, which means knowing every URL variant in your database.
• Stale sizes aren’t fixed. Even if you fix the domain, URLs like photo-300x200.jpg still point to a file that may not exist anymore. A domain replace doesn’t know about WordPress image sizes.
• No verification. After running the replace, you have no idea if it worked without manually checking posts. There’s no report of what changed or what’s still broken.

---

The StaticQ Approach: Post Content Scanner

StaticQ Media’s Post Content Scanner was built specifically for this problem. Instead of a blind find-and-replace, it reads every post, identifies every image URL, and cross-references each one against your actual media library. Then it tells you exactly what’s wrong and fixes what it can.

Here’s the step-by-step process.

Step 1: Install StaticQ Media and Register Your Library

Install StaticQ Media from Plugins > Add New (search for “StaticQ Media”) or download it from WordPress.org.

Once activated, go to StaticQ > Media Manager and click Register Unregistered Attachments. This creates tracking records for every image in your media library. Registration is read-only — it indexes what’s there without modifying anything.

This step matters because the Post Content Scanner needs to know what images exist in your library in order to identify which URLs in your posts are valid and which are broken.

Step 2: Run the Post Content Scanner

Navigate to the Post Content Scanner section and click Scan Post Content.

The scanner reads through every post, page, and custom post type in your database. For each <img> tag and image URL it finds, it checks:

• Is the domain correct? Does it match your current site URL?
• Does the referenced attachment still exist in the media library?
• Does the specific file (including the size suffix like -300x200) exist on disk?
• Is the URL using the correct protocol (HTTP vs HTTPS)?

This runs in batches, so it won’t time out even on sites with thousands of posts.

Step 3: Review the Results

When the scan completes, you’ll see a categorized report. Each issue type tells you something different:

• Wrong domain — The image URL references oldsite.com instead of newsite.com. The attachment exists, the file exists, just the domain in the post content is wrong. Auto-fixable.
• Stale size — The URL references a specific image size (e.g., photo-300x200.jpg) that no longer exists on disk, but the parent attachment is valid and other sizes are available. Auto-fixable — StaticQ rewrites the URL to use a valid size.
• Deleted attachment — The URL doesn’t match any attachment in the media library. The image may have been deleted during migration. Requires manual review.
• Broken URL — The URL is malformed or points to an external resource that’s no longer available. Requires manual review.

For each issue, you can see which post is affected and what the problematic URL is.

Step 4: Back Up Your wp_posts Table

Before fixing anything, back up your wp_posts table. The Fix All operation modifies post content directly, and while it’s been tested extensively, a backup takes 30 seconds and gives you a rollback path.

You can do this with your hosting panel’s database export, WP-CLI (wp db export --tables=wp_posts), or phpMyAdmin.

Step 5: Fix All

Click Fix All to automatically rewrite the fixable URLs.

For wrong domain issues, StaticQ updates the domain portion of the URL to match your current site URL. For stale size issues, it rewrites the URL to reference a valid size that exists on disk.

The fix operates on post content only — it doesn’t touch wp_options, wp_postmeta, or serialized data. This means it avoids the serialization corruption risk that plagues raw SQL replacements.

Step 6: Verify

Open a few of the posts that had issues and confirm the images are loading. Check:

• Do images display correctly on the front end?
• Are the URLs in the page source pointing to the correct domain?
• Do any posts still show broken image icons?

If you enabled StaticQ’s front-end delivery, images will be served as <picture> elements with WebP sources through your CDN — so you’re not just fixing broken URLs, you’re upgrading the delivery at the same time.

---

What the Scanner Can and Can’t Fix

To set expectations clearly:

Auto-fixable (Fix All handles these):

• Wrong domain — oldsite.com rewritten to newsite.com
• Stale image sizes — -300x200.jpg rewritten to a valid size that exists on disk

Requires manual review:

• Deleted attachments — the image was removed from the media library entirely. You’ll need to re-upload it or remove the image from the post.
• Broken URLs — malformed or external URLs that don’t correspond to any local attachment. Review each one and update the post manually.

The scanner gives you a clear list of the manual-review items so you’re not hunting through posts blindly. Even if it can’t auto-fix everything, knowing exactly which posts have problems — and what kind of problem — saves hours compared to manual spot-checking.

---

Don’t Let Broken Images Linger

Broken images hurt your SEO, frustrate your visitors, and make your site look neglected. After a migration, the temptation is to fix the obvious pages and hope the rest are fine. They usually aren’t — stale URLs hide in old blog posts, archived pages, and custom post types you forgot about.

StaticQ Media’s Post Content Scanner finds all of them in one pass, fixes the straightforward cases automatically, and gives you a checklist for the rest. It’s free, it doesn’t require WP-CLI or database access, and it’s safer than a SQL find-and-replace.

Get StaticQ Media — Free on WordPress.org →