HTTPS protects the connection between a visitor’s browser and your website, and many sites can enable it with a free SSL certificate. This guide explains how certificates work, how to choose an installation method, and how to troubleshoot common warnings such as mixed content, redirect loops, expired certificates, and hostname mismatches.
Overview
“SSL certificate” is the familiar term, although modern websites generally use TLS to encrypt traffic. The certificate helps a browser verify that a website controls a particular domain and allows the connection to use HTTPS. When setup is correct, visitors see a secure connection in their browser rather than an unsecured HTTP warning.
A free certificate is often sufficient for a blog, portfolio, small-business site, documentation project, or standard online store. The important factors are not the purchase price but correct domain validation, reliable installation, automatic renewal, and complete coverage of the hostnames visitors use. A paid certificate may provide additional organizational validation or support through a provider, but paying for a certificate is not automatically necessary for encryption.
Before changing anything, record your current setup. Note whether the site uses www, the root domain, subdomains, a content delivery network, a reverse proxy, or separate services for email and applications. HTTPS applies to web traffic; it does not replace the DNS, MX, SPF, or other records used by email. For a broader record-by-record explanation, see our DNS records guide.
| Certificate or setup type | Typical use | What to check |
|---|---|---|
| Single-domain certificate | One domain or one specified hostname | Whether both the root domain and www are covered |
| Wildcard certificate | A domain and its subdomains, depending on the certificate scope | Which subdomain levels are included and where it will be installed |
| Multi-domain certificate | Several separately named hostnames | The complete hostname list and renewal process |
| Hosting-panel certificate | Sites managed through a compatible hosting dashboard | Whether issuance and renewal are automatic |
| Manually installed certificate | Servers, containers, or platforms without automated integration | Private-key security, renewal reminders, and deployment steps |
Checklist by scenario
Using shared hosting or a site builder
- Confirm that your domain points to the correct hosting account. If DNS is managed elsewhere, identify where the A, AAAA, or CNAME records are controlled.
- Open the hosting or builder security settings and look for an option such as SSL, HTTPS, or secure certificate. Many platforms can request and install a free certificate on your behalf.
- Include every hostname that receives visitors, commonly the root domain and
www. Add a subdomain only if it serves a separate web application. - Wait for validation and installation to complete before forcing HTTPS. If validation fails, check DNS targets, proxy settings, and any temporary access restrictions.
- Enable the platform’s automatic renewal option where available. Confirm that you know who receives renewal or failure notifications.
Using WordPress
- Install the certificate at the hosting or server level first. A WordPress setting cannot repair a certificate that the web server does not present.
- Check the WordPress Address and Site Address values and use the same preferred format, such as HTTPS with or without
www. - Update the site’s canonical URL, image references, scripts, stylesheets, and embedded resources. Search for hard-coded
http://links in content and theme or plugin settings. - Clear relevant caches after changes, including the WordPress cache, host cache, CDN cache, and browser cache.
- Test logged-in and logged-out pages, forms, media, search, checkout, and administrative areas before declaring the migration complete.
Using a VPS, dedicated server, or custom stack
- Choose an ACME-compatible automated certificate process or another method supported by your server environment.
- Verify that the web server can answer the certificate authority’s domain-validation request and that DNS points to the intended machine.
- Install the certificate and private key in the server’s TLS configuration. Keep the private key restricted and do not place it in a public website directory.
- Configure the complete certificate chain when your platform requires it, then reload the web server safely.
- Test automated renewal in a non-destructive way and document how a renewed certificate is deployed. An issued certificate is not enough if the running server continues using the old one.
If HTTPS is part of a host migration, coordinate the certificate, DNS change, redirects, and email records rather than treating them as separate last-minute tasks. The website migration guide provides a wider sequence for moving without losing traffic or email.
What to double-check
- Hostname coverage: Test the exact URLs people use. A certificate for
example.comdoes not necessarily cover every subdomain. - DNS alignment: Certificate validation and website delivery can fail when old A, AAAA, or CNAME records remain active. Check both IPv4 and IPv6 records if your host uses them.
- Renewal ownership: Identify whether renewal belongs to the hosting company, CDN, control panel, deployment pipeline, or a manual administrator. Set a reminder even when renewal is advertised as automatic.
- Redirect destination: HTTP should normally redirect to the chosen HTTPS version, and duplicate HTTPS variants should resolve consistently. Avoid sending visitors through several redirect hops.
- Mixed content: A page can be HTTPS while still requesting images, scripts, fonts, or frames over HTTP. Replace those URLs with HTTPS or a protocol-relative decision appropriate to the resource.
- External services: Confirm that analytics, payment tools, APIs, webhooks, fonts, and embedded media support HTTPS and have the correct callback or origin settings.
- Search and sharing signals: Review canonical tags, XML sitemaps, internal links, hreflang where applicable, and analytics properties after changing URLs. A useful launch reference is the website launch and maintenance checklist.
Common mistakes
Forcing HTTPS before the certificate works. This can create an outage or an endless redirect loop. First verify that the server presents a valid certificate at the final hostname, then enable redirects.
Assuming the padlock means every page is secure. Browsers may display a warning when active or passive resources still load over HTTP. Inspect the browser’s security or developer tools to identify the specific request.
Changing DNS records unrelated to the website. Removing MX or TXT records while trying to fix web hosting can interrupt email authentication or delivery. Only change records you understand, and keep a copy of the previous zone.
Forgetting alternate hostnames. A redesign, staging environment, API subdomain, or old www address may use a different certificate or server. List every public hostname before and after the change.
Relying on manual renewal without a named owner. Certificates expire independently of content updates. If automation is unavailable, keep a calendar reminder, renewal procedure, backup contact, and documented installation steps.
Using a security plugin as a substitute for server configuration. Plugins can help update URLs or identify mixed content, but they cannot issue a certificate or correct an incorrect DNS target on their own.
When to revisit
Review this checklist whenever you launch a domain, change hosts, redesign a site, add a subdomain, place a CDN or proxy in front of the server, or move from a site builder to a custom platform. Recheck it before seasonal campaigns and other high-traffic periods so a renewal failure or redirect mistake is not discovered during an important promotion.
Make HTTPS part of routine maintenance. At a practical minimum, inspect certificate status, expiry or renewal logs, hostname coverage, redirects, mixed-content warnings, forms, checkout flows, and important integrations. Repeat the review after changing DNS providers, hosting panels, WordPress URL settings, server software, deployment workflows, or security controls.
Your next action is simple: write down the preferred HTTPS URL, identify who controls DNS and certificate renewal, test the root and www versions, and save the result. If the setup is unclear, start with the domain name setup guide, then document the final configuration so the next renewal or migration is a controlled task rather than an emergency.
