Ch 17 — Security incidents¶

Part VI — Change events · The Technical SEO Reference

Playbook coupling: seo-checklist.md covers security in the hacked-site playbook (line 226: quarantine → assess → clean → review; rendered-HTML forensics) and HTTPS in one Phase 1 line (line 107). This chapter supplies the depth: the HTTPS doctrine archaeology (what Google actually ever promised), certificates/HSTS/mixed-content mechanics, Safe Browsing as the enforcement engine, the complete Security Issues taxonomy, field guides to the three classic hack patterns, the full recovery playbook with review timelines, and DNS-level compromise.

Security failures reach SEO through two separate machines. Safe Browsing flags dangerous content and puts warnings in front of users (browser interstitials, SERP labels) — that's about protection, and it has a review process. Indexing/canonicalization quietly reacts to certificate and protocol problems — no warning, no penalty, just your HTTP URL becoming canonical or your hacked spam pages entering the index. Diagnosing means knowing which machine you're looking at.

17.1 HTTPS — what Google actually promised, in three layers¶

🟢 2014: "we're starting to use HTTPS as a ranking signal… only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content." Google reserved the right to strengthen it and never announced doing so.
🟢 2015 — the real mechanism, indexing preference: Google will "typically choose to index the HTTPS URL" of an HTTP/HTTPS pair only if eight conditions hold: no insecure dependencies; not robots-blocked; no redirects to/through HTTP; no rel=canonical to the HTTP page; no noindex; no on-host outlinks to HTTP URLs; sitemap lists the HTTPS (or omits the HTTP) URL; valid TLS certificate (Dec 2015 post). ⚠️ Any one failure can flip your indexed canonical back to HTTP — silently (→ Ch 8).
🟢 Today: "Are your pages served in a secure fashion?" is a self-assessment question; "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher"; the HTTPS report help states the preference: "If your site has a page with both an HTTP and HTTPS address, Google prefers to index the HTTPS version."
⚠️ Doc-location trap (V0-verified): the dedicated doc at developers.google.com/search/docs/crawling-indexing/https returns a hard 404 with no redirect (Wayback shows it 404ing since at least Sept 2025 — it never moved); the older /advanced/security/https path 301s to web.dev. Cite web.dev/enable-https and the HTTPS report help; the HTTPS-canonical-preference text's live home is the canonicalization doc (→ Ch 8).

17.2 Implementing HTTPS: certificates, HSTS, preload¶

🟢 Mechanics (web.dev/enable-https): 2,048-bit RSA key pair minimum; "Use 301 (Moved Permanently)… and redirect your users to the HTTPS version"; migration is formally a site move with URL changes minus Change of Address (→ Ch 16 §16.8).
🟢 HSTS (📘 RFC 6797): "Use HTTP Strict Transport Security (HSTS) to avoid the cost of the 301 redirect" — the browser rewrites future http:// requests before they leave the machine. ⚠️ Hard-fail semantics: "Clients that have listed your site as a known HSTS Host are likely to hard-fail if your site ever has an error in its TLS configuration." 🟢 HSTS is a consistency aid — never documented as a ranking input (and per the canonicalization doc, HSTS cannot override canonical selection → Ch 8).
🟢 HSTS preload (hstspreload.org, Chrome-run): valid cert, same-host HTTP→HTTPS redirect, all subdomains on HTTPS incl. www, max-age ≥ 31536000 + includeSubDomains + preload. ⚠️ "Inclusion in the preload list cannot easily be undone… it takes months for a change to reach users" — preload only when every subdomain is permanently HTTPS-ready.
🟡 Certificate class (DV/OV/EV) makes no difference to Search — docs only ever require "a valid certificate"; Mueller: "A free certificate from Let's Encrypt works just as well" (🟡 Mueller via Twitter, 2019, per SEJ writeup — fetched 2026-08-04). 📘 Wildcard certs cover one label level only (*.example.com ≠ a.b.example.com — RFC 9525 §6.3, formerly RFC 6125: the wildcard matches a single left-most label) — a recurring "invalid certificate" cause on deep subdomains.

17.3 Mixed content¶

