Category: Security

You installed a security plugin, and now it emails you every day to say your site blocked four hundred login attempts. Or you looked at the logs for the first time and found somebody has been trying to get in as “admin” every few seconds since March.

The natural reading is that somebody is targeting your business. It is worth saying plainly, before anything else, that they almost certainly are not.

Why you are seeing hundreds of failed logins

Automated software scans the entire internet continuously looking for WordPress sites, and every WordPress site has its login page in the same place. Having found one, the software tries a list of common usernames and passwords, gives up after a while, and moves on.

This happens to every site. A local plumber, a national charity and a FTSE company all get the same treatment, because the process never looks at who you are. Your security plugin has simply started telling you about weather that was always there.

Failed login attempts are not evidence that you are a target. They are evidence that you have a website. The number worth worrying about is not how many failed, it is whether any succeeded.

That said, this background noise is exactly how sites get broken into, because eventually one of these attempts finds a weak password on a forgotten account. So the right response is neither panic nor ignoring it. It is closing the few things that actually matter.

The two changes that do most of the work

1. Two factor authentication on every administrator

If there is one thing on this page to do this afternoon, it is this.

Two factor means a password alone is not enough. Even if an attacker has your password, from a data breach somewhere else or from guessing, they cannot get in without the code on your phone. It turns the entire category of password guessing into a waste of their time.

Use an authenticator app rather than SMS where you can. SMS is much better than nothing and is also the weakest form, because phone numbers can be moved to a new SIM by someone who knows enough about you.

Apply it to every account with administrator or editor rights, not only your own. One developer from two years ago with a reused password undoes the whole exercise.

2. Fewer administrators

Open Users and filter by Administrator. Most sites we look at have between two and five times as many as they need.

The agency that built the site in 2021. A freelancer who did one job. A plugin support technician who needed access for an afternoon. A staff member who left. Every one of those is a live key to your website held by somebody who is no longer thinking about it.

Anyone who writes content is an Editor or an Author, not an Administrator. Administrator means the ability to install code on your server, and very few people in an organisation need that. Removing an account takes ten seconds and is the single cheapest security improvement available.

Worth doing, in roughly this order

1. Limit login attempts. Lock an IP address out for a while after a handful of failures. Most security plugins do this and most have it switched on by default. It converts an endless guessing attack into a few attempts an hour.
2. Remove the username “admin”. Every automated attack tries it first. You cannot rename a WordPress user, so create a new administrator with a different name, log in as that, and delete the old one, assigning its content to the new account.
3. Use a password manager. The reason people reuse passwords is that remembering unique ones is impossible. A manager removes the reason. This matters more than password complexity rules, because a unique weak password beats a strong reused one.
4. Turn off XML-RPC if you do not use it. An older WordPress feature that allows many login attempts inside a single request, which is convenient for attackers. Some apps and plugins still need it, so check before disabling.
5. Change your login URL. Moving /wp-admin somewhere else removes most of the automated noise, because the bots are looking in the standard place. Treat it as reducing volume rather than as security in itself, and be aware you must remember the new address.
6. Put a firewall in front. A web application firewall blocks a lot of this before it ever reaches your site, which also saves the server resources currently being spent rejecting attempts.

Security theatre worth skipping

Some common advice makes people feel safer without helping much.

• Forcing password changes every ninety days. Widely dropped as guidance, including by the National Cyber Security Centre, because it pushes people towards predictable variations. A long unique password kept until there is a reason to change it is better.
• Hiding your WordPress version number. Trivially discoverable by other means. It costs nothing to do and buys nothing.
• Complexity rules without a manager. Demanding symbols and numbers produces the same word with a nought for an o, written on a note by the monitor. Length and uniqueness beat complexity.
• Relying on the login URL change alone. Useful for noise, but if the address leaks, or a plugin exposes it, you are back to where you started with nothing else in place.

What a successful break-in looks like

Failed attempts are noise. These are the things that mean somebody got in.

• A successful login at an odd hour from a country nobody works in. Most security plugins log this, and it is the single most useful line in the log.
• A new administrator account you did not create. Frequently the first thing an attacker does, so their access survives a password change.
• Your own password stops working. Sometimes they lock you out deliberately.
• Password reset emails you did not request. Somebody is at least trying.
• The administration email address has changed. A quiet way to intercept future resets. Check Settings then General.
• You get logged out repeatedly. Can be innocent, and can also mean security keys were changed or sessions invalidated by someone else.

If you recognise any of those, work through our guide to how to tell if your WordPress site has been hacked before assuming it was a glitch. It happened to us: when our own site was compromised, two administrator accounts had been created that nobody recognised, and that was the clearest single signal.

If you think someone has your password

Changing your password is not enough on its own, and this is the step most people miss.

WordPress keeps you logged in using a cookie signed with a set of security keys stored in wp-config.php. If an attacker has an active session, changing your password does not necessarily end theirs. Replacing those keys does, because it invalidates every existing session on the site including your own.

So the order is: change passwords, replace the security keys in wp-config.php, then check the Users list for accounts you do not recognise, then check whether anything was installed while they were in. A password change alone can leave somebody sitting inside the site with a valid session.

Frequently asked questions

Should I be worried about hundreds of blocked login attempts?

No. Blocked means the system worked. It is normal background traffic for every WordPress site. What deserves attention is a successful login you cannot account for, or a new administrator account.

Why does WordPress keep logging me out?

Usually innocent. Cookie or site address mismatches between the www and non-www versions of your domain, a caching plugin interfering with logged in sessions, or a short session length setting. It can also follow a security key change. If it started suddenly alongside anything else on this page, check the rest before assuming it is a settings problem.

Is changing the login URL actually worth it?

Yes, with realistic expectations. It removes most automated noise and reduces the server load of rejecting it. It is obscurity rather than security, so it should sit on top of two factor and sensible accounts rather than instead of them.

Do I need a security plugin at all?

A good one helps, and it is not sufficient by itself. It cannot decide which of your plugins is risky, update them, test your backups, or notice that a new administrator appeared last Tuesday. Tooling plus a person is the combination that works, which is what our WordPress security services provide.

What about passkeys?

Support is arriving and it is genuinely better, because there is no password to steal or reuse. If your setup supports it and your team can manage the recovery process, it is a good direction. For most small business sites today, two factor on every administrator is the practical answer.

---

Not sure who has access to your site?

Most owners are surprised by their own Users list. We will go through it with you, set up two factor properly, and tell you honestly what else is worth doing and what is not.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

The first sign is rarely dramatic. It is usually a Tuesday morning and there are forty seven failed orders in the dashboard from overnight, all for small amounts, all from cards that were declined.

Or a customer emails to say their card was used somewhere else a few days after they bought from you. Or your payment provider gets in touch about your chargeback rate before you have noticed anything at all.

None of those look like the hacking you see in films, which is part of why store owners tend to dismiss them for a week or two. All three are worth acting on the same day.

Why a shop is a different problem to a website

Every WordPress site faces the same background noise of automated attacks. A store faces all of that, and then three more things, because there is money moving through it.

• Your checkout is a card validation service to somebody. A criminal with a list of stolen card numbers needs to know which ones still work. Your checkout will tell them, for free, at scale.
• Your customers type card details into your pages. That makes the pages themselves worth attacking, whether or not you ever store the numbers.
• You hold personal data. Names, addresses, order history, phone numbers. That has value on its own, and it carries obligations that a brochure site does not.

A brochure site being hacked is a problem. A store being hacked is a problem, a cost, and potentially a notification you have to make within seventy two hours.

Card testing: what those tiny failed orders are

Card testing, sometimes called carding, is the most common attack on small WooCommerce stores and the most commonly misunderstood.

Someone has bought a batch of stolen card numbers. Most will be cancelled already. To find the live ones they need a checkout that will attempt a payment and report back, and they need it to be a small enough amount that the real cardholder does not notice. Your store is not the target. Your store is the instrument.

What it looks like in your dashboard:

• A cluster of orders in a very short window, often overnight
• Mostly failed payments, with a few succeeding
• Small amounts, frequently on your cheapest product or a variable price field
• Different names and email addresses, sometimes randomly generated
• Repeating patterns in the addresses, or the same address with different names
• Traffic straight to the checkout with no browsing beforehand

What it costs you even though the payments failed: most providers charge a fee per attempted transaction, so a few thousand attempts is a real bill. Your decline rate climbs, which some providers treat as a risk signal against your account. The successful ones become chargebacks later, and chargebacks carry their own fee on top of the lost money. If the rate gets high enough, providers can and do close merchant accounts.

What actually helps: rate limiting at the checkout, a CAPTCHA on the payment step rather than on the contact form, blocking the obvious repeat offenders by IP, turning off guest checkout if your business can live without it, removing any product priced at a token amount, and enabling whatever fraud tooling your payment provider offers. Stripe Radar and its equivalents are usually already included in what you pay.

Payment skimming: the one that is genuinely serious

This is the risk that almost none of the general WooCommerce security advice covers, and it is the one with real consequences.

