Updating WordPress URLs from HTTP to HTTPS is the cleanup step that stops browsers, feeds, and plugins from continuing to request stale plain-HTTP links after the secure site is already live. Leaving the stored URLs behind can keep posts, media, profile links, and admin screens mixed between both schemes even when the web server already redirects visitors to TLS.
The primary public URLs live in the home and siteurl options, which appear in Settings → General as Site Address (URL) and WordPress Address (URL). Older http://// references can still remain in wp_posts, metadata, user profiles, widgets, and plugin-managed tables, so a redirect or proxy change by itself does not rewrite stored content. WP-CLI is the safer correction path because wp search-replace understands serialized data and can limit the rewrite to the correct WordPress table set. The workflow assumes the HTTPS site already works correctly at the web-server, load-balancer, or CDN layer before any stored URLs are rewritten. If /wp-config.php/ defines WP_HOME or WP_SITEURL, update those constants first because they override the database values; use the final public HTTPS URL without a trailing slash, take a rollback dump before any write, and keep the URL rewrite scoped to the old hostname and scheme that are actually being replaced.
===== Steps to update WordPress URLs from HTTP to HTTPS: ===== - Open a terminal session in the WordPress document root and confirm the current public URLs. <code>$ cd /var/www/example.com/public_html $ wp option get home http://www.example.com $ wp option get siteurl http://www.example.com</code>
Run the remaining wp commands from the directory that contains /wp-config.php/. On subdirectory installs, siteurl can differ from home by design.
- Export a rollback dump before changing stored URLs. <code>$ mkdir -p ~/backups/wordpress $ wp db export ~/backups/wordpress/pre-https-url-update-$(date +%Y%m%d%H%M%S).sql Success: Exported to '/home/user/backups/wordpress/pre-https-url-update-20260329120612.sql'.</code>
A fresh SQL dump is the fastest recovery path if the target hostname, replacement scope, or multisite target URL is wrong.
Related: How to back up a WordPress site
- Check whether /wp-config.php/ hard-codes the site URLs. <code>$ grep -nE “WP_HOME|WP_SITEURL” wp-config.php 45:define( 'WP_HOME', 'http://www.example.com' ); 46:define( 'WP_SITEURL', 'http://www.example.com' );</code>
If these constants are present, update them to HTTPS first. They override the database values, so wp option update alone will not change the active URLs, and removing the constants later can expose the older database values again.
- Replace any HTTP WP_HOME or WP_SITEURL constants with HTTPS when they are defined. <file>define( 'WP_HOME', 'https://www.example.com' ); define( 'WP_SITEURL', 'https://www.example.com' );</file>
Skip this step when /wp-config.php/ does not define either constant. Use the final public URL and keep the value free of a trailing slash.
- Review the current home and siteurl values before replacing stored content. <code>$ wp option get home http://www.example.com $ wp option get siteurl http://www.example.com</code>
Both settings should include https:// when updated and should not end with a trailing slash. On subdirectory installs, siteurl can differ from home.
- Update the home option to HTTPS. <code>$ wp option update home 'https://www.example.com' Success: Updated 'home' option.</code> - Update the siteurl option to HTTPS. <code>$ wp option update siteurl 'https://www.example.com' Success: Updated 'siteurl' option.</code>
Running the option updates first makes the primary site URLs correct before the broader replacement pass.
- Run a dry-run search-replace to inventory the remaining stale HTTP references before writing changes. <code>$ wp search-replace 'http://www.example.com' 'https://www.example.com' –all-tables-with-prefix –skip-columns=guid –precise –dry-run –report-changed-only Table Column Replacements Type wp_postmeta meta_value 2 PHP wp_posts post_content 3 SQL wp_usermeta meta_value 1 PHP Success: 6 replacements to be made.</code>
The dry run keeps the database unchanged while showing the exact rows that still need cleanup. If this command returns zero replacements after the home and siteurl updates, the site URLs were the only stale values and the write step can be skipped.
--precise forces the safer PHP pass for serialized data, while --report-changed-only removes unchanged rows from the report. If a plugin stores URLs in a custom table that does not use the normal wp_ prefix, add that table name explicitly instead of widening the rewrite to the whole database.
- Apply the same search-replace command without --dry-run after the replacement list looks correct. <code>$ wp search-replace 'http://www.example.com' 'https://www.example.com' –all-tables-with-prefix –skip-columns=guid –precise –report-changed-only Table Column Replacements Type wp_postmeta meta_value 2 PHP wp_posts post_content 3 SQL wp_usermeta meta_value 1 PHP Success: Made 6 replacements.</code>
Avoid raw SQL string replacement for this job. Serialized option and metadata values can break when string lengths are not recalculated.
Skipping the guid column avoids rewriting feed identifiers. On multisite, target the correct site with --url=https://www.example.com and add --network only when the change is intentionally network-wide.
- Flush the WordPress object cache so updated URLs are served immediately. <code>$ wp cache flush Success: The cache was flushed.</code>
If a caching plugin, host page cache, or reverse proxy is in use, purge that layer from its normal control panel as well.
- Re-run the same dry-run search-replace command until no pending replacements remain for the old HTTP hostname. <code>$ wp search-replace 'http://www.example.com' 'https://www.example.com' –all-tables-with-prefix –skip-columns=guid –precise –dry-run –report-changed-only Success: 0 replacements to be made.</code>
Repeat the check for any second old URL when siteurl and home use different values.
- Verify the active WordPress URLs now return HTTPS. <code>$ wp option get home https://www.example.com $ wp option get siteurl https://www.example.com</code>
Open the front page, a post, and wp-admin over HTTPS and check the browser console for mixed-content warnings. If the dashboard is reachable, Settings → General should also show HTTPS in both URL fields. Remaining HTTP references usually come from plugin-specific settings, page-builder data, or hard-coded theme files that need a targeted follow-up pass.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
