Three plugins hold up a professional WordPress site: Yoast SEO (SEO layer), Redis Object Cache (server-side performance) and Advanced Custom Fields Pro (structured content). One per critical layer. The rest is optional.
Our fixed trio: Yoast SEO for SEO, Redis Object Cache for server-side performance and ACF Pro for structured content. One plugin per critical layer — the rest is bloat until proven otherwise.
Every “essential plugins” list you have ever read had 20, 25, 31 items. Ours has three. Not because there is nothing to install, but because every extra plugin is weight: more code to load, more database queries, one more thing that can break on an update. This guide shows the stack a software house actually keeps in production — with the real config for each — and why the count stops at three.
Why 3, not 30
Plugin bloat is one of the top causes of a slow or broken site. It is not an opinion: every active plugin adds PHP to parse, hooks to fire and, almost always, database queries on every load. Twenty poorly chosen plugins take a site down faster than a traffic spike — and the pattern of the most common WordPress errors almost always starts with a conflicting plugin.
The rule we follow is simple: one plugin per critical layer, and only when the layer actually exists.
- SEO is a critical layer on almost every site → Yoast comes in.
- Database performance is critical on dynamic sites → Redis Object Cache comes in.
- Structured content is critical on any site that is not a brochure → ACF Pro comes in.
What is not a critical layer — or what is better solved outside WordPress — does not become a fixed plugin. That is the difference between our list of three and the generic 20-to-31-item lists that optimize for a number, not for a healthy site.
Yoast SEO — the SEO layer
When it comes in
Yoast comes into practically every project that needs to be found on Google. It handles the basics well: title and meta description per page, indexing control (noindex/nofollow), XML sitemap generation, canonical, breadcrumbs and the schema (structured data) that helps the site show up better in results. The readability and keyword-focus analysis is useful as an editorial checklist — not as dogma.
The point: we don’t install Yoast for the little green lights. We install it because it centrally controls the site’s technical SEO output. That is infrastructure, not decoration.
Real config
Half of Yoast’s value is in turning off what gets in the way and locking sensible defaults. We do that in code, in a mu-plugin (must-use, always loaded and out of the client’s reach), instead of relying on clicks in the panel:
<?php
/**
* Plugin Name: Pixelize — Yoast Defaults
* Description: Defaults de SEO travados por código, não por clique.
*/
// Remove o comentário "generated by Yoast" no HTML — ruído inútil.
add_filter( 'wpseo_debug_markers', '__return_false' );
// noindex em arquivos de autor num site de autor único (conteúdo duplicado).
add_filter( 'wpseo_should_index_links', '__return_true' );
// Remove taxonomias sem valor de busca do sitemap (ex.: post_format).
add_filter( 'wpseo_sitemap_exclude_taxonomy', function ( $excluded, $taxonomy ) {
return in_array( $taxonomy, array( 'post_format' ), true ) ? true : $excluded;
}, 10, 2 );
// Ajusta o título de forma programática quando necessário.
add_filter( 'wpseo_title', function ( $title ) {
return $title; // ponto de extensão previsível — o motivo de escolhermos Yoast.
} );The detail that matters: Yoast’s filter API is predictable and stable across versions. A mu-plugin like this keeps working after years of updates — and that is exactly what an agency needs to maintain dozens of sites without rework.
An honest aside: Yoast vs Rank Math
We are not fanatics. Rank Math is a great SEO plugin — it has a more generous free tier (features Yoast only ships in premium), is slightly lighter and brings a modern interface. If you are starting a site from scratch and want the most for free, it is a defensible choice.
Still, the house standardizes on Yoast for three practical reasons:
- Stability. Years in the market, a conservative release cycle, fewer surprises on update — which matters when you maintain many sites.
- Predictable API. The filters and hooks are documented and change little. Our customizations survive the updates.
- Readability and consistency. The editorial flow is the same across every project, which lowers the cost of training team and client.
It is posture, not religion. A client already running Rank Math well configured is not migrated just to migrate — the migration would cost something and the gain would be zero. One SEO plugin per site; never both.
Redis Object Cache — server-side performance
Object cache ≠ page cache
Here lives the most common confusion. They are different things:
Page cache stores the already-rendered HTML of a page and serves that static file to anonymous visitors. Fast, but it only works when the page is identical for everyone.
Object cache stores database query results in memory (the output of
WP_Object_Cache). It speeds up dynamic pages — the ones page cache cannot serve as static.
Without a persistent object cache, WordPress rebuilds the same database queries on every request. With a persistent object cache (Redis or Memcached), the result stays in memory and is reused between visits. It is not the same as page cache — it is the layer below, the database.
When it really helps
Redis Object Cache shines exactly where page cache is useless: pages that are dynamic by nature.
- WooCommerce: cart, checkout, “my account”, product pages with dynamic stock and price. None of it can be served static — object cache drastically cuts the load on the database.
- Logged-in users: any site with a member area, dashboard or personalized content. Every logged-in visit hits the database; object cache absorbs the repetition.
- wp-admin: the admin panel itself gets faster, which the client’s team feels every day.
Where it is marginal: a simple brochure blog, almost all anonymous traffic, already served by a good page cache. There the gain exists, but it is small — page cache already handles most of it. It is worth measuring the hit rate before claiming it solved anything.
Real config
First, the non-negotiable prerequisite: Redis must be installed and running on the server. The plugin is just the bridge between WordPress and Redis. Without the service, there is no gain at all.
With Redis on the server and the plugin installed, point the connection in wp-config.php:
// wp-config.php — antes de "That's all, stop editing!"
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
// Isola o cache deste site — evita colisão de chaves em servidor compartilhado.
define( 'WP_CACHE_KEY_SALT', 'pixelize_cliente_prod:' );Then enable the object cache drop-in. With WP-CLI it is one line:
# Verifica se o Redis responde e ativa o object cache persistente
wp redis status
wp redis enable
# Confirma o hit rate depois de algum tráfego real
wp redis statuswp redis enable creates object-cache.php in wp-content/, the drop-in that wires WP_Object_Cache to Redis. From there, measure: a high hit rate confirms the cache is catching. If it is low, either the site is too anonymous (page cache would already be enough) or something is clearing the cache too early.
Advanced Custom Fields Pro — structured content
Usage
ACF Pro solves the most common problem on any content site: data that does not fit the default editor. Price, map coordinates, a gallery, product specs, the fields of a real-estate listing, the data of a spec sheet. Instead of forcing everything into a free-text field — fragile and impossible to maintain — ACF creates structured, named fields, comfortable to edit and rendered with full control in the theme.
It is the difference between organized content (which you can query, filter and reuse) and a block of text no one can evolve.
ACF Blocks — a native Gutenberg block in PHP
Here ACF connects to our stack stance. We are a Gutenberg, not Elementor team: WordPress’s native editor produces clean HTML, does not tie the client to a proprietary builder and does not weigh the page down with unnecessary layers of CSS/JS.
The detail that makes the difference: ACF Blocks let you build native Gutenberg blocks by writing PHP, without touching React. For an agency with a strong PHP base, that means shipping real custom blocks — which show up in the native editor, with a real preview — in a fraction of the time of a traditional React block.
Real config
A modern ACF Block is registered via block.json with a PHP render callback:
// functions.php ou um mu-plugin do tema
add_action( 'init', function () {
// Registra o bloco a partir do block.json na pasta do tema.
register_block_type( get_stylesheet_directory() . '/blocks/destaque' );
} );// blocks/destaque/block.json
{
"apiVersion": 3,
"name": "pixelize/destaque",
"title": "Destaque",
"category": "design",
"icon": "star-filled",
"acf": {
"mode": "preview",
"renderTemplate": "render.php"
},
"supports": { "align": true, "mode": false }
}// blocks/destaque/render.php — renderização 100% em PHP, sem React.
<div class="bloco-destaque">
<h2><?php echo esc_html( get_field( 'titulo' ) ); ?></h2>
<p><?php echo esc_html( get_field( 'texto' ) ); ?></p>
</div>A native Gutenberg block, editable in the default editor, rendered with PHP that any dev on the team understands and maintains. No React build chain, no proprietary builder.
A client asset, not lock-in
The legitimate fear with any content tool is entrapment. With ACF, the answer is honest: the fields and content live in the client’s own database. The data is their asset — it stays accessible in the WordPress tables, exportable, migratable.
You do depend on the plugin to edit and render the fields comfortably, true. But that is very different from the visual lock-in of a page builder, where the content is embedded in proprietary shortcodes and markup that turn to garbage the day the builder leaves. With ACF, the worst case is rewriting the display layer — the content itself was never trapped.
The runner-up and the ones left out
WP Rocket — conditional, not fixed
WP Rocket is the best page cache plugin on the market and our runner-up. It does not make the fixed trio because the page cache layer is often already solved on the server. The clearest case: on LiteSpeed hosting, LiteSpeed Cache is free and integrated into the web server — installing WP Rocket on top would be paying for something the infrastructure already delivers.
The rule: if the server does not offer native page cache, WP Rocket comes in as a fourth plugin. If it does (LiteSpeed, or page cache at the host level), WP Rocket is not needed. A layer solved outside WordPress is a layer that does not become a plugin.
Why Wordfence, UpdraftPlus and Query Monitor don’t make it
Three usual suspects on every generic list that, deliberately, stay out of our trio:
- Wordfence (security): real security is better solved at the host and infrastructure layer — server firewall, WAF, managed updates, correct file permissions. A firewall plugin runs inside PHP, after the request has already arrived; the strongest protection is before that. Useful in some contexts, indispensable as a fixed plugin it is not.
- UpdraftPlus (backup): backup is indispensable as a function, not as a plugin. Server-level snapshots and host-managed backups are more reliable and don’t weigh on the site’s PHP. We prefer to solve backup outside WordPress whenever the hosting allows.
- Query Monitor (debug): it is an excellent tool — for development and staging. In production it should not stay active: it adds overhead and exposes internal details. Active when we need to investigate, off right after. A dev tool is not a production plugin.
Notice the common thread: none of these is useless. They simply solve layers that either live better outside WordPress (security, backup) or do not belong in production (debug). That is why the fixed trio is fixed — and the rest is situational.
How many plugins to install, after all
There is no magic number. What decides is not the quantity, it is the quality and the real need for each plugin. As a practical reference: small sites usually run fine with around 5 to 10 plugins, and ~20 is a practical ceiling before the site becomes a maintenance problem. Every installed plugin is a performance cost added to a maintenance and security surface — install on proven need, never out of habit.
Our trio — Yoast, Redis Object Cache, ACF Pro — is the base because each one solves a critical, irreplaceable layer. From there, every addition must justify itself: which layer does it solve, and why can’t it be solved outside WordPress?
A slow or broken site is almost never a lack of plugins. It is an excess — and the pattern of WordPress errors confirms it every day. Fewer plugins, better chosen, is the cheapest performance decision there is. And keeping that lean over time is part of what we do in WordPress maintenance — just as in every WordPress development project we ship.
Three plugins. The rest is bloat until proven otherwise.