WordPress SEO Spam Hack: Cleanup and Recovery Plan

A jump from roughly 60 indexed pages to 3,700—followed by a Google Search Console live test showing Vietnamese gambling content such as “79king”—is not a normal indexing fluctuation. It is a strong WordPress SEO spam hack signal, and this guide gives you an ordered recovery plan: contain the compromise, remove persistent access, clear spam URLs correctly, and resume sitemap monitoring without feeding bad URLs to search engines.

The incident pattern discussed in a recent WordPress community report involved GoDaddy Managed WordPress, Divi, Rank Math SEO, unfamiliar root-level PHP files, hundreds of nested .htaccess files, broken XML sitemaps, and two unauthorized Google Search Console owners. Any single symptom can have another explanation. Together, they should be treated as an active security incident—not merely an SEO problem.

Recognize the WordPress SEO spam hack pattern

SEO spam is designed to exploit a site’s authority and Google’s crawling systems. The attacker may create thousands of junk URLs, inject gambling or casino pages, manipulate sitemaps, or serve different content to Googlebot than to ordinary visitors.

The clearest warning signs in this case are concrete:

• Google indexed approximately 3,700 URLs where the site previously had around 60.
• The sudden growth occurred within a narrow period, around September 18–21 in the original report.
• Googlebot received gambling content headed “79king,” while normal visitors still saw legitimate student-housing content.
• Unknown Gmail accounts appeared as verified owners in Google Search Console.
• Files such as accesson.php, auth.php, and authentication.php appeared in the WordPress root.
• A Rank Math XML sitemap returned parsing errors or appeared to loop across sitemap URLs.

One of these items could be a configuration issue. The combination of crawler-only gambling content, unknown PHP files, and unauthorized ownership is compelling evidence of a compromise. Do not wait for a Google Safe Browsing warning before responding; a remote scanner or Safe Browsing status check can be useful, but neither replaces an investigation of the server, files, database, and credentials.

A normal browser session is not sufficient proof that the website is clean. Cloaking malware often checks the requesting user agent, IP reputation, referrer, or a query parameter before deciding what to serve. That is why Search Console’s URL Inspection live test, server access logs, and direct review of HTTP responses matter here.

Separate the three problems before you fix them

A successful recovery distinguishes three related but separate issues. Blending them together leads to superficial fixes, such as deleting one PHP file or removing one Search Console user while the attacker still has a route back in.

1. Attacker access and persistence

This is the underlying security problem: a vulnerable plugin, stolen password, compromised administrator account, infected local computer, vulnerable server configuration, or malicious upload may have let someone write files or alter the database. The suspicious PHP files and hidden plugin directory may be backdoors or droppers, but only a full investigation can establish the initial entry point.

GoDaddy’s guidance warns that reliably removing malware by hand is difficult and recommends restoring a known-clean backup where one exists, changing credentials, and identifying the weakness that allowed the compromise. WordPress’s own hardening guidance likewise treats backups, updates, file permissions, logging, and monitoring as parts of a broader security process—not a one-click repair.

2. Googlebot cloaking and indexed spam URLs

The visible SEO damage is different from the intrusion itself. Attackers may use .htaccess, index.php, wp-config.php, a must-use plugin, theme code, scheduled tasks, database options, or a rogue plugin folder to serve spam only to Googlebot.

Removing a cached page from Google does not remove the code that generates it. Conversely, deleting malicious code does not instantly erase every already-indexed spam URL. Both jobs must happen, in the right order.

3. Search Console ownership verification

Unknown owners are a serious control problem, but removing them alone is not malware remediation. Google explains that a verified owner can regain access if their verification token remains valid. If an attacker has server access, they can often add back an HTML verification file, meta tag, DNS record, or another token after you remove their account from the interface.

Treat Google Search Console ownership as evidence of the incident and an urgent containment task—not the root cause.

Contain the incident before submitting or changing URLs

The first goal is to stop a compromised site from generating, exposing, or submitting more spam. Pause any automated URL-discovery, Indexing API, or IndexNow submission workflow while you establish what URLs are trustworthy. This is not because submission caused the hack; it is because an automation tool should never be allowed to discover and announce attacker-created URLs during an active compromise.

Use this immediate checklist:

