The Plugins I Keep, and the One I Just Removed

There are four plugins on this blog, three of which arrived with the hosting rather than by choice. That is not a discipline I am proud of, it is just what a one-person site needs. The interesting one is the fourth, which I am taking off the site after finding out that it was not doing the job I installed it for.

So this is not a list of the best WordPress plugins. It is an inventory of what is running on the site you are reading, why each one is there, what is conspicuously missing, and the one removal that took me an afternoon of reading policy documents to be sure about.

The one I am removing: Complianz

Complianz is a well-regarded consent plugin and the free version is genuinely capable. I installed it to handle the cookie banner on a blog that intends to carry Google advertising. On 19 September 2026 I went to check that it was configured properly and found three separate problems, only one of which was my fault.

The first is structural. To serve personalised ads to visitors in the European Economic Area and the UK, Google requires a consent management platform that is certified by Google and integrated with the IAB Europe Transparency and Consent Framework; the same requirement extended to Switzerland from 31 July 2024, and from 1 March 2026 new TC strings have to be TCF v2.3 (Google’s consent management requirements). Complianz is certified, but its TCF support lives in the Premium version, from 59 euros a year, which the plugin’s own pricing FAQ states (Complianz pricing FAQ, checked 20 September 2026). I was running the free version. Its TCF setting was empty. So the banner I had been looking at for weeks was, for Google’s purposes, not a certified CMP at all.

The second is worse and entirely mine: the AdSense script was loading anyway, before any consent had been given, because I had never wired the plugin’s script blocker to it. A banner that does not gate anything is decoration.

The third is embarrassing in a smaller way. The plugin had generated two cookie policy pages, one in English and one in Spanish, on a site written entirely in English. Both were half-finished, with “Purpose pending investigation” and “not synced yet” still visible in the tables, and the contact block was showing a personal Gmail address rather than the address on the domain. Any human reviewer reading those two pages learns everything they need to know about how carefully the site is being run.

None of that is Complianz failing. It is me installing a plugin, seeing a banner appear, and assuming the job was done.

What goes in its place

Nothing, in plugin terms. AdSense includes its own European regulations message under Privacy and messaging: it is free, it is certified, and it already runs TCF v2.3. For a site whose only advertising relationship is with Google, adding a second consent layer on top of Google’s own would mean two banners and two records of consent, and the plugin’s script blocker can interfere with the CMP’s script anyway.

Two details I would not have guessed. The message has to be created with the “Do not consent” option switched on, otherwise the first screen only offers “Manage options” and “Consent”, and refusing is not as easy as accepting — which is exactly what European data protection authorities have been objecting to. And Google’s “maximise message coverage” setting is on by default and will show its own fallback message if it does not detect a TCF CMP, so if you want the message you designed rather than the one Google substitutes, that is a box to look at.

The two generated cookie pages become one, written by hand, in English, naming Google as the advertising vendor and explaining how to reopen the consent choice. That page is now shorter than what the plugin produced and considerably more honest.

The full plugin list

PluginHow it got hereStatus
Complianz (free, 7.5.2)I installed itBeing removed, see above
Hostinger ToolsCame with the hostingStaying
Hostinger AICame with the hostingStaying for now
Hostinger ReachCame with the hostingGoing: its newsletter form does not work
The plugin list as visible from the site’s public REST API, checked 19 September 2026.

The Hostinger plugins are the panel’s hooks into the site: cache controls, the AI assistant, the newsletter widget. They arrive with the plan, which I describe from the inside in my Hostinger review, and I have no strong feelings about the first two. The third had been rendering a subscribe form in the footer that silently goes nowhere, which I had never once tested, because nobody tests their own footer. That is the quiet lesson of this whole audit: every broken thing I found was something I had looked at a hundred times without seeing.

The plugin that is missing, and that is a fault

There is no caching plugin on this site. I assumed from the day the blog launched that there was, because the hosting runs LiteSpeed and LiteSpeed caching is one of the things you buy shared hosting for.

On 20 September 2026 I checked the response headers properly: no x-litespeed-cache header on either of my two WordPress blogs, on any request, and a cache-busting query string that made nothing slower. Every visit goes through PHP 8.3.33.

