Visitors may not notice anything, but search tools or raw HTML reveal gambling, pharmaceutical or counterfeit-product links. Attackers can hide them with CSS, place them off-screen or inject them into global content stored in the database.
The domain or anchor text is the indicator. “All external links” is not a safe deletion scope.
Capture examples and rendering context
Save several affected URLs, raw HTML snippets and the destination domains as text. Note whether links appear only to search crawlers, logged-out visitors or mobile devices.
Inspect computed CSS and DOM to see how they are hidden. Preserve the parent element and nearby legitimate content.
Do not visit the spam destinations from an everyday browser.
Search storage systematically
On a protected database copy, search for the exact destination hostname and distinctive anchor. Include posts, revisions, post meta, options, widgets, reusable blocks, menus and plugin/builder tables.
Use read-only queries first. Limit returned columns so customer, order or form data is not unnecessarily exported.
Search for URL-encoded or escaped variants only after the plain indicator is mapped.
Distinguish current content from revisions
A malicious link can remain in a post revision after the published content is cleaned. Revisions are not normally rendered, but they can reintroduce the payload if someone restores one.
Preserve the incident revision separately, then remove affected revisions according to the site’s retention policy. Keep legitimate editorial history intact.
Check autosaves, translations and cloned templates.
Identify global injection points
If the same links appear everywhere, inspect footer widgets, menus, theme options, builder global templates and SEO/plugin settings before editing hundreds of posts.
One infected global block can make every page look individually compromised. Conversely, malware may have copied links into each post, requiring a reviewed batch cleanup.
Establish which pattern exists from record IDs and timestamps.
Clean with reversible, scoped changes
Take a fresh database backup and export the affected rows. Use WordPress or builder APIs where possible.
For multiple posts, prepare a list of exact record IDs and expected old values, run the change first on staging and review a diff. Avoid generic regular expressions that remove legitimate links or damage HTML.
Never modify serialised options with an ordinary text replacement.
Inspect code that hides or reinserts links
Search theme/plugin files and database snippets for the spam domain, injected CSS classes and filters that append content. Review cron and administrators.
Patch vulnerable components and remove backdoors before cleaning the final database, or the links may return.
Check tag manager/CDN transformations if no database record owns the public markup.
Remove the hiding mechanism too
Search stylesheets, inline CSS and builder settings for the selectors used to conceal the links. Rules involving huge negative offsets, zero-size text or visibility changes can be legitimate accessibility/layout techniques, so inspect their exact target.
Remove only the confirmed malicious rule and regenerate affected CSS. If the spam links are deleted but the injected stylesheet remains, an attacker-controlled class or later payload may still use it. Retest skip links, screen-reader text and mobile menus so accessibility helpers are not lost.
Restore search-facing accuracy
Purge targeted caches after the origin/database is clean. Inspect raw public HTML as ordinary and crawler-like visitors.
If attackers created spam URLs as well as links, return accurate 404/410 statuses and submit clean sitemaps. Do not redirect every removed path to the homepage.
Monitor Search Console and new outbound-link changes while recrawling occurs.
Verify legitimate content
Test navigation, affiliate links, citations, multilingual pages and WooCommerce descriptions. Search the clean database for the exact malicious indicators and confirm zero expected matches.
Keep a dated cleanup manifest and monitored link baseline.
When specialist support is safer
Request an assessment when links span serialised builder data, revisions and templates. Send sample public pages/domains without attaching the database.
The repair should remove only malicious links, preserve legitimate content and close the insertion route.