How to Fix SSL After Moving a Website
Moving a website can break HTTPS even when the site itself appears to load normally.
If the certificate, DNS, or server configuration no longer matches the new environment, browsers may show warnings, mixed content errors, or redirect loops.
This guide explains how to fix SSL after moving website assets, domains, or hosting so your visitors see a secure connection again and your search rankings stay protected.
Why SSL breaks after a website migration
SSL and TLS certificates are tied to the domain name and, in many cases, to the hosting configuration that serves them.
When a site is moved, several changes can disrupt the secure handshake between the browser and server.
- Domain propagation is incomplete: DNS still points to the old server or to multiple servers with different certificate setups.
- The certificate was not installed on the new host: Some migrations copy files but leave SSL configuration behind.
- The certificate is for the wrong hostname: A certificate for example.com will not fully cover www.example.com unless both are included.
- The web server is not redirecting correctly: HTTP to HTTPS rules may conflict with new platform defaults.
- Mixed content exists: Pages load over HTTPS, but images, scripts, or stylesheets still use HTTP URLs.
Step 1: Confirm the certificate status on the new server
Start by checking whether the new hosting account has an active certificate for the correct domain.
In many cases, the fastest fix is simply reissuing or reinstalling the certificate in the new environment.
What to verify
- The certificate is installed for the exact domain used by visitors.
- The certificate chain includes the intermediate certificate.
- The expiration date is valid.
- The certificate matches both the root domain and the www version if both are used.
If you use a managed host such as SiteGround, Kinsta, WP Engine, or Cloudways, look for the SSL or security section in the hosting panel.
If you use cPanel or Plesk, check the SSL/TLS manager and confirm the certificate is assigned to the domain.
Step 2: Make sure DNS points to the right place
After migration, DNS is often the hidden reason SSL appears broken.
If the domain still resolves to the previous server, users may see the wrong certificate or an outdated site configuration.
Check these DNS records
- A record: Should point to the new server’s IP address.
- AAAA record: Should be correct if IPv6 is enabled.
- CNAME record: Should match the platform’s required target when applicable.
- Nameservers: Must be updated if the domain is moving to a new DNS provider.
Use a DNS lookup tool such as dig, nslookup, or an online checker to confirm that propagation is complete.
During propagation, visitors in different regions may hit different servers, which can create inconsistent SSL behavior.
Step 3: Reissue or reinstall the certificate
If the certificate was not transferred cleanly, reissue it on the new host.
This is especially common with free certificates from Let’s Encrypt, since many hosts automate issuance but do not migrate the certificate files themselves.
When reissuing, ensure the certificate includes every hostname you use:
- example.com
- www.example.com
- subdomains such as blog.example.com or shop.example.com, if needed
For organizations using an EV or OV certificate from a commercial Certificate Authority such as DigiCert, Sectigo, GlobalSign, or Entrust, reinstallation may require validation steps, private key access, or a new CSR generated on the destination server.
Step 4: Fix HTTP to HTTPS redirects
Once the certificate is active, test whether the site redirects cleanly from HTTP to HTTPS.
A migration often changes server rules, so redirects that once worked may now be missing or duplicated.
Common redirect problems
- HTTP and HTTPS versions both load without redirecting.
- Redirects loop between www and non-www versions.
- Old rules in .htaccess conflict with application-level redirects.
- Cloudflare or another CDN is forcing HTTPS while the origin server does the same.
For Apache, review .htaccess or virtual host rules.
For Nginx, check server blocks and the listen directives.
For WordPress, verify the site URL and home URL values in the database or wp-config.php if they were not updated during migration.
Step 5: Remove mixed content from the site
Even with a valid certificate, browsers can still warn users if any page element loads over HTTP.
Mixed content is one of the most common issues after moving a website because internal links often still point to the old protocol or domain.
Typical mixed content sources
- Hardcoded image URLs in posts or page builder blocks
- JavaScript and CSS files loaded over HTTP
- Embedded videos, fonts, or iframes
- Theme options or plugin settings storing old URLs
Use your browser developer console to identify blocked resources.
Then replace old URLs in the database, theme files, and content editor settings.
In WordPress, tools such as Better Search Replace or WP-CLI can help update large sets of URLs safely when used carefully.
Step 6: Update the CMS and application settings
Many SSL issues after migration are caused by the application itself still believing it lives at the old address.
This is common in WordPress, Magento, Shopify custom themes, Laravel apps, and other CMS platforms.
Check for these settings
- Site URL and home URL values
- Force SSL settings in admin areas
- Canonical URLs in SEO plugins
- API endpoints and webhook URLs
- CDN and asset delivery domains
In WordPress, also confirm that the WordPress Address and Site Address match the live HTTPS version.
If you use a plugin such as Yoast SEO, Rank Math, or All in One SEO, verify that canonical tags and sitemap URLs use HTTPS as well.
Step 7: Check the CDN and proxy layer
If you use Cloudflare, Fastly, Akamai, or another reverse proxy, SSL may need to be configured in two places: at the edge and on the origin server.
A mismatch can lead to 525, 526, or similar TLS errors.
What to verify with a CDN
- SSL mode is set appropriately, such as Full or Full (Strict) in Cloudflare.
- The origin certificate is valid.
- Page rules or redirects are not conflicting with server redirects.
- Cached assets are not serving old HTTP references.
Purging the CDN cache after migration often helps, especially if the old site assets were cached with outdated URLs or certificate references.
Step 8: Test the site from multiple angles
After the fixes are in place, test the site systematically.
A single browser check is not enough because SSL problems can vary by device, cache state, and region.
- Load the site in an incognito window.
- Check both example.com and www.example.com.
- Test internal pages, not just the homepage.
- Inspect the certificate details in the browser.
- Use an SSL checker to confirm the chain, hostname, and expiration.
- Run a crawl with a tool such as Screaming Frog to identify remaining HTTP URLs.
You should also review Google Search Console and Bing Webmaster Tools for crawl errors, redirect issues, and indexing problems related to the migration.
How to avoid SSL problems in future migrations
The easiest way to reduce SSL issues is to include certificate and URL handling in the migration plan before the move begins.
That saves time and prevents post-launch downtime.
- Export the SSL certificate plan with the hosting checklist.
- Confirm the destination server supports the same domain names.
- Lower DNS TTL values before switching hosts.
- Map all HTTP references and update them during the move.
- Test redirects and certificate coverage in staging before launch.
For complex setups, document where SSL is handled: the web server, application layer, CDN, load balancer, or managed hosting panel.
Clear ownership makes troubleshooting much faster when something fails after launch.
When to contact your host or certificate provider
If you have reinstalled the certificate, corrected DNS, fixed redirects, and removed mixed content but the browser still shows errors, the problem may be deeper in the server stack.
At that point, contact your host’s support team with details such as the domain, error message, certificate type, and the exact time the issue appeared.
Certificate providers can also help if the CSR, private key, or validation status is inconsistent.
Providing screenshots of browser errors and results from SSL test tools will speed up resolution.