LiteSpeed Cache is the plugin that should be there, it is free where the server supports it, and it is the next thing I am installing. I am measuring before and after rather than assuming, and that experiment is written up in I thought my blog was cached, it was not.

Two things I will not claim from this. It does not mean Hostinger does not cache — it means no caching plugin is active on my installation, which is my doing. And it is a measurement of one page on one day, not a verdict on the host.

No SEO plugin. A must-use plugin instead.

There is no Yoast and no Rank Math here, which meant the site shipped with no meta descriptions, no Open Graph tags and no structured data at all. Not a lean setup: an incomplete one.

Rather than add a plugin with sixty features to use four of them, I wrote the four, with an AI assistant doing most of the typing and me reading every line: a meta description drawn from the excerpt, Open Graph tags, an article schema block with a real author, and a related-posts shortcode. It is one file of PHP, it is readable in a sitting, and I know exactly what it does. If this site grows into needing redirect management and internal link reporting, I will install a proper SEO plugin and say so here, because that is a real reason and “plugins are bloat” is not.

Where that file lives matters more than what is in it. The obvious home is the theme’s functions.php, and that is wrong here, for a reason I learned the hard way: my theme is a parent theme, and a theme update overwrites functions.php. The AdSense snippet on this site went into exactly that file, one update away from vanishing without a single error message. Anything of mine, that snippet included, is moving to wp-content/mu-plugins/, where updates cannot reach it and where it cannot be deactivated by a mis-click.

The theme, which I did not really choose

The theme came out of Hostinger’s AI site-building flow, which is how a lot of one-click WordPress installs start now. It is a block theme, it is fast enough, and editing it means the site editor rather than a stack of customiser panels.

What I would tell anyone accepting a generated theme: find out on day one whether it is a parent theme, and if it is, never put your own code in it. That single question would have saved me the AdSense problem above.

And the honest limit on this section: I have not built sites on Astra, Kadence or GeneratePress, which are the three themes every list of this kind recommends. They may well be better. I have no basis for telling you so, and a theme roundup written by someone who has used one theme is exactly the kind of article this blog is trying to stop publishing.

The editor, and the week block markup saved me

I write in the block editor, and the reason I am glad about that is not the writing experience. It is that block content is stored as plain HTML with comment delimiters around it, so it can be read, rewritten and put back programmatically.

When I audited all ninety posts on this site, I pulled every one of them out through the WordPress REST API and worked on them offline, and the rewrites go back the same way. Ninety posts, no clicking. If the content had been stored as a page builder’s serialised data, that job would have been a manual afternoon per post, and I would simply not have done it.

I have never used Elementor, so I am not going to review it. What I will say is what I would check before committing to any page builder: open a post through /wp-json/wp/v2/posts/ and look at what comes back. If it is readable HTML, you can leave whenever you like. If it is a blob of the builder’s own format, you have chosen your editor for the lifetime of the site, and that is a bigger decision than the drag-and-drop demo suggests.

What a plugin has to answer before it goes on

  • What exactly does this do that I cannot do in twenty lines of my own code?
  • Is the feature I am installing it for in the free version, or only in the paid one? That is the Complianz lesson, and it took me weeks to notice.
  • How will I verify it is working from outside the site, with curl or a browser in a private window, rather than by looking at its settings screen?
  • If I delete it in a year, what does it leave behind — pages, database tables, shortcodes in old posts?

The third question is the one that changed how I work. A settings page telling you a feature is enabled is a claim by the plugin about itself. Backups, security headers and consent are all things I now check from the outside, and the two I check most often are covered in hardening WordPress after finding my own site wide open and my backup routine, written down after nearly needing it.

Plugin weight, which I have not measured

I have not measured the load cost of individual plugins on this site, so I have no numbers on which of them is heaviest, and I am not going to repeat the usual claim that plugin count is what slows a site down. My install is small because my site is small, not because I have discovered anything.

What this inventory is good for is the habit behind it: once you check what each plugin is actually doing from outside the dashboard, roughly half of them turn out to be doing something other than what you assumed. On this site it was three out of four. The full build, with what it costs, is in how this blog is set up.