A skimmer is a small piece of JavaScript injected into your checkout page. It sits quietly and copies what customers type into the card fields, sending it to a server somewhere else. The customer’s order completes normally. Your store behaves normally. Nothing is broken, nothing looks wrong, and the theft can run for months.

The technique is usually called Magecart, after the group that popularised it against Magento stores, and the same approach works anywhere card details are typed into a page you control.

Why “we use Stripe so we are fine” is not quite right. If your checkout uses a hosted payment page or a properly isolated iframe, the card details are never typed into your pages and a skimmer on your site cannot read them. That is genuinely safer, and it is worth knowing which setup you have. But many stores use an embedded card field for a smoother checkout, and injected JavaScript on the page can interfere with that. Find out which one you are running before you rely on it.

How to check: open your live checkout, open the browser developer tools, and look at the Network tab while you type into the form. Anything being sent to a domain that is not yours, your payment provider, or a service you deliberately installed is worth investigating immediately. Also compare the scripts loading on the checkout against a staging copy you trust.

If you find one, treat it as an active data breach rather than a website problem, and read the obligations section below before you delete anything.

Fraudulent orders

Different from card testing, because here the goal is to receive goods rather than to validate a number. Warning signs are familiar to anyone who has run a shop for a while: an unusually large first order, express shipping chosen regardless of cost, a billing address and delivery address in different countries, an order placed at three in the morning, or several orders to the same address under different names.

The awkward truth about chargebacks is that for card-not-present transactions the liability usually sits with you rather than the bank, even when you did nothing wrong. That is why the boring controls matter: address verification, requiring a signature on high value deliveries, and simply holding a suspicious order for a phone call before dispatch.

Checking your store this week

None of this needs a developer.

1. Sort your orders by date and look at the overnight hours. Clusters of small failed payments are the card testing signature.
2. Check your payment provider dashboard for decline rate. A climbing decline rate with flat sales is the clearest early warning there is.
3. Look at your Users list. WooCommerce creates customer accounts, so scan for administrators specifically, and for a burst of customer registrations that never ordered anything.
4. Open the checkout in developer tools and read the list of scripts loading on it. You should recognise every domain.
5. Check wp-content/uploads for PHP files. There should be none, ever.
6. Confirm your backups actually restore. A store backup that has never been tested is not a backup, and a store has a database that changes every hour rather than every month.

If any of that turns something up, our WordPress malware removal service covers stores, including the checkout side and the search recovery afterwards.

The part nobody writes about: what you owe afterwards

Search for WooCommerce security advice and you will find a great deal about prevention and detection. You will find almost nothing about what happens once something has actually got in, which is the moment a store owner most needs to know what to do.

Three separate sets of obligations can apply, and they are not the same thing.

Data protection

If personal data has been exposed, UK GDPR sets out when a breach must be reported to the Information Commissioner’s Office, and the headline figure people remember is 72 hours from becoming aware of it. There are also circumstances where you have to tell the affected customers directly.

Whether a specific incident meets the threshold is a judgement, and it is not one to make from a blog post. What matters practically is that the clock starts when you become aware, so “we will look into it next week” is the wrong instinct. Get advice quickly rather than deciding on your own that it probably does not count.

Your payment provider and PCI

Separate obligations, owed to your provider and the card schemes rather than to a regulator. Your merchant agreement will say what you have to report and when. If card details were captured, tell them early. Providers deal with this constantly and would far rather hear it from you.

Preserving evidence

This is where good intentions do damage. The instinct is to delete the malicious file immediately and restore a backup. If you may have a reportable breach, you have just destroyed the record of what was taken and when, which is exactly what you will be asked for.

Take a full copy of files and database first. Keep the server logs. Note the times. Then clean.

We are a web agency, not solicitors, and the paragraphs above are context rather than legal advice. If customer data may have been exposed, that is the point to speak to somebody qualified rather than to work it out from a search result.

More on protecting a store

We have written a fair amount about the practical side of blocking bad actors on a WooCommerce store, which sits alongside everything above:

• WooCommerce security: essential tips to protect your store
• Top fraud prevention tactics for WooCommerce
• Protecting your store from phishing threats
• Blocking users by IP address
• Email blacklisting to prevent fraud and spam
• Blocking fraudulent users in WooCommerce

Frequently asked questions

Is WooCommerce less secure than Shopify?

Not inherently. The difference is who is responsible. On a hosted platform the provider patches the software whether you think about it or not. On WooCommerce that is your job, or your agency’s. WooCommerce gives you far more control and hands you the maintenance along with it. Neither is safer in the abstract, and a well maintained WooCommerce store is safer than a neglected anything.

Does WooCommerce store card numbers?

Standard WooCommerce with a normal payment gateway does not store full card numbers in your database. It does store names, addresses, email addresses, phone numbers and complete order histories, which is still personal data and still worth stealing. “We do not hold card details” is true and it is not the same as “there is nothing here to protect”.

Do I have to worry about PCI compliance?

Almost certainly something applies, and how much depends on how your checkout is built and how many transactions you process. A store using a hosted payment page carries a much lighter burden than one accepting card details directly on its own pages. Your payment provider is the right first call, because they will tell you which category you fall into.

Can I just block the countries the attacks come from?

You can, and it reduces noise. It is a blunt instrument, because attackers use proxies in whatever country you allow, and because you may block genuine customers. Useful as one layer, not as the strategy.

How often should a store be updated?

More often than a brochure site, and more carefully, because an update that breaks the checkout costs money immediately. That is the argument for staging: apply updates to a copy, confirm the checkout still takes a test payment, then apply to the live store. Our WordPress security plans include a WooCommerce tier that does exactly this.

---

Seeing odd orders, or worried about your checkout?

Send us what you are seeing and we will tell you whether it is card testing, fraud or something worse. If your checkout has been tampered with, that is urgent and we will treat it that way.

Marketing the Change is a digital marketing agency based in Liverpool. We build and maintain WooCommerce stores for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

You typed your own domain into Google, or somebody sent you a screenshot, and there they are. Page after page of Japanese text under your business name. Product listings for things you have never sold, in a language you do not speak, all sitting on your website.

Then you opened your site to look, and everything was completely normal.

That combination is the signature of the Japanese keyword hack, and the fact that your site looks fine to you is not reassuring. It is part of how the thing is designed.

What is actually happening to your site

Somebody has got into your website and is using it to run a shop.

Not on your homepage, where you would notice. They have generated thousands of pages at addresses you would never visit, filled them with Japanese product listings, and pointed them at a store selling counterfeit goods. Your domain has years of history and a certain amount of trust with Google. They are borrowing that trust to get their spam ranked, because a brand new domain would not rank at all.

The reason you cannot see it is a technique called cloaking. The site checks who is asking for the page. If it is Googlebot, or a visitor who clicked through from a Google search, it serves the spam. If it is a logged in administrator loading the homepage directly, it serves your normal site. You are, in effect, the one visitor the malware is specifically hiding from.

The owner is usually the last person to find out, and it is not because they were not paying attention. The infection is built so the owner is the last person to find out.

How to confirm it in five minutes

Three checks, none of which require any technical skill.

1. Search your own site

In Google, search for site:yourdomain.com. This lists what Google has indexed for your domain and nothing else. Scroll. If there are Japanese pages, you will see them, and the result count at the top is often the first clue: a ten page brochure site does not have 40,000 indexed pages.

2. Check Search Console

Open Google Search Console and look at two places. Security Issues will often say “Hacked: Content injection” or similar. Pages under Indexing will usually show a sharp climb in indexed pages starting on a specific date, which is roughly when it happened.

If you do not have Search Console, set it up now. It is free, and without it you are guessing about what Google can see.

3. Look at your site the way Google does

Take one of the spam URLs from the site: search and open it in a private browsing window, having first clicked through from the Google result rather than pasting the address. Because you arrived from Google and are not logged in, you will often see the spam page that your normal browser refuses to show you.

Use Search Console’s URL Inspection tool on the same address for the definitive answer, because that shows you exactly what Googlebot receives.

How it got in

Almost always a plugin or theme that had not been updated.

Most of these infections belong to a family called Balada Injector, which has been running since 2017 and has compromised over a million WordPress sites. It works through publicly disclosed vulnerabilities in popular plugins. Once a vulnerability is announced, automated scanners begin sweeping the whole web for sites still running the old version. The gap between disclosure and mass exploitation is often measured in hours.

Nobody chose you. A scanner found a version number it recognised.

Balada is also unusually persistent. It typically creates administrator accounts, plants multiple backdoors in different places, and installs its own scheduled tasks. That is why sites get cleaned and then reinfected a week later: somebody removed the spam pages and missed the four other things holding the door open. We described that pattern in detail when we found a live infection on a client site, including a backdoor hiding in a folder that does not appear anywhere in the WordPress dashboard.

Why this is an SEO problem, not just a security one

This is the part that surprises owners, and it is the part that costs the money.

Deleting the malicious files removes the infection. It does not remove the thousands of spam URLs Google has already indexed under your domain. Those pages will start returning errors, which is correct, but they sit in the index for a while regardless. Meanwhile:

• Your crawl budget has been spent on spam rather than your real pages
• Search Console is full of errors that make genuine problems impossible to spot
• Your sitemap may have been replaced or added to
• Google may have applied a manual action, which does not lift on its own
• Your actual pages have been competing for attention with 40,000 junk ones

A security company will hand you back a clean site. That is a genuine and necessary piece of work, and it is also only half of what you needed. The other half is getting the index cleaned up and the rankings back, which is search work.

Being both is the reason our malware removal service includes the recovery rather than treating it as a separate project.

The step almost everyone misses: rogue Search Console owners

This is the first thing Google itself tells you to do, and it is the one we most often find has been skipped. It is also why some sites get cleaned properly and are compromised again a fortnight later.

When an attacker gets into your site they frequently add themselves as a verified owner in Google Search Console. They do it by dropping a Google verification file in your site root, or by adding a rewrite rule to .htaccess that generates verification files on demand. The rule looks something like RewriteRule ^google(.*)\.html$ dir/file.php?google=$1 [L], and it means any token Google asks for is answered automatically.

The effect is that even after you have removed every malicious file, they still hold a verified line into your Search Console. They can read your data, submit sitemaps, and request removal of your real pages.

What to do:

1. In Search Console open Settings then Users and permissions and read the ownership list. Remove anybody you do not recognise.
2. Open Verification details and check how each owner verified. Remove the tokens belonging to anyone you have just removed.
3. Delete stray google*.html files from your site root that you did not put there.
4. Check .htaccess for the rewrite rule above and remove it.

Do this before you request a review, not after.

Cleaning it up properly

The order matters more than the individual steps.

1. Take a copy before you change anything. Including the database. You are preserving evidence, not making a backup to restore.
2. Find every affected file. Compare WordPress core against clean originals, check the theme, check mu-plugins, and check wp-content/uploads, which should never contain a single PHP file. Sort by modification date and look for anything changed on a day nobody touched the site. Obfuscated payloads usually announce themselves through a handful of functions: base64_decode, eval, gzinflate, str_rot13, strrev and preg_replace.
3. Check the database. Injected content frequently lives in the options and posts tables rather than in files. A file-only cleanup leaves it running.
4. Remove the accounts. Filter Users by Administrator and remove anything you did not create. Check for accounts with odd registration dates.
5. Remove the scheduled tasks. Balada leaves cron entries that reinstall the payload. Miss these and it comes back on a timer.
6. Close the entry point. Update everything, and work out which plugin was the way in. If you cannot identify it, assume the worst and update or remove aggressively.
7. Rotate everything. Passwords, and the security keys in wp-config.php, which invalidates any session the attacker still holds.
8. Check your sitemaps. These hacks frequently add their own sitemap file, or inject thousands of spam URLs into yours, which is how Google found the pages so quickly. Delete any sitemap you did not create and regenerate your real one.
9. Then deal with Google. Submit removals for the worst of the spam URLs, resubmit your clean sitemap, and request a review in Search Console if a security issue or manual action is listed.
10. Confirm from outside. Run the site through Google’s Safe Browsing site status page, Sucuri SiteCheck, VirusTotal and Quttera. Each catches slightly different things, and a clean result across all four is considerably more convincing than a clean result from your own security plugin.

Restoring an old backup is tempting and usually wrong. It puts the site back to a point where the vulnerable plugin is still installed and still vulnerable, and you lose whatever legitimate content you have published since.

How long recovery takes

Honest ranges, not promises.

• The cleanup itself: usually hours rather than days for a standard site.
• Search Console security warning: typically days after a successful review request, provided the site is genuinely clean when they check.
• Spam URLs leaving the index: weeks. Thousands of pages do not vanish at once, and Google recrawls them at its own pace.
• Impressions and rankings: commonly several weeks to a few months, depending on how long the spam was live and how much of it was indexed.

The single biggest factor is how long it ran before anyone noticed. A fortnight is very recoverable. Eight months of indexed spam is a longer road.

The pharma hack is the same thing wearing a different coat

If your spam pages are in English and selling pharmaceuticals rather than Japanese and selling handbags, everything above still applies. The pharma hack uses the same cloaking, the same entry points and the same persistence tricks. Occasionally it is subtler, injecting keywords into your existing page titles and meta descriptions rather than creating new pages, so what you see in Google is your own page title with a drug name bolted onto it.

Same problem, same fix, same two halves.

Frequently asked questions

Will my rankings come back?

In most cases yes, provided the cleanup is thorough and the search side is handled as well as the files. Sites that were established before the hack tend to recover reasonably well. What does not recover well is a site that gets cleaned three times because the entry point was never closed.

Do I need to disavow the links?

Usually not. The problem is spam pages on your own domain rather than bad links pointing at you. Disavowing is the wrong tool for this and can cause harm if used carelessly. Deal with your own site first.

Can I just delete the pages in Search Console?

The removals tool hides URLs from search results for about six months. It is useful for stopping the bleeding while you work, and it is not a fix. If the underlying infection is still there it will simply generate more pages. Use it as first aid, not as treatment.

Why does it keep coming back?

Because something was missed. In our experience it is nearly always one of four things: an administrator account left in place, a scheduled task that reinstalls the payload, a backdoor in mu-plugins or the uploads folder, or the original vulnerable plugin still sitting there un-updated.

My host cleaned it and it is still in Google. Is it still hacked?

Not necessarily. Index removal lags the cleanup, so seeing spam URLs in Google a week after a clean is normal. Check whether they still load. If they return an error, the cleanup worked and you are waiting on Google. If they still serve spam, the cleanup did not.

How much does this cost to fix?

For a standard WordPress site, a straightforward cleanup starts at £70. A full engagement, where we clean the site, close the entry point and handle the search recovery, is typically around £395. You get a fixed figure before anything starts.

---

Found Japanese pages under your domain?

We deal with these regularly. We will remove the infection, find and close the way in, and then do the part most cleanups skip: getting the spam out of Google and your rankings back.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

You searched for your own business, the way you do every so often, and there is a line of grey text under your listing that says This site may be hacked. Or worse, you clicked through and got a full red screen telling you the site ahead is dangerous.

The first feeling is usually not panic. It is disbelief, followed by a quick check on your phone to see whether it is really happening. Then you start wondering how long it has been there, how many customers have seen it, and whether anyone was going to tell you.

Here is what each of those warnings actually means, what caused it, and how you get it taken down. The warnings are not all the same, and treating them as though they are is why some sites stay flagged for weeks longer than they need to.

First, the question you are actually asking

Is this real, or is Google wrong?

It is almost always real. Google does not flag sites on suspicion or on a competitor’s say so. Something on your site, or something your site is loading from somewhere else, has been identified as harmful. False positives happen, but they are rare enough that you should assume the warning is correct and work from there.

The more useful question is which warning you have, because that tells you what Google found.

“This site may be hacked”

This one appears in the search results, as a small grey line under your page title. There is no red screen. Visitors can still click through to your site without an interstitial.

It means Google believes someone has added pages or content to your site without your permission. Typically that is spam: pages selling pharmaceuticals, counterfeit goods, or pages in a language you do not publish in. Google is not saying your site will harm the visitor’s computer. It is saying your site is not entirely yours any more.

The quickest way to see what Google is talking about is to search for site:yourdomain.com and look through the results. If there are pages you do not recognise, that is your answer. You can also add a keyword you would never sell, for example site:yourdomain.com viagra, and see what comes back.

The most common reaction we get when we show an owner their own spam pages is that they cannot see them on the site itself. That is deliberate. The pages are usually built to be visible to Google and invisible to you.

“Deceptive site ahead”

This is a full red page in Chrome, Firefox and Safari, and it stops visitors before they reach you. It is the most damaging of the four, because almost nobody clicks past it.

It means Google Safe Browsing believes your site is being used for phishing, which is to say tricking people into handing over passwords, card details or personal information. Usually the site has had a fake login page added somewhere in a folder nobody looks at, imitating a bank, a courier or a well known brand.

Owners often assume this must be a mistake, because their own site clearly is not a bank. That is the point. The attacker is not impersonating you, they are using your domain and your hosting to impersonate somebody else.

“The site ahead contains malware”

Another full red page. This one means Google has found code on your site that tries to install something on the visitor’s machine, or that quietly sends the visitor somewhere that will.

A common version of this involves a script that only runs for some visitors. That is why you may load the site twenty times and see nothing wrong. Google’s crawler saw it once and that was enough.

“The site ahead contains harmful programs”

This is the unwanted software warning, and it is the one most likely to genuinely surprise an owner, because it is sometimes not a hack at all.

It fires when a site offers downloads that behave badly: installers that bundle extra software, downloads that change browser settings, or advertising scripts from a network that has been abused. If you run downloads on your site, or you added an ad network recently, start there before assuming you have been broken into.

What it is costing you while it is up

This matters for deciding how fast to move, so it is worth being straight about it.

