SEO spam malware WordPress không nên được xử lý như một vấn đề “xóa URL rác khỏi Google”. Japanese Keyword Hack, Pharma Spam, hidden links, casino pages hoặc snippet lạ chỉ là biểu hiện. Việc cần làm là xác định nguồn tạo nội dung, phạm vi compromise, persistence, trạng thái live của URL và bằng chứng còn lại trong Search. Chỉ khi source đã được xử lý và website không còn tái tạo spam mới chuyển sang bước Search Console review hoặc reindex. Một case end-to-end để đối chiếu biểu hiện này là Redirect, JavaScript Injection và SEO Spam Malware trên WordPress.
Một kết quả tìm kiếm lạ không tự chứng minh website vẫn đang nhiễm; ngược lại, live site “trông bình thường” cũng không chứng minh compromise đã hết. Cần tách rõ live-site evidence và search-index evidence.
Xác định trạng thái compromise và search evidence
Phân biệt live-site evidence và search-index evidence
| Quan sát | Live site | Search/index | Diễn giải hợp lý |
|---|---|---|---|
| URL spam còn trả 200 và render nội dung lạ | Có | Có/không | Compromise hoặc source tạo spam có thể còn active |
| URL spam không còn trên site nhưng vẫn xuất hiện trong Search | Không | Có | Có thể là index chưa cập nhật; cần kiểm tra status/canonical/render hiện tại |
| Search Console báo hacked content nhưng frontend nhìn bình thường | Không rõ | Có cảnh báo | Cần kiểm URL mẫu, alternate render, user-agent/referrer condition và source owner |
| Spam tự tái tạo sau cleanup | Có | Có/không | Nghi persistence hoặc nguồn tạo nội dung chưa xử lý |
| URL cũ trả 404/410 nhưng snippet còn tồn tại | Không | Có thể còn | Có thể là stale search state; không tự chứng minh reinfection |
Japanese Keyword Hack, Pharma Spam và hidden links khác nhau ở biểu hiện, không phải ở nguyên tắc điều tra
Japanese Keyword Hack thường tạo URL/title/snippet tiếng Nhật hoặc nội dung không liên quan tới site. Pharma Spam có thể chèn nội dung hoặc link liên quan dược phẩm. Hidden links có thể nằm trong HTML, template, option, widget, database hoặc code render có điều kiện để người dùng bình thường khó thấy.
Điểm chung là cần xác định owner của output: post/revision, database option, template, plugin/MU-plugin, cron, compromised account, injected file hay logic server-side. Nếu chỉ xóa page nhìn thấy mà không xử lý owner/source, spam có thể quay lại.
IOC & Search Evidence Matrix
| Signal | Nguồn kiểm tra | Có thể là gì? | Cần correlate với |
|---|---|---|---|
| Title/snippet lạ | SERP/Search Console | Indexed spam hoặc stale result | Live HTML, status, canonical, source owner |
| URL không do site tạo | Search Console, crawl, access log | Spam route/page injection | Rewrite, DB, template, generated route |
| Hidden outbound links | Rendered DOM + source | Injected content | Theme/plugin/DB/template/file |
| Japanese/pharma keyword | DB/file/render/search index | IOC nội dung | Entry point + persistence |
| Spam chỉ hiện với bot/referrer nhất định | Controlled fetch/render | Conditional render/cloaking-like behavior | Plugin/code/WAF/cache rule |
| Post/URL tự tái tạo | Revision, audit log, cron, DB | Persistence hoặc automation bị chiếm dụng | Account/process/source code |
Điều tra source và persistence
Workflow điều tra SEO spam theo evidence
- Khóa sample set: ghi URL, query, title/snippet, first-seen và nguồn phát hiện.
- Kiểm live response: status code, redirect, canonical, rendered HTML và source.
- Kiểm Search Console: Security Issues, URL mẫu, indexed URL và bất kỳ cảnh báo nào liên quan.
- Inventory source: post/revision, database, option, plugin, MU-plugin, cron, file, rewrite hoặc generated route.
- Pivot identity: user/account nào tạo hoặc sửa nội dung, có login/session bất thường không.
- Tìm persistence: cron, backdoor, account lạ, plugin/theme/file bị sửa, DB injection hoặc job tái tạo.
- Contain/cleanup: xử lý source + persistence + entry point; không chỉ xóa URL.
- Verify live: URL mẫu, route liên quan, account/file/DB source và observation window.
- Search recovery: sau khi live state sạch và ổn định mới request review/re-crawl khi phù hợp.
Search Console Security Issues: cách dùng đúng
Nếu Google cung cấp URL mẫu hoặc loại cảnh báo, hãy lưu lại nguyên trạng trước khi thay đổi. URL mẫu là điểm bắt đầu điều tra chứ không phải toàn bộ scope. Một URL có thể đã bị xóa trong khi source tạo spam vẫn tồn tại ở route khác.
Trước khi request review, cần đảm bảo remediation đã hoàn tất: source tạo nội dung đã xử lý, persistence đã xử lý, account/credential liên quan đã review và URL mẫu không còn render spam. Nếu cảnh báo xuất hiện ở Search Console hoặc kết quả tìm kiếm, dùng workflow xử lý khi Google cảnh báo website bị hack hoặc chứa nội dung độc hại để tách review request khỏi remediation kỹ thuật. Xem Google Search Central — Malware and Security Issues.
Query & Evidence Worksheet
Đây là mẫu để điền bằng evidence thật; không phải kết quả mặc định của site.
case_id: SEO-SPAM-YYYY-NNN
observed_query: ...
search_result_title: ...
search_result_snippet: ...
affected_url: ...
first_seen_utc: ...
last_seen_utc: ...
search_console_example: ...
live_status: 200|3xx|404|410|other
live_html_matches_spam: yes|no|conditional|unknown
canonical: ...
source_owner:
type: post|revision|option|plugin|mu-plugin|theme|file|cron|rewrite|unknown
id_or_path: ...
database_matches: ...
file_matches: ...
account_or_process: ...
persistence_found: yes|no|unknown
entry_point_hypothesis: ...
evidence_refs: [...]
next_action: ...
Đừng chỉ xóa post spam
Nếu WordPress tự tạo post, cần xác minh nguồn tạo: user, revision, database, plugin, cron hoặc code injection. Workflow riêng tại WordPress tự đăng post spam. Nếu dữ liệu nằm trong database, tiếp tục với kiểm tra database WordPress bị chèn mã độc/spam.
Nếu output đến từ file/template/plugin thay vì post, việc xóa post hoàn toàn không giải quyết source. Ngược lại, nếu spam chỉ tồn tại ở index nhưng live URL đã biến mất đúng cách, không nên tự động kết luận reinfection.
Đừng dùng removal khỏi Search như cleanup
Search removal hoặc URL removal chỉ tác động cách kết quả hiển thị/tạm ẩn; nó không loại bỏ malware, account compromise, backdoor, rewrite, file injection hoặc cron tái tạo. Nếu source còn tồn tại, spam có thể quay lại sau khi removal hết hiệu lực hoặc qua URL khác.
Thứ tự đúng là remediate website → verify live → quan sát stability → xử lý Search state.
Verification và Search recovery
Persistence Verification Checklist
- Không còn post/page/URL spam mới xuất hiện sau cleanup.
- Không còn cron/job không có owner liên quan tới source tạo spam.
- Account lạ hoặc compromised account đã được xử lý; session/credential liên quan đã review.
- File/plugin/theme/MU-plugin tạo output spam đã được xác định và xử lý.
- Database option/content bị chèn đã được làm sạch có kiểm soát.
- Route/rewrite/generated URL không còn tái tạo spam.
- URL mẫu từ Search Console không còn trả/render nội dung spam.
- Observation window đủ để kiểm tra tái xuất hiện theo cơ chế đã phát hiện.
Clean vs stale index: tiêu chí phân biệt
| Trạng thái | Live evidence | Search evidence | Decision |
|---|---|---|---|
| ACTIVE COMPROMISE | Spam còn render/tái tạo | Có/không | Tiếp tục incident response |
| REMEDIATED / SEARCH STALE | Source xử lý, không tái tạo, URL state hợp lệ | Snippet/index cũ còn tồn tại | Theo dõi/review Search state |
| UNKNOWN | Không đủ evidence owner/persistence | Có dấu hiệu lạ | Không được kết luận clean |
Recovery sequence
- Inventory URL/query/snippet/IOC đã biết.
- Xác định source owner và blast radius.
- Contain nếu site đang phát tán nội dung độc hại hoặc attacker còn hoạt động.
- Cleanup file/database/account/plugin/cron/rewrite liên quan.
- Xử lý persistence và entry point.
- Verify live site, URL mẫu và owner/source.
- Theo dõi observation window để phát hiện tái tạo.
- Chỉ sau đó mới request review/re-crawl khi cần.
PASS/FAIL cho remediation SEO spam
- PASS: source tạo spam đã xác định và xử lý; persistence/entry point đã review; URL mẫu không còn render spam; không tái tạo trong observation window; Search issue đủ điều kiện chuyển sang review.
- FAIL: chỉ xóa post/URL, không biết owner/source, spam tái tạo, account/backdoor chưa xử lý hoặc Search removal được dùng thay cleanup.
- HOLD: live site có vẻ sạch nhưng source/persistence chưa xác định hoặc Search evidence mâu thuẫn với live evidence. HOLD cần tiếp tục điều tra.
Khi nào nên escalation?
Nếu spam xuất hiện trên nhiều site, đi cùng Admin lạ/backdoor, tái xuất hiện sau cleanup hoặc có Security Issues đang ảnh hưởng người dùng, nên escalation. WordPress đơn lẻ cần cleanup + recovery + verification có thể theo Malware Removal; incident rộng hoặc đang hoạt động xem Incident Response.
Nguồn kỹ thuật tham khảo
- Google Search Central — Spam policies
- Google Search Central — Malware and Security Issues
- WordPress.org — FAQ: My site was hacked
Kết luận
SEO spam recovery đúng phải nối được search symptom → live evidence → source owner → persistence → remediation → verification. Japanese Keyword Hack, Pharma Spam và hidden links chỉ là biểu hiện. Khi source tạo nội dung và persistence đã được xử lý, live site ổn định và không còn tái tạo, lúc đó Search Console review mới có ý nghĩa.