Security findings hit roughly 7 out of every 10 sites I scan with Seoxpert. The biggest offender by far is missing or weak Content-Security-Policy headers — most sites either don't have a CSP at all, or they ship one with unsafe-inline and unsafe-eval that defeat the entire point of having one.
The 8 issues below are the ones I see fix the most actual risk per hour of work. Most are header configurations a developer can deploy in 15 minutes if they know which header to add. The hardest one (a real CSP that doesn't need unsafe-inline) takes a couple of hours of nonce or hash plumbing. None of these require a code rewrite.
Check if your site has these issues — free, no install required.
Pages delivered over plain HTTP expose every byte of user data in transit. An attacker on the same network can intercept form submissions, session tokens, and personal information without any indication to the user. Google has used HTTPS as a ranking signal since 2014, and Chrome marks all HTTP pages as "Not Secure" in the address bar.
The fix is a valid TLS certificate and a permanent 301 redirect from all HTTP origins to HTTPS. Modern hosting providers and CDNs issue free certificates automatically — there is no longer any cost or complexity argument for serving HTTP.
Why this hurts: HTTPS is a confirmed Google ranking signal. Browser security warnings on HTTP pages visibly suppress conversions and destroy trust.
How to detect it: the scanner checks the protocol of every crawled URL. Any URL beginning with http:// is flagged.
HTTP security headers are a browser-enforced security layer that the server controls. Without them, browsers have no instructions on how to handle mixed content, framing attempts, MIME-type confusion, or protocol downgrade attacks. The four essential headers are HSTS (forces HTTPS on repeat visits), Content Security Policy (restricts script sources), X-Frame-Options (prevents clickjacking), and X-Content-Type-Options (prevents MIME sniffing).
These headers are typically absent on default server configurations and are often stripped by CDNs that were set up without them. Adding them globally at the web server or middleware layer takes less than an hour and reduces a site's attack surface immediately.
Why this hurts: missing headers leave browsers without safeguards against clickjacking, XSS, and protocol downgrade. Security issues at scale can lead to site compromise and eventual deindexation.
How to detect it: the scanner inspects HTTP response headers for HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy.
Mixed content occurs when an HTTPS page loads resources — images, scripts, stylesheets, or iframes — via HTTP. Browsers block active mixed content (scripts and iframes) outright and generate security warnings for passive mixed content (images). The result is broken functionality, console errors, and visible security warnings that damage user trust.
The most common cause is a CMS migration from HTTP to HTTPS where legacy content still contains hardcoded http:// image URLs in the database. Adding a Content-Security-Policy: upgrade-insecure-requests directive forces the browser to upgrade these URLs automatically without a database migration.
Why this hurts: blocked mixed content breaks page functionality. Warnings damage conversion rates and user trust signals.
How to detect it: the scanner checks image, script, stylesheet, and link URLs on HTTPS pages for any http:// references.
Admin panels, configuration files, and backup directories that return HTTP 200 OK are publicly accessible. Paths like /admin, /.env, /config, and /backup are the first targets of automated vulnerability scanners. An exposed admin login page invites credential-stuffing attacks; an exposed .env file may contain database credentials or API keys.
The fix requires both server-level access controls (IP restrictions, HTTP Basic Authentication) and moving sensitive files outside the web root. robots.txt disallow rules are not a security control — they are advisory only and ignored by malicious bots.
Why this hurts: exploited admin panels or exposed credentials can lead to site compromise, data breach, malware injection, and deindexation by Google.
How to detect it: the scanner checks whether known sensitive paths return HTTP 200 OK.
View full fix guide →Content-Security-Policy (CSP) is the browser's primary defence against cross-site scripting (XSS) attacks. Without a CSP, a single injected script in user-generated content, a compromised third-party widget, or an ad network exploit can execute arbitrary JavaScript in the context of your site — stealing session cookies, redirecting users, or exfiltrating form data.
CSP is part of the broader missing security headers finding. Start with a report-only policy to understand current script sources before enforcing. A permissive policy (default-src 'self' *) is better than no policy at all, as it enables the upgrade-insecure-requests directive.
Why this hurts: without CSP, XSS attacks can run unrestricted, potentially compromising user accounts, injecting spam content, and triggering Google's malware warnings.
How to detect it: covered by the security headers check — scanner looks for the content-security-policy response header.
HTTP Strict Transport Security (HSTS) instructs browsers to always use HTTPS for future visits to the domain, even if the user types a plain HTTP URL. Without HSTS, a user who visits your site for the first time over HTTP — before the server issues a redirect — is vulnerable to a protocol downgrade attack, allowing a network attacker to intercept the initial request.
HSTS is enabled by adding a single response header: Strict-Transport-Security: max-age=31536000; includeSubDomains. After browsers receive this header once, they enforce HTTPS for a full year without contacting the server again. This is part of the broader security headers fix.
Why this hurts: without HSTS, the first HTTP request to your site remains vulnerable to man-in-the-middle interception even if your server redirects immediately.
How to detect it: covered by the security headers check — scanner looks for the strict-transport-security header.
When a site migrates from HTTP to HTTPS, redirect chains frequently accumulate if the redirect logic is layered incrementally: http://example.com → https://example.com → https://www.example.com. Every additional hop adds latency, and browser pre-load lists (HSTS preload) cannot function correctly when the HSTS header is only sent at the final destination.
For security, the HTTP → HTTPS redirect should be a single 301 hop. The HSTS header must be present on the HTTPS response, not on an intermediate redirect. Any www/non-www canonicalisation should be collapsed into the same hop.
Why this hurts: multi-hop redirects dilute link equity, add measurable latency, and delay HSTS enforcement to downstream hops where it may arrive too late.
How to detect it: the scanner traces redirect chains across all crawled URLs.
View full fix guide →When a site is compromised, search engines may discover the injected content before the owner does. Google can apply a manual or algorithmic penalty that marks the domain as potentially dangerous — but a subtler consequence is that the attackers themselves inject noindex directives, meta robots overrides, or robots.txt disallow rules to hide their spam pages from detection.
After a security incident is cleaned up, it is essential to audit every page for unexpected noindex directives that were not present before the compromise. Pages that appear normal in a browser may carry injected meta robots tags in the HTML. Recovery also requires a Google Search Console reconsideration request and a clean security audit.
Why this hurts: injected noindex directives can silently remove legitimate pages from Google's index, destroying organic traffic that takes months to recover.
How to detect it: the scanner reads <meta name="robots"> and X-Robots-Tag headers on every page. Unexpected noindex on content pages is flagged.
Browse all security findings in the security issues library.
The Seoxpert security scanner checks all of the above in a single pass. Enter your URL to get a complete security audit — protocol enforcement, header presence, mixed content, and sensitive path exposure in under 2 minutes.
Or sign up to use your free scan credit. View plans for ongoing monitoring.