PageVital
← Back to Blog

Security

·9 min read

How to Improve Your Website Security Score: 9 Actionable Steps

PageVital Team·

Why Your Security Score Matters

A low security score does not mean your website has been hacked. It means your website is missing protective measures that modern browsers can enforce on your behalf — measures that cost nothing to implement and dramatically reduce your attack surface.

When PageVital scans a website's security, it checks nine specific items that represent the foundational security layer every public website should have. These are not obscure enterprise requirements. They are standard HTTP headers and configurations that browsers already know how to use — if your server tells them to.

The security category accounts for 25% of your overall PageVital health grade. If you are scoring a C or below in security, the fixes in this guide can move you to an A in under an hour, often with just configuration changes and zero code modifications.

The 9 Security Checks and How to Fix Each One

PageVital's security scanner evaluates these nine checks, each weighted by severity. Critical and high-severity checks have the most impact on your score. Here is each check, what it means, and exactly how to fix it if your scan shows a fail or warning.

1. SSL Certificate (Critical Severity)

What it checks: Whether your site is accessible over HTTPS with a valid SSL/TLS certificate.

Why it matters: SSL encryption protects data transmitted between your visitors' browsers and your server. Without it, login credentials, form submissions, and personal data are transmitted in plain text that anyone on the network can intercept. Google also flags non-HTTPS sites as "Not Secure" in Chrome, which destroys visitor trust.

How to fix it:

  • If you do not have SSL at all, most hosting providers offer free certificates through Let's Encrypt. Check your hosting control panel for a one-click SSL option.
  • If your certificate is expired, renew it through your certificate provider or set up auto-renewal with Let's Encrypt's Certbot.
  • If your certificate is for the wrong domain (e.g., you have SSL for www.example.com but not example.com), request a certificate that covers both, or use a wildcard certificate (*.example.com).
# Check your certificate expiry from the command line
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -dates

2. HTTPS Redirect (Critical Severity)

What it checks: Whether HTTP requests are automatically redirected to HTTPS.

Why it matters: Having an SSL certificate is only half the equation. If visitors can still access your site over plain HTTP (by typing http://example.com or following an old link), their connection is unencrypted. A proper HTTPS redirect ensures every visitor gets the encrypted version, regardless of how they arrive.

How to fix it:

For Apache servers, add to your .htaccess file:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

For Nginx, add to your server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

For Cloudflare users, enable "Always Use HTTPS" in the SSL/TLS settings — this handles the redirect at the CDN level before traffic reaches your server.

3. HSTS — HTTP Strict Transport Security (High Severity)

What it checks: Whether your server sends the Strict-Transport-Security header.

Why it matters: Even with an HTTPS redirect in place, there is a brief window during the first visit where the browser sends an unencrypted HTTP request before receiving the redirect response. HSTS tells browsers to never even attempt an HTTP connection to your site — they automatically upgrade to HTTPS before sending any request. This closes the redirect vulnerability window entirely.

How to fix it:

Add this header to your HTTPS server response:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • max-age=31536000 tells browsers to remember this policy for one year
  • includeSubDomains applies the policy to all subdomains
  • preload qualifies your domain for inclusion in browser HSTS preload lists (submit at hstspreload.org)

For Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

For Apache:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

4. Content Security Policy (High Severity)

What it checks: Whether your server sends a Content-Security-Policy header.

Why it matters: CSP is your primary defense against cross-site scripting (XSS) attacks. It tells the browser exactly which sources of content (scripts, styles, images, fonts) are allowed to load on your page. If an attacker manages to inject a malicious script tag, the browser blocks it because the attacker's domain is not in your CSP allowlist.

How to fix it:

Start with a report-only policy to identify what your site loads, then enforce it:

# Step 1: Monitor what your site loads (does not block anything)
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-reports

# Step 2: After reviewing reports, enforce the policy
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com

Key directives to configure:

  • default-src 'self' — only allow content from your own domain by default
  • script-src — explicitly list every domain that serves JavaScript your site needs
  • style-src — list CSS sources (note: many frameworks require 'unsafe-inline' for inline styles)
  • img-src — list image sources (include data: if you use base64 images)

CSP is the most complex header to configure correctly because it depends on your site's specific dependencies. Take an iterative approach: start with report-only mode, review the violation reports, adjust the policy, and only enforce once violations are resolved.

5. X-Frame-Options (High Severity)

What it checks: Whether your server sends the X-Frame-Options header.

Why it matters: Without this header, attackers can embed your website inside an invisible iframe on a malicious page. When a visitor interacts with what they think is the attacker's page, they are actually clicking buttons on your site — a technique called clickjacking. This can trick users into changing account settings, making purchases, or granting permissions they did not intend to.

How to fix it:

X-Frame-Options: SAMEORIGIN

This allows your site to be framed by pages on your own domain (useful for admin panels or embedded previews) but blocks all other domains from framing it. If you never need your site in a frame, use DENY instead.

For most web servers, this is a single line of configuration:

# Nginx
add_header X-Frame-Options "SAMEORIGIN" always;

# Apache
Header always set X-Frame-Options "SAMEORIGIN"

6. X-Content-Type-Options (Medium Severity)

What it checks: Whether your server sends the X-Content-Type-Options header with the value nosniff.

Why it matters: Browsers sometimes try to be helpful by "sniffing" the content type of a response, ignoring what the server declared. An attacker can exploit this by uploading a file that the server treats as an image but the browser interprets as JavaScript. The nosniff directive forces browsers to respect the declared content type, preventing this class of attacks.

How to fix it:

This is the simplest security header to implement — one line, no configuration needed:

X-Content-Type-Options: nosniff

# Nginx
add_header X-Content-Type-Options "nosniff" always;

# Apache
Header always set X-Content-Type-Options "nosniff"

7. Referrer-Policy (Medium Severity)

What it checks: Whether your server sends a Referrer-Policy header.

Why it matters: When a visitor clicks a link on your site that leads to an external page, the browser sends a Referer header containing the URL they came from. If your URLs contain sensitive information (user IDs, search queries, session tokens in query parameters), that data leaks to every external site your visitors navigate to.

How to fix it:

The recommended value balances privacy with analytics functionality:

Referrer-Policy: strict-origin-when-cross-origin

This sends the full URL for same-origin requests (so your own analytics work correctly) but only sends the origin (domain) for cross-origin requests (protecting URL paths and query parameters from leaking to external sites).

8. Permissions-Policy (Medium Severity)

What it checks: Whether your server sends a Permissions-Policy header.

Why it matters: Modern browsers support powerful features like camera access, microphone access, geolocation, and payment APIs. If your site does not use these features, you should explicitly disable them. This prevents malicious scripts (injected through a compromised ad network, for example) from activating your visitors' cameras or requesting their location without your knowledge.

How to fix it:

Disable features your site does not use:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

The empty parentheses () mean "no one can use this feature, not even our own site." If you do use geolocation (for a store locator, for example), use geolocation=(self) to allow only your own domain.

9. Mixed Content (High Severity)

What it checks: Whether your HTTPS page loads any resources (images, scripts, stylesheets, fonts) over plain HTTP.

Why it matters: A single HTTP resource on an HTTPS page breaks the security guarantee. The browser may block the resource entirely (for scripts and stylesheets) or display a warning that undermines visitor trust. More importantly, that unencrypted resource request can be intercepted and modified by an attacker, potentially injecting malicious content into your otherwise secure page.

How to fix it:

  • Find mixed content: Open your browser's developer tools, load your site, and check the Console tab for mixed content warnings. PageVital also detects mixed content during its scan.
  • Update hardcoded URLs: Search your codebase, templates, and database content for http:// URLs that load assets. Replace them with https:// or protocol-relative // URLs.
  • Fix CMS content: In WordPress, plugins like "Better Search Replace" can update all http:// URLs in your database to https://.
  • Check third-party embeds: Verify that all external scripts, widgets, and tracking pixels use HTTPS URLs.

Prioritizing Your Security Fixes

Not all security checks carry equal weight. PageVital's scoring engine applies severity multipliers that reflect real-world impact:

| Severity | Multiplier | Checks | |----------|-----------|--------| | Critical | 3× | SSL Certificate, HTTPS Redirect | | High | 2× | HSTS, CSP, X-Frame-Options, Mixed Content | | Medium | 1× | X-Content-Type-Options, Referrer-Policy, Permissions-Policy |

If you can only tackle a few items today, fix the critical items first. Getting SSL and HTTPS redirect correct has the largest impact on both your score and your actual security posture.

Verifying Your Improvements

After implementing these changes, verify each one actually took effect:

  1. Clear your browser cache or use an incognito window — browsers cache security headers aggressively.
  2. Run a fresh PageVital scan to see your updated security score. The scan hits your live server and checks every header in real time.
  3. Check individual headers using your browser's developer tools: open the Network tab, click on the main document request, and inspect the Response Headers section.

Most hosting providers and CDNs apply configuration changes within minutes. If your changes are not reflected in a rescan, verify that the configuration is applied to the correct domain, server block, or virtual host — it is common to accidentally add headers to a staging environment instead of production.

From D to A in One Afternoon

The nine checks above represent the complete security evaluation that PageVital performs. Unlike application-level security (SQL injection, authentication flaws, business logic vulnerabilities), these are all configuration-level improvements that do not require code changes to your application.

A website that implements all nine items correctly will score an A in PageVital's security category. Combined with healthy performance, SEO, and technology scores, that security A contributes significantly to an overall grade that gives you and your visitors confidence in the site's health.

Run a free scan with PageVital to see exactly which security checks your site is passing and failing — then work through this list from the top and rescan to watch your grade climb.