Hacked site spam links: finding pages you never published

How an injection shows up in link data

The pattern is odd. Your top pages list contains URLs you do not recognise, often with strange parameters or Japanese or pharmaceutical words in the path.

Call toppages for your domain and read the list slowly, because a normal site has its home page, a few guides and a handful of products near the top. Rows that look like /wp-content/uploads/xyz-cheap-watches.html mean something placed pages on your domain and then built links to them.

A site:yourdomain.com search in Google, combined with words such as casino or replica, finds the indexed side of the same story. The link data tells you which of those pages the attacker thought worth promoting, and that tells you where to start cleaning.

Finding planted pages without a crawler

Before you buy a tool for hacked site spam links, read what you already have. The top pages export, the indexed pages list in Search Console and a plain folder listing on the server each show a different slice of the same problem. Compare the three.

Look for folders you did not create. Attackers often drop a directory with a product-like name, or reuse an upload folder that your CMS never touches. Count the files in each one. Near-identical stubs are hard to explain away.

Read the folder tree

Your server's file tree should match the structure of your site. A folder with random characters, or a copy of a plugin with an extra word in its name, deserves a look. Note the modified dates, but do not trust them alone, because timestamps can be changed.

Write down every folder you cannot explain. An unexplained folder is not proof of an attack, but it is a question you must answer before you call the site clean.

Keep the reference list with your exports. The next person who reads the incident should see what was checked, what was clean and what was removed, in that order.

Compare titles and descriptions

A hacked CMS sometimes rewrites titles and descriptions across hundreds of pages at once. Export the titles of your indexed pages and sort them. The export comes back as a list you can read. A repeated unfamiliar phrase makes the pattern visible in minutes, and it shows which templates were touched.

Check descriptions the same way. If they mention products you have never sold, you have found a second layer of the injection.

If the titles changed only on pages you do not recognise, the planted pages tell the whole story. If they changed on pages you still recognise, the template was touched, and the fix sits in your theme.

• Titles that share one unfamiliar phrase
• Descriptions that mention products you do not sell
• Pages with no link from your own navigation

Check the page source

View the source of your home page and of a few guides. Injected links often sit in footers, in hidden blocks or inside a script loaded from another host. Hidden blocks stay invisible on screen. Read the raw HTML.

Note every external domain the source loads. A domain you cannot name in your own stack deserves a line in the incident log. A toppages pull costs 2 credits and returns JSON, so you can put those planted links next to the planted pages in one sheet.

Why the entry point matters more than the cleanup

Removing the spam pages is the visible half of the job. The invisible half is the way in, and that route usually stays open until someone finds it. Put the entry point first. Not last.

If you miss it, the planted pages return within days, and the cleanup starts again from zero. The result is a loop of clean, re-infect and clean again, and each pass costs time you cannot spare during an incident.

Outdated plugins and themes

Old components are a common door. Update the CMS, every theme and every plugin, then remove anything abandoned. A plugin with no recent updates is not a safe one, even when it still works.

Write down what you removed and when. That list is useful evidence if a host or a search engine later asks what happened.

Reused or stolen passwords

A password used on a second site, or one kept in a shared spreadsheet, can give an attacker the same access tomorrow. Change the hosting, database, CMS admin, FTP and SSH credentials together, not one at a time. Otherwise the attacker still holds a working key.

Remove admin users you do not recognise, and check the list again after the password change.

Verification files you did not add

An attacker with file access can also add a verification file for your Search Console property. Check the list of owners and remove anyone you do not recognise. Then look in the root folder for HTML files you never uploaded.

Repeat the owner check a week after cleaning. It takes a minute, and it catches the case where access was kept quietly.

Sitemaps, titles and structured data after a clean-up

Once the planted URLs are gone, three places can still hold the old story. Each one is quick to check. Easy to forget, too. Give each of them a line in your incident log.

Use the same dated export you made at the start, so you can see exactly what changed.

Sitemaps

Open the sitemap your CMS generates and read every URL in it. Planted pages sometimes ride along in a sitemap that a plugin built, and a sitemap full of junk tells crawlers where to go. Regenerate the file after cleaning, then submit it again.

Keep the old sitemap as evidence rather than deleting it.

Structured data

Some injected markup describes products or reviews that never existed on your site. Check the page source for schema blocks you did not add, and test a few planted URLs with a structured data testing tool.

Any markup you cannot trace back to your templates is a removal task, not a content task.