Skip to content
ExponaBLOG
TECHNICAL SEO FOR DEVELOPERS · DAY 080 / 100

HTTPS and security for SEO: patterns, pitfalls and fixes

Security is a baseline expectation.

Expona Admin7 min read

By day 80 of your technical SEO journey, you've optimized site architecture, fixed crawlability issues, and tuned page speed. Now we tackle something that search engines and browsers treat as non-negotiable: HTTPS and security for SEO. If your site isn't secure, you're leaving rankings on the table and actively harming user trust—no amount of keyword optimization fixes that.

Why security matters to search engines

Google started ranking HTTPS as a tiebreaker signal in 2014 and has only strengthened that stance. Security isn't a nice-to-have feature; it's a baseline expectation. When crawlers encounter security issues—expired certificates, mixed content warnings, hacked pages—they either slow down crawling, flag your site, or stop indexing altogether. Users who see "Not Secure" warnings bounce immediately, tanking your engagement metrics. From an SEO perspective, you're optimizing in an unstable foundation if your security house isn't in order.

I've seen production platforms in e-commerce and SaaS lose organic visibility after certificate expirations or security breaches. The recovery is painful: you're fighting both algorithmic penalties and user perception damage. Let's work through the core security requirements that protect your SEO performance.

HTTPS everywhere — Redirect all HTTP traffic with 301s and use HSTS

The first rule is absolute: every page must load over HTTPS. This means every HTTP URL should redirect to its HTTPS equivalent using a 301 (permanent redirect). Search engines follow 301s and consolidate ranking signals to the HTTPS version, so the redirect itself isn't an SEO penalty—but sloppy redirects are.

Here's a production-grade redirect setup I've used in NestJS middleware:

html
import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';

@Injectable()
export class HttpsRedirectMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    // Force HTTPS in production
    if (process.env.NODE_ENV === 'production' && req.protocol !== 'https') {
      const redirectUrl = `https://${req.get('host')}${req.originalUrl}`;
      res.redirect(301, redirectUrl);
      return;
    }
    next();
  }
}

// In your main.ts or app.module.ts
app.use(HttpsRedirectMiddleware);

For Next.js sites, I handle this at the server level with middleware or next.config.js redirects. The key is that every HTTP request gets a 301 before the browser renders anything.

Beyond redirects, you need HTTP Strict-Transport-Security (HSTS). This header tells browsers to automatically upgrade future requests to HTTPS, even if a user types http:// in the address bar. It eliminates the redirect hop and protects against downgrade attacks.

html
// Express / NestJS
app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );
  next();
});

// Next.js headers config
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=31536000; includeSubDomains; preload',
          },
        ],
      },
    ];
  },
};

The max-age=31536000 sets the policy for one year. The preload directive lets you submit your domain to the HSTS preload list, which major browsers bake in permanently. This prevents any downgrade scenario. In my ride-hailing and travel platforms, HSTS eliminated entire classes of security incidents.

Valid certificates — Expired certificates block users and crawlers

An expired SSL/TLS certificate is a silent SEO killer. Browsers show a red warning, crawlers slow down or fail entirely, and users leave. I've seen e-commerce sites lose 30–50% of organic traffic within hours of certificate expiration simply because crawlers backed off and users avoided the site.

In production, certificate expiration should never surprise you. Use automated renewal with Let's Encrypt and acme.sh, or rely on your hosting provider (AWS Certificate Manager, Heroku, Vercel). Set calendar reminders 60 days before expiry as a safety net.

To verify your certificate is valid, use this check:

html
openssl s_client -connect yourdomain.com:443 -showcerts

Look for the notAfter date. If it's in the past or within 14 days, renew immediately. For platforms running on Kubernetes or Docker, I automate certificate renewal with cert-manager so expiry is impossible:

html
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: yourdomain-cert
spec:
  secretName: yourdomain-tls
  issuerRef:
    name: letsencrypt-prod
  dnsNames:
    - yourdomain.com
    - www.yourdomain.com
  duration: 2160h # 90 days
  renewBefore: 720h # 30 days

Monitoring is equally critical. Set up alerts via your hosting provider or a tool like Sectigo (formerly Comodo) that watches expiry dates and notifies you 30 days before renewal. This proactive approach has saved me from multiple outages.

Mixed content — HTTP resources on HTTPS pages break padlocks and features

A page loads over HTTPS, but if it includes images, stylesheets, scripts, or fonts from HTTP sources, browsers mark it as "mixed content" and break the green padlock. Users see warnings, and some features (like service workers or geolocation) won't load. From an SEO perspective, crawlers still index the page, but mixed content signals poor security posture.

