Practical security advice for website owners
WordPress SSL Warning or Malware Warning? Tell the Difference
Security guidance · References checked 2 November 2026
In this guide
A visitor says your WordPress website is “not secure”. That phrase can describe an expired certificate, a hostname mismatch, mixed content or a browser warning about harmful behaviour. These are different problems. Buying another SSL certificate will not clean malware, and deleting files will not necessarily repair a certificate renewal failure.
Start with the exact browser message, affected URL and time. The wording and where it appears help determine which system is reporting the problem. Do not ask visitors to bypass a warning or enter personal information while the cause is unresolved.
Record the warning without normalising the risk
Use a screenshot that avoids personal information and record the complete address, including hostname and scheme. Ask which browser and device were used and whether the warning appears before the page loads or only within a particular interaction.
Check from an authorised clean device using a current browser. If the warning indicates dangerous content, avoid casually proceeding into the page. Use an appropriate investigation environment or the provider’s diagnostic tools rather than treating repeated visits as harmless testing.
A warning on one device does not automatically mean it is a false alarm. Cached information, local clock settings, browser extensions or a conditional website problem can change what people see. Record the difference and investigate it instead of dismissing the report.
Certificate errors concern the connection
TLS helps protect the connection between a browser and the relevant server. A certificate issue may involve expiry, the wrong hostname, an incomplete chain or an origin configuration behind a proxy. The MDN TLS implementation guide explains the role of secure transport.
Ask the host which endpoint serves the affected certificate and how renewal is managed. Check all public hostnames used by the website. A working certificate for the apex domain does not automatically establish correct configuration for every subdomain.
Repair through the hosting or certificate provider’s supported process. Do not disable certificate verification as a permanent workaround. After the change, verify the intended hostname and the business functions that depend on it, including forms and integration callbacks.
| Symptom | Layer to investigate | What a certificate alone cannot establish |
|---|---|---|
| Certificate expiry or hostname error | TLS endpoint and renewal configuration | Whether site content is clean. |
| Harmful-site or phishing warning | Reporting provider and affected content | Whether a warning review will be accepted. |
| Blocked insecure resource | Resource URL and component configuration | Whether every page template is fixed. |
A valid certificate does not certify clean content
A malicious website can use HTTPS, and an infected legitimate website may continue presenting a valid certificate. The padlock or connection indicator concerns transport; it is not an endorsement of the site’s files, owners or business practices.
If visitors see redirects, unexpected downloads or credential prompts, investigate those symptoms even if the certificate is valid. Review the actual behaviour and relevant records. Avoid declaring the website safe based only on an SSL checker’s result.
This distinction also matters in purchasing security services. Certificate repair and malware investigation may overlap during an incident, but they are not interchangeable deliverables. Ask the provider to state which problem its quote addresses.
Malware and phishing warnings follow another route
Google explains the differences between harmful-content warnings and other search issues in its dangerous-site warning guidance. Review the relevant Search Console Security Issues report through a trusted account if Google is the source of the warning.
Capture the reported category and sample URLs. Do not assume that every browser warning comes from Google or that one sample URL defines the whole affected scope. Other browsers, security products and hosting providers have their own systems and review processes.
Where malicious content is confirmed, remove the identified threats, address the access or software issues and verify the agreed scope before requesting the appropriate review. Providers control their own warning updates. A developer cannot responsibly guarantee an immediate removal time or a particular search ranking outcome.
Mixed content needs a targeted diagnosis
An HTTPS page may still request resources over an insecure scheme. Depending on the resource and browser, this can cause blocked assets or connection warnings. Investigate the specific requests and the component generating them rather than blindly replacing every string in the database.
Use supported migration or configuration methods, particularly where page builders store structured or serialised data. Confirm the correct public URL and any proxy configuration with the host. A mistaken global change can damage content or create redirect loops.
Test representative pages after repairs. A homepage may contain no insecure resources while a product template, embedded form or old campaign page still does. Include those page types in the verification list.
Use a simple decision record
For each symptom, record the reporting system, exact message, affected hostname, suspected layer, evidence and responsible provider. This turns a vague “not secure” task into a manageable repair plan.
For example, a certificate renewal failure may be assigned to hosting with a hostname verification test. A harmful-content report may require a recovery specialist and a provider review request. These are planning examples, not client results or a claim that only one problem can exist at a time.
If several symptoms appear together, coordinate the changes. Restoring a certificate may be necessary to reach the site securely, but it should not be presented as completion of an unrelated malware investigation.
When to request specialist help
Ask for help when the warning is unclear, the site handles sensitive transactions, redirects appear unexpectedly or your provider identifies malicious content. Send the public URL, exact warning and when it began. Do not send administrator credentials in the initial enquiry.
Request a scope that separates connection repair, content investigation, security improvements and any external review. That clarity helps you understand what will be tested and prevents a superficial fix from being mistaken for full website recovery.
Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.