How to Fix SSL on SiteGround: A Practical 2026 Troubleshooting Guide

How to fix SSL on SiteGround

If your SiteGround site is showing browser warnings, redirect loops, or mixed content errors, the problem is usually easier to diagnose than it looks.

This guide explains how to fix SSL on SiteGround by checking certificates, forcing HTTPS correctly, and resolving the most common WordPress conflicts.

SiteGround uses a managed hosting stack with Let’s Encrypt SSL, AutoSSL-style certificate provisioning, and server-level tools that can make HTTPS setup fast when everything is aligned.

When one setting is off, though, the issue can cascade across WordPress, DNS, CDN, and caching layers.

What SSL does on SiteGround

SSL, now commonly referred to as TLS in modern browsers, encrypts traffic between your website and visitors.

On SiteGround, SSL certificates are typically issued through Let’s Encrypt or another supported certificate provider and then installed through Site Tools.

• Browsers display the padlock and trust your domain.
• Login forms, checkout pages, and contact forms are encrypted.
• Google and other search engines can index the secure version of your site.
• Mixed content and redirect issues can still occur if WordPress or plugins keep loading HTTP URLs.

Check whether the SSL certificate is active

The first step is confirming that the certificate itself is installed correctly.

In SiteGround, open Site Tools for the affected domain and check the SSL manager.

If the certificate is pending, expired, or not assigned to the correct domain, HTTPS will not work reliably.

What to verify

• The correct domain and subdomain are covered, including www if you use it.
• The certificate status shows active or installed.
• The domain points to the correct SiteGround server in DNS.
• No old certificate from a previous host is still being referenced in your configuration.

If the certificate has just been issued, wait a short period for propagation.

DNS changes and certificate validation can take time, especially after a migration.

Renew or reissue the certificate in Site Tools

If the certificate is missing or invalid, reissue it from SiteGround.

SiteGround generally supports automatic provisioning for Let’s Encrypt, which is the fastest way to restore SSL for most websites.

Common reasons reissuance helps

• The domain was recently migrated to SiteGround.
• The DNS records changed and validation failed.
• The certificate was issued for the wrong hostname.
• The site briefly used a temporary URL or staging domain.

After reissuing, test the secure version of the site again.

Use both the root domain and the www version to make sure the certificate matches how visitors access your site.

Force HTTPS the right way

Once the certificate is valid, the next step is redirecting visitors from HTTP to HTTPS.

On SiteGround, this is often done with a built-in HTTPS enforcement option or by updating your WordPress settings and redirect rules.

Do not enable multiple competing redirects at the same time.

For example, if SiteGround is already forcing HTTPS, adding a second redirect in .htaccess, a caching plugin, and a CDN rule can create loops.

Use one primary redirect method

• Prefer the SiteGround HTTPS enforcement tool when available.
• Use WordPress site URL settings only if they match the secure domain exactly.
• Avoid stacking redirects in multiple plugins.
• Check that the redirect goes from HTTP to the exact HTTPS canonical URL.

If you see “too many redirects,” clear browser cookies, disable temporary redirect rules, and test in an incognito window.

Redirect loops are often caused by mismatched site URLs or conflicting proxy settings.

Fix mixed content in WordPress

Mixed content happens when the page loads over HTTPS but some assets, such as images, CSS files, JavaScript, or fonts, still load over HTTP.

Browsers may show a warning or block those resources entirely.

This is one of the most common reasons people search for how to fix SSL on SiteGround after the certificate is already installed.

Where mixed content usually comes from

• Hard-coded image URLs in posts or page builders.
• Theme files referencing HTTP asset paths.
• Plugin scripts loaded from insecure URLs.
• Old URLs stored in the WordPress database.

Start by updating the WordPress Address and Site Address to the HTTPS version.

Then run a search and replace in the database for old HTTP URLs if your site was previously live without SSL.

Tools like Better Search Replace or the SiteGround WordPress toolkit can help, but always back up first.

How to confirm mixed content is gone

• Open the site in Chrome or Firefox.
• Inspect the browser console for blocked resources.
• Check the padlock icon and security details.
• Reload key pages that use images, forms, and embeds.

Clear caches at every layer

SSL changes can appear broken simply because an older cached version of the site is still being served.

SiteGround includes server-side caching, and many WordPress sites also use a plugin cache or a CDN such as Cloudflare.

Clear caches in this order:

1. SiteGround dynamic cache and other server caches.
2. WordPress cache plugins such as WP Rocket, W3 Total Cache, or LiteSpeed Cache if installed elsewhere.
3. CDN cache if your site is proxied through Cloudflare or another provider.
4. Browser cache and cookies for a clean test.

If SSL works in one browser but not another, stale caching is a strong possibility.

Check Cloudflare and proxy settings

If your SiteGround site uses Cloudflare or another reverse proxy, SSL must be configured consistently between the origin server and the proxy.

A common mistake is setting Cloudflare to Flexible SSL while SiteGround expects HTTPS at the origin.

That can cause redirect loops or insecure requests.

Best-practice checks

• Use Full or Full (strict) when the origin certificate is valid.
• Make sure DNS records point to the intended proxied hostnames.
• Confirm that the SiteGround certificate covers the domain Cloudflare serves.
• Review Page Rules or redirects that may override SiteGround settings.

For troubleshooting, temporarily pause the proxy and test direct access to the SiteGround server.

If SSL works directly but fails through the proxy, the issue is in the CDN layer.

Update WordPress URLs and database entries

WordPress stores site URLs in several places, and leaving old HTTP values behind can break SSL behavior even when the certificate is correct.

This is especially important after migrations, domain changes, or staging-to-production pushes.

Look for these URL locations

• WordPress core settings for site URL and home URL.
• Theme customizer settings.
• Page builder content, especially Elementor or WPBakery.
• Serialized data inside plugin options.
• Widgets, menus, and custom CSS files.

After making changes, revisit important pages and verify that assets now load from HTTPS.

If you updated the database manually, test carefully because serialized data can break if edited with the wrong tool.

When the SSL certificate still shows as not secure

If the browser still marks the site as insecure after all visible settings are correct, the issue may be external to SSL itself.

Check whether the domain points to the right SiteGround IP, whether the certificate covers the exact hostname, and whether the site is forcing a redirect to a different URL than the one secured by the certificate.

Also confirm that the site is not loading an old cached version from a CDN or service worker.

For sites with custom applications, verify that the application base URL, API endpoints, and webhook callbacks all use HTTPS.

Most common SiteGround SSL fixes at a glance

• Reissue or activate the certificate in Site Tools.
• Force HTTPS with one redirect method only.
• Update WordPress URLs to HTTPS.
• Replace hard-coded HTTP links in content and theme files.
• Clear SiteGround, plugin, CDN, and browser caches.
• Check Cloudflare SSL mode and proxy settings.
• Test both root and www versions of the site.

When to contact SiteGround support

Contact SiteGround support if the certificate will not install, the domain fails validation repeatedly, or the server shows a configuration issue you cannot resolve from Site Tools.

Support can verify whether the domain is pointing correctly, whether the certificate is attached to the right virtual host, and whether the issue is caused by a server-side redirect or migration artifact.

If you have already checked DNS, SSL activation, redirects, WordPress URLs, and caching, SiteGround support can usually identify the remaining server-level cause faster than trial and error.