Mixed content comes from three sources: old CDN URLs, third-party widgets, and legacy image references. Here's a real scenario: a CRM platform I worked on had HTTPS everywhere, but customer testimonial images still loaded from an old HTTP server. Browsers blocked those images, the page looked broken, and users bounced.

Audit your site with the browser DevTools console (you'll see warnings), or run it through Mozilla's HTTP Observatory. Then fix systematically:

html
// ❌ Mixed content
<img src="http://cdn.example.com/image.jpg" alt="Product" />


// ✅ HTTPS only
<img src="https://cdn.example.com/image.jpg" alt="Product" />

For dynamic content (user-generated or third-party APIs), use a content security policy (CSP) to block HTTP:

html
// In your response headers
Content-Security-Policy: upgrade-insecure-requests;

This directive tells the browser to automatically upgrade any HTTP request to HTTPS. In Next.js:

html
module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "upgrade-insecure-requests",
          },
        ],
      },
    ];
  },
};

In my SaaS platforms, this single header eliminated 99% of mixed content issues without requiring code changes.

Security breaches don't just slow crawling; they actively harm SEO. Hackers inject spam pages, redirect traffic, or backlink to malicious sites using your domain's authority. Google's Search Console flags hacked content, and recovery requires removal, verification, and often a manual review request.

I've seen trading platforms and ride-hailing apps compromised by SQL injection or weak admin credentials. The attacker added hundreds of spam pages, and recovery took weeks: removing the pages, patching the vulnerability, resubmitting to Google, and rebuilding trust.

Prevention is simpler than recovery. Monitor three things:

  1. Unauthorized pages: Use Search Console's "Coverage" report and site: operator to check for unexpected indexed pages. Set up a cron job to crawl your sitemap and alert if new URLs appear unexpectedly.
  2. Backlinks: Monitor inbound links via Ahrefs or SEMrush. Sudden spikes in spam backlinks (casino, pharma, etc.) signal compromise. Google ignores most spam links but acts on patterns.
  3. Server logs: Check access logs for 200 responses to admin paths, unusual POST requests, or file uploads. In production, forward logs to a SIEM (security information and event management) tool.

Programmatically, integrate file integrity monitoring:

html
// Pseudo-code for integrity checking
const fs = require('fs');
const crypto = require('crypto');

const baselineHashes = require('./baseline.json');

function checkIntegrity(filePath) {
  const content = fs.readFileSync(filePath);
  const hash = crypto.createHash('sha256').update(content).digest('hex');
  
  if (hash !== baselineHashes[filePath]) {
    console.error(`Modified: ${filePath}`);
    alert('Security team'); // Send to alerting system
  }
}

// Run on startup or periodically
checkIntegrity('./public/index.html');

In production CRM and e-commerce systems, I've also added Web Application Firewalls (WAF) like AWS WAF or Cloudflare to block injection attacks at the edge. This stops 99% of automated attacks before they reach your application.

Common mistakes

  • Redirecting with 302 instead of 301: A 302 is temporary; it tells search engines not to consolidate ranking signals. Always use 301 for HTTP → HTTPS.
  • Forgetting www and non-www variants: Set a canonical preference and redirect the non-preferred version. Don't let both live.
  • Mixing HSTS with short max-age: Start with 300 seconds for testing, then bump to 31536000 (one year) once stable. A too-short header doesn't protect users.
  • Ignoring third-party widgets: Ads, analytics, and chat widgets often serve over HTTP. Update their embed code or use script proxies to serve them over HTTPS.
  • No monitoring for certificate expiry: Set reminders, not just fire-and-forget renewals. I've seen Let's Encrypt renewals fail silently.
  • Assuming Google ignores security issues: Security affects crawlability, indexation, and ranking. It's not a nice-to-have.

Key takeaways

  • HTTPS is non-negotiable for SEO and user trust. Redirect all HTTP traffic with 301s and enable HSTS with preload.
  • SSL/TLS certificates must be valid and renewed automatically. Expiration kills both crawling and user access.
  • Audit and eliminate mixed content (HTTP resources on HTTPS pages). Use CSP's upgrade-insecure-requests as a safety net.
  • Monitor for hacked content via Search Console, backlink tools, and server logs. Implement WAF and file integrity checks in production.
  • Security is a ranking factor and a crawlability factor. Invest in it early; remediation is painful and slow.
ShareXLinkedInReddit

Found this useful? Support the writing.

Buy me a coffee
Written by
Expona Admin
Site administrator

Comments

Loading comments…

Leave a comment

Comments are reviewed before they appear. Be kind and stay on topic.

Related articles