An SSL certificate can be working correctly while the site still triggers mixed-content warnings. WordPress may retain old HTTP addresses in posts, media records, widgets, builder layouts, and plugin settings, so those stored references need a careful, serialization-aware update.
A redirect alone may not fix every saved URL. Old addresses can remain in post content, theme options, widgets, and page-builder data. Replacing them with a plain SQL command can also damage serialized values.
Confirm the HTTPS site first, take a database backup, preview the exact URL change, and apply it only after reviewing the affected tables. Redirects, caches, and the browser console still need separate checks afterward.
- HTTP and HTTPS in simple terms
- Why old HTTP URLs remain
- What mixed content means
- What to do before you replace HTTP URLs
- Replace URLs with a WordPress tool
- Use WP-CLI for search and replace
- Why direct SQL can be risky
- Check WordPress URLs and redirects
- Replace HTTP URLs, then test the whole site
- The correct order of work
HTTP and HTTPS in simple terms
HTTP carries data between a browser and a server. HTTPS adds TLS encryption and helps the browser confirm that it is talking to the intended server.
The certificate makes HTTPS possible, but it does not rewrite every address stored in the database. A page loaded from HTTPS can still request http://example.com/image.jpg.
Why old HTTP URLs remain
WordPress stores URLs in more places than post content. Menus, widgets, theme settings, page-builder layouts, custom fields, and plugin options can all contain full addresses. Identify whether each remaining HTTP request comes from the database, a theme file, a CDN, or an external service before changing it.
- Images inserted before SSL was enabled,
- Elementor or other builder data,
- Theme customizer settings,
- Menu and widget links,
- External scripts and fonts.
Some values are ordinary text. Others are serialized, which means PHP stores both the value and its length. Safe tools update both.
What mixed content means
Mixed content appears when an HTTPS page requests an HTTP resource. A browser may warn about passive content such as an image and block active content such as JavaScript.
If a page loses its layout and the console reports “Blocked loading mixed active content,” a CSS or JavaScript URL may still use HTTP.
What to do before you replace HTTP URLs
- Create a full database backup.
- Write down the exact old and new URLs.
- Check whether the site uses www.
- Run a dry run before changing data.
- Review the tables and match count.
http://example.comand http://www.example.comare different search values. Use the address that actually exists in the database.
Replace URLs with a WordPress tool
A search-and-replace tool that understands serialized data is the easiest option for most users.
- Enter the complete old URL.
- Enter the complete HTTPS URL.
- Run a dry run.
- Check the affected tables and number of matches.
- Confirm the backup, then run the real replacement.
- Keep the result or history for later reference.
Do not replace the word httpacross the entire database. That can affect external services and text that should not change.
Use WP-CLI for search and replace
With SSH access, begin with a dry run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-runIf the results are correct, remove --dry-run:
wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefixThe official WP-CLI search-replace documentation lists the available options.
Why direct SQL can be risky
A simple SQL REPLACE()query can change plain text, but it does not update the length stored inside serialized PHP data. When the old and new URLs have different lengths, a theme or plugin option can become unreadable. Use a serialization-aware tool so WordPress can still decode those values after the address changes.
Use direct SQL only when you fully understand the target column and have tested the exact operation on staging.
Check WordPress URLs and redirects
Open Settings → Generaland confirm that WordPress Address and Site Address use HTTPS. If those values are defined in wp-config.php, the fields may be locked.
Keep one clear permanent redirect from HTTP to HTTPS. Conflicting rules in the host, CDN, and .htaccesscan create a loop. You can also review certificate, redirect, and mixed-content status with AIOWS SSL Manager.
Replace HTTP URLs, then test the whole site
- Open key pages in a private window.
- Check the browser Console and Network panels.
- Test forms, login, checkout, and account pages.
- Clear page cache and CDN copies.
- Search the page source for the old domain.
If a few URLs remain, identify their source before running another database-wide replacement. A theme file or external service may be responsible.
ALL IN ONE WP SETTINGS · REPLACE MANAGER
Preview and apply WordPress URL changes with confidence
AIOWS Replace Manager brings dry runs, serialization-aware replacement, and a reviewable operation history into WordPress. For an HTTP-to-HTTPS conversion, that means the exact domain pair and the expected scope can be checked before any database value changes.
Enter the complete HTTP and HTTPS URLs rather than broad fragments such as http. Run the preview, review the match count and affected tables, and inspect whether the results belong to the site. Once the scope is correct and a restorable backup is available, apply the replacement. Serialization handling matters for widgets, theme options, page-builder layouts, and plugin settings whose encoded lengths must change with the URL.
After the write, use the operation history to confirm what was run, then validate the site itself. Open representative pages and editors, inspect the browser console, and test login, forms, checkout, and account routes. Replace Manager updates stored database values; it does not install the certificate, decide whether an external HTTP link should change, repair a URL hard-coded in a theme file, or configure the HTTP-to-HTTPS redirect. Those checks remain separate parts of the HTTPS rollout.
- Preview matches before any database value changes.
- Protect serialized WordPress data during replacement.
- Review completed operations in a clear history.
- Use the same workflow for HTTPS, domain, and path changes.
The correct order of work
Install the certificate, confirm the WordPress addresses, take a backup, and preview the exact HTTP-to-HTTPS replacement. Apply it with a serialization-aware tool only after the match list looks correct, then test redirects, cached pages, and mixed content across the site.
For larger migrations, see searching and replacing URLs after migrationand protecting serialized data during replacement.