🟢 Definition (web.dev): secure HTML + insecure subresources. Passive (images/video/audio) — Chrome auto-upgrades to HTTPS and blocks if no secure version; active (scripts, stylesheets, iframes) — blocked outright: "Active mixed content interacts with the page as a whole."
🟢 SEO tie-in: "It doesn't contain insecure dependencies" is condition #1 of the HTTPS-canonical list (§17.1) — mixed content can silently cost you the HTTPS canonical. 📘 Fix at scale with the CSP directive upgrade-insecure-requests (W3C).
Rendering tie-in: blocked active resources are also unfetchable render dependencies (→ Ch 6 §6.2).

17.4 The GSC HTTPS report + Chrome's 2026 deadline¶

🟢 The HTTPS report shows indexed HTTP-vs-HTTPS with a failure taxonomy mapping 1:1 to §17.1's conditions: "HTTP marked with canonical tag"; "HTTPS has invalid certificate"; "Sitemap points to HTTP"; "HTTPS has redirect" (to HTTP); "HTTPS URL is roboted"; "HTTPS not evaluated."
🟢 ⚠️ The Chrome timeline that makes HTTP untenable (blog.google, Oct 28, 2025 — odd slug, verified live by V0): Chrome 147 (April 2026, already shipped) enabled Always Use Secure Connections for Enhanced-Safe-Browsing users; Chrome 154 (October 2026) enables it "by default" for everyone: "Chrome will ask for the user's permission before the first access to any public site without HTTPS." An HTTP site will sit behind a permission prompt for most of the web within months — the CTR argument now dwarfs any ranking argument.

17.5 Safe Browsing — the enforcement engine¶

🟢 Safe Browsing "helps protect over five billion devices every day"; it powers the browser interstitials and two SERP labels: "This site may be hacked" (spam-hack; removed "after we check that your site is fixed") and "This site may harm your computer" (malware).
🟢 Public diagnostic without GSC access: the Safe Browsing site status at transparencyreport.google.com/safe-browsing/search?url=… — first move when auditing any acquired or client domain.
🟢 ⚠️ Repeat Offenders (policy doc, updated 2025-12-10): "Sites that repeatedly switch between compliant and noncompliant behavior within a short window of time will be classified as Repeat Offenders" — review requests blocked for 30 days. 🟡 The famous "hacked sites are exempt" carve-out exists only in the Nov 8, 2016 launch post ("websites that are hacked will not be classified as Repeat Offenders" — post body unfetchable in 2026; wording per contemporaneous coverage, e.g. WeLiveSecurity/9to5Google Nov 2016); the current policy doc no longer states it (re-confirmed live 2026-08-04: absent). The book presents it as historical-informal, not current policy.

17.6 The Security Issues taxonomy — complete¶

🟢 From the report help. Consequence: "warning label in search results or an interstitial warning page in the browser."

Hacked content (backed by the spam policies, 2026-05-15: "any content placed on a site without permission, due to vulnerabilities in a site's security"): - Hacked: Malware — site infected by/hosting malware. - Hacked: Code injection — malicious code in existing pages ("malicious JavaScript injected directly into the site, or into iframes"; crypto-mining). - Hacked: Content injection — spammy links/text "which may be harder for you and your users to spot… hidden links or hidden text… or cloaking." - Hacked: URL injection — "A hacker has created new pages on your site" (possibly even making your server "participate in a denial-of-service attack"). - Policy adds the fourth form: hacked redirects — "depends on the referrer, user agent, or device. For example, clicking a URL in Google Search results could redirect you to a suspicious page, but there is no redirect when you visit the same URL directly" (⚠️ the referrer-conditional pattern that makes hacks invisible to owners; → Ch 16 §16.4).

Social engineering: Deceptive pages (phishing/deceptive content); Deceptive embedded resources — ⚠️ "a policy violation for the host page": your rotating ad inventory's fake buttons and system dialogs flag your site ("you might need to refresh a page a few times before you're able to see any social engineering ads"); Possible phishing detected on user login (Chrome password-reuse alert).

Downloads: Harmful downloads; Links to harmful downloads; Uncommon downloads (⚠️ "hasn't seen before" — a warning, not necessarily a hack; common on niche software vendors); Unclear mobile billing.