1. Preserve evidence. Export Search Console reports showing indexed spam URLs, ownership details, sitemap submissions, crawl timestamps, and URL Inspection results. Save relevant hosting logs and take a file/database backup for forensic review before making destructive changes.
2. Pause automatic submissions. Disable sitemap-triggered URL notifications and any manually scheduled submissions until the clean sitemap is verified.
3. Change credentials from a clean device. Rotate WordPress administrator passwords, GoDaddy account credentials, SFTP credentials, database credentials where appropriate, API keys, and passwords for accounts that can modify DNS, files, or deployments. Enable two-factor authentication where available.
4. Restrict change access. Remove unknown WordPress admin users, unused SFTP users, obsolete deployment keys, and unfamiliar scheduled jobs. Keep a record of every removal.
5. Escalate the hosting case. For GoDaddy Managed WordPress, ask the host or an experienced WordPress incident-response provider to investigate persistence, not just clean flagged files.

Do not start by deleting random files found through WinSCP. A file called auth.php could be malicious, but deleting it without preserving a copy, identifying references, and checking for duplicates can destroy evidence while leaving the actual loader or reinfection mechanism alive.

Remove unauthorized Google Search Console owners correctly

Google Search Console ownership needs a two-part response: remove the person’s access and remove every verification mechanism that proves their ownership. Google’s documentation is explicit that deleting a verified owner from the users list is insufficient if their HTML file, meta tag, DNS record, Analytics-based token, Tag Manager token, or other verification method still exists.

In Search Console, review Settings > Users and permissions and inspect each unknown verified owner’s verification details. Also review the section for leftover or unused ownership tokens. The original community discussion specifically called out unused tokens because an old token can remain a path to restored access.

For each unauthorized owner:

• Record the verification method and token details before deletion.
• Remove the related token from the site, DNS zone, tag manager, Analytics configuration, or server root.
• Clear page and CDN caches before checking whether a removed HTML file or meta tag is still exposed.
• Use Search Console to remove or unverify the owner.
• Recheck ownership details after the environment has been cleaned.

If an unknown owner used an HTML verification file, search the document root and deployment artifacts—not only the current WordPress dashboard. If the property is domain-level, examine DNS TXT records as well. Removing the owner is necessary, but Google cautions that it is only temporary if the site remains hacked.

For related diagnostic context, see our guide to Google Search Console indexing delays once the security incident is under control. A delay is very different from crawler-specific malicious content.

Clean and rebuild the WordPress environment, not just the symptoms

A WordPress SEO spam hack should be treated as a full-environment cleanup. In the reported case, the root directory contained unfamiliar PHP files, a background-image-cropper directory was not visible in the WordPress dashboard, and deeply nested folders under wp-content/well-known/acme-challenge/ contained many .htaccess files. Those are leads for investigation, not a complete list of what must be checked.

Prefer a known-clean restore or controlled rebuild

If you have a backup from before the compromise and can establish that it predates the infection, restoring it can be safer than trying to identify every malicious line manually. A restore is not automatically safe, however: it can reintroduce the exploit if you restore vulnerable plugins, stolen credentials, infected uploads, or a compromised database.

Where the integrity of the backup is uncertain, a controlled rebuild is often more defensible:

• Deploy fresh WordPress core from an official source.
• Reinstall only necessary themes and plugins from trusted sources.
• Update WordPress, PHP, themes, and plugins before restoring content.
• Restore uploads selectively after scanning them.
• Migrate database content carefully, reviewing administrator users, options, scheduled events, injected posts, redirects, and unfamiliar code.
• Compare active files against clean plugin and theme packages.

GoDaddy’s support documentation notes that Managed WordPress customers use SFTP for malware-removal access requests. That detail matters operationally: give a qualified responder the correct access path, but do not casually share long-lived credentials in tickets or chat transcripts.

Check common persistence locations

Your responder should investigate, at minimum, WordPress admin users, wp-content/mu-plugins, active and inactive plugins, themes, uploads containing executable files, cron events, .htaccess, wp-config.php, server-level configuration, database options, and scheduled tasks outside WordPress. Check modified timestamps, but do not assume the newest files are the only malicious ones.

