What security does HTTPS provide?
HTTPS encrypts communication between the browser and the connected server using TLS, and authenticates the domain through a certificate. 'SSL certificate' remains a common everyday term; modern connections use the TLS protocol.
A website using HTTPS does not, by itself, prove that the business is trustworthy or that its application code has no vulnerabilities. Account security, software updates, data access and backups are separate layers. A certificate does not automatically secure a misconfigured application.
Check which names the certificate covers
The root domain and the 'www' subdomain are different DNS names. If you use both, verify that the certificate covers both. A wildcard certificate generally covers subdomains at the specified level; check root-domain and deeper-subdomain coverage separately.
Domain validation can use methods such as HTTP or DNS. An incorrect DNS record, blocked validation path or restrictive CAA record can prevent certificate issuance. When moving to another server, test that the certificate is ready in the new environment.
Redirect HTTP traffic to one HTTPS address
First verify that the website works correctly over HTTPS, then configure a permanent redirect to the preferred domain format. For example, if using 'www', send HTTP/HTTPS and www/bare-domain variants to the same destination. Test that page paths and required query parameters are preserved.
Plan redirects in the web server, control panel, CDN or application layer. Different rules across multiple layers can create a loop. In an environment using a reverse proxy or CDN, the application must correctly detect the visitor's secure connection; use a verified configuration method appropriate to your infrastructure.
Remove mixed-content errors
An HTTPS page requesting an image, font, script or stylesheet over HTTP can create mixed content. Browsers block some resources or try to upgrade them. Inspect remaining HTTP requests in Developer Tools' Console and Network tabs.
Check application settings, hardcoded URLs in the theme and URLs stored in content. If a system such as WordPress needs bulk database replacement, use a tool that preserves serialised data and back up first. Consider a secure alternative if an external service does not support HTTPS.
Example: test four address variants individually
Try the following four address formats in separate browser tabs. Replace example.com with your domain; each should reach your preferred HTTPS format.
http://example.com/ http://www.example.com/ https://example.com/ https://www.example.com/
Check the final address bar URL, the absence of certificate warnings and preservation of an inner page's path. If Developer Tools' Network tab shows consecutive redirects or a loop returning to the same URL, review panel and application rules together.
Update indexing signals and permalinks
Canonical tags, the sitemap, internal links and social sharing URLs should match the selected HTTPS domain. Keep redirects so old HTTP links continue working. Check that robots.txt or a 'noindex' directive left over from testing is not blocking the website.
During an HTTPS migration, review site coverage in verification and monitoring tools such as Search Console. Checking only the homepage is not enough; test examples of different content templates and old links.
Plan renewal and the HSTS decision separately
Monitor certificate expiry and the renewal mechanism. Configuring automatic renewal does not guarantee it will continue working after DNS or validation settings change. Check after changes to the domain or validation paths.
HSTS is a security policy that tells browsers to connect to a domain over HTTPS. Options such as 'includeSubDomains' and preloading may affect every subdomain and cause access problems for older services without HTTPS. Do not enable these options before verifying their full scope.
Explore SSL solutions for your certificate needs; if you encounter an error, create a support request with the domain and the exact browser error text.
Check the status code and Location header
Open the Network tab in browser Developer Tools and inspect the document request's status and redirect destination. On the command line, curl -I https://example.com/sample-page requests headers only; use your own URL. Some applications respond differently to HEAD requests, so verify the result with a normal browser GET request too.
Educational example — not actual server output: HTTP/2 301 location: https://www.example.com/sample-page
Check that the same page path is preserved at the expected destination. Redirecting every inner page to the homepage is not a correct migration, even if the redirect chain is short. If the command returns a certificate error, do not treat it as successful by disabling validation; check the name, validity dates and certificate chain.
| Observation | Check |
|---|---|
| Loop between HTTP and HTTPS | Check that the CDN/proxy and application interpret the visitor's scheme consistently. Assess trusted proxy headers and the CDN-to-origin TLS mode together. |
| Loop between www and the root domain | Check whether the CDN, web server and CMS enforce different primary addresses. Define a single preference. |
| Certificate name mismatch | Check that the certificate covers the exact hostname visited and that DNS points to the correct server. |
| HTML 200, but a security warning appears | Look in the browser console for images, fonts, scripts or form destinations requested over HTTP. |
The MDN redirect guide explains differences between status codes. Do not add the same redirect recipe to several layers without understanding your infrastructure's rules.
Your next step
Review the service scope using the link below. For an account-specific action, contact the support center.
Compare SSL coverage →See all practical guides →
