WordPress sitemap spam appears when an XML sitemap lists product pages, foreign-language paths, doorway URLs, or author archives you never created. The sitemap is not usually the original infection. It is evidence that WordPress, a plugin, a cache, or malicious code still believes those URLs exist.
I’m Ryohei Yokoyama, founder of SiteFixNow. I’ve worked as an IT engineer for over 20 years and have handled many WordPress malware removal, hacked site repair, and SEO-spam cleanup cases. Here I’ll show how to trace sitemap spam without deleting legitimate content by mistake.
- How to inventory every suspicious sitemap URL before cleanup
- How to distinguish spam posts, virtual routes, and stale cache output
- How to remove the reinjection source and verify a clean recovery
WordPress Sitemap Spam Means an Unauthorized URL Source Is Still Active
The safest conclusion is that an unknown sitemap entry represents an active or recently cached source. A sitemap generator normally discovers URLs from posts, pages, products, taxonomies, users, or callbacks registered by plugins. It does not invent unrelated paths by itself.

Treat the sitemap as evidence, not the infection
If search results also show foreign-language titles or keyword-stuffed pages, follow the Japanese keyword hack and WordPress SEO-spam checks. The visible sitemap may be only one output of a wider compromise.
- Do not block the entire site in robots.txt.
- Do not delete every database row containing a suspicious word.
- Do not request search removal before fixing the live source.
WordPress Sitemap Spam Should Be Inventoried Before Anything Is Deleted
Build a complete URL inventory before cleanup. The parent sitemap may look normal while one child sitemap contains thousands of entries. A security plugin can also publish a separate sitemap that is absent from WordPress core output.
Capture the sitemap index and every child sitemap
curl -i https://example.com/robots.txt
curl -i https://example.com/wp-sitemap.xml
curl -i https://example.com/sitemap_index.xmlFor each unknown URL, record the source child sitemap, HTTP status, page title, canonical URL, and whether the page appears in WordPress admin. Group patterns by path, language, author, post type, and creation time. Patterns reveal the writer more reliably than one page.
Compare sitemap entries with stored WordPress objects
wp post list --post_type=any --post_status=any \
--fields=ID,post_type,post_status,post_date,post_name,post_titleWhen URLs map to rows in wp_posts or suspicious values in wp_postmeta, use the evidence-first WordPress SEO-spam database workflow. Run read-only queries first, confirm the table prefix, and keep a backup before editing any record.
WordPress Sitemap Spam Can Come From the Database, Runtime Code, or Cache
Find the generating layer before choosing a cleanup action. If a rogue URL exists as a real post, remove the writer and repair confirmed records. If no matching object exists, inspect runtime routes, sitemap filters, rewrite rules, and cached output instead.
Check database-backed sitemap entries
SELECT ID, post_author, post_date, post_status, post_type,
post_name, post_title
FROM wp_posts
WHERE post_name LIKE '%suspicious-pattern%'
ORDER BY post_date DESC;Check virtual routes and sitemap providers
A URL that renders but has no post row may be created by init rewrite code, template_redirect, a REST callback, or sitemap filters such as wp_sitemaps_posts_query_args. Inspect active plugins, must-use plugins, the current theme, drop-ins, and recently modified PHP files.
For a wider inspection of files, database payloads, and hidden access points, use the WordPress malware cleanup and backdoor checklist.
WordPress Sitemap Spam Reinjection Must Be Stopped Before Cleanup
Remove the mechanism that writes or exposes the URLs before cleaning sitemap output. Otherwise a cron task, stolen administrator session, application password, vulnerable plugin, or remote database job can recreate every entry within minutes.
Contain accounts and automation without destroying evidence
Record unknown administrators, recent logins, application passwords, API activity, scheduled posts, and cron events. Revoke unauthorized access, rotate affected credentials through secure channels, and update WordPress core, themes, and plugins from trusted sources.
wp user list --fields=ID,user_login,user_email,roles,registered
wp cron event list --fields=hook,next_run,recurrence
wp plugin list --fields=name,status,version,updateTest whether the source is truly gone
After containment, remove one confirmed test entry, purge only the relevant caches, and regenerate the sitemap. If it returns, stop bulk cleanup and continue tracing. The WordPress reinfection root-cause process explains how to correlate recurring changes across accounts, files, database jobs, and hosting layers.

WordPress Sitemap Spam Cleanup Should Be Narrow and Reversible
- Quarantine malicious code and revoke the access path that installed it.
- Delete or repair confirmed spam posts, terms, metadata, options, and users.
- Regenerate permalinks or sitemap indexes only when their provider requires it.
- Purge WordPress, server, CDN, and browser caches in a controlled order.
- Request the sitemap again as a logged-out visitor and record the result.
WordPress Sitemap Spam Recovery Requires URL and Search Verification
A clean XML file is only the first verification point. Each former spam URL must now return the intentional response, such as a genuine 404 or a deliberate 410. It must not redirect to another spam path, return a soft 404 with status 200, or vary only for search crawlers.
Check the sitemap repeatedly after cron intervals and cache expiration. Search Console reports can lag behind the live site, so use current HTTP responses as primary technical evidence while monitoring discovered and indexed counts over time.
If the incident caused browser or search security warnings, complete cleanup first and then follow the Google warning cleanup and review-request steps. A review submitted while reinjection is active may fail.
WordPress Sitemap Spam FAQ
WordPress Sitemap Spam Recovery Depends on Removing the Source
The correct sequence is evidence, inventory, source identification, containment, narrow cleanup, sitemap regeneration, and repeated verification. Deleting XML output first reverses that sequence and can hide the mechanism you need to find.
After recovery, apply a post-malware WordPress hardening plan. Patch the entry point, reduce privileges, review API access, protect backups, and monitor for new files, users, posts, and sitemap changes.
If You Can’t Secure or Recover Your WordPress Site Yourself

If your website shows malware warnings, redirects to strange pages, or you are not sure whether it is secure,
SiteFixNow can help clean, repair, and recover your WordPress site.
- Your WordPress site may be infected with malware.
- Security warnings appear in Google or browser results.
- You found unknown admin users or suspicious files.
- The site redirects to spam or unknown websites.
- You need urgent WordPress hacked site repair.
- Reduce visitor risk and SEO damage.
- Find hidden malware and backdoors, not only visible symptoms.
- Recover the site safely without unnecessary data loss.