• The red interstitials stop nearly all traffic. A visitor who sees a full page warning does not usually continue. Treat that traffic as gone for as long as the warning is up.
• The search results label costs you clicks rather than all of them. Some people still click. Many do not.
• Your email may be affected. If the same server has been sending spam, your domain can end up on email blacklists, and your invoices start landing in junk folders.
• Your host may suspend you. Most hosts scan for this, and a suspension takes the site down entirely.
• Rankings drift down. Not usually immediately, but spam pages competing with your real pages under the same domain does you no favours.

Check what the outside world sees

Before you change anything, get an independent read on the site. Your own security plugin has an obvious blind spot, which is that it is running on the possibly compromised server.

• Google Safe Browsing site status. Google’s own checker. It tells you directly whether your domain is currently flagged and what for.
• Sucuri SiteCheck. Free, external, and good at spotting injected scripts and blacklist status across several vendors at once.
• VirusTotal. Runs your URL past dozens of security vendors, which is useful when one vendor disagrees with the others.
• Search Console. The only source that tells you specifically what Google found on your site, with sample URLs.

Take a screenshot of each before you start work. When you request the review later, having a clear before and after is genuinely useful, and it also stops you second guessing whether the warning was ever really there.

Remove any Search Console owners you do not recognise

This is the step that most cleanup guides omit entirely, and it is the reason some sites are compromised again shortly after being cleaned.

Attackers routinely add themselves as verified owners of your property in Search Console, either by leaving a Google verification file in your site root or by adding an .htaccess rule that produces one on demand. Removing the malware does not remove their access.

Open Settings then Users and permissions, read the list, and remove anyone you cannot name. Then open Verification details and revoke the tokens they verified with. Finally, delete any google*.html files in your site root that you did not put there.

What to do in the first hour

In order, and the order matters.

1. Do not restore an old backup yet. It feels like the obvious move. It also wipes the evidence of how they got in, and if the entry point is still open, the restored site gets infected again. Take a copy of the site as it is now before changing anything.
2. Do not delete files you think look suspicious. Same reason. You will almost certainly miss one, and you will have destroyed the trail to the others.
3. Change your hosting and WordPress administrator passwords. Do this from a device you trust.
4. Open Google Search Console and look at Security Issues. If you do not have Search Console set up, set it up now. It is free, and it is the only place Google tells you specifically what it found and gives you sample URLs.
5. Check your users list. In WordPress, go to Users and filter by Administrator. Any account you did not create needs investigating.
6. Tell your host. They may already know, and they can often tell you when the files changed.

If you would rather someone else did all of this properly, that is exactly what our WordPress malware removal service covers, including the review requests below and the search recovery afterwards.

Getting the warning removed

Here is the part that trips people up. The review request is the last step, not the first.

If you request a review and Google re-checks the site while it is still infected, the request fails. Repeated failed requests do not get you seen faster, and some site owners spend a fortnight resubmitting a site that was never clean.

The sequence that works:

1. Remove the malicious files, the injected database entries, any scheduled tasks and any accounts the attacker created.
2. Close the way in, which is usually an out of date plugin or a stolen password.
3. Rotate passwords and security keys again, now that the backdoor is gone.
4. Remove any Search Console owners and verification tokens you do not recognise, as above.
5. Confirm the site is clean. Check as a search visitor and on mobile, not just logged in on your own laptop.
6. Then open Search Console, go to Security Issues, and click Request Review. Describe what you found and what you did. A specific, honest description does better than a one line request.

How long does it take?

Once the site is genuinely clean and the review has been requested, the browser interstitials usually clear within a day or two. The search results label tends to go at the next crawl of the affected pages. Spam pages that were indexed take longer to disappear entirely, and rankings take longer again.

Anyone who promises you a fixed number of hours is guessing. Anyone who tells you the rankings come back the moment the warning does is wrong.

The part most cleanups skip

Removing the files and clearing the warning is not the same as recovering.

If the hack put spam pages into Google’s index, those pages are still there after the files are gone. They will 404 now, which is progress, but they need to drop out of the index, your Search Console coverage report needs to settle down, and any internal linking the hack mangled needs repairing. That is a search job rather than a security job, and it is why we treat the two as one piece of work rather than handing you a clean site and wishing you luck.

The malware might take an afternoon. The damage to your search visibility can take months, and it does not repair itself when the files are deleted.

Frequently asked questions

Can I just ignore it and hope it clears?

No. Google does not remove these automatically because time has passed. The flag stays until the site is clean and a review has been passed. Left alone, the situation normally gets worse, because whoever is using your site keeps using it.

Why can I not see anything wrong on my own site?

Most modern injections are conditional. They show themselves to search engine crawlers and to visitors arriving from Google, and hide from logged in administrators and repeat visitors. Loading your homepage while logged in is the least reliable test there is. Try a different device, a private window, and arriving via a Google search rather than typing the address.

Will this hurt my rankings permanently?

Permanently, no, in the great majority of cases. Sites recover. How quickly depends on how long the spam was live, how much of it was indexed, and how thoroughly the cleanup dealt with the search side as well as the files.

My host says the site is clean but the warning is still there. What now?

Two possibilities. Either the review has not been requested, in which case do that in Search Console. Or the host’s scan cleared the obvious files and missed something, which is common with database injections and backdoors placed in mu-plugins, a folder that does not appear anywhere in the WordPress admin. A second opinion is worth it before you resubmit again.

Do I need to tell my customers?

If the site handled personal data or card details and there is any chance it was exposed, take advice, because you may have obligations under UK GDPR. If it was spam pages in a folder and no customer data was involved, that is a different situation. Do not guess at this one.

How did they get in?

Nearly always an out of date plugin or theme with a publicly known vulnerability. Automated scanners test millions of sites for the same handful of weaknesses, find a match, and run the exploit. It is not personal, and it is not a reflection on the size of your business. We wrote up exactly what one of these infections looked like if you want to see the mechanics.

---

Seeing one of these warnings on your site right now?

We remove the infection, close the way in, request the review and handle the search recovery afterwards. If it turns out not to be a hack at all, we will tell you that instead of selling you a cleanup.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

A customer rings to say your website took them to a page selling something strange. You open the site on your laptop while they are still on the phone, and it is completely fine. Homepage loads, everything where it should be.

So you tell them it must be their browser, or their phone, or something at their end. Then a second person mentions it. Then a third.

They are not imagining it, and your site is not fine. This is one of the most common WordPress compromises there is, and the entire design of it is to keep you convinced that nothing is wrong.

Why it works for you and not for them

A redirect hack that fired for everybody would be found and fixed within the hour. Whoever wrote it knows that, so the code makes a decision about every visitor before it does anything.

Typical conditions we find:

• Only visitors arriving from a search engine. If you type the address directly, nothing happens. Click a Google result and you are gone.
• Only mobile devices. Desktop users see a normal site. Phone users get redirected, which is most of your traffic on many sites.
• Only visitors who are not logged in. You are logged in as an administrator almost all the time, so you are exempt.
• Only once per visitor. The code sets a cookie, so it fires once and then behaves. If you do test it and catch it, trying again looks like it fixed itself.
• Only outside your office hours or your IP address. Less common, but we have seen it.
• Sometimes it is not a redirect at all. Some variants leave the page alone and instead trigger browser push notification prompts, so visitors end up subscribed to spam alerts that keep arriving long after they have left your site.

Loading your own homepage while logged in on your own laptop is the least reliable test available. It is the exact scenario the malware is written to survive.

Reproducing it on purpose

Before you can fix it you need to see it. Work through these until it happens. No technical skill required for the first three.

1. Use your phone on mobile data, not the office wifi, and search for your business in Google rather than typing the address. Click the result.
2. Use a private or incognito window on your computer, so you are not logged in, and again arrive via a Google search.
3. Ask someone who has never visited the site to try it from their own phone. A fresh visitor with no cookies is the ideal test subject.
4. Use the browser developer tools. Open them, switch to the device toolbar to emulate a phone, tick “Preserve log” in the Network tab so the redirect chain is not wiped, and reload. The Network tab will show you the redirect happening and where it goes.

Do not visit the destination and start clicking things. Note the address and leave.

Where the code is hiding

There are five usual homes for this, and a thorough cleanup checks all of them rather than stopping at the first one found.

The .htaccess file

The classic location, because it runs before WordPress does. Look for rewrite rules referencing a domain you do not recognise, or conditions checking the referrer for search engines. Attackers often pad the file with blank lines so the malicious block sits far below what you see on opening it, or hide a second .htaccess inside a subfolder.

The theme files

Usually functions.php or header.php. This is where we found it on our own site in August, as an injected script in the theme header that redirected bots. Look for long strings of encoded characters, or anything using base64_decode, eval, gzinflate, str_rot13, strrev or preg_replace. Those functions all have legitimate uses, so treat them as a reason to look closely rather than as proof on their own.

The database

Frequently missed, and a common reason cleanups fail. Injected JavaScript often lives in the wp_options table, particularly in fields holding header or footer scripts, in theme_mods, or in custom CSS. It also turns up in wp_posts, and specifically in the post_content_filtered column, which almost nobody thinks to check because it is invisible in the editor. A file-only cleanup leaves all of that running happily.

The mu-plugins folder

