SEO Spam Scanner

• Crawler-view versus visitor-view differences on the same URL.
• Language blocks inconsistent with the page's declared language.
• Outbound link domains present in the page source.
• Hidden content signals such as zero-size or off-screen anchors.

1. STEP 01

   Fetch as a visitor and as a crawler

   Request the URL with a browser user agent, then with a Googlebot user agent, and diff the two responses.

2. STEP 02

   Compare indexed pages with real pages

   Use Search Console coverage and a site: query to find URLs your CMS never created.

3. STEP 03

   Inventory outbound domains

   Extract external links from the source and subtract the ones you intend to have.

• Site owners who received a Search Console security notice, a hosting abuse notice or a browser warning and need to see the evidence themselves.
• Agencies inheriting a site whose organic traffic dropped without a corresponding algorithm update or site change.
• Anyone who has found unfamiliar URLs under their domain in a site: query or in the Search Console Pages report.
• Consultants verifying a cleanup: the same scan, re-run 24 hours later, is what confirms removal held.

If you have no signal at all and simply want a baseline, run the scan against your homepage and two template-heavy pages such as a blog post and a category listing. Injected spam is usually placed in shared templates, so those three requests cover most of the surface.

Injected spam pages inherit the trust of the domain they are planted on, which is precisely why attackers want a compromised site rather than a new one. Google's spam policies cover hacked content explicitly, and a manual action for hacked spam removes affected URLs from results until the site is cleaned and a reconsideration request is accepted.

• Search visibility: spam URLs compete with, and can displace, your own pages.
• Trust: interstitial browser warnings stop conversions outright.
• Access: spam is the visible symptom of write access, which usually also means a backdoor and possibly database access.
• Cost: remediation time scales with how long the injection has been indexed.

• It cannot read your server filesystem, so it cannot locate the backdoor or the modified file.
• It cannot see pages behind authentication, because the check depends on seeing what an anonymous crawler sees.
• It cannot confirm a whole site is clean from a single URL — spam is frequently confined to injected paths that are linked only from an injected sitemap.
• It cannot tell you when the compromise started; server and access logs answer that.
• It cannot judge intent: a legitimate multilingual site can trip the language-mismatch signal, which is why every finding is shown with its evidence rather than as a verdict.

1. STEP 01

   Preserve evidence

   Save the responses, note the timestamps, and export the affected URL list from Search Console before you delete anything.

2. STEP 02

   Find persistence before cleaning

   Look for unexpected admin accounts, recently modified files, unfamiliar scheduled tasks and unknown API keys. Removing spam first only buys hours.

3. STEP 03

   Clean in dependency order

   Reinstall platform, theme and plugin code from source, then clean stored database content, then purge every cache and CDN layer.

4. STEP 04

   Rotate every credential

   CMS administrators, database users, hosting panel, SFTP keys and any token stored in configuration files.

5. STEP 05

   Request review and verify

   Submit a reconsideration request if a manual action exists, then re-run the scan after 24 hours and again after a week.