What you are seeing
A warning before your site loads is one of four things: a certificate problem, a reputation blocklist, a security challenge from your own CDN, or a hack showing fake pages. Visitors cannot tell these apart, and you often cannot see the warning yourself. Get a screenshot from someone who sees it, including any code under the message.
| Warning | What it usually means |
Your connection is not private with NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_COMMON_NAME_INVALID or NET::ERR_CERT_AUTHORITY_INVALID | A certificate problem: expired, wrong name, or incomplete chain. |
Warning: Potential Security Risk Ahead (Firefox) | The same certificate problems, worded for Firefox. |
Not secure in the address bar, no full-page warning | Mixed content, or the page loaded over plain HTTP. |
A red page: Deceptive site ahead or The site ahead contains malware | Google Safe Browsing listed the site, almost always after a hack. |
| A block page from antivirus or a company firewall (Norton, McAfee, Bitdefender, Fortinet and others) | That vendor rates the site as risky or puts it in a blocked category. |
A Verify you are human box that asks the visitor to press Win+R, Ctrl+V and Enter, or to paste a command into Terminal | A fake CAPTCHA (ClickFix) injected by attackers. Your site is hacked. |
Cloudflare's Sorry, you have been blocked with an error such as 1020 | A Cloudflare security rule on your own account is blocking that visitor. |
A genuine Cloudflare checkbox or Verifying you are human page that then loads the site | A challenge from your Cloudflare security settings. Annoying, not dangerous, and it never asks visitors to run anything. |
You cannot visit example.com right now because the website uses HSTS | Any certificate error on a site that sends HSTS, with no way to click through. |
Confirm it in two minutes
1. Read the certificate the server sends.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
Run it in your own computer’s terminal (or use the SSL checker). Replace both example.com entries with the exact hostname visitors use. Good: notAfter in the future and every name you use listed under Subject Alternative Name. Bad: a past date or a missing name. That is a certificate problem, not a hack.
2. Check Google’s blocklist. Open https://transparencyreport.google.com/safe-browsing/search?url=example.com with your domain at the end, and look under Security issues in Search Console. Good: No unsafe content found. Bad: any listing. Search Console names the pages and the type of problem.
3. Look for a fake CAPTCHA in the page source.
curl -s -A 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36' https://example.com/ | grep -ioE 'clipboard|powershell|mshta|verify you are human' | sort | uniq -c
Run it on your own computer. -A sends a Windows Chrome user agent, because these scripts often show only to Windows visitors; the grep counts words that clipboard-hijacking scripts use. Good: no output. Bad: hits for powershell, mshta or clipboard on a site that has no reason to use them. The script may also load from another domain or only show to first-time visitors, so no output does not prove the site is clean.
4. See who answers and whether HTTP is redirected.
curl -sI http://example.com/ | grep -iE '^(HTTP|location|server|cf-ray)'
Run it on your own computer. Good: a 301 to the https:// address. server: cloudflare and a cf-ray line mean Cloudflare is in front, so a block page may come from your own Cloudflare rules (check Security, Events in the Cloudflare dashboard).
5. Check one vendor’s verdict. If only some visitors see a block page, ask which antivirus or network they use, then look your domain up on that vendor’s own site review page. Corporate networks often block whole categories, which is not a security verdict.
Most likely causes, in order
- An expired or mismatched certificate. Tell: check 1 shows a past date or a missing name. Fix: renew or reissue, as the SSL guides show.
- A hacked site on a blocklist. Tell: check 2 shows a listing, often with spam pages or redirects. Fix: clean the site first, then request a review in Search Console.
- A fake CAPTCHA overlay. Tell: visitors describe a box asking them to press keys or paste a command, or check 3 finds hits. Fix: treat it as a hack today, and tell visitors who followed the instructions to have their computer checked.
- Mixed content. Tell:
Not secure with no error page, and console warnings naming http:// files. Fix: update the stored URLs to https.
- Your own security rules. Tell: check 4 shows Cloudflare, and the visitor sees a 1xxx code. Fix: find the matching event in Security, Events and adjust that rule.
- One vendor’s rating. Tell: only users of one antivirus or one company network are blocked. Fix: clean anything real, then ask that vendor for a review.
- The visitor’s device. Tell: one person only, with a wrong clock or antivirus HTTPS scanning. Fix: correct the clock or turn off HTTPS scanning on that device.
What it usually is not
- Fixed by an SSL plugin. A plugin cannot fix an expired certificate or a blocklist listing.
- Fine because you cannot see it. Fake CAPTCHAs and redirects often skip logged-in users and repeat visitors.
- A real Cloudflare check, when it asks for a command. Genuine challenges never ask visitors to open Run, Terminal or PowerShell.
- Removed by asking for a review early. Reviews requested before cleaning tend to fail and can slow later reviews.
What to send your host or the relevant provider
- To your host: the screenshot, the hostname, the time in UTC, and the output of checks 1 and 4.
- For a blocklist or fake CAPTCHA: a request to scan the account and keep raw access logs for the window, plus any malware notice ID.
- For a certificate problem: every affected hostname and any renewal error from the panel.
- To an antivirus vendor, after cleaning: the domain, what was found and removed, and a request to re-review.
Which guides to read