Short for “must use plugins”. Anything placed here loads on every request and does not appear anywhere in the WordPress plugins list. There is no toggle, no version number, nothing to see. Most site owners have never opened this folder, which is exactly why it gets used. We found a backdoor here on a client site recently and wrote up exactly how it worked.

The uploads folder

Your media library lives in wp-content/uploads and should contain images, PDFs and video. It should never contain a single .php file. If there is one in there it is not yours. This is one of the fastest checks available and one of the most reliable, because a normal WordPress site simply does not put executable code in the uploads folder.

The wp-includes folder, and your site address settings

wp-includes holds WordPress core machinery that nobody has any business editing, so anything added or modified in there is suspect.

Separately, check Settings then General in WordPress, or the siteurl and home rows in the wp_options table. If either has been pointed at a domain that is not yours, that alone redirects your entire site, and it is a two second fix once you know to look.

A plugin that should not be there

Sometimes the redirect arrives as a real, installed plugin with a plausible name, added by an administrator account the attacker created. Check your plugins list for anything nobody remembers installing, and check the Users list while you are there. Filenames we see repeatedly include mplugin.php and wp-zzz.php, though the name is whatever they felt like on the day, so judge it on whether you recognise it rather than on whether it looks sinister.

Removing it so it stays removed

The redirect is the symptom. The backdoor is the problem. Sites that get cleaned and reinfected within a week have almost always had the symptom treated and the cause left alone.

1. Take a full copy of files and database first, as evidence rather than as a restore point.
2. Narrow the search by modification date. Over SSH, find . -type f -mtime -7 -ls lists everything changed in the last week, which usually puts the malicious files at the top of a very short list.
3. Remove the redirect code from wherever you found it, and keep looking after you find the first one. Multiple copies are normal.
4. Replace WordPress core files with clean originals rather than trusting a visual inspection.
5. Search the database for the injected snippet and remove it there too.
6. Delete administrator accounts you did not create, and check for scheduled tasks that reinstall the payload.
7. Identify the way in, which is usually an out of date plugin, and close it.
8. Rotate all passwords and the security keys in wp-config.php, which logs out any session the attacker still has.
9. Clear every layer of cache: the caching plugin, the host cache, and any CDN in front of the site. A cleaned site served from a stale cache still redirects, and this is a common reason people believe a cleanup failed when it did not.
10. Reinstall plugins and themes from official sources rather than trusting the copies already on the server, and delete anything you are not actively using.
11. Retest using the reproduction steps above from a device that has never loaded the site, then confirm with an outside scanner such as Sucuri SiteCheck or VirusTotal.

If that list reads like a fortnight of your life, it is the job our WordPress malware removal service exists to do, usually within a few hours.

Then deal with Google

A redirect hack that has been running for any length of time has usually attracted attention. Check Search Console for security issues, and check whether a browser warning has appeared. If it has, we have written a full guide to what each Google warning means and how to get it lifted.

Request the review only once the site is genuinely clean. Requesting it early and failing is the most common way people add a week to their own recovery.

Frequently asked questions

Could this be a plugin conflict rather than a hack?

A redirect to another domain you have never heard of is a hack. Redirect loops, or being sent to your own homepage unexpectedly, can be a misconfigured plugin, a site address setting or an SSL rule. If the destination is somebody else’s website, stop looking for an innocent explanation.

Can I just restore a backup from before it started?

You can, and it often works for about a week. The backup contains the same vulnerable plugin that let them in, so unless you update everything immediately afterwards you have restored the door along with the site. You also lose any legitimate content published since.

My security plugin scanned and found nothing. Am I clear?

Not necessarily. Scanners are good at recognising known malicious files and much weaker at database injections, at heavily obfuscated code, and at files in mu-plugins. A clean scan alongside customers reporting redirects means the scan missed something, not that the customers are wrong.

How much traffic am I losing while this runs?

Potentially most of it. If the condition is “arrived from a search engine”, every organic visitor is being handed to somebody else, and your analytics will show the sessions starting and then nothing. A sudden drop in pages per session alongside stable session counts is a strong hint.

Will my rankings recover?

Usually, yes. The longer it ran, the longer the recovery. Google noticing that your pages send visitors somewhere else is not a good look, and reversing that impression takes a few weeks of clean crawling rather than a switch being flipped.

---

Customers seeing a different site to the one you built?

Send us the site and we will tell you whether it is a redirect hack within the hour, usually for nothing. If it is, we will give you a fixed price to clean it and close the way in.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

Something has made you suspicious. Maybe the site felt slow this morning, or a customer mentioned something odd, or you saw a login notification you did not expect. Maybe you just read about somebody else getting hacked and thought you had better check.

The frustrating thing about that moment is that there is no single button marked “am I hacked”. Loading your homepage tells you almost nothing, because the infections that matter are built to look normal to you specifically.

So here is what actually works, in the order we run it. The first four checks take about ten minutes between them and catch most of what is out there. The rest are for when you want to be certain.

The ten minute version

1. Search your own site in Google

Search for site:yourdomain.com. This shows only pages Google has indexed for your domain.

Two things to look at. First the page count: if you have a twelve page website and Google reports 9,000 results, that is your answer. Second, scroll through for anything in a language you do not publish in, or products you do not sell. Pharmaceuticals, replica goods and Japanese text are the classics.

Clean result: roughly the number of pages you would expect, all recognisable.

2. Check Search Console security issues

In Google Search Console, open Security & Manual Actions. If Google has spotted a compromise, it says so here, and it usually gives you example URLs.

While you are in there, look at Indexing > Pages and check the graph. A sudden vertical climb in indexed pages on a specific date is one of the clearest signals there is, and it dates the infection for you.

Clean result: “No issues detected”, and an indexing graph without cliffs.

3. Look at your administrator accounts

In WordPress, go to Users and filter by Administrator. Read every single one.

Any account you did not create, or that belongs to a developer who finished eighteen months ago, needs dealing with. Attackers frequently give these accounts ordinary looking names precisely so a quick glance skips over them. Check the email address on each account as well as the username, because the username can look entirely reasonable while the email points somewhere else.

When our own site was compromised in August, two administrator accounts had been created that nobody recognised. That was one of the clearest signals we had.

Clean result: every administrator is a person you can name.

4. Visit your site as a stranger

Take your phone off the office wifi, search for your business in Google, and click the result. Do not type the address in.

This one check defeats most conditional malware, which hides from logged in administrators and from direct visits but shows itself to search visitors on mobile. If you get redirected somewhere unexpected, you have found it, and our guide to the WordPress redirect hack covers what happens next.

Clean result: your site, looking like your site.

If you only do one of these, do this one. Almost every owner who tells us their site is fine has tested it while logged in, on a desktop, by typing the address directly. That is the one visitor the malware is written to fool.

If you want to be thorough

5. Check whether Google is warning about you

Search for your business name and look underneath the result for “This site may be hacked”. Then click through and watch for a full red interstitial. Each of the four warnings Google shows means something different, and we have written up what each one means and how to get it removed.

6. Look at your plugins list

Anything nobody remembers installing is worth investigating, as is anything with no author, no version number or a description that reads oddly. Also note which plugins have updates waiting, because the one that let them in is usually somewhere in that list.

7. Check your email is still arriving

Send yourself an invoice or a contact form notification from the site to an address on a different provider. Compromised sites are frequently used to send bulk spam, which gets the domain blacklisted, and the first business symptom is often that your quotes stop reaching people rather than anything visible on the website.

8. Look at when files were last modified

Through your hosting file manager or over SFTP, sort the WordPress folders by modification date. You are looking for files changed on a date when nobody touched the site. Core WordPress files that changed outside an update window are a strong signal.

One detail worth knowing: if a group of files all share the exact same timestamp, down to the second, that was a script rather than a person.

9. Open the mu-plugins folder

Look in wp-content/mu-plugins. Most sites either do not have this folder or have one or two files in it that a developer added deliberately.

It matters because anything placed here runs on every request and never appears in the WordPress plugins list. There is no activate toggle and nothing to see in the dashboard. It is one of the most common hiding places for a backdoor, and almost nobody checks it. This is precisely where we found a backdoor on a client site, which we documented in this write-up of a live infection.

10. Check the REST API namespaces

This is the technical one, and it is the check that found the infection in the post above.

Visit yourdomain.com/wp-json in a browser. You will get a wall of technical text. Look for the namespaces list near the top. Every entry should correspond to WordPress itself or to a plugin you recognise. An entry with a plausible but unfamiliar name, something like a fake update or fix plugin, is a backdoor advertising itself.

It is an odd place to look, which is exactly why attackers are relaxed about it.

11. Check your post revision history

Open a few of your important pages in the editor and scroll to Revisions. WordPress keeps a history of every change, including changes made by somebody who should not have been there. If a page was edited on a date nobody was working, the revision history will show you what changed and under which account.

It is an underused check and it is often the fastest way to date an infection precisely.

12. Check your site address settings

In Settings then General, confirm the WordPress Address and Site Address are both your own domain, and that the administration email is yours. Changing the admin email is a quiet way to intercept password resets, and changing the site address redirects the whole site in one move.

