These hacks redirect only phone visitors arriving from search, so the owner never sees them. Test on a phone through a search result in a private tab, then clean the site and close the hole it came through.

The site looks fine from the office

A customer mentions, almost apologetically, that when she tapped your business in Google on her phone, she landed on a page telling her she had won a new phone.

You check from your desk. You type the address, the home page loads, and everything looks exactly as it should.

It is tempting to decide she tapped the wrong result. Often she did not.

Some hacks are built so that the owner never sees them. They send phone visitors arriving from search somewhere else, and show everybody else the ordinary site.

How it hides

The injected code checks a few things about each visitor before deciding what to do.

The fourth is why these reports sound like mistakes. A customer who tries again to show you what happened usually gets the normal site the second time.

The fifth is why the hack pays: the site keeps its place in search, and its visitors are what is being taken.

Why phone visitors

Phone visitors from search are numerous, they cannot easily see the full address of the page they land on, and they rarely report anything. They just leave.

The destinations vary: fake prize pages, warnings that the phone has a virus, sign-ups for paid text messages, plain spam. Whoever runs the redirect is paid for the traffic.

Every week the owner fails to notice is another week of income, which is why so much effort goes into staying out of sight.

How it is usually found

Most often, by a customer who mentions it.

Sometimes by Google. Search Console can send a message and list the problem under security issues, and your listing in search results can carry a hacked-site warning.

Sometimes by a browser. If the destination is a known scam, phones may show a red warning page instead, and the visitor blames your site.

And occasionally by whoever maintains the site, noticing files that changed when nobody had changed anything.

Testing it yourself

The test has to look like the visitors the hack is aiming at.

Use a phone on mobile data, not the office Wi-Fi, which some hacks recognise from your logins. Open a private tab, search for your business by name, tap your own result, and watch where you land.

Then search for one of your services with your town's name and do the same. Try a second phone of a different make if you can.

If any of those lands somewhere else, even once, take it as confirmed.

A worked example

A family-run Vietnamese restaurant took most of its takeout orders by phone, and most callers found the number by searching on their own phones.

Two customers in one week said the website had sent them to a prize page. The owner checked from the office, saw nothing, and almost let it go.

The web company tested from a phone through a search result and landed on the prize page on the first try.

The code sat in two places: a few lines in the theme's functions file, and a server rule that applied only to phones arriving from search engines.

An administrator account nobody recognised had appeared the same week, on a site running an image slider plugin two years out of date with a published flaw.

The files were replaced with clean copies, the account removed, every password changed and the slider replaced. When it was tested again from three phones, every search result led to the menu.

Cleaning it up

Start with a full backup of the infected site, files and database: evidence of what happened, and a fallback if the clean-up breaks something.

Then replace rather than repair. WordPress itself, the theme and every plugin should be reinstalled from fresh copies, since injected code can sit in any ordinary-looking file.

Check where code hides outside those: server configuration files, PHP files in the uploads folder, which should hold only images and documents, and scripts stored in the database.

Remove any user you cannot account for, change every password connected to the site, including hosting, FTP and the database, and replace the security keys so anybody still logged in is thrown out.

Closing the hole it came through

A clean site with the same weakness can be reinfected within days, so finding the way in matters as much as removing what came through it.

The common doors are few: an outdated plugin or theme with a known flaw, one abandoned by its developer, a pirated paid theme, a reused password, or another neglected site in the same hosting account.

The server's access logs around the date the files changed usually show which. Whoever maintains your site should be able to name the door, not just say the site is clean.

Telling Google it is fixed

If Google flagged the site, the warning stays until somebody asks for a review.

Once the site is clean and the hole closed, request one from the security issues section of Search Console, noting what was found and fixed. The warning comes off when Google confirms the site is clean.

If nobody at the business can log in to Search Console, sort that out first. It is also where the next warning will arrive.

The counter-case

Not every redirect on a phone is a hack.

Some advertising scripts redirect phone visitors on their own, and an old mobile plugin can send people to a separate mobile version that no longer exists. Both look similar from outside and need a different fix.

And a site with no forms, logins or plugins, such as a plain set of static pages, has far fewer doors for this to come through.

But the test costs two minutes. Search on a phone, tap your own result, and treat any customer who mentions a strange page as telling the truth.

If a customer mentions it

  1. Thank them and ask what they searched for.
  2. Test on a phone in a private tab.
  3. Tap through from a search result, not the address bar.
  4. Call whoever maintains the site the same day.
  5. Back up before anything is removed.
  6. Find the way in, not just the code.
  7. Request a review if Google flagged it.

Step three is where most owners go wrong. Typing the address skips the very condition the hack is checking for, so the site looks clean and the problem carries on.

Protection that does not weigh down every page is covered in security plugins that slow the site down.


Frequently asked questions

Why does my site look fine to me?

Because the hack checks each visitor first. Desktop browsers, typed addresses, logged-in users and repeat visitors get the normal site; only phone visitors from search are redirected.

How do I test for it?

On a phone, on mobile data, in a private tab: search for your business and one of your services, tap your own result, and watch where you land.

Why does it only happen sometimes?

Many of these hacks set a cookie so each visitor is redirected only once. A customer who tries again to show you usually sees the normal site.

Is restoring a backup enough?

Only if the backup predates the hack and the hole is closed. Otherwise the same weakness lets it back in, sometimes within days.

How do hackers usually get in?

Through an outdated plugin or theme with a known flaw, an abandoned or pirated one, a reused password, or another neglected site in the same hosting account.

How do I remove Google's hacked warning?

Clean the site, close the hole, then request a review from the security issues section of Search Console. The warning comes off once Google confirms the site is clean.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Customer mentioned a strange page?

Tell us what they searched for. We will test from phones, clean the site and find how it got in.

Start a Conversation