← Back to Course Index

Module 5.8 — Security & SEO

Security is not a separate concern from SEO — it is a prerequisite for it. A hacked site loses rankings overnight. Mixed content warnings suppress crawling. A poorly configured HSTS policy breaks HTTPS migration. This module treats security as an integrated part of your technical SEO practice: something you audit, protect, monitor, and recover from systematically.

Learning Objectives


1. HTTPS: The Foundation

Google confirmed HTTPS as a ranking signal in 2014, and it has since become table stakes. More importantly, Googlebot prefers HTTPS URLs: if both HTTP and HTTPS versions of a page exist, Google canonicalises to HTTPS. Any site still serving on HTTP in 2025 is working against itself at every level.

Why HTTPS matters beyond the ranking signal

TLS certificate requirements

301 redirects from HTTP to HTTPS

Every HTTP URL must 301-redirect to its HTTPS equivalent. Not 302 — that would tell crawlers the move is temporary, preventing them from transferring PageRank and updating their index. The redirect must be:

# Nginx — force HTTPS for all requests
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}
# Apache — .htaccess redirect to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

2. HSTS — HTTP Strict Transport Security

HSTS is an HTTP response header that instructs browsers to never send a plain-HTTP request to your domain again — even if the user types http:// explicitly or clicks an HTTP link. The browser enforces HTTPS entirely client-side, without waiting for a server redirect.

This eliminates the "TLS stripping" attack vector: an attacker who intercepts traffic between the user and your server can downgrade HTTPS to HTTP before the redirect fires. HSTS prevents that window from existing.

The HSTS response header

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

HSTS preloading

The HSTS preload list (hstspreload.org) is a hardcoded list of domains shipped with every browser. A domain on this list gets HTTPS enforced before the first connection — even on a brand-new browser that has never visited the site.

Requirements before submitting to the preload list:

HSTS and SEO migrations

The critical warning: HSTS is extremely difficult to undo. Once a browser caches your HSTS policy (especially with a one-year max-age), rolling back to HTTP is not simply a matter of changing your server config — every browser that has cached the policy will refuse HTTP connections for the full max-age window. Being on the preload list is effectively permanent.

Before enabling HSTS on a site you are migrating to HTTPS:


3. Mixed Content

Mixed content is the single most common failure mode in HTTPS migrations. It occurs when an HTTPS page loads one or more resources (images, scripts, stylesheets, iframes, fonts) over HTTP.

Why mixed content breaks SEO and rankings

Types of mixed content

Note: browsers are progressively upgrading passive mixed content to active (and blocking it). Treat all mixed content as broken, not just the active kind.

Finding mixed content

Fixing mixed content

<!-- Meta tag version (for pages you cannot set headers on) -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
# HTTP header version (preferred — set at server or CDN level)
Content-Security-Policy: upgrade-insecure-requests

4. Hacked Sites — Detection, Cleanup, and Recovery

A hacked site faces one of the most severe SEO penalties Google applies. The consequences are immediate and severe: manual actions, de-indexing, interstitial warnings in Chrome ("This site may be hacked" / "This site contains malware"), and zero organic traffic until the issue is resolved and a reconsideration request is filed.

Understanding how hacks manifest in SEO terms is essential, because compromised sites are not always obviously broken to the site owner — the attacker specifically hides damage from admins while showing it to crawlers and users arriving from search.

How hacked sites affect SEO

Detecting a compromise

Site owners often discover a hack weeks or months after it occurred. Use these detection methods proactively:

Hacked site cleanup — step by step

Cleanup is not optional and cannot be partial. Leaving any trace of the attacker's code allows them to re-compromise the site (often via a backdoor they planted independently of the original attack vector).

  1. Take an immediate backup (even the compromised state): You need forensic evidence of what was injected. Do not skip this.
  2. Put the site into maintenance mode or take it offline if it is actively distributing malware. Protecting users takes priority over rankings.
  3. Identify the attack vector: Common vectors include outdated plugins/themes (WordPress especially), weak admin passwords, compromised hosting credentials, insecure file permissions, or a vulnerability in the server software itself. You must patch the entry point or the attacker returns within hours.
  4. Change all credentials: Admin accounts, FTP/SSH, database, cPanel, API keys for any connected services. Assume all credentials are compromised.
  5. Restore from a clean backup if you have one from before the compromise date. Verify the backup is actually clean (check file modification dates — backdoors may predate when you noticed the hack).
  6. Remove injected content: If no clean backup exists, manually remove all injected files, suspicious code blocks, and database entries. In WordPress this means:
    • Replacing core files from a fresh WordPress download (do not overwrite wp-config.php or wp-content/).
    • Replacing all plugins and themes from official sources.
    • Scanning wp-content/uploads/ for PHP files (there should be none).
    • Auditing the database for injected JavaScript in post content, widget options, and custom options rows.
  7. Harden the installation:
    • Update all software: CMS core, plugins, themes, PHP version, server software.
    • Remove unused plugins and themes (attack surface reduction).
    • Set correct file permissions: directories at 755, files at 644, wp-config.php at 400 or 440.
    • Disable PHP execution in upload directories (Nginx/Apache config or .htaccess).
    • Enforce strong passwords and enable two-factor authentication on all admin accounts.
    • Add a Web Application Firewall (WAF) — Cloudflare, Sucuri, or Wordfence (WordPress).
  8. Crawl the cleaned site with Screaming Frog before requesting review. Confirm no injected pages remain in the index.
  9. Request a Google review: In GSC → Security Issues report → click "Request Review" after confirming the site is clean. Describe exactly what you found and what you fixed. Google's review can take days to weeks; field data in Search Console (impressions, clicks, manual action status) will reflect the resolution.
  10. Monitor post-cleanup for re-infection. Compromised sites are frequently re-attacked because attackers know a cleaned site was vulnerable. Set up file-change monitoring (Sucuri, Wordfence, server-side auditd) and GSC email alerts.