13. Look for PHP files in your uploads folder

Open wp-content/uploads in your hosting file manager and search for .php. There should be no results. Your media library holds images and documents, not executable code, so anything with a .php extension in there was put there by somebody else.

14. Check who has access to your Search Console

In Search Console, open Settings then Users and permissions. Attackers often add themselves as a verified owner so they keep access after a cleanup. If there is an owner you cannot name, that is a finding in its own right, and it needs removing along with the verification token they used.

15. Get a second opinion from outside the site

Run the domain through Google’s Safe Browsing site status page, Sucuri SiteCheck and VirusTotal. All three are free, none of them requires access to your site, and because they look from the outside they are not fooled by anything hiding on your server.

Symptoms, and what they usually mean

What you are seeing	Most likely cause
Customers redirected, site fine for you	Conditional redirect hack
Foreign language pages in Google	Japanese keyword hack, usually Balada Injector
Pharmaceutical pages or keywords in your titles	Pharma hack
Red browser warning	Safe Browsing flag, phishing or malware
Homepage replaced entirely	Defacement
Host suspended the account	Outbound spam or resource abuse
Emails suddenly landing in junk	Domain blacklisted, often after spam sending
Site suddenly slow	Cryptomining, spam sending, or an unrelated performance problem
White screen or critical error	Usually a plugin conflict or PHP change, not a hack
Cannot log in, password rejected	Credentials changed, or a login page injection

That last but one row is worth dwelling on. A white screen or a “There has been a critical error on this website” message feels like the worst thing that can happen, and it is almost never a compromise. It is usually an update that disagreed with something. We took one of those apart line by line in this post about a 3:27am outage.

If a check comes back badly

Two things not to do, both of which feel like the responsible reaction.

• Do not start deleting files that look suspicious. You will miss some, and you will have destroyed the trail to the rest.
• Do not restore an old backup over the top. It removes the evidence and restores the vulnerable plugin that let them in, so you get reinfected and now have no idea how.

Do change your hosting and administrator passwords, take a full copy of the site as it currently stands, and tell your host. Then get the cleanup done properly, either yourself or by someone who does it regularly. Our WordPress malware removal service covers the whole job including the search recovery afterwards.

Frequently asked questions

My security plugin says the site is clean. Is that enough?

It is evidence, not proof. Scanners match against known malicious code, so they are strong on common infections and weak on anything new, heavily obfuscated, or sitting in the database rather than in a file. The infection we found on a client site had been partially detected: one of the two files was flagged, the other was not.

How does a website get hacked in the first place?

Overwhelmingly through an out of date plugin or theme with a publicly known vulnerability. After that, weak or reused administrator passwords, and then shared hosting where a different site on the same server was compromised first. Targeted attacks on small business websites are rare. Automated scanning is constant.

How long do these usually go unnoticed?

Longer than owners expect. A defacement is found in minutes because it is obvious. A cloaked spam injection can run for months, and the first sign is often a customer complaint or a drop in enquiries that gets blamed on the market.

Is a small business website really a target?

You are not a target. That is the point. Nobody chose your site. A scanner tested millions of sites for one specific weakness, yours matched, and the exploit ran automatically. Size is irrelevant to a process that never looked at who you are.

Can I check without touching the site?

Yes. Checks one, two, four and five are all done from outside, using Google and your phone. You do not need to log in to anything except Search Console, and you cannot break anything by doing them.

---

Something came back that you did not like?

Send us what you found and we will tell you what it means. If it is nothing, we will say so. If it is a compromise, we will give you a fixed price to clean it and close the way in before it gets worse.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

\n\n

It started with a routine security check.

The site looked fine. No warnings in the browser, no defaced pages, no spam links in the footer. A visitor would have noticed nothing. The client had noticed nothing. But buried in the WordPress REST API response, in a list of technical namespaces most people never look at, was a name that had no business being there: wp-fixplugin/v1.

That one anomaly unravelled a two-component malware infection that had been live for two days. Both files were placed on the server in the same second. One had already been partially detected by a security scanner. The other had not been detected at all.

Here is exactly what we found, how it worked, and what you should check on your own site right now.

How WordPress Sites Get Hacked (It is Probably Not What You Think)

The most common thing we hear from site owners after a hack is some version of: “Why would anyone target us?”

They would not. That is the point.

The vast majority of WordPress compromises are not targeted attacks at all. Automated scanners probe millions of WordPress sites continuously, looking for known vulnerabilities in specific plugin versions. When a scanner finds a match, it does not stop to consider whether the site belongs to a multinational or a local business. It runs the exploit and moves on. The whole process takes seconds.

This is why the timestamp on the two malicious files in the incident we investigated was identical. Not the same minute, not the same hour: the same second. A human browsing a file system does not work that way. An automated deployment script does.

The entry point is almost always a plugin that has not been updated. Plugin developers issue security patches regularly, often in response to publicly disclosed vulnerabilities. Once a vulnerability is public, every site still running the old version becomes a target. The window between disclosure and exploitation is often measured in hours, not days.

Signs Your WordPress Site Has Been Hacked

The infection we found left no visible traces. But that is not always the case. Here are the most common indicators that a WordPress site has been compromised:

• Google is showing a warning. If visitors see “This site may be hacked” or a red warning page before reaching your site, Google has already flagged it. Check Search Console for manual actions.
• Your site redirects to somewhere else. Visitors land on a different site entirely, often a spam page or a phishing site. This is one of the most common signs of a WordPress hack.
• Spam emails are being sent from your domain. If contacts are receiving emails you never sent, or your domain ends up on an email blacklist, your site or server may be the source.
• You cannot log in. Your password stops working, or your account no longer exists. Attackers often change admin credentials after gaining access.
• New admin accounts you do not recognise. Go to Users and filter by Administrator. Any account you did not create yourself needs investigating immediately.
• Your host has suspended the account. Reputable hosts scan for malware and suspend sites that are actively attacking other servers or distributing malicious code.
• Pages or posts you did not write. Injected spam content, often in languages you do not recognise, is a common side effect of search engine spam attacks.

The absence of these signs does not mean your site is clean. The malware we found showed none of them. Its entire purpose was to stay hidden.

If any of these checks turn something up, do not start deleting files, because that destroys the evidence of how they got in. Our WordPress malware removal service covers the cleanup and the search recovery that follows it.

What the Malware Actually Did

This infection used two files working together. Removing one without the other would have left the site still compromised.

Component One: The Remote Control Door

The first file was placed inside a folder called mu-plugins.

Most WordPress users have never heard of this folder, which is exactly why attackers use it. mu-plugins stands for “must-use plugins.” Files placed here load automatically on every page request and do not appear anywhere in the WordPress admin panel. There is no plugins list entry, no activate/deactivate toggle, no version number. The folder is functionally invisible to anyone who does not know to look for it.

The file registered three hidden REST API endpoints:

• /wp-fixplugin/v1/update: accepts an encrypted payload along with a key and encryption parameters. In plain terms, the attacker can send an encrypted instruction from anywhere in the world and have it executed on the server.
• /wp-fixplugin/v1/status: a heartbeat check, confirming the backdoor is still active.
• /wp-fixplugin/v1/remove: a self-destruct, allowing the attacker to clean up their tracks on command.

This is a command-and-control backdoor. With the right key, whoever placed it there could run any code on the server, read any file, modify any database record, or pivot to other sites hosted on the same account. The Jetpack security scanner, which had run a full scan of the site that morning, did not flag this file.

Component Two: The Hidden Administrator

The second file was disguised as a plugin called “WordPress Cache Optimizer.” Cache optimisation is a legitimate, boring, entirely plausible reason for a plugin to exist. It is exactly the kind of name a site owner skims past without a second thought.

This one Jetpack did catch, with two separate threat signatures. The plugin did two things. First, it created a secret administrator account on every page load, ensuring that even if the account were deleted, it would simply be recreated the next time someone visited the site. Second, it hooked into WordPress’s own user query system to strip that account from every list, every search, and every admin screen. The user existed in the database. It simply did not appear anywhere a site owner would look.

The two components worked together: the hidden admin account provided a persistent login if the backdoor were ever removed, and the backdoor provided remote code execution if the hidden account were ever deleted. Redundant access, two different methods.

How to Check Your Own WordPress Site Right Now

These checks take less than five minutes and require no specialist tools.

• Check the REST API namespace list. Go to yourdomain.com/wp-json/ in your browser. Look through the list of namespaces. You should be able to match every one to a plugin or theme you recognise. Anything unfamiliar is worth investigating.
• Check your mu-plugins folder. Go to yourdomain.com/wp-content/mu-plugins/. If your server has directory listing enabled, you will see the files inside. Any file you do not recognise, particularly a large one, is a red flag.
• Run a Jetpack scan. If you have Jetpack installed, go to Jetpack and trigger a scan. It will not catch everything, as this case demonstrates, but it covers a significant proportion of known malware signatures.
• Check your user list carefully. In WordPress admin, go to Users and filter by Administrator. Count them. Any account you do not recognise deserves immediate attention.
• Look at your active plugins list critically. Any plugin with a generic name you do not remember installing is worth scrutiny. “Cache Optimizer,” “Performance Booster,” and “Security Enhancer” are exactly the kinds of names attackers use.