A hidden plugin directory is particularly concerning because WordPress may not show arbitrary folders as installed plugins. Likewise, hundreds of .htaccess files in unexpected nested locations can be used to route requests, rewrite spam paths, or control who sees malicious content.

Verify and remove Googlebot-only cloaking

After cleanup, test the same URLs from more than one perspective. The objective is not merely to make the homepage look normal; it is to prove that Googlebot, users, and crawlers receive consistent legitimate responses.

Use a small evidence table for representative URLs:

Test the homepage, a known legitimate page, several spam URLs, a spam directory pattern, and URLs with query strings or mixed case. Google’s removal documentation emphasizes URL variations because different paths, capitalization, parameters, and directory patterns can point to similar unwanted content.

If Googlebot still receives different content after a supposed cleanup, stop the SEO recovery workflow and return to incident response. It may indicate an overlooked backdoor, server-level rule, cache poisoning issue, or conditional loader. This is not a scenario where resubmitting URLs will help.

Remove spam URLs from Google permanently

Once the site is clean and no longer serves the attacker’s pages, make the spam URLs return an appropriate permanent result. For content that never belonged on the site, a 404 Not Found or 410 Gone is generally the correct response. Do not redirect thousands of unrelated casino URLs to the homepage; that can create confusing soft-404 behavior and does not communicate that the URL is invalid.

Google’s Search Central guidance separates two jobs:

1. Permanent removal: remove the content or protect it, and ensure every relevant URL variation no longer serves the spam page.
2. Temporary suppression: use the Google Search Console Removals tool when you need unwanted results hidden quickly while Google recrawls the permanent fix.

A temporary removal request can take effect quickly, but Google says it lasts about six months. It is a visibility control, not a cleanup tool. If the URL remains live, remains indexable, or comes back through another variation, it can reappear after the temporary request expires.

Prioritize removal requests for branded searches, the highest-volume spam directories, dangerous pages, and URLs that expose users to malicious redirects. Keep a spreadsheet with the exact request pattern, first seen date, HTTP status after cleanup, and Search Console inspection result.

For a fuller comparison of submission paths after recovery, see Submit URL to Google and Bing: Search Console vs IndexNow. The important distinction is that valid pages may be submitted after remediation; spam URLs should be made unavailable, not submitted again.

Repair the XML sitemap without amplifying attacker URLs

A broken Rank Math sitemap, XML parsing error, or sitemap loop deserves immediate attention after malware cleanup. It may be a direct effect of injected rules or files, but it can also be a separate configuration issue. Do not assume the sitemap was malicious solely because the site was compromised; inspect the actual XML and its HTTP response.

Your clean-sitemap checklist should include:

• Fetch the sitemap URL and confirm it returns valid XML rather than HTML, redirects, PHP errors, or a loop.
• Verify each sitemap index child URL resolves correctly.
• Sample URLs from every child sitemap and confirm they are legitimate canonical URLs.
• Remove spam paths, parameter URLs, staging URLs, and old attacker-generated sitemap references.
• Check Search Console’s sitemap report for fetch errors and the last read time.
• Submit only the validated clean sitemap after containment and cleanup are complete.

A sitemap can assist discovery; it does not grant Google permission to index a bad URL or force indexing of a good one. Still, attackers may use sitemap changes to make spam pages easier for crawlers to find. That is why the sitemap belongs in both the forensic review and the post-recovery monitoring plan.

Use sitemap monitoring as early warning, not malware remediation

After recovery, the most useful question is not “How fast can we submit every URL?” It is “How quickly will we know if the sitemap begins exposing URLs we did not create?”

At Indexa, we position sitemap monitoring and URL-discovery notifications as an early-warning layer. A local desktop workflow can watch for new or updated sitemap URLs and notify you before routine submissions proceed. During an incident, keep submissions paused. After a clean baseline is approved, monitor additions against expected publishing activity.

For example, if a small student-housing website normally adds 5 to 20 listing or editorial URLs in a week, an overnight discovery of 500 paths under unfamiliar folders deserves immediate review. The precise threshold varies by site, so establish a baseline from your own publishing schedule rather than relying on a universal number.

Useful alerts and review rules include:

