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
- Understand why HTTPS is foundational to indexing, ranking, and trust signals.
- Configure HSTS correctly without locking yourself out of your own site.
- Diagnose and fix mixed content — the most common HTTPS migration failure.
- Detect, clean, and recover from a hacked site (spam injection, malware, cloaking).
- Recognize spam injection patterns and their SEO fingerprints.
- Use Google Search Console and third-party tools to monitor for compromise.
- Understand the policies Google applies to hacked and deceptive content.
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
-
Data integrity: HTTP traffic is plain-text — ISPs and network intermediaries can
inject content (ads, scripts, redirects) into HTTP pages. HTTPS prevents this; it also prevents
stripping of referrer headers, which restores referral traffic attribution you lose over
plain HTTP.
-
User trust: Browsers show a "Not Secure" warning on HTTP pages. This elevates
bounce rate and suppresses conversions, both indirect SEO signals.
-
HTTP/2 & HTTP/3: These newer, faster protocols are practically limited to HTTPS
connections. Staying on HTTP means staying on HTTP/1.1 — a direct performance penalty.
-
Service Worker & modern APIs: Progressive enhancement features that improve
performance and UX require HTTPS. No HTTPS means no Service Workers, no Web Push, no device APIs.
TLS certificate requirements
- Use a certificate from a trusted Certificate Authority (CA). Let's Encrypt (free) is fully
trusted by all major browsers and Googlebot.
- Ensure the certificate covers all subdomains you serve — either a wildcard (
*.example.com)
or a SAN (Subject Alternative Names) certificate.
- Set up auto-renewal. Certificate expiry is one of the most avoidable security (and SEO) disasters:
an expired cert causes browser "Your connection is not private" errors, which effectively removes
a page from organic traffic overnight.
- Use TLS 1.2 or 1.3. TLS 1.0 and 1.1 are deprecated and should be disabled at the server level.
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:
- A true 301 at the server level (Apache, Nginx, CDN), not a client-side redirect.
- Direct:
http://example.com/page/ → https://example.com/page/ — not
through an intermediate step that introduces a redirect chain.
- Comprehensive: every subdomain and every HTTP URL on the site.
# 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
max-age=31536000 — Remember this policy for one year (31,536,000 seconds). Start
with a low value (e.g., 300) when first deploying and increase it over time as you
gain confidence.
includeSubDomains — Apply the policy to all subdomains. Omit this if any subdomain
still needs HTTP (e.g., a legacy staging environment).
preload — Indicates willingness to be included in browsers' built-in HSTS preload
lists. This is the maximum protection level.
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:
- A valid certificate on all served content.
- Redirect of all HTTP traffic to HTTPS.
- HSTS header with
max-age of at least 31,536,000 seconds on the base domain.
includeSubDomains directive present.
preload directive present.
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:
- Confirm every page, asset, and subdomain is serving correctly over HTTPS.
- Confirm certificate coverage and auto-renewal are in place.
- Start with a short
max-age (300 seconds), test for a week, then ramp up.
- Do not add
includeSubDomains until all subdomains are HTTPS-ready.
- Do not submit to the preload list until everything is confirmed stable.
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
-
Browser blocking: Modern browsers block active mixed content
(scripts, stylesheets, iframes) outright. The page may fail to render correctly or entirely —
killing user experience metrics and bouncing visitors.
-
Browser warnings: Even passive mixed content (images, audio) triggers a
"Not Secure" indicator in the browser UI, undermining user trust.
-
Invalidates HTTPS as a signal: A page with active mixed content is not a
secure page. Googlebot treats it accordingly.
-
Performance: HTTP resources do not benefit from the same CDN edge caching or
HTTP/2 multiplexing as your HTTPS resources, adding latency.
Types of mixed content
-
Active mixed content (blocked by default):
<script src="http://...">,
<link rel="stylesheet" href="http://...">, <iframe src="http://...">,
XMLHttpRequest to HTTP endpoints, fetch() to HTTP.
-
Passive mixed content (flagged but not blocked):
<img src="http://...">,
<audio src="http://...">, <video src="http://...">.
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
-
Browser DevTools: Open the Console tab. Mixed content errors and warnings appear
in red/yellow. The Network tab filtered to HTTP shows you exactly which resources are the culprits.
-
Screaming Frog: Under "Response Codes" → filter for HTTP resources loaded on HTTPS
pages. Or use the "Insecure Content" filter directly.
-
Search Console: The Security Issues report surfaces HTTPS issues, though it may
lag behind real-time state.
-
Lighthouse: The audit "Does not use HTTPS" and related items flag insecure resources.
Fixing mixed content
-
Update hardcoded URLs: Find and replace all
http://example.com/
references in templates, CMS content, and database records to use relative URLs
(/path/to/asset) or protocol-relative URLs (//example.com/path).
Protocol-relative is acceptable but relative paths are cleaner.
-
Database search-replace (WordPress): Use WP-CLI
(
wp search-replace 'http://example.com' 'https://example.com' --all-tables)
or a plugin like "Better Search Replace" after making a backup. Serialised data requires a
tool that handles PHP serialised strings correctly.
-
Third-party resources: If a third-party script only serves over HTTP, that is
their problem you need to escalate — or replace the vendor. You cannot force an external domain
to serve HTTPS.
-
CSP upgrade-insecure-requests: As a stopgap (not a fix), the
Content Security Policy directive
upgrade-insecure-requests instructs browsers to
upgrade HTTP sub-resources to HTTPS automatically. This helps with resources you control but
cannot update immediately. It does not fix active mixed content from truly HTTP-only origins.
<!-- 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
-
Spam content injection: The attacker injects keyword-stuffed pages (often in
pharmaceuticals, gambling, luxury goods, or adult content) that rank in your site's index under
your domain's authority. These pages are invisible in your CMS and sometimes shown only to
Googlebot.
-
Link spam injection: Hidden links (using CSS
display:none, tiny
font sizes, off-screen positioning, or white text on white backgrounds) are inserted into every
page, pointing to the attacker's sites to pass PageRank.
-
Cloaking: The server returns different HTML to Googlebot than to regular users —
the classic definition of cloaking, which is a manual action trigger in its own right.
-
Redirect hacks: Mobile users or users arriving from Google search are
transparently redirected to scam/malware sites, while desktop direct visitors see the normal page.
-
Malware distribution: Scripts injected into pages attempt to install malware on
visitors' machines. Google's Safe Browsing database flags the domain, triggering Chrome
interstitials.
Detecting a compromise
Site owners often discover a hack weeks or months after it occurred. Use these detection methods
proactively:
-
Google Search Console — Security Issues report: GSC is often the first place
Google alerts you. Enable email alerts. A "Security Issues" notification requires immediate
action.
-
Site: operator search: Run
site:yoursite.com casino or
site:yoursite.com viagra in Google Search. If you see indexed pages you did not
create, the site is compromised.
-
Google Safe Browsing Transparency Report:
https://transparencyreport.google.com/safe-browsing/search?url=yoursite.com.
Check if your domain has been flagged for malware or phishing.
-
View Source vs CMS output: Fetch your page source from a browser and search for
hidden links, suspicious
<script> tags, iframes to unknown domains, or
base64-encoded blobs. Compare against what your CMS template outputs.
-
Fetch as Googlebot: Use GSC's URL Inspection tool to see what Googlebot sees.
Spam content only visible to Googlebot will appear in the "Rendered HTML" view. This exposes
cloaking.
-
Sucuri SiteCheck: Sucuri's free scanner checks your public pages against known
malware signatures and blacklists.
-
Server-side file integrity checks: On the server, run tools like
rkhunter, chkrootkit, or compare file hashes against a clean backup.
Look for recently modified core files: find /var/www -name "*.php" -mtime -7
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).
-
Take an immediate backup (even the compromised state): You need forensic evidence
of what was injected. Do not skip this.
-
Put the site into maintenance mode or take it offline if it is actively
distributing malware. Protecting users takes priority over rankings.
-
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.
-
Change all credentials: Admin accounts, FTP/SSH, database, cPanel, API keys
for any connected services. Assume all credentials are compromised.
-
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).
-
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.
-
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).
-
Crawl the cleaned site with Screaming Frog before requesting review. Confirm no
injected pages remain in the index.
-
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.
-
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:
-
Use the GSC URL Removal Tool to emergency-remove URLs that appear in search during the attack
window. Note: this is a temporary suppression, not permanent de-indexing. Once your site is
clean and re-crawled, the pages will naturally return as 404s and drop.
-
Ensure all injected URLs return 404 or 410 after cleanup. Do not 301-redirect them — you would
send PageRank to the spam destination.
-
Submit an updated sitemap that reflects only legitimate URLs.
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.
-
Monitoring: Track your backlink profile weekly in Google Search Console
(Links report), Ahrefs, or Semrush. Sudden large spikes in low-quality referring domains are
a signal.
-
Disavow file: Available in GSC at domain level. Submit as a last resort and
only when there is clear evidence of manual action or algorithmic impact from links you could
not have placed yourself. Format:
# 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:
-
Google Search Console Security Issues: Enable email notifications. Check the
report weekly as part of your GSC review.
-
Google Safe Browsing status: Check
https://transparencyreport.google.com/safe-browsing/search?url=yourdomain.com
monthly, and immediately after any suspected compromise.
-
Crawl spot-checks: Include
site:yourdomain.com casino type
searches in your monthly SEO review. Takes 30 seconds and catches hacks early.
-
Uptime monitoring with SSL checks: Services like UptimeRobot, Pingdom, or
Better Uptime can monitor certificate expiry and alert you 30/14/7 days in advance.
-
Log file monitoring: Unusual Googlebot crawl patterns — such as a sudden spike
in crawl activity on URLs you do not recognise, or 404 responses on paths you have never
created — can indicate injected pages were discovered and removed (or that an attack is
ongoing).
-
File integrity monitoring: On self-hosted environments, set up server-side
tools or WordPress plugins (Wordfence, iThemes Security) to alert on unexpected file changes.
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:
- Provision and install TLS certificate with correct domain/subdomain coverage.
- Test HTTPS availability on all pages before enabling redirects.
- Implement 301 redirects from HTTP to HTTPS at the server or CDN level — not via JavaScript
or a plugin-only approach.
- Update all internal links to use HTTPS (or protocol-relative / root-relative URLs).
- Update the
<link rel="canonical"> on all pages to HTTPS URLs.
- Update XML sitemap URLs to HTTPS. Submit the updated sitemap in GSC.
- Update all external backlinks you control (social profiles, Google Business Profile,
directory listings).
- Update GSC: add the HTTPS property. If using a domain property, it covers both — if using
a URL-prefix property, add both the HTTP and HTTPS versions.
- Run Screaming Frog on the HTTPS site: zero mixed content, all canonicals point to HTTPS,
no HTTP internal links generating redirect hops.
- Run Lighthouse and DevTools to confirm no mixed content warnings in console.
- Deploy HSTS header with a low
max-age. Monitor for two weeks. Increase to
one year. Consider preload submission after six months of confirmed stability.
- Monitor impressions/clicks in GSC post-migration. A temporary dip is normal (a few days to
two weeks); a prolonged decline indicates a configuration error in redirects, canonicals,
or the sitemap.
10. Key Concepts Summary
- HTTPS is a ranking signal, a prerequisite for HTTP/2 performance, and the
foundation of all other security measures on the web.
- HSTS eliminates the HTTP→HTTPS redirect window but is near-irreversible once
deployed — configure it incrementally.
- Mixed content invalidates HTTPS for the user and the crawler; hunt it
with DevTools and Screaming Frog and fix it at the source, not just with
upgrade-insecure-requests.
- Hacked sites face deindexing, manual actions, and Safe Browsing warnings.
Detection, full cleanup (not partial), and hardening are required before Google will
reinstate rankings.
- Spam injection is designed to be invisible to site owners and visible only
to crawlers — active monitoring via GSC Security Issues, site: operator checks, and file
integrity tools is the only reliable defence.
- Security headers (CSP, HSTS, X-Content-Type-Options) protect the integrity
of the page content that search engines index.
- Security monitoring is SEO monitoring. Treat them as the same practice.
Hands-On Exercises
-
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).
-
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.
-
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.
-
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:
- Perform a full HTTPS health check on a site and fix all mixed content findings.
- Write a correct HSTS header configuration, explain the preload risks, and describe the correct
incremental deployment process.
- Follow the complete hacked-site cleanup and recovery process from detection through to GSC
review request, without referencing this material.
- Identify, from server response headers and page source alone, whether a site is adequately
hardened against the attack vectors described in this module.
- Integrate security monitoring into a weekly technical SEO operations workflow.