Getting a padlock on a WordPress site is two separate jobs, and confusing them is why so many sites end up half-secured. The first is issuing a certificate, which happens on the server and has nothing to do with WordPress. The second is making WordPress use it everywhere, which is entirely inside WordPress and is where the work actually is. A certificate can be perfectly valid while the site still loads images over plain HTTP and shows a broken padlock.
Ahosting includes a free SSL certificate, so the first job is usually already done or a few clicks away. This walks through both, and then through the mixed-content cleanup that follows almost every conversion.
Step 1: make sure the certificate is active
In cPanel, open the SSL/TLS Status page. It lists every domain and subdomain on the account with its certificate state. A domain showing a valid certificate needs nothing further here.
If a domain is not covered, use the option to run AutoSSL on it. Issuance normally takes a few minutes. If it fails, the cause is nearly always DNS: the domain is not yet pointing at this server, so the certificate authority cannot verify you control it. Fix the DNS first, then retry, no amount of retrying will succeed while the domain resolves elsewhere.
Confirm before moving on. Load https:// followed by your domain directly. If it loads without a certificate warning, stage one is done.
Step 2: point WordPress at the HTTPS address
In the dashboard, open Settings then General. Change both WordPress Address and Site Address to start with https://. Save.
You will be logged out, which is expected. The session cookie was issued for the other address. Log back in at the https:// URL.
If changing these locks you out entirely, set them in wp-config.php instead, which overrides whatever is stored in the database:
define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );
Be consistent about www. Setting these to the bare domain while the server forces www produces a redirect loop, which is the single most common way this step goes wrong.
Step 3: redirect HTTP to HTTPS
Both addresses still work at this point, which means visitors with old links and search engines with indexed HTTP URLs stay on the insecure version. Send them across with a permanent redirect in .htaccess, placed above the WordPress block:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Take a copy of .htaccess before editing it. A mistake here produces a 500 error or a redirect loop across the whole site, and having the original to put back turns a crisis into a thirty-second fix.
Test by loading the http:// address and confirming you land on https://. Test a deep page too, not just the homepage.
Step 4: fix mixed content
This is the step people skip, and the reason the padlock stays broken. Years of content contain image tags, stylesheet links and script sources written with http://, stored in the database. The page loads securely and then asks for those resources insecurely. Browsers flag it, and block insecure scripts outright, which can break sliders, forms and maps.
Open the site, open the browser's developer console, and reload. Mixed content warnings name each offending URL, which tells you whether the problem is in content, in the theme, or in a plugin.
For URLs stored in posts and pages, a search-and-replace across the database is the practical fix. Use a plugin built for it instead of a plain SQL UPDATE: WordPress stores some settings as serialized data, where string lengths are recorded alongside the strings, and a naive replacement corrupts those rows in ways that are annoying to unpick. Back up the database first regardless.
For URLs hard-coded in a theme or plugin file, edit the file, in a child theme, so an update does not overwrite your change. If the resource is on a third-party server that does not support HTTPS at all, replace it or host it yourself; there is no way to load it securely.
Step 5: update the things that point at your site
Change the site URL in Google Search Console and analytics properties, and update the address in any service that pings your site. Then check your sitemap actually lists https:// URLs, some SEO plugins cache it and keep serving the old one until regenerated.
Common problems
Padlock shows a warning triangle. Mixed content. The console names the exact resource.
Redirect loop. A www mismatch, or a redirect rule fighting a plugin that also forces HTTPS. Turn off the plugin's redirect and keep the one in .htaccess; two rules pointing at each other is the usual cause.
Certificate warning naming the wrong domain. The certificate covers a different name: often the bare domain when you are loading www, or the reverse. Reissue covering both.
Admin area works, front end does not. Usually a caching layer still holding HTTP versions of pages. Clear the site cache after conversion; this is easy to forget and produces a very confusing few minutes.
Why partial HTTPS is worse than it looks
Securing only the login page and leaving the rest on HTTP does not protect the session. The cookie that identifies a logged-in administrator is sent with every request, including the plain HTTP ones, where anyone on the same network can read it. Whoever has that cookie is you, without needing the password.
That is why the redirect step matters as much as the certificate. A certificate that only some pages use protects almost nothing.
Once HTTPS is in force, the rest of the hardening list is worth working through: securing WordPress against vulnerabilities puts this step in order alongside the others.
Installing the certificate is half of it; every address on the site has technically changed. How to Move a Site to HTTPS Without Losing Rankings walks through the four things that must move with it.