If Your WordPress Site Has Already Been Hacked: What to Do First

Order matters here. Done wrong, a cleanup can leave a site still compromised.

1. Do not just change passwords and hope for the best. If the attacker placed a backdoor file, changing passwords will not remove it. The file will still be there and still work.
2. Identify and remove the malicious files first. Check mu-plugins, check your plugin folders, and run a scanner. Only then is the server actually clean.
3. Find and delete any accounts you did not create. Once the file hiding them is removed, they should become visible in your user list.
4. Change all passwords after the cleanup, not before. Resetting passwords while a backdoor is still active is pointless. The attacker can simply create a new account or use the backdoor to reset credentials again.
5. Check server access logs. Your host can tell you when and how the malicious files were uploaded. This tells you which plugin or credential was the entry point, so you can close it properly.
6. Restore from backup if in doubt. If you cannot be certain the site is clean, a known-good backup is faster and more reliable than trying to find every file an attacker may have modified.

What Good WordPress Security Actually Looks Like

None of this requires expensive tools or a dedicated security team. Most WordPress compromises are entirely preventable.

• Keep every plugin updated. This is not optional. The gap between a vulnerability being disclosed and automated scanners exploiting it is shrinking. Plugins on old versions are open doors.
• Fewer plugins means a smaller attack surface. Every plugin you are not actively using is a potential entry point with no benefit in return. Deactivate and delete anything you do not need.
• Enable your firewall. Jetpack includes a Web Application Firewall that many sites have installed but never switched on. Either enable it or use an alternative like Wordfence.
• Disable directory listing. Your server should not allow visitors to browse your file structure. Add Options -Indexes to your .htaccess file, or ask your host to disable it.
• Have someone check the site properly once a year. A scan and a manual review of users, plugins, and the REST API namespace list takes about an hour and catches things automated tools miss.

Frequently Asked Questions

Has my WordPress site been hacked?

Common signs include: Google showing a warning to visitors, your site redirecting to another domain, new administrator accounts you do not recognise, spam being sent from your email domain, or your host suspending your account. That said, sophisticated malware often leaves none of these signs. If you are unsure, check your mu-plugins folder, your full user list, and the REST API namespace list at yourdomain.com/wp-json/.

Why does WordPress get hacked so much?

WordPress itself is not the problem. The core software is well-maintained and patched quickly when vulnerabilities are found. The issue is scale and the plugin ecosystem. WordPress powers around 43% of all websites, which makes it worth automating attacks against. And with thousands of third-party plugins, each with their own update cycles and security track records, there are a lot of potential entry points. One unpatched plugin on one site is all it takes.

Is WordPress safe from hackers?

WordPress core, kept up to date, is reasonably safe. The risk comes from plugins and themes, particularly ones that are not updated regularly or that have known vulnerabilities. A WordPress site with a small number of well-maintained plugins, a firewall active, and regular updates applied is significantly harder to compromise than one that has not been touched in eighteen months.

What should I do immediately if my WordPress site has been hacked?

Do not just change passwords and assume the problem is solved. If a backdoor file has been placed on your server, it will still be there and still function regardless of your login credentials. The priority is identifying and removing the malicious files first, then finding and deleting any accounts the attacker created, and only then resetting all passwords. If you are not confident in doing this yourself, get someone to do it properly rather than doing it halfway.

Can a hacked WordPress site be recovered without a backup?

Yes, in most cases. Malware typically adds files rather than deleting your content, so recovery usually involves finding and removing the malicious code and accounts rather than rebuilding from scratch. A backup makes the process faster and more certain, but it is not always necessary. The harder part is identifying everything the attacker left behind, which is why a professional cleanup is often worth the investment.

---

Think your WordPress site might be compromised?

If you found something in the checks above, or you just want a second pair of eyes on your site before something goes wrong, we can take a look. This is something we do regularly, and the earlier we look, the less there is to clean up.

Marketing the Change is a digital marketing agency based in Liverpool. We manage WordPress sites for clients across the UK, which means we occasionally find things like this. When we do, we write about it.

A few weeks ago we picked up a domain at auction. The site behind it had been offline since 2018, but the domain itself carried real backlink history: over a hundred live referring sites, a couple of them with Ahrefs domain ratings north of 90, a scatter of university faculty pages, small-business homepages, and one old public-service site in South Africa.

None of that surprised us. What did surprise us was why they were still linking. The site used to run a free web counter, a small script embed that visitors would drop into their own page HTML to display a live view count. Fifteen years later, those embeds are still on the page. They still fire on every visit. They just fetch nothing, because the endpoint has been dead for seven years.

Which means the moment we bought the domain, we controlled what those hundreds of visitor browsers loaded. That is the story.

How the counter worked, in plain English

Free web counters were everywhere in the early 2000s. You would sign up on the counter provider’s site, pick a username, and paste a snippet like this into your own site’s HTML:

<a href="https://provider.example/" rel="noopener">
  <script src="https://provider.example/pphlogger.js.php?id=jsmith"></script>
  <noscript>
    <img src="https://provider.example/pphlogger.php?id=jsmith&showme=y">
  </noscript>
</a>

Every visit to your page ran two things. It fired a request to the image URL, which incremented your counter and returned an image showing the current total. And it loaded the JavaScript file, which used document.write to inject an image tag into your page.

That second part is the interesting one. The JavaScript file executes on your visitor’s browser. It has the same permissions as the rest of your page’s code. It can write anything into the DOM. It can call any URL. It can read your visitor’s cookies for your own site if you loaded it in-page without an iframe.

Whoever owns the counter provider’s domain controls that JavaScript file. In 2003, the original operator was serving up an image tag and nothing else. In 2026, the domain was for sale.

A dormant script is exactly the sort of thing a routine review catches and nothing else does. That is what our WordPress security services are for, and if something has already been exploited, our malware removal service picks it up from there.

What we could have done, if we were bad actors

We bought the domain to rebuild the tool as a modern free counter. But the same purchase could have gone very differently. Here is a short list of what a bad actor could have done from day one:

• Credit card skimmer. On any e-commerce site that still had the counter embedded, inject a Magecart-style script into the checkout page. Read the card number, CVV, and address, ship it to a domain the attacker owns.
• Credential harvester. On any login page or portal, add a fake password field or intercept the form submit before the browser posts.
• SEO poison. Inject links to a spam network on every page that ran the counter, cheaply weaponising a hundred university and small-business sites into a link farm.
• Redirect chain. If a visitor arrived from a search engine, bounce them through a click-fraud chain before the real page loaded.
• Cryptomining. Silently run a cryptominer in the visitor’s browser while they read the page. Small cost per visit, big cost when the counter fires on hundreds of pages every day.
• Malware dropper. Serve up an exploit kit targeting outdated browsers, or fingerprint the visitor and only attack the vulnerable ones.

None of these would have set off an alarm on the sites that embedded the counter. Their WordPress site, their Wix site, their static HTML, would look identical in the page source. The malicious code lives on our server, not theirs. Their content security policy (if they even had one) probably allowed us because we had been trusted since 2003.

This is not theoretical. It has already happened.

Dormant third-party dependencies are a common attack path. A few well-known examples:

• In 2018 the analytics library Feedify was compromised and used to skim payment data from a chain of e-commerce sites.
• In 2020 a compromised JavaScript CDN shipped skimmer code to hundreds of Magento sites via bundled extension updates, documented by Sansec.
• In 2023 Polyfill.io was bought by a Chinese CDN and turned into a mass-injection tool, hitting more than 100,000 sites overnight.

Each time the pattern was the same. A useful, trusted, third-party script. A change of ownership. New code shipped from the same URL. Users had no idea until researchers noticed.

Why this matters especially when a company shuts down

When a service goes dark, most site owners do not remove the embed. They notice the counter is not rendering, they might tut about it, and they leave the code in the page. It costs them nothing while the domain sits dormant.

It costs them everything the moment the domain changes hands. And domains change hands quietly. The counter provider’s DNS record does not blast out a notification when the WHOIS changes. The site inheriting the embed has no built-in way to know.

So the moment you notice a service has shut down, remove the code. Then the moment you inherit a site from a former agency or a departing colleague, audit what third-party code is running on the pages you own. It is the cheapest, highest-impact security work you will do in a quarter.

How to audit your own site in 20 minutes

You do not need a security team. You need a browser and a clear afternoon.

• Open your homepage in a fresh Chrome or Firefox window. Right-click, choose View Page Source. Search the raw HTML for <script src and <iframe. Every result is a third-party dependency you should recognise.
• Open DevTools (F12) and go to the Network tab. Reload the page. Sort by domain. Every domain you do not recognise is a candidate for removal.
• Search for “counter”, “widget”, “tracker”, “stats”, “hitcounter”, “webring”. These are all common names for embeds that were popular a decade or two ago and often still sit dormant.
• Check your WordPress functions.php, footer.php, or theme options. A depressing number of themes still hard-code a legacy embed.
• Look at your Cloudflare or Cloudflare-equivalent access logs. Look for outbound requests you do not recognise firing on every page load.

