Your Host Gave You SSL. Your Site Still Isn't Secure.
That green padlock icon in the browser bar doesn't mean your WordPress installation is properly configured for HTTPS. It means a certificate exists. Those are two different things — and conflating them is exactly how sites end up with broken checkout pages, insecure REST API endpoints, and mixed content warnings that quietly erode visitor trust and SEO rankings.
Most SSL "setups" stop at certificate installation. The WordPress-level configuration — the part that actually determines how your site serves content — gets skipped entirely. What you get is a half-migrated site: a certificate on the server, HTTP asset URLs hardcoded in the database, and a WordPress core that still thinks it lives at http://.
This guide covers the complete switch — not just the certificate, but the WordPress configuration, the database-level URL changes, the .htaccess redirect rules, and the mixed content cleanup that most tutorials conveniently omit.
The Myth: Enabling SSL Is the Same as Running HTTPS
This is the most common misconception in WordPress SSL setup, and it causes real damage.
Hosting panels — cPanel, Plesk, and managed hosts like Kinsta or WP Engine — make certificate provisioning trivially easy. One click via Let's Encrypt, and you have a valid SSL certificate. That's infrastructure-level SSL. It protects data in transit between your server and the browser.
What it does not do:
- Update your WordPress Site URL and Home URL settings from http:// to https://
- Rewrite hardcoded HTTP asset references in your database (images, scripts, stylesheets)
- Fix your REST API base URL, which exposes endpoints at http:// if left unconfigured
- Set up the HTTPS redirect in .htaccess or at the Nginx config level
- Configure your wp-config.php to force SSL for the admin panel
Until all of that is done, you don't have an HTTPS site. You have a site with a certificate.
What Actually Breaks When You Flip to HTTPS
When you switch WordPress to HTTPS without handling the underlying configuration, several things break simultaneously — and they break quietly, meaning you often won't know until a user reports it or your rankings drop.
Mixed content warnings are the most visible symptom. The browser loads your page over HTTPS but detects resources (images, JavaScript files, embedded iframes) still being requested over HTTP. Modern browsers block mixed content or flag the connection as "not fully secure." Your padlock disappears or shows a warning triangle.
Checkout pages break. In WooCommerce, payment gateways that require a secure connection will refuse to load over a mixed-content page. That's a direct revenue impact — not theoretical.
The WordPress admin panel may redirect loop. If wp-config.php doesn't include the correct HTTPS constants, or if FORCE_SSL_ADMIN is set without a proper redirect in place, the admin login can enter an infinite redirect loop and lock you out.
Cached objects become stale. Object cache (whether you're using Redis, Memcached, or a plugin-based solution) holds HTTP URLs. After switching to HTTPS, cached responses may still serve http:// links, causing continued mixed content warnings even after database updates.
Transients break. WordPress transients stored in wp_options often contain serialized data with hardcoded URLs. If you run a search-and-replace without accounting for serialization, those transients either serve stale data or fail silently.
The Correct Sequence for WordPress SSL Migration
Order matters here. Do this wrong and you're doing it twice.
Step 1: Provision and Verify the Certificate
Before touching WordPress, confirm your certificate is valid and installed at the server level. Use a tool like SSL Labs (ssllabs.com/ssltest/) to verify the certificate chain, expiry date, and protocol support. Let's Encrypt certificates expire every 90 days — confirm auto-renewal is active.
If you're on a host that doesn't auto-renew, set a calendar reminder. An expired certificate is worse than no certificate for user trust.
Step 2: Update WordPress URLs in Settings
Log into your WordPress admin. Go to Settings → General. Update both WordPress Address (URL) and Site Address (URL) from http:// to https://. Save.
This alone will cause a redirect loop if your server isn't yet serving HTTPS traffic properly — which is why Step 1 comes first.
Step 3: Update wp-config.php
Add the following above the /* That's all, stop editing! */ line in wp-config.php:
define('FORCE_SSL_ADMIN', true);
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
$_SERVER['HTTPS'] = 'on';
}
The second block matters specifically if you're behind a load balancer or reverse proxy — which is standard on most managed hosting environments. Without it, WordPress can't detect that the connection is already HTTPS, and it loops.
Step 4: Add the HTTPS Redirect in .htaccess
Add this block at the top of your .htaccess file, before the standard WordPress rewrite rules:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
A 301 redirect — not 302 — is critical. 301 is permanent and passes link equity. 302 is temporary and doesn't. Getting this wrong costs you SEO authority on every page of your site.
If you're on Nginx (which many managed hosts use), this redirect belongs in the server block configuration, not .htaccess. Ask your host or handle it at the Nginx level via WP-CLI-accessible configs if you have server access.
Step 5: Run a Database-Level URL Search and Replace
This is where most partial migrations fail. Your database contains thousands of hardcoded http:// references — in post content, post meta, widget settings, theme options, and wp_options rows.
The correct tool for this is WP-CLI:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --skip-columns=guid --all-tables
The --skip-columns=guid flag is intentional. The guid column in wp_posts should not be updated — it's a historical identifier, not a live URL. Updating it causes data integrity issues.
WP-CLI handles serialized data correctly. Most plugin-based search-replace tools do too, but verify this before running. An unserialized search-and-replace on serialized data in wp_options breaks option values silently — and debugging that is miserable.
Do this on a staging environment first. Always. Run the replace, verify the site, then push to production. If you don't have a staging workflow, you're operating without a rollback strategy — and that's a separate problem worth fixing before you touch production.
Step 6: Flush Object Cache and Transients
After the database replace, purge everything cached.
Via WP-CLI:
wp cache flush
wp transient delete --all
This clears stale HTTP URLs from object cache and removes transients stored in wp_options. If you skip this, visitors may see mixed content warnings for hours or days — from cached data that your database replace already fixed.
Step 7: Audit for Remaining Mixed Content
After completing the above, run your site through a mixed content scanner. Tools like WhyNoPadlock.com or browser developer tools (check the Console and Network tabs) will surface any remaining HTTP asset loads.
Common culprits after a database replace:
- Hardcoded URLs in theme files (header.php, footer.php, functions.php)
- External scripts loaded over HTTP (old analytics tags, third-party embeds)
- Iframes pointing to HTTP sources
- Plugin settings stored outside wp_options that didn't get caught in the replace
Fix these individually. If they're in theme files, they need a code edit. If they're external resources, contact the provider or replace the resource.
The PHP and Plugin Compatibility Factor
SSL migration is also a good time to check your PHP version. PHP versions below 8.0 are no longer receiving security updates. Running an outdated PHP version means your SSL-secured site still has an insecure runtime — which is a contradiction.
Beyond that, some older plugins make hardcoded HTTP calls internally — not just for assets, but for API requests. A plugin abandoned by its developer two years ago might be making unencrypted HTTP requests to external services, bypassing your SSL configuration entirely. Plugin abandonment risk is real, and SSL migration surfaces it.
Check your active plugins for last-update dates in the WordPress repository. Any plugin not updated in 12+ months on a site running modern PHP deserves scrutiny.
What This Costs If You Get It Wrong
For informational sites, a broken SSL migration means lost rankings, visitor trust warnings, and a manual cleanup process that takes 2–4 hours when done correctly.
For WooCommerce stores, the math is more direct. A store averaging $2,000/day in revenue loses roughly $83/hour during any checkout disruption. A botched SSL migration that breaks the payment flow for six hours costs $500 in lost transactions — before you account for cart abandonment patterns and the trust damage that extends beyond the downtime window.
That's not a hypothetical risk model. That's the operational cost of skipping a staging workflow and running changes directly on production.
If you want to understand the full scope of what a proper WordPress maintenance and security setup covers — SSL being one component — that's a starting point.
Why "My Host Handles This" Doesn't Hold
Infrastructure security and application security are not the same layer.
Your host secures the server. WordPress runs on top of it. The application layer — your wp-config.php, your database, your plugin configurations, your .htaccess rules — is yours to manage. The host's SSL certificate protects the transport. It does nothing for mixed content in your post editor, stale transients in wp_options, or a FORCE_SSL_ADMIN constant that was never set.
This is the most persistent myth in WordPress site management, and it's the reason sites with perfectly valid SSL certificates still show browser security warnings.
If you're not sure where your site stands, review what a proper WordPress care plan actually covers — there's a checklist there that makes the gap visible.
Before You Touch Production: The Non-Negotiable Pre-Flight
Every SSL migration should start with:
- A full database backup
- A staging environment copy
- A verified rollback path
If you don't have a staging workflow and you're migrating SSL on a live production site, you're operating without a safety net. On a WooCommerce site, that's not bold — it's reckless.
Vimsy's managed WordPress maintenance plans include staging environments as standard — not as an add-on. Because running migrations without a rollback is exactly the kind of gap that turns a 30-minute SSL fix into a multi-hour emergency recovery.
If It's Already Broken
If you're reading this after the fact — mixed content warnings active, padlock gone, admin in redirect loop — the sequence is the same, but you need to approach it diagnostically.
Start with wp-config.php. Check whether FORCE_SSL_ADMIN is set and whether the HTTP_X_FORWARDED_PROTO block is present. Then check your .htaccess for redirect conflicts. A common issue is multiple redirect rules firing in sequence — particularly if a caching plugin also injects redirect logic.
If the admin is inaccessible, you can update the WordPress site URL directly in the database via WP-CLI:
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'
This bypasses the admin panel entirely and gets you back in.
For active emergencies affecting a live site, Vimsy offers emergency WordPress support with rapid-response turnaround — not a ticket queue.
Look — I'm writing this because this is a problem I see constantly, and it's also exactly what we built Vimsy to solve. If you want professionals handling this instead of hoping nothing breaks, book a free call.
An SSL certificate is the minimum. A properly configured, fully HTTPS WordPress site — with clean redirects, a scrubbed database, flushed transients, and a staging workflow — is what actually protects your site, your rankings, and your revenue.