Dealing with spam injection in search results

Attackers frequently create hundreds of spammy URLs under your domain. Even after cleanup, these may remain indexed. After your site is confirmed clean:


5. Content Security Policy (CSP)

A Content Security Policy is an HTTP response header (or <meta> tag) that tells the browser which sources of scripts, styles, images, and other resources are allowed to load on a given page. A well-configured CSP prevents cross-site scripting (XSS) attacks — one of the most common vectors for spam injection.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  frame-src 'none';
  object-src 'none';
  upgrade-insecure-requests;

CSP is complex to implement without breaking third-party tag manager integrations and inline scripts. Use report-only mode (Content-Security-Policy-Report-Only) first to capture violations without enforcing them, then tighten the policy iteratively.

From an SEO perspective, CSP matters because inline scripts injected by attackers will be blocked by a strict CSP before they can modify your page's content or redirect users — including Googlebot.


6. Security Headers and Their SEO Relevance

Several security-related HTTP headers have indirect SEO relevance. They do not directly affect ranking signals, but they protect the integrity of the signals that do.

X-Frame-Options / frame-ancestors

X-Frame-Options: DENY
# Or via CSP (preferred):
Content-Security-Policy: frame-ancestors 'none';

Prevents your pages from being embedded in iframes on other sites — protects against clickjacking attacks that can manipulate user interaction and falsely attribute engagement signals.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Prevents browsers from MIME-sniffing response content types. Without this, an attacker who uploads an HTML file disguised as an image could have it executed as HTML by the browser.

Referrer-Policy

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

Controls how much referrer information is sent when navigating away from your site. Relevant to analytics accuracy (how much of your traffic is attributed as "direct" due to referrer stripping) and privacy compliance.

Permissions-Policy

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

Limits which browser APIs pages can access. Prevents injected scripts from silently accessing sensitive browser capabilities.


7. Negative SEO and Link Spam Attacks

Negative SEO is an attack where a competitor (or malicious actor) attempts to harm your rankings by pointing mass quantities of toxic, spammy backlinks at your domain, hoping to trigger a manual action or algorithmic penalty.

Google's current position is that the Penguin algorithm is now integrated into the core algorithm and handles link spam algorithmically — most incoming link spam is neutralised automatically. However, in rare cases where a manual action is raised, or where a pattern of suspicious link growth is detected, the disavow tool is still available.

# Disavow entire domain
domain:spammydomain.com

# Disavow specific URL
https://spammydomain.com/specific-page-linking-to-you

The disavow file is not for routine backlink cleanup. Disavowing legitimate links is a direct self-harm action. Use it only when the harm is demonstrable and documented.


8. Security Monitoring as an SEO Practice

Security monitoring should be woven into your regular SEO workflow, not treated as a separate discipline. The following checks should run continuously or on a weekly cadence:


9. HTTPS Migrations — The SEO Checklist

Moving from HTTP to HTTPS is a site migration. It carries all the risks of any migration, plus the HSTS commitment risk outlined above. Use this checklist:


10. Key Concepts Summary


Hands-On Exercises

  1. HTTPS and mixed content audit: Take any live site. Run Screaming Frog and filter for insecure content. Open DevTools Console on three representative pages. Document every mixed content warning. Prescribe the exact fix for each finding (template change, database replacement, CSP header, or vendor escalation).
  2. Security header analysis: Use securityheaders.com on a site you manage or a test domain. Read the report. Write the Nginx or Apache configuration (or Next.js headers() config for Payload/Next.js learners) that would achieve an A rating.
  3. Hacked-site simulation: On a local WordPress installation, manually inject a <div style="display:none"> block containing spammy links into a page template. Then: (a) detect it using only the tools described in this module, (b) remove it, and (c) write a short remediation report as you would present it to a client.
  4. GSC Security monitoring setup: On a GSC property you have access to, confirm email notifications for Security Issues are enabled. Document your weekly SEO review checklist with security checks integrated.

Milestone

You have completed this module when you can: