Website Security: How Sites Actually Get Hacked

"Why would anyone bother hacking me?"

The answer dismantles the assumption inside the question: whoever compromised your site did not choose it. Automated scripts run continuously across the internet, and their job is not to study individual sites. It is to try one known vulnerability against every server that exposes it. Being small does not make you invisible. It only makes the attack impersonal.

This guide covers how sites are actually compromised, why the cost lands on the commercial side rather than the technical one, and which precautions genuinely work.

Key Takeaways

• Most attacks are untargeted. They follow automated scanning for known vulnerabilities.
• The entry point is usually not core software but un-updated plugins and themes. WordPress runs on 40.2% of all websites (W3Techs, 29 September 2026).
• An outdated PHP version is a security line item: security support for PHP 8.2 ends on 31 December 2026 (php.net).
• SSL is encryption, not security. Let's Encrypt issues certificates at zero cost (Let's Encrypt).
• The real cost is traffic: Google states that Chrome may warn visitors away from a flagged site (Google).

Sites are not chosen, they are found

It is tempting to picture a person at a keyboard studying your site. What actually happens is far more boring and far more common: a script sweeps IP ranges looking for one specific version of one specific plugin. At every address it finds, it tries the same two lines. If they work it is inside; if not it moves on.

This is why "there is nothing worth stealing on my site" is not a defence. A compromised site is usually wanted for its infrastructure, not its data: somewhere to host spam pages, to serve a phishing form, to relay other attacks, or to add hidden links to pages search engines already trust.

That last one is the quiet variant. The site keeps working, you notice nothing, and the pages Google sees carry links you never put there.

The door usually opens through a plugin

WordPress runs on 40.2% of all websites and holds 58.7% of the market among sites whose CMS is known (W3Techs, 29 September 2026). That scale is not a vulnerability in itself — but it does make a target list for automated scanners.

The distinction that matters: the problem is rarely in the core software. Core is updated regularly and reviewed by a large group. Around it sits an average of fifteen to twenty plugins, some abandoned years ago, some silently stopped receiving updates when a licence lapsed.

A plugin that no longer receives updates is not a free plugin. It is a deferred problem.

The practical consequence: every installed plugin is a maintenance obligation. The one installed years ago "just in case" and then forgotten returns more risk than it ever added in function.

An outdated PHP version is a security line item

This is among the most concrete costs and among the least discussed at proposal stage.

Each PHP release branch receives two years of active support — bugs and security issues fixed in regular releases — followed by two more years in which only critical security issues are fixed. Security support for PHP 8.2 ends on 31 December 2026 (php.net).

WordPress points the same way in its own requirements: PHP 8.3 or greater is recommended, and the page notes that older versions, while they will still function, have reached end of life and "may expose your site to security vulnerabilities" (WordPress.org).

The trap is that nothing visibly breaks. A site running on an unsupported PHP version loads fine, forms submit, nobody notices. The only thing that changed is that newly discovered vulnerabilities are no longer being patched on it. Those dates are also the clearest answer to what belongs in a maintenance scope.

SSL is not security

A common misunderstanding, worth correcting plainly.

An SSL/TLS certificate encrypts traffic between the visitor's browser and the server. That is the whole of its job. It has no bearing on whether the software on that server is current, whether a plugin carries a vulnerability, or what the administrator password is.

Certificates are no longer an investment either: Let's Encrypt states that "anyone who owns a domain name" can obtain "a trusted certificate at zero cost" (Let's Encrypt). Something free and universal cannot be the measure that separates you from anyone.

The padlock in the address bar does not say the site is safe. It says the connection is encrypted. Most phishing pages use HTTPS too.

The real cost is commercial, not technical

The first thing most companies think about after a compromise is the database. The larger loss is elsewhere.

Google states that when social engineering content is detected, "the Chrome browser may display a 'Deceptive site ahead' warning when visitors view your site" (Google Search Central). The same documentation notes that Google Safe Browsing warns users before they visit such pages.

Which means: whatever your position in search results, visitors meet a red interstitial and turn back. The organic traffic you spent months earning becomes unusable overnight.

Recovery is not instant either. You close the vulnerability, clean the content, then request a review from Google — and review takes days. Throughout that window the site is technically up and commercially closed.

What actually works

The list is short and dull. That is why it works.

Make updating a calendar task. One fixed day a month: core, plugins, theme and PHP version checked. Updates postponed so that "nothing breaks" become riskier the longer they accumulate.

Delete everything you do not use. A deactivated plugin still sitting on the server is still attack surface. Deactivating is not enough; remove it.

Keep backups somewhere other than the site. A backup stored on the same server disappears with the server. Test a restore at least once a year — an untested backup is not a backup.

Narrow administrative access. Not everyone needs an admin role, closed accounts should actually be closed, and two-factor authentication should be on. A share of compromises arrive not through a vulnerability but through an old account nobody disabled.

Separate server responsibility from application responsibility. Your host covers the operating system and network; the CMS version, plugins and passwords are yours. Ask in writing what a package advertised as "security included" actually covers — it is the same discipline as reading any scope written in adjectives.

In short

Sites are not selected, they are scanned. The door usually opens through an un-updated plugin or a PHP version past its support window, not through core software. SSL plays no part in that picture; it is encryption, not protection.

And the cost is not where you expect it. Less in your database than in the warning a browser shows your visitors, and in the days it takes to clear it.

Do you know which PHP version your site runs on, and how many plugins have gone a year without an update? If not, the security question has already started. Tell us who keeps your site running and we will look at it with you.