Replaced Old URLs
When migrating a WordPress site from a local development environment to a live server, one of the most common challenges is replacing all instances of the old local URLs with the live domain URL.
In my case, I needed to replace https://mnrdsgn.com
with https://mnrdsgn.com
throughout my WordPress database. This post explains the process I followed to ensure a smooth URL migration and avoid broken links.
Step 1: Run wp search-replace
on wp_posts
The first step is to replace the URLs in the wp_posts
table, where the content of your posts (such as URLs in the post content, title, and excerpt) is stored. This is where most of the content-related URLs (like internal links and images) are found.
I ran the following command:
bashCopywp search-replace 'https://mnrdsgn.com' 'https://mnrdsgn.com' wp_posts --skip-columns=guid
This command performs a search and replace on the wp_posts
table, changing all occurrences of https://mnrdsgn.com
to https://mnrdsgn.com
, while skipping the guid
column to preserve permanent post identifiers.
Result:
The command successfully replaced URLs in post_content
, post_title
, and other content-related fields. However, no replacements were made (0 replacements) in my case, likely because the database already had the correct live URLs, or I missed some edge cases.
Step 2: Recursively Replace URLs in Objects
In addition to post content, URLs can also be found in serialized objects in the database, such as settings, widget data, or plugin data. To ensure all URLs were replaced across these objects, I used the --recurse-objects
flag.
bashCopywp search-replace 'https://mnrdsgn.com' 'https://mnrdsgn.com' --recurse-objects --skip-columns=guid
Result:
This ran recursively across all objects in the database, but again, no replacements were made (0 replacements). This indicates that either the URLs had already been replaced, or they were not found in the objects.
Step 3: Replace URLs in wp_postmeta
Next, I ran the search-replace command on the wp_postmeta
table, which contains custom fields and metadata associated with posts. Sometimes, URLs can be stored in this table (for example, if plugins or themes store media links or custom URLs).
bashCopywp search-replace 'https://mnrdsgn.com' 'https://mnrdsgn.com' wp_postmeta
Result:
Again, no replacements were made (0 replacements), which indicated that no URLs needed replacement in this table.
Step 4: Verify and Regenerate Media URLs
After running the search-replace
commands, I checked the media URLs in my posts to ensure they pointed to the correct domain. If any image URLs were still referencing the local URL, I would need to update them manually or use the wp media regenerate
command to regenerate the media URLs.
bashCopywp media regenerate
This step ensures that all image sizes are regenerated and that all media URLs are updated.
Step 5: Verify Other Tables
Sometimes URLs are stored in other tables like wp_commentmeta
, wp_links
, and wp_options
. If you suspect there are still URLs that need to be replaced, you can run the same command on these tables:
bashCopywp search-replace 'https://mnrdsgn.com' 'https://mnrdsgn.com' wp_commentmeta wp_links wp_options
Additional Step: Clear Cache and Test
Finally, I cleared the site cache (if using a caching plugin) and cleared the browser cache to ensure that I was loading the most up-to-date version of the site.
Final Thoughts
Migrating a WordPress site to a live server involves several steps, but replacing URLs in the database is one of the most crucial tasks. By using wp-cli
’s wp search-replace
command, I was able to ensure that all internal URLs pointed to the live site instead of the local environment.
Remember to:
- Run
wp search-replace
across key tables (wp_posts
,wp_postmeta
, etc.). - Regenerate media URLs with
wp media regenerate
. - Check for any hardcoded URLs in your theme or plugin files.
With these steps, your WordPress migration should be smooth, and you’ll have no broken links or missing images!