⚠️ Security Issues ≠ Manual Actions: hacked content is handled through Security Issues; there is no "hacked" entry in the manual actions list (→ Ch 18). Different report, different review, different team.

17.7 The three classic hack patterns — field guide¶

🟢 From the web.dev hacked series (⚠️ last updated 2015 — mechanics still accurate, tooling references stale, see §17.8):

Pattern	SERP/site signature	Persistence trick	Cleanup specifics
Japanese keyword hack	"New pages with autogenerated Japanese text… in randomly generated directory names," monetized with "affiliate links to stores selling fake brand merchandise"	⚠️ Rogue GSC owners: "If you've received a notification that someone you don't know has verified your site in Google Search Console, there's a strong possibility that your site has been hacked"	Remove rogue owners AND their verification tokens (files/DNS records); replace .htaccess; reinstall CMS core; sweep new .php files; recheck sitemaps
Gibberish hack	"Many pages with nonsensical sentences filled with keywords"; visitors "redirected to an unrelated page"	⚠️ Cloaks to the owner: "Hackers will try to trick you into thinking the page is gone or fixed… by cloaking content. Check for cloaking by entering your site's URLs in the URL Inspection tool"	Hunt malicious .txt template files + .php droppers; .htaccess
Cloaked keywords + links	Template-styled spam pages that "might look like normal parts of your site until you read the content"; may cloak a fake 404 to the owner	.htaccess `RewriteRule` → dropper .php	Back up → inspect .htaccess → delete dropper → reinstall core → sweep by file-modification dates

🟢 Malware variant — special handling: "Avoid using a browser to view pages on your site… opening a malware-infected page in a browser may damage your computer" — use cURL/Wget. Sweep: .htaccess redirects, SQL-injected records, injected iframes/scripts, compromised 404 templates. The umbrella truth: "Hacks are often invisible to users, yet remain harmful" — injected code "can record keystrokes on visitors' computers."

17.8 Forensics: seeing the site as Googlebot sees it¶

🟢 URL Inspection — indexed version and live test; "View crawled page" shows raw HTML + headers + JS console + resources (→ Ch 6 §6.14 for exact panel semantics). Fetches as Google-InspectionTool — which is what defeats user-agent cloaking.
🟢 site: enumeration — "opening a Google Search window and typing site:your site url… will show you the pages that Google has indexed for your site, including the hacked pages." ⚠️ Note the sanctioned tension: site: is wrong for counting (→ playbook line 77) but documented for surfacing injected URLs.
🟢 Log verification of "Googlebot" — reverse DNS to googlebot.com/google.com/googleusercontent.com, or the published IP-range JSONs (→ Ch 5 §5.4). Hack tools fake the UA constantly.
⚠️ Stale-tooling trap: the web.dev series still says "Verify cleanup using Fetch as Google" — retired 2019; the modern equivalent is URL Inspection → Test live URL.
🟢 Standing monitors: periodic site: self-search, Security Issues report, log watches for "unfamiliar URL parameters" or "spikes in traffic to redirect URLs."

17.9 Recovery: quarantine → assess → clean → review¶

🟢 The full sequence (web.dev series) with the mechanics the playbook's four-line version compresses:

Quarantine — "Stop your web server or point your website's DNS entries to a static page on a different server that uses a 503… the response should occur from outside your compromised server." ⚠️ "Using a robots.txt disallow is also insufficient because it only blocks search engine crawlers" — quarantine is for users, not just bots. (503 semantics → Ch 16 §16.9.)
Credentials & accounts — rotate "FTP, database access, system administrators, and content management system (CMS) accounts"; inventory then delete rogue accounts.
Assess — file inventory by damage; branch by warning type (malware track vs spam track).
Clean — restore only from a pre-hack backup; patch everything; rotate passwords again; ⚠️ close the loop: "Did I fix the root cause vulnerability?" URL removals for hacker-created URLs are situational (volume/damage call). Long-term: automated backups, update discipline.
Request review (timelines) — from the Security Issues report, after all pages are fixed ("Fixing the issue on just some pages will not earn you a partial return"). Published turnarounds: hacked-spam "up to several weeks"; malware "a few days"; phishing "about a day." Clearance: "warnings… will be removed within 72 hours" of a clean verdict. Explain fixes per category (Google's model answer: "…corrected the vulnerability by updating an out-of-date plugin").

17.10 Vectors, prevention, and DNS-level compromise¶

🟢 Google's six intrusion vectors: compromised passwords; missed security updates; insecure themes/plugins ("Remove themes or plugins that are no longer maintained"); social engineering; security-policy holes; data leaks. Root-cause checklist: infected admin machine (keylogger), weak/reused passwords, out-of-date everything, permissive code (open redirects, SQL injection).
🟢 Standing controls: GSC Users & permissions + verification-token audit (closes the Japanese-hack persistence hole — and the playbook's Phase 1 takeover audit, line 73, is this control); careful third-party content ("Pick third-party content providers very carefully" — ad tags can flag a clean site, §17.6).
⚪ DNS-layer compromise (critic addition; no dedicated Google doc — labeled accordingly): dangling-CNAME subdomain takeover — a decommissioned service leaves blog.example.com CNAME'd at a claimable host; an attacker claims it and serves spam on your subdomain, inheriting your domain's trust. Same "spam indexed under your domain" symptom as a hack, completely different fix (delete/repoint the DNS record). Prevention: DNS inventory hygiene on every decommission; monitor Security Issues + site: for subdomains you don't recognize. Crawl-side wildcard-DNS mechanics → Ch 4 §4.5.

Symptoms & diagnosis¶

Symptom	Likely cause	Where
"This site may be hacked" label	Spam-hack (Security Issues will list the category)	§17.5, §17.6
SERP shows Japanese/gibberish titles for your URLs	URL-injection hack pattern	§17.7
Pages look fine to you, spam in Google's cache/index	Cloaked hack — verify via URL Inspection live test	§17.7, §17.8
Unknown person verified in GSC	Japanese-hack signature — audit owners AND tokens	§17.7, §17.10
Mobile-only redirects to spam	Hacked redirects (referrer/UA/device-conditional)	§17.6, Ch 16 §16.4
HTTP URLs indexed despite HTTPS available	One of the eight conditions failing — work the HTTPS report taxonomy	§17.1, §17.4
"Deceptive site ahead" without any hack	Embedded third-party ads/social engineering — host-page liability	§17.6
Review request rejected repeatedly	Partial cleanup (all-pages rule) or root cause unfixed	§17.9
Review button locked	Repeat Offenders 30-day lockout	§17.5
Spam on a subdomain you don't run	Dangling-CNAME takeover, not a server hack	§17.10

Sources¶

All fetched 2026-08-04 (research corpus + V0; V2 re-fetches all): - web.dev hacked series: hacked, quarantine-your-site, assess-spam-damage, clean-and-maintain-your-site, request-a-review, fix-the-japanese-keyword-hack, fix-the-gibberish-hack, fix-the-cloaked-keywords-hack, hacked-with-malware, how-do-i-know-if-my-site-was-hacked, top-ways-sites-get-hacked-by-spammers, identify-the-vulnerability, faq-for-hacked-sites (⚠️ series last updated 2015; tooling references stale) - Security Issues report · Spam policies — hacked content (2026-05-15) · Social engineering (2025-12-10) · Malware/unwanted software · Prevent malware - Safe Browsing · "This site may be hacked" · "This site may harm your computer" · Repeat Offenders policy (2025-12-10) - HTTPS: 2014 ranking-signal post · 2015 indexing-by-default post · HTTPS report help · web.dev/enable-https · mixed content · hstspreload.org · Chrome HTTPS-by-default (V0-verified live) - Verifying Googlebot (301s to /crawling/ home) · URL Inspection help - V2 resolutions (2026-08-04): 2016 Repeat-Offenders exemption pinned to the Nov 8, 2016 post (body unfetchable; wording per contemporaneous coverage); Mueller cert-class → 🟡 with SEJ writeup; wildcard-cert one-label rule → 📘 RFC 9525 §6.3 (fetched live). ⚠️ Google blog-post bodies (2014/2015 HTTPS posts) are SPA-rendered and unfetchable to text extractors as of 2026-08-04 — their quotes stand on the drafting-era corpus.