• New URL paths containing gambling terms, random strings, unfamiliar language, or unexpected file extensions.
• Large sitemap-count jumps outside a planned migration or catalogue import.
• New sitemap index files or unexpected child-sitemap locations.
• URLs outside expected content types, such as /wp-content/, hidden directories, or executable-looking paths.
• Status-code changes where valid pages suddenly redirect or spam URLs unexpectedly return 200 OK.

Monitoring cannot disinfect PHP files, remove a malicious WordPress admin, or replace a forensic cleanup. Its value is detection: it gives website owners and agencies a faster chance to pause automation and investigate when URL discovery stops matching reality. For more on the operational tradeoff, read Google indexing automation software vs Search Console and IndexNow.

Validate recovery over the following weeks

Recovery is complete only when the server is clean, the attack path is closed, Googlebot sees legitimate content, unauthorized ownership is gone, and the spam URL population declines through recrawling and removal processing.

For the first several weeks, review these signals at a fixed cadence:

• Search Console security issues, manual actions, pages, and sitemap reports.
• Search Console ownership and unused verification tokens.
• New WordPress administrator accounts and plugin/theme changes.
• Server, SFTP, and WordPress audit logs for unexplained logins or file writes.
• Googlebot requests and responses for former spam URLs.
• XML sitemap diffs and newly discovered URLs.
• Google Safe Browsing status and any host malware scan results.

Expect indexing recovery to be gradual. Google must recrawl the old spam paths, observe that they are gone, and refresh its index. Do not confuse a lingering report count with proof that the malicious code remains. Use live tests, server status codes, and logs to distinguish historic index data from an active reinfection.

If only one legitimate page appears indexed after cleanup, treat that as a separate diagnostic issue rather than trying to solve it by resubmitting everything. Our guide to Google Search Console only one page indexed covers that narrower indexing problem.

FAQ

How can I tell whether thousands of indexed URLs are a WordPress SEO-spam hack?

A sudden increase from dozens to thousands of URLs, especially when the new pages contain casino terms, random folders, foreign-language gambling content, or pages you never published, is a strong warning. Confirm with Search Console URL Inspection, sitemap review, server logs, and direct HTTP checks. The case becomes urgent when unknown PHP files, cloaking, or unauthorized Search Console owners appear too.

Why does Googlebot see gambling content when normal visitors see my real website?

That pattern is usually cloaking. Malware can inspect the Googlebot user agent, referrer, IP signals, or request parameters, then serve spam only to crawlers while ordinary visitors see legitimate pages. Check .htaccess, root PHP files, index.php, must-use plugins, theme code, scheduled tasks, database injections, and server-level rules. A normal browser view alone cannot rule it out.

How do I remove an unauthorized owner from Google Search Console permanently?

First identify how that owner verified access in Search Console. Remove every associated verification token—such as an HTML file, meta tag, or DNS TXT record—then remove or unverify the owner in Users and permissions. Review unused ownership tokens as well. If the attacker still controls the site or DNS, they can add a new token, so server and credential cleanup must happen alongside this step.

Should I delete suspicious PHP files from a hacked GoDaddy Managed WordPress site?

Do not rely on deleting individual files as the full fix. Preserve evidence, identify what calls those files, check for duplicates and backdoors, and involve GoDaddy or a qualified responder where needed. A known-clean restore or controlled rebuild is often safer than piecemeal deletion when unknown root PHP files, hidden plugin folders, database changes, and crawler-only spam all appear together.

How do I get spam URLs removed from Google after cleaning a hacked WordPress site?

Make each spam URL permanently unavailable by removing the malicious content and returning a true 404 or 410 where appropriate. Then use Google Search Console’s Removals tool for urgent temporary suppression of high-priority URLs or directories. The removal request does not replace the permanent server-side fix; Google describes temporary removals as lasting about six months, so the URLs must remain gone when Google recrawls them.

Can a hacked XML sitemap or URL-discovery workflow cause spam pages to be indexed?

A hacked sitemap can help Google discover spam URLs, and an automated discovery workflow could repeatedly encounter those URLs if it trusts a compromised sitemap. Pause submissions during the incident, validate sitemap XML and every child sitemap after cleanup, then resume monitoring with alerts for unusual URL spikes and unfamiliar paths. Monitoring helps reveal a relapse; it does not remove malware by itself.