Why abandoned WordPress sites get taken over — and how it happens

Here is a line from a real website's logs. Not a big site — an ordinary business site in Nigeria, live a few weeks:

GET /wp-admin/install.php    404

Somebody asked that site for its WordPress installer. The site does not run WordPress, so it answered "not found", and nothing happened.

Two things are worth understanding about that single line, because together they explain almost everything in this module.

First: nobody chose this business. No person sat down and decided to attack a tailor in Surulere. A program is working through every address it can find, asking every one of them the same question. It costs almost nothing to ask, so it asks everybody, forever.

Second: look at what it asked for. Not the login page. The installer — the page that runs when WordPress has been uploaded but setup was never finished. That page, on an unfinished install, is not protected by anything, because there is no site yet to protect it. Whoever reaches it first can point that WordPress at their own database and own it completely, in about thirty seconds, without a password.

It is hunting for abandoned work. This lesson is about why that works, and why a site nobody is looking after is the one that gets taken.

Words in this lesson

Nobody is targeting your client

This is the part clients find hardest to believe, and the part that changes how they think about maintenance.

Small business owners assume they are too small to be worth attacking. They are right that nobody has chosen them, and wrong about what follows from it. Attacks are not chosen. They are swept. A program scans enormous ranges of addresses, tries a short list of known weaknesses on each, and keeps whatever opens.

Being small does not protect you. It only means nobody will notice for a long time.

That reframing is what makes a client understand maintenance. The question is not "why would anybody attack me?" It is "what happens when the sweep reaches me, and is my site one of the ones that opens?"

What they actually want

Rarely the client's data. A tailor's customer list is of little interest.

What they want is the server, because a working website with a real domain is a useful thing to own:

Read the right-hand column again. The worst outcomes are the ones the business cannot see. A defaced home page is obvious and gets fixed the same day. Hidden scam pages under their domain can run for a year, and the first the owner knows is when their email stops being delivered or the host suspends them.

The three ways in

Nearly every compromise of a small WordPress site is one of these.

1. Software nobody updated

A flaw is found in a plugin or theme, the developer fixes it, and the fix is published. The publication is the problem: it tells everybody exactly what the flaw was, so within hours bots are sweeping for sites that have not applied it.

An updated site is fine. An unmaintained site has a public, documented, machine-readable list of ways in. That is why "we'll update it when something breaks" is such a poor policy — the window opens the moment the fix is announced.

2. Guessable credentials

Bots try common usernames against common passwords, endlessly. This is why Module 2 insisted the username must never be admin — using it hands over half the problem already solved.

There is no cleverness here. It is a program trying thousands of combinations because trying costs nothing.

3. Abandoned plugins

A plugin whose developer has stopped working on it never gets fixed. It sits there, doing its job, with an unpatched flaw in it — and it looks completely normal in the dashboard.

This is why Module 4 kept saying a plugin is a stranger's code running on your client's site. A plugin installed in 2023 "to try it" and never removed is a door nobody is watching.

Why it stays silent

A defaced site is the rare case. Most compromises are quiet on purpose, because a quiet site keeps working and keeps being useful to whoever took it.

So the site looks fine. The client notices nothing. Months pass. And then one of these happens:

• Their email starts bouncing, because the domain is on a blocklist
• Google shows a warning beside the site in search results
• The host suspends the account with little notice
• A customer says the site "went somewhere strange" on their phone

By then it has usually been going on for a long time, and the clean-up is far more work than the prevention would have been.

This is the same silent-failure problem as the contact form in Module 5. Working and broken look identical from the outside, so neither can be managed by waiting for a complaint. Both have to be checked on a schedule — which is Lesson 5, and it is what you charge for.

What this module actually does

The four things that close nearly all of it:

None of it is exotic. The reason sites get taken is almost never a clever attack — it is that nobody was doing the ordinary things.

Common mistakes

The short version

• Nobody chose your client. Bots sweep every address they can find, constantly, because asking costs nothing.
• Being small does not protect a site. It means nobody notices for longer.
• They want the server, not usually the data — for spam, scam pages, redirects and hidden links.
• The worst outcomes are invisible to the business until email stops arriving or the host suspends them.
• Three ways in: unupdated software, guessable credentials, abandoned plugins.
• A published fix tells everybody what the flaw was, so waiting is the dangerous choice.
• Most compromises are deliberately quiet. Working and broken look the same, exactly like the contact form.
• Sites are taken because nobody was doing the ordinary things, not because of clever attacks.

Try it yourself

Part one — see the sweep. If you have access to any live site's logs — your practice site once it is on hosting, or a site you help with — look for requests to paths that do not exist: /wp-admin/install.php, /wp-login.php, /.env, /wp-content/plugins/….

You will find them. Write down three of them and what each one was hunting for. If you have no live site yet, look at what your host's dashboard reports about blocked or failed requests.

This is the most convincing thing in this module, because it stops being theory the moment you see your own domain being swept.

Part two — the plugin audit. On your practice site, list every installed plugin. For each one, find:

• When it was last updated
• Whether you installed it deliberately, or it came with the theme or host
• Whether the site would break if it were removed

Anything you cannot justify, remove. Then write one sentence explaining, in a client's words, why an unused plugin is not harmless.

Part three — the sentence for the client. Write what you would say to a business owner who says "nobody would bother attacking my small business."

Do not use the words "hacker" or "security". Use the sweep, and use what they would actually experience — the email that stops arriving, the host suspending the account. Make it about what happens to them, not about computers.

You'll know you've got it when a client says they are too small to be a target and you can explain, in thirty seconds and without jargon, why that is the wrong question.