Spam Injected Into Your XML Sitemap

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Search Console says your sitemap contains forty thousand URLs. Your site has sixty pages. Somewhere in that gap is a spam campaign that has been using your domain's credibility to get its pages indexed, and the sitemap was chosen deliberately, because it is the most efficient way anyone has ever devised to tell a search engine about content you want crawled.

Why attackers target the sitemap

A sitemap is a direct submission channel to search engines. Spam pages buried in a site do get found eventually, but a sitemap gets them crawled fast and at scale, which matters when the whole business model depends on volume before anyone notices. Adding entries to a file search engines already fetch regularly is far more efficient than waiting for organic discovery.

It also borrows your reputation. An established domain with real history gets crawled more attentively than a new throwaway one. That is the entire point of compromising ordinary sites for this — not because your site is valuable, but because your domain's standing with search engines is.

Where the spam actually lives

There are three common arrangements, and telling them apart changes the fix. Sometimes a completely separate sitemap file has been added to your web root with a plausible name, sitting alongside your real one and submitted independently. Sometimes your legitimate sitemap has had a sitemap index entry appended, pointing at an attacker-controlled file. And sometimes the spam pages are genuinely in your database as published posts, in which case your sitemap plugin is doing its job correctly and listing them.

That third case is the important one to identify, because deleting a file fixes nothing when the plugin will simply regenerate the list from content that is still there. Check whether the URLs in the sitemap resolve to pages on your site before assuming the sitemap itself is the problem.

Finding every piece of it

Fetch your sitemap directly in a browser and read it rather than trusting the plugin's admin screen. Follow any nested sitemap index entries to their targets. Then list the XML files actually present in your web root over FTP or SSH, because an added file will be sitting there plainly, often with a modification date that stands out sharply against everything around it.

Look at your robots.txt too, since sitemap locations are commonly declared there and an added line is an easy thing to miss. My guide on hacked robots.txt files covers what else turns up in that file. And check your post and page counts in the dashboard against what you expect — a sudden surplus of published content points straight at the database.

Cleaning it up

Delete added sitemap files, remove injected index entries, and clean any sitemap declarations added to robots.txt. If spam pages exist in the database, remove them properly rather than unpublishing them, and check for injected content in existing legitimate posts while you are there — my guide on database malware covers that sweep.

Then regenerate your real sitemap and confirm its contents match your actual content. Do not stop at the sitemap, though. A sitemap is an output; something wrote to your site to create it. Look for the backdoor, check for unrecognized administrator accounts, and close the way in, or the entries come back.

Cleaning up with the search engines

The cleanup is only half of it, because by this point Google may have indexed thousands of spam URLs under your domain. Once the pages are genuinely gone and returning proper 404 or 410 responses, resubmit your corrected sitemap in Search Console and let the removals process naturally.

If a bogus sitemap file was submitted separately, delete that submission so Google stops fetching it. Where the volume is large, my guide on getting spam URLs out of Google's index covers the faster routes, and Search Console security issues covers what to do if you picked up a warning along the way.

What to watch afterwards

Keep an eye on your indexed page count for a few weeks. It should fall back toward your real content volume as the spam URLs drop out, and it is the clearest single indicator that the cleanup worked. A count that stops falling, or starts climbing again, means something is still generating pages.

This kind of hack is also rarely alone — sitemap spam usually accompanies doorway pages or keyword spam, and the same compromise that enabled one enabled the others. If your rankings took a hit while this was running, ranking recovery after a hack covers what to expect, and my cleanup service covers the technical side end to end.

Common questions

Should I just delete my sitemap?

No. Your sitemap is genuinely useful for search engines, and deleting it does nothing about spam pages that already exist in your site or your index. Clean the spam, regenerate a correct sitemap, and resubmit it. Removing the sitemap only removes your own visibility into the problem.

The spam URLs in my sitemap return 404. Is that fine?

It is a good sign — it suggests the pages themselves are gone and only the listing remained. Clean the listing so search engines stop requesting them, and let the 404s do their work in dropping the URLs from the index. If they still load, the pages are real and still in your database.

How did spam pages get into my database?

Through the same routes as any compromise: a vulnerable plugin, a stolen administrator password, or an existing backdoor. Mass-published spam posts usually mean either an administrator account you did not create, or code with direct database access. Both are worth hunting down before you consider the job finished.

Will this hurt my rankings?

It can, significantly. Thousands of thin spam pages under your domain dilute your site's quality signals, and if the content is deceptive enough you can attract a manual action. The good news is that this damage is usually reversible once the pages are removed and the index catches up, which typically takes weeks rather than months.

How do I stop my sitemap plugin regenerating the spam?

By removing the underlying content rather than the sitemap file. If the spam pages exist as posts, the plugin is correctly listing your actual content — it is not malfunctioning. Delete the posts, confirm the counts look right, then regenerate and resubmit.