WordPress and plugins

WordPress is a content management system, software that runs on a server, stores your pages in a database, and assembles them into a site every time someone visits. Most WordPress sites are not run as bare WordPress. They are run with a stack of plugins on top, small pieces of add-on software that handle everything from contact forms to SEO settings to security itself.

That plugin model is WordPress’s biggest strength and its biggest liability at the same time. It is why WordPress can do almost anything: there is a plugin for nearly every feature a business could want. It is also why WordPress sites are, in practice, the most commonly compromised category of website on the internet. Each plugin is a separate piece of code, written by a separate developer, updated on a separate schedule, and each one is a door into your site that you did not build and often cannot fully check.

One of the clients I work with had exactly this happen. Their rubbish removal site was compromised through a WordPress plugin earlier this year, not through some sophisticated attack, just an add-on with a hole in it that someone found before anyone patched it.

Why it matters to you

A compromised site is not an abstract IT problem. It can serve malware to your own visitors, get blacklisted by Google, or quietly redirect your traffic somewhere else while you have no idea it is happening. Recovering from that costs real time and, sometimes, real reputation with customers who searched for you and landed somewhere wrong.

The plugin risk compounds over time too. A site that has been live for years tends to accumulate plugins the way a garage accumulates tools nobody remembers buying. Each one is still running, still a target, whether or not anyone still uses what it does.

How I set it up

For a client coming off a WordPress site that has had a security incident, or one that simply wants to stop carrying that risk, I rebuild on Astro instead. There is no database behind the page, no admin login for an attacker to guess, and no plugin marketplace sitting on the live site. Whatever the plugins used to do gets rebuilt as code that I control end to end, or handed off to a dedicated, purpose-built service.

Where a client’s site works fine on WordPress and there is no urgent reason to move, I do not force a migration for its own sake. The point is matching the platform to the actual risk, not chasing a trend.

What it looks like in practice

Before: a login page an attacker can hammer, a database that holds every page, and a list of plugins that grows every time someone wants a new feature, each one a fresh piece of attack surface.

After: a site with nothing to break into, because there is no admin panel, no plugin list and no database sitting behind the page waiting for the next vulnerability to surface. The features are still there. They are just built in rather than bolted on.