Bogus Search Results

[Lime-Results]

Hi,

A website I look after was hacked.  We cleaned it up , removed malicious content and changed passwords.  However the bogus links which were created have kept multiplying.  Search Console is all clear.  But they keep adding to Google, bogus links.

My client site is www.mechfieldfm.com.au

For example http://mechfieldfm.com.au/JCB-BACKHOE-IGNITION-SWITCH-WITH-2-KEYS-PART-NO-70180184-70145500-372796/

There are thousands of bogus links created.  But I believe they are outside the hosting.

Any help would be appreciated.

[Lime-Results]

Thanks for your follow up.

Regards

Wayne

[effectdigital]

These invasive URL hacks can be very tricky to get under control. Sometimes if you're lucky, it's just a matter of erasing the pages and stuff. In other circumstances scripts are injected which recreate the bad URLs (and links to them) when you take them down. You certainly want to be on the lookout for unknown scripts on your site, or links to external scripts which didn't exist before

[Lime-Results]

Thanks very much for your detailed response.

When the website was hacked they created the hacked pages and when you searched in Google you would go to an actual page.  Once we shut the attack down, the links went back to our website.

I thought I had it under control.  Listed in search console not to to index  links and was going to place redirects on.  But in the last few days another 5 pages of the bogus links have been created.  Just checked again and more bogus links are being created.  Therefore it could be an endless job, if they are going to be added to.

Correct client is a Air Conditioning  service business.  When you go to site:mechfieldfm.com.au the first couple of pages are actually from client website.

I will look at locking down  the HTTP>HTTPS  redirect.

[effectdigital]

Are you sure that this:
http://mechfieldfm.com.au/JCB-BACKHOE-IGNITION-SWITCH-WITH-2-KEYS-PART-NO-70180184-70145500-372796/

... is an example of a bogus or hacked page? Because when I check Google's cache for the URL:

http://webcache.googleusercontent.com/search?q=cache:http%3A%2F%2Fmechfieldfm.com.au%2FJCB-BACKHOE-IGNITION-SWITCH-WITH-2-KEYS-PART-NO-70180184-70145500-372796%2F

https://d.pr/i/6sioLy.png (screenshot)

It looks like it was once a 'real' page. Google's cached version only looks so messed up as they failed to capture the CSS properly. It just seems weird that someone would hack your client's site and just leave info for construction-related products on your client's domain. Usually with hacks it's a phishing / political agenda or something like that (or some kind of scam)

Still, having said that; although your client is in construction they don't seem to list any products of any kind (your client appears to be service-based). You have to admit though, to an outsider, it looks more like 'dev-gone-wrong' than a hack. It's just really weird, at the very least

Can't you just write a redirect rule that 301s or 302s all of those bogus URLs somewhere else? Those URLs shouldn't be accessible anyway. Your client has a valid SSL certificate and the site loads just fine on HTTPS: https://mechfieldfm.com.au - so another question is, why was HTTP left exposed? The bogus URLs are on HTTP, maybe they found an entry-point because that architecture was left exposed instead of being properly redirected

Even Google mostly link to the site on HTTPS:

https://www.google.co.uk/search?q=site%3Amechfieldfm.com.au

https://d.pr/i/XfbNF7.png (screenshot)

Where they're not doing this, it's because they are linking to more examples of 'bogus' URLs. Personally I'd just slap no-index tags and status code 410 (gone) on all of those problematic URLs. If you're worried you can't use no-index as the HTML of those pages is gone, you can still fire Meta no-index directives through the HTTP header using X-Robots, so be sure to look that up

It will probably take a while (some weeks) for Google to digest all the disruption and fixes. In the future, ensure that disused architectures (like HTTP) are made physically inaccessible via redirects. Leaving old architectures active is a recipe for disaster. Once this is all cleaned up, be sure to properly implement HTTP -> HTTPS redirects

Here's something odd. On your client's homepage, the HTTP->HTTPS redirect is properly implemented. Somehow these 'hacked' URLs are evading that redirect. You need to at least lock that down or it could happen again