If you find something that fits the pattern (small utility, shut down years ago, embed still fires), remove the code, redeploy, and check your Content Security Policy blocks its domain going forward. Do not wait to see who buys the domain next.

What we did with the domain, since you are wondering

We rebuilt the counter. Same URLs, same query parameters, same image tag output. Every site still embedding the snippet now sees a live SVG counter again with no code change on their end.

Starting from zero would have been misleading, so we queried the Ahrefs API for every referring site, scanned the top 500 by traffic for the embed pattern, extracted the counter IDs still in the wild, and seeded each counter with the referring domain’s all-time Ahrefs traffic estimate. That is our best proxy for how many visits the counter would have accumulated if the endpoint had kept working. The seeded totals are visible on the counter itself; nothing is faked, and the source of the number is documented on the site.

We did this because it was the honest option. It is also the option that treats the small-business owner whose old about-us page still embeds the counter as someone worth respecting. Their counter did not get reset by a domain change. Their visitor traffic estimate is grounded in real data.

Where we can help

The audit is not just for old sites. If you inherited a WordPress site from another agency, run one before you make your first change. If your business changed hands, run one on the first day. If a supplier goes into administration, check whether they were serving code on your pages, and if so, block the domain the same afternoon.

The takeaway

You do not control the code you did not write. You control the code you choose to load. Every third-party script on your site is a trust decision, and trust decisions expire when the company you trusted stops existing.

If you learn one thing from this piece: the moment a service you rely on shuts down, remove the code. Do not wait for the domain to change hands. Do not assume it will stay parked. Do not trust that a security researcher will notice before an attacker does.

If you want a second pair of eyes on your site, that is what we do. And if you spot a dormant counter, tracker, or widget still fetching from a domain that should not exist any more, treat it like a fuse. Because that is exactly what it is.

TL;DR:
I was contacted by what appeared to be a legitimate non-profit client requesting WordPress support. After several normal emails, I was asked to log in via a fake WordPress login page designed to steal credentials. The scam relied on patience, trust-building, and realistic workflows, not urgency. Always verify login URLs, never send credentials, and treat unusual access requests as a red flag.

The Scam I Almost Fell For (And How to Spot It)

Even when you work in digital marketing every day, scams can still catch you off guard, especially when they’re well-written, patient, and carefully tailored to your industry.

For context, Marketing the Change has been operating for over a decade, working on hundreds of WordPress websites across a wide range of sectors. We’re trusted Jetpack partners, and a large part of our work involves security, malware cleanup, and recovering hacked WordPress sites. Spotting suspicious behaviour is genuinely part of our day-to-day wor,k which is exactly why this experience stood out.

Just before Christmas, I was contacted about some website work that, on the surface, looked completely legitimate. The emails were professional, the website looked real, and the request itself was something we deal with all the time.

It nearly worked.

Here’s what happened and what you can learn from it.

How It Started (Very Normally)

I received an email from someone introducing themselves as a marketer for a US-based non-profit organisation. They asked for help improving their website and shared:

• A real-looking website
• A Google Doc listing website tasks
• A believable story about firing a previous developer for overbilling

Nothing about this felt rushed or suspicious. In fact, it felt too normal the exact type of enquiry agencies deal with every week.

The Trust-Building Phase

Over a few emails, the conversation stayed professional and measured:

• Discussion about site speed and performance
• Clarifying whether issues were UX-related or SEO-related
• Polite, patient responses (no pressure tactics)

They even leaned into shared values, mentioning Christian ministry work, something that subtly lowers your guard if you’re not careful.

This phase is important: good scams don’t rush you.

• Link to website
• Fake phone number
• Real website
• read address
• Real logo

Here is a snapshot of the Google Doc they sent

He even sent a video showcasing the issue that he was facing

The Red Flag Moment

Things changed when I was asked to:

• Log in to a WordPress site using a non-standard login URL
• Complete a Google authorisation flow
• Send back a generated username after logging in

At first glance, the page looked like a normal WordPress login screen. But it wasn’t loading from the website’s own domain and that’s where everything fell apart.

On closer inspection, the login page was pulling scripts and assets from an entirely different domain:
https://matungasert.com/ a website that Google has flagged as a dangerous site.

Digging a little deeper revealed multiple red flags:

• The login page was masquerading as WordPress
• The site’s real /wp-admin The login still existed and worked normally
• External scripts were being loaded from a known malicious domain
• The request to “send back a username” made no sense in any legitimate WordPress workflow

At that point, it was clear this wasn’t a misconfiguration or a buggy plugin.
It had all the hallmarks of a credential-harvesting phishing setup, designed to quietly capture logins while appearing completely legitimate.

What I Did Next

Instead of logging in, I:

1. Stopped the conversation immediately
2. Recorded a quick video showing what looked wrong
3. Contacted the actual site owner via their public contact email
4. Warned them that someone may be impersonating their organisation
5. Called and spoke to them about the issue

Whether the site had been compromised or the domain was being abused, one thing was clear:
No legitimate client will ever ask you to log in through a custom URL and send credentials back to them.

Key Lessons for Freelancers & Agencies

If you do web, SEO, or marketing work, watch out for these signs:

If you work with WordPress, SEO, web development, or digital marketing, this is the uncomfortable truth: you are a prime target for phishing scams. Not because you’re careless but because you’re trusted with access.

Here are the key takeaways from this experience:

1. Never Log In Before Scope, Contract, or Verification

Any request to access a website before a scope of work, agreement, or payment structure is clearly defined should be treated with caution. Legitimate clients don’t need admin access granted before basics are agreed.

2. Always Verify the WordPress Login URL

A real WordPress login will be accessible via /wp-admin or /wp-login.php on the same domain.
Custom login URLs, redirects, or “temporary” login pages should be independently verified especially if external scripts are involved.

3. Watch for External Script Loading

If a login page is pulling files, scripts, or assets from another domain, stop immediately. This is a common technique used in credential-harvesting attacks and should never be part of a standard WordPress setup.

4. Google Authorisation ≠ WordPress Access

Requests to complete Google authorisation flows, or OAuth steps, as part of WordPress access are highly unusual. These workflows are often abused in phishing attempts and should be validated outside of email instructions.

5. Never Send Credentials, Usernames, or Auth Tokens

No legitimate workflow requires you to log in and then send back usernames, passwords, or generated IDs. If you’re asked to do this, assume malicious intent.

6. Trust Discomfort, Not Familiarity

This scam didn’t rely on urgency or pressure; it relied on being familiar, polite, and believable. If something feels slightly “off,” pause and verify independently.

Scammers are getting better. They’re patient, polite, and informed.

Credential theft is one of the few routes into a site that no plugin can close for you. Two factor authentication and a proper access review will, and both are part of our WordPress security services.

Final Thoughts

This scam did not rely on fear or urgency.
It relied on familiarity.

That same reliance on trust is why industries like healthcare require a much higher bar for digital practices — from security and compliance to how SEO and advertising are handled. We’ve explored this balance in depth in our article on how healthcare marketing agencies use SEO & ads without compromising trust.

That is what made it dangerous.

If something feels slightly off, pause.
If access is requested in an unusual way, stop.
If credentials are ever involved, verify everything independently.

I was lucky. I spotted it just in time.

Hopefully, this helps someone else do the same.

Need Help With Malware or a Hacked Website?
If you’re worried your website may have been compromised, or you’ve spotted unusual login behaviour, redirects, or external scripts loading from unknown domains, it’s important to act quickly.

We regularly help businesses clean up hacked WordPress sites, remove malware, secure admin access, and prevent future attacks.

If you need help or just want a second opinion, get in touch here:

Even if you’re not sure something is wrong, it’s always better to check.

They Tried Again — This Time Using the PUMA Brand

A few weeks later, the same pattern appeared again.

This time, the enquiry came from someone claiming to represent an organisation linked to PUMA. The message read:

“One of our developers will be in touch soon… We are currently experiencing several technical issues and malfunctions on our website… Please reply to me for full details.”

It included:

• A US phone number
• A Gmail address
• A vague description of “technical issues”
• No real scope
• No specific URLs mentioned

On the surface, it looks like a standard website support enquiry. But the structure was almost identical to the previous attempt.

The brand had changed.
The script had not.

The same workflow pattern was emerging:

1. Open with a vague but believable website issue
2. Suggest urgency without being aggressive
3. Move the conversation toward login access
4. Funnel the target to a non-standard WordPress login page
5. Load external scripts from the same malicious hosting routine

The only real difference was the brand being used to create credibility.

This is an important reminder: scammers often reuse infrastructure. They rotate organisation names and email addresses, but keep the same phishing setup behind the scenes.

If you see:

• Generic Gmail addresses claiming to represent established brands
• Vague “technical issue” outreach with no detail
• Requests to log into unfamiliar admin URLs
• External assets loading from unrelated domains

Pause immediately.

The branding may change.
The malware routine often doesn’t.