Your Wix website is not secure because it is loading over an unencrypted HTTP connection instead of HTTPS. This happens when your custom domain lacks an active SSL certificate, your DNS records point to the wrong servers, or you have mixed content blocking the browser padlock.
When your Wix website is not secure, web browsers display a stark warning page that drives visitors away. You need to find out exactly where the secure connection fails so you can apply the correct fix to your domain.
Why is my Wix website not secure?
The warning means data sent between your visitor and your website is exposed. Browsers require a valid Secure Sockets Layer certificate to encrypt this traffic. Wix provides these certificates automatically for premium accounts, but the automated system breaks when your domain settings are wrong.
You can check the exact status of your certificate by running your address through a secure connection checker to see if the SSL is missing, expired, or installed incorrectly.
If the certificate is missing, the browser blocks the site entirely. If the certificate is present but the page loads insecure assets, the browser removes the padlock icon and shows a text warning. You must isolate the cause. The problem usually comes from your domain configuration, your billing status, or the specific files embedded on your page.
Your DNS records are incorrect
Wix cannot issue an SSL certificate if your domain does not point to their servers correctly. This is the most common reason your site shows a warning after connecting a custom domain.
You have two ways to connect a domain to Wix. You can use name servers or you can use pointing. Each method requires specific DNS records.
If you connected your domain via name servers, your domain registrar must have the exact Wix name servers active. You then need the default A and CNAME records in your Wix account. Log into your Wix account and go to the Domains section. Click the Domain Actions icon next to your domain. Select Manage DNS Records. Check the A record and CNAME sections. If these records are missing or altered, the SSL certificate fails to generate.
If you connected your domain via pointing, you manage the DNS records at your domain registrar. You must log into your registrar account, such as GoDaddy or Namecheap, and check your zone file. You need two exact records for pointing to work.
- An A record with the host name set to @ and the value set to 185.230.63.107.
- A CNAME record with the host name set to www and the value set to pointing.wixdns.net.
The A record maps your domain directly to the Wix server IP address. The CNAME record handles the www version of your address. If you have multiple A records, delete the ones not pointing to Wix. Conflicting A records confuse the SSL provisioning system. The certificate authority cannot verify you control the domain, so it refuses to issue the certificate.
Your domain is still propagating
When you change DNS records, the updates do not happen instantly. The changes must propagate across global servers. This process takes up to 48 hours.
During this window, your Wix website is not secure because the SSL certificate cannot be issued until the global DNS network recognizes your new records. If you just connected your domain today, you have to wait. Internet service providers cache DNS records based on a Time to Live value. If the previous host set a long Time to Live, routers around the world will hold onto the old insecure routing for a full day.
Do not change your DNS settings again during this period. Changing the records restarts the clock. You can use a DNS lookup tool to check the propagation status across different countries. Once the records resolve to Wix globally, the system provisions your certificate automatically. Calling support will not speed up this global caching process.
DNSSEC is blocking the certificate
If you bought your domain from an outside registrar, you might have Domain Name System Security Extensions active. This protocol protects your domain from spoofing, but it often blocks Wix from generating your SSL certificate.
Wix does not support DNSSEC for domains connected via name servers. If this feature is turned on at your registrar, the propagation process halts. Your domain fails to connect properly, and your site remains insecure.
Log into your domain registrar account and look for the DNSSEC settings. If the status is signed or active, you must disable it. Once you turn it off, wait a few hours for the change to register across the network. Wix will then complete the connection and apply the SSL certificate to your domain.
You have mixed content on your page
Sometimes your domain has a valid SSL certificate, but the browser still says the site is not secure. This happens when you have mixed content.
Mixed content occurs when a secure HTTPS page loads elements over an insecure HTTP connection. Browsers see this as a security risk. They remove the padlock icon and display a warning, even though the main page is encrypted.
The insecure elements are usually hardcoded images, custom scripts, or embedded iframes. If you pasted custom code into a Wix HTML widget, check the URLs inside that code.
You can find the exact file causing the problem using Chrome developer tools.
- Open your website in Chrome.
- Right click anywhere on the page and select Inspect.
- Click the Console tab at the top of the developer panel.
- Look for red and yellow warning messages.
Chrome lists every insecure file it blocked. The message will state that the page was loaded over HTTPS but requested an insecure resource. Read the file path in the console to identify the broken element. Go into your Wix editor, find that specific image or widget, and change the URL from HTTP to HTTPS. Publish your site and refresh the live page. The browser warning will clear. If you need help managing these technical audits, you can book a technical review session with a systems specialist.
Your custom domain requires a premium plan
Wix provides free hosting on their basic tier, but this comes with a Wix branded domain. You cannot connect a custom domain to a free Wix site.
If you try to point a custom domain to a free Wix site using outside DNS records, the connection fails. The site will not load properly, and any traffic that reaches it will trigger a severe security warning. Wix only provisions SSL certificates for custom domains on their premium plans.
You must upgrade your Wix account to a premium tier before you change any DNS records. Once the billing is active, the domain connection tool provides the correct DNS values. If your billing lapsed and your premium plan expired, Wix disconnects your custom domain. The SSL certificate drops, and your visitors see a warning immediately. Check your Wix billing dashboard to ensure your subscription is active.
Your SSL certificate failed to renew
SSL certificates are not permanent. They expire. Wix automatically renews your certificate before the expiration date, but this automated process requires your DNS records to remain untouched.
If you altered your A records or CNAME records to verify a third party tool, you might have broken the routing Wix uses for renewal. When the renewal fails, the certificate expires. Browsers immediately flag the site as unsafe.
You must restore the required Wix DNS records. According to the official Wix troubleshooting documentation, you can reset your DNS records to their default settings directly inside the Wix domain manager.
Go to the Domains section in your account. Click the Domain Actions icon, select Manage DNS Records, and look for the option to reset to default settings. This clears conflicting records and forces Wix to request a new certificate. Do not add custom A records unless you know exactly how they affect your primary hosting.
Third party code is breaking your connection
Wix allows you to add custom code blocks to your site header and footer. Business owners use this feature to install tracking scripts for Google Analytics, Meta Pixel, and other marketing tools.
If you paste a poorly formatted script, or a script that calls an insecure external server, the browser intercepts it. This triggers a security warning. The browser assumes the third party server is trying to steal data from the secure session. Free weather widgets and visitor counters are notorious for loading assets from unencrypted servers.
To test this, you must disable your custom code. Go to the Settings tab in your Wix dashboard. Scroll down to the Advanced section and click Custom Code. Toggle off every active script. Clear your browser cache and reload your live website.
If the site loads securely with the padlock, one of your scripts is the culprit. Turn them back on one by one, refreshing the live site each time. When the security warning returns, you have found the broken script. You must delete it and source a secure version from the tool provider. Proper tracking requires clean code, so add third party scripts one at a time and check the padlock after each one.
Your third party domain host is blocking Wix
When you buy a domain from Wix directly, the system configures the DNS records for you. When you buy a domain from a third party host like GoDaddy or Namecheap, you have to bridge the gap manually.
Sometimes these third party hosts apply default parking records to your domain. A parking record is an A record that points your domain to a placeholder page. If you add the Wix A record but fail to delete the parking record, your domain points to two different servers at the same time.
The Wix SSL provisioning system scans your domain to verify ownership. When it sees traffic splitting between Wix and a GoDaddy parking page, it aborts the certificate request. Your site remains insecure until you resolve the conflict.
Log into your third party domain host. Open your DNS management screen. Look at your A records. You should only see one A record pointing to the Wix IP address. If you see any other A records with the host name set to @, delete them immediately. Save your changes and wait for the new routing to propagate.
Your browser is caching the insecure page
Sometimes your Wix website is secure, but your own computer refuses to show the padlock. This happens when your browser caches the old HTTP version of your site to load the page faster.
Browsers store static files like images and stylesheets locally. If you visited your site while the SSL certificate was broken, your browser remembers that broken state. When Wix finally provisions the certificate, every new visitor sees a secure site, but you still see the warning.
You must force your browser to fetch the live, secure version of the site.
First, open your website in an incognito or private browsing window. Incognito mode ignores your stored cache and requests a fresh copy of the page from the Wix servers. If the site loads securely in incognito mode, your domain is fixed. The problem is isolated to your local cache.
To fix your main browser, you need to clear your cached images and files. In Chrome, click the three dots in the top right corner. Select More Tools, then click Clear Browsing Data. Choose the option to clear cached images and files. Do not clear your cookies unless you want to log out of every website you use. Refresh your Wix site, and the browser will download the new secure connection.
How to force HTTPS on your Wix site
Once your SSL certificate is active, you want every visitor to use the secure connection. If a visitor types the old HTTP version of your address, they should be redirected automatically.
Wix handles this redirect by default for all premium sites. You do not need to write redirect rules or alter server files. The system forces HTTPS across your entire site.
If the redirect fails, it means the SSL certificate is not fully provisioned. You cannot force a secure connection if the certificate is missing. You must resolve the underlying DNS or propagation issue first.
Do not attempt to build manual redirects using Wix code to solve a missing certificate. Manual redirects to a broken SSL create infinite redirect loops. The browser will crash and display an error stating the site redirected too many times. Stick to fixing the DNS records and letting the Wix platform handle the routing.
Moving away from persistent security errors
If you have checked your DNS records, waited 48 hours for propagation, cleared your mixed content, and disabled DNSSEC, your site should be secure.
When a Wix site refuses to secure after all these steps, the domain connection is deeply corrupted. You must disconnect the domain entirely from your Wix account. Wait one full hour, then start the connection process from scratch. This forces the Wix servers to generate a fresh connection request and a new SSL certificate.
Persistent security errors damage your brand. Modern browsers actively block downloads and form submissions on insecure pages. Visitors do not trust a business with a broken website. They will not submit contact forms, and they will not buy products. If your current platform requires too much technical maintenance to keep a simple padlock active, it might be time to stop fixing it. Consider migrating your content and rebuilding it as a proper mobile site on a dedicated system where security is managed for you.