Skip to main content
← Back to blog

SEO Hāna 7: Vaito‘anga — Ne faka‘āko‘i ia ‘e Google i he 2026

·12 min read·by LANGR SEO

SEO Hāna 7: Vaito‘anga

Ko e Hāna 7 o e SEO Hāna 13. 'E lele 'a e vaito‘anga, 'oku 'ikai ko e faka'āko 'o einga — 'oku ngata 'a e fakamatala ki he taumafa ‘o e mālohi a e search rankings. 'I he ta'u 2014, na'e fakahaa 'e Google 'a e HTTPS ko e mālohi ranking, 'mo e ngaahi uepā na'e hiki i he to'onga.

Most site owners think of security as a binary: "We have SSL, so we're secure." In reality, Google evaluates dozens of security signals. Sites with proper security headers, valid certificates, and no mixed content outrank sites with just a basic SSL certificate — all else being equal.

The good news: most security fixes are one-time configurations. Set them once, and they protect your rankings permanently.

SSL Configuration

SSL (technically TLS) encrypts the connection between your server and visitors. Since 2014, Google has explicitly confirmed HTTPS as a ranking signal. In 2026, not having HTTPS isn't just a ranking issue — Chrome marks HTTP sites as "Not Secure" in the address bar, destroying user trust.

Requirements for proper SSL:

| Requirement | Why | How to Check | |-------------|-----|--------------| | Valid certificate | Expired = browser warning = bounced users | Check expiry date | | Full chain | Incomplete chains fail on some devices | SSL Labs test | | TLS 1.2+ | Older versions have known vulnerabilities | SSL Labs test | | No SHA-1 | Deprecated, browsers reject it | Certificate details | | SAN coverage | www and non-www must both be covered | Certificate details | | Auto-renewal | Prevents expiry disasters | Let's Encrypt / provider config |

SSL scoring:

100% = Valid cert + Full chain + TLS 1.3 + Strong cipher + Auto-renew
  0% = Expired or missing certificate

Common SSL mistakes:

  1. Certificate expires without notice — Set up monitoring (Step 6) at minimum 30 days before expiry
  2. Incomplete certificate chain — Server must send intermediate certificates, not just the leaf
  3. Mixed content — HTTPS page loads HTTP resources (images, scripts, stylesheets)
  4. Redirect loops — HTTP → HTTPS → HTTP cycles caused by misconfigured CDN/proxy
  5. Non-www vs www mismatch — Certificate covers one but not the other

Quick win: Run your domain through SSL Labs (ssllabs.com/ssltest). Anything below an "A" rating has actionable issues. Most hosting providers fix these with one click.

Security Headers

Security headers are HTTP response headers that instruct browsers how to behave when loading your site. They prevent entire categories of attacks — and Google's crawlers check for them.

The essential security headers:

Content-Security-Policy (CSP)

CSP is the most powerful security header. It tells browsers exactly which resources (scripts, styles, images, fonts) are allowed to load on your pages.

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; connect-src 'self' https://api.example.com; frame-ancestors 'none';

What CSP prevents:

  • Cross-site scripting (XSS) attacks
  • Data injection attacks
  • Clickjacking (via frame-ancestors)
  • Unauthorized script execution (cryptominers, ad injectors)

CSP deployment strategy:

  1. Start with Content-Security-Policy-Report-Only (logs violations without blocking)
  2. Monitor reports for 1-2 weeks
  3. Whitelist legitimate sources
  4. Switch to enforcing mode
  5. Add report-uri or report-to for ongoing violation logging

X-Frame-Options

Prevents your site from being embedded in iframes on other domains (clickjacking protection).

X-Frame-Options: DENY

Or if you need to allow same-origin framing:

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options

Prevents browsers from MIME-type sniffing (interpreting files as different types than declared).

X-Content-Type-Options: nosniff

This one-liner prevents attacks where a .jpg file contains hidden JavaScript that the browser might execute.

Referrer-Policy

Controls how much referrer information is sent when users click links from your site.

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

This sends the full URL for same-origin requests but only the origin (domain) for cross-origin requests. Balances analytics needs with privacy.

Permissions-Policy

Controls which browser features (camera, microphone, geolocation, etc.) can be used on your site.

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

Disabling features you don't use prevents third-party scripts from abusing them.

Header implementation example (Next.js):

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: '/(.*)',
      headers: [
        { key: 'X-Content-Type-Options', value: 'nosniff' },
        { key: 'X-Frame-Options', value: 'SAMEORIGIN' },
        { key: 'Referrer-Policy', value: 'strict-origin-when-cross-origin' },
        { key: 'Permissions-Policy', value: 'camera=(), microphone=(), geolocation=()' },
        { key: 'Strict-Transport-Security', value: 'max-age=31536000; includeSubDomains; preload' },
      ]
    }]
  }
}

Header implementation (Apache .htaccess):

Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Header implementation (Nginx):

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Quick win: Add all 5 headers above to your server configuration. This takes 5 minutes and immediately improves your security posture in any scan tool.

HSTS Preload

HTTP Strict Transport Security (HSTS) tells browsers to always use HTTPS for your domain — even before the first request. Without HSTS, the first visit to your site may still use HTTP (vulnerable to interception) before the redirect to HTTPS happens.

HSTS header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The three directives:

| Directive | Meaning | |-----------|---------| | max-age=31536000 | Remember this for 1 year (in seconds) | | includeSubDomains | Apply to all subdomains too | | preload | Request inclusion in browser preload lists |

HSTS preload list:

The ultimate HSTS protection. Browsers ship with a built-in list of domains that must always use HTTPS. Submitting your domain to hstspreload.org means:

  • First-time visitors get HTTPS immediately (no HTTP → HTTPS redirect)
  • Impossible for attackers to downgrade connections
  • Permanent (difficult to remove once submitted)

Requirements for HSTS preload:

  1. Valid HTTPS certificate
  2. Redirect all HTTP to HTTPS (including subdomains)
  3. HSTS header with max-age >= 31536000
  4. HSTS header includes includeSubDomains
  5. HSTS header includes preload
  6. All subdomains must support HTTPS

Warning: Only submit to preload if ALL your subdomains support HTTPS. The includeSubDomains directive means any HTTP-only subdomain will become inaccessible.

Quick win: If you already have HTTPS on all subdomains, add the full HSTS header and submit to hstspreload.org. Processing takes a few weeks but the protection is permanent.

Vulnerability Scanning

Automated vulnerability scanning identifies known security issues in your stack before attackers exploit them.

What vulnerability scanning checks:

  • Outdated software: WordPress, plugins, JavaScript libraries with known CVEs
  • Exposed files: .env, .git, wp-config.php, database dumps
  • Information leakage: Server version headers, debug mode, stack traces
  • Default credentials: Admin pages without auth, default passwords
  • Open ports/services: Unnecessary services exposed to the internet
  • Injection points: Forms without CSRF protection, unvalidated inputs

Common vulnerabilities by platform:

| Platform | Top Vulnerability | Fix | |----------|-------------------|-----| | WordPress | Outdated plugins | Auto-update + WAF | | Shopify | Third-party app permissions | Audit app list quarterly | | Next.js | Exposed API routes | Auth middleware + rate limiting | | Static sites | CDN misconfiguration | Review cache rules | | Custom | SQL injection | Parameterized queries |

Scanning frequency:

  • Daily: Automated surface scan (SSL, headers, exposed files)
  • Weekly: Dependency vulnerability check (npm audit, WordPress plugin scanner)
  • Monthly: Deep scan with authenticated testing
  • After every deploy: Regression check

Quick win: Run npm audit (Node.js) or check your CMS plugin list for outdated components. Fix critical/high severity issues immediately.

Mixed Content

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets, iframes) over HTTP. This partially breaks encryption and triggers browser warnings.

Types of mixed content:

| Type | Severity | Example | Browser Behavior | |------|----------|---------|------------------| | Active | High | HTTP script, iframe, CSS | Blocked by default | | Passive | Medium | HTTP image, video, audio | Loaded with warning |

Active mixed content is blocked by modern browsers — meaning your scripts and styles simply won't load. Passive mixed content loads but shows security warnings.

Finding mixed content:

  1. Open Chrome DevTools → Console
  2. Look for "Mixed Content" warnings
  3. Alternatively, scan with a crawler (Screaming Frog, LANGR)

Common mixed content sources:

  • Hardcoded http:// URLs in content (blog posts, product descriptions)
  • Third-party widgets loading HTTP resources
  • Embedded content (YouTube old embeds, social media widgets)
  • CSS background-image with HTTP URLs
  • Fonts loaded over HTTP

Fixing mixed content:

<!-- Bad -->
<img src="http://example.com/image.jpg" />

<!-- Good -->
<img src="https://example.com/image.jpg" />

<!-- Best (protocol-relative, adapts to page protocol) -->
<img src="//example.com/image.jpg" />

Database fix (WordPress):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://yourdomain.com', 'https://yourdomain.com');
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'http://yourdomain.com', 'https://yourdomain.com');

Quick win: Open your homepage in Chrome, press F12, check the Console tab for mixed content warnings. Fix any that appear — these are directly visible to Google.

Third-Party Script Risks

Every external script you load is a potential security (and performance) liability. Third-party scripts can:

  • Be compromised (supply chain attacks)
  • Track your users without consent (GDPR violation)
  • Slow your site (render-blocking, network latency)
  • Break functionality (version updates, outages)
  • Inject unwanted content (ad scripts gone wrong)

Audit your third-party scripts:

| Script | Necessary? | Risk Level | Alternative | |--------|-----------|------------|-------------| | Google Analytics | Often yes | Low | Server-side tracking | | Chat widgets | Maybe | Medium | Self-hosted solutions | | Social share buttons | Rarely | Medium | Static share links | | A/B testing | Sometimes | High | Server-side testing | | Retargeting pixels | Business decision | High | First-party data | | Font CDNs | Convenient | Low | Self-host fonts |

Risk mitigation for essential third-party scripts:

  1. Subresource Integrity (SRI): Hash verification prevents tampered scripts from loading
<script src="https://cdn.example.com/lib.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxAE+sO0..."
        crossorigin="anonymous"></script>
  1. CSP restrictions: Only allow scripts from known domains
  2. Sandboxed iframes: Isolate third-party widgets
  3. Regular audits: Quarterly review of all external resources
  4. Monitoring: Alert on new external domains appearing in your pages

Quick win: List every