Tres plugins sostienen un sitio WordPress profesional: Yoast SEO (capa de SEO), Redis Object Cache (rendimiento de servidor) y Advanced Custom Fields Pro (contenido estructurado). Uno por capa crítica. El resto es opcional.
Nuestro trío fijo: Yoast SEO para SEO, Redis Object Cache para rendimiento de servidor y ACF Pro para contenido estructurado. Un plugin por capa crítica — el resto es bloat hasta que se demuestre lo contrario.
Toda lista de “plugins indispensables” que has leído tenía 20, 25, 31 ítems. La nuestra tiene tres. No porque falte qué instalar, sino porque cada plugin extra es peso: más código que cargar, más consultas a la base de datos, una cosa más que puede romperse en una actualización. Esta guía muestra el stack que una software house mantiene de verdad en producción — con la config real de cada uno — y por qué la cuenta se detiene en tres.
Por qué 3, y no 30
El exceso de plugins es una de las principales causas de un sitio lento o roto. No es opinión: cada plugin activo añade PHP que interpretar, hooks que disparar y, casi siempre, consultas a la base de datos en cada carga. Veinte plugins mal elegidos tumban un sitio más rápido que un pico de tráfico — y el patrón de los errores más comunes de WordPress casi siempre empieza con un plugin en conflicto.
La regla que seguimos es simple: un plugin por capa crítica, y solo cuando la capa existe de verdad.
- El SEO es una capa crítica en casi todo sitio → entra Yoast.
- El rendimiento de base de datos es crítico en sitios dinámicos → entra Redis Object Cache.
- El contenido estructurado es crítico en cualquier sitio que no sea un folleto → entra ACF Pro.
Lo que no es una capa crítica — o lo que se resuelve mejor fuera de WordPress — no se convierte en plugin fijo. Esa es la diferencia entre nuestra lista de tres y las listas genéricas de 20 a 31 ítems que optimizan por número, no por un sitio sano.
Yoast SEO — la capa de SEO
Cuándo entra
Yoast entra en prácticamente todo proyecto que necesita ser encontrado en Google. Resuelve lo básico bien hecho: título y meta description por página, control de indexación (noindex/nofollow), generación de sitemap XML, canonical, breadcrumbs y el schema (datos estructurados) que ayuda al sitio a aparecer mejor en los resultados. El análisis de legibilidad y de foco de palabra clave es útil como checklist editorial — no como dogma.
El punto: no instalamos Yoast por las lucecitas verdes. Lo instalamos porque controla, de forma centralizada, la salida de SEO técnico del sitio. Eso es infraestructura, no adorno.
Config real
La mitad del valor de Yoast está en apagar lo que estorba y fijar defaults sensatos. Lo hacemos por código, en un mu-plugin (must-use, cargado siempre y fuera del alcance del cliente), en vez de depender de clics en el 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.
} );El detalle que importa: la API de filtros de Yoast es previsible y estable entre versiones. Un mu-plugin así sigue funcionando tras años de updates — y eso es exactamente lo que una agencia necesita para mantener decenas de sitios sin retrabajo.
Un aparte honesto: Yoast vs Rank Math
No somos fanáticos. Rank Math es un gran plugin de SEO — tiene un plan gratuito más generoso (funciones que Yoast solo entrega en premium), es ligeramente más ligero y trae una interfaz moderna. Si estás empezando un sitio desde cero y quieres lo máximo gratis, es una elección defendible.
Aun así, la casa estandariza en Yoast por tres motivos prácticos:
- Estabilidad. Años en el mercado, ciclo de release conservador, menos sorpresas en la actualización — lo que importa cuando mantienes muchos sitios.
- API previsible. Los filtros y hooks están documentados y cambian poco. Nuestras personalizaciones sobreviven a los updates.
- Legibilidad y consistencia. El flujo editorial es el mismo en todos los proyectos, lo que reduce el coste de formar al equipo y al cliente.
Es postura, no religión. A un cliente que ya corre Rank Math bien configurado no lo migramos por migrar — la migración tendría coste y la ganancia sería cero. Un plugin de SEO por sitio; nunca los dos.
Redis Object Cache — rendimiento de servidor
Object cache ≠ page cache
Aquí vive la confusión más común. Son cosas distintas:
El page cache guarda el HTML ya renderizado de una página y sirve ese archivo estático a los visitantes anónimos. Rápido, pero solo funciona cuando la página es igual para todos.
El object cache guarda en memoria el resultado de las consultas a la base de datos (la salida de
WP_Object_Cache). Acelera páginas dinámicas — las que el page cache no puede servir estáticas.
Sin un object cache persistente, WordPress reconstruye las mismas consultas a la base de datos en cada petición. Con un object cache persistente (Redis o Memcached), el resultado queda en memoria y se reutiliza entre visitas. No es lo mismo que el page cache — es la capa de abajo, la base de datos.
Cuándo ayuda de verdad
Redis Object Cache brilla exactamente donde el page cache es inútil: páginas dinámicas por naturaleza.
- WooCommerce: carrito, checkout, “mi cuenta”, páginas de producto con stock y precio dinámicos. Nada de eso puede servirse estático — el object cache reduce drásticamente la carga en la base de datos.
- Usuarios logados: cualquier sitio con área de miembro, panel o contenido personalizado. Cada visita logada golpea la base de datos; el object cache absorbe lo repetido.
- wp-admin: el propio panel administrativo se vuelve más rápido, algo que el equipo del cliente siente cada día.
Dónde es marginal: un blog institucional simple, casi todo el tráfico anónimo, ya servido por un buen page cache. Ahí la ganancia existe, pero es pequeña — el page cache ya resuelve la mayor parte. Vale la pena medir el hit rate antes de decir que resolvió algo.
Config real
Primero, el prerrequisito no negociable: Redis tiene que estar instalado y en ejecución en el servidor. El plugin es solo el puente entre WordPress y Redis. Sin el servicio, no hay ganancia alguna.
Con Redis en el servidor y el plugin instalado, apunta la conexión en 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:' );Después, activa el drop-in de object cache. Con WP-CLI es una línea:
# 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 crea el object-cache.php en wp-content/, el drop-in que conecta WP_Object_Cache con Redis. A partir de ahí, mide: un hit rate alto confirma que la caché está atrapando. Si es bajo, o el sitio es demasiado anónimo (el page cache ya bastaría) o algo está limpiando la caché demasiado pronto.
Advanced Custom Fields Pro — contenido estructurado
Uso
ACF Pro resuelve el problema más común de todo sitio de contenido: datos que no caben en el editor estándar. Precio, coordenadas de mapa, galería, especificaciones de producto, campos de un inmueble, datos de una ficha técnica. En vez de forzar todo en un campo de texto libre — frágil e imposible de mantener —, ACF crea campos estructurados y nombrados, cómodos de editar y renderizados con control total en el tema.
Es la diferencia entre contenido organizado (que consultas, filtras y reutilizas) y un bloque de texto que nadie consigue evolucionar.
ACF Blocks — bloque Gutenberg nativo en PHP
Aquí ACF se conecta con nuestra postura de stack. Somos equipo de Gutenberg, no de Elementor: el editor nativo de WordPress genera HTML limpio, no ata al cliente a un maquetador propietario y no carga la página con capas de CSS/JS innecesarias.
El detalle que marca la diferencia: los ACF Blocks permiten crear bloques Gutenberg nativos escribiendo PHP, sin tocar React. Para una agencia con una base fuerte en PHP, eso significa entregar bloques personalizados de verdad — que aparecen en el editor nativo, con preview real — en una fracción del tiempo de un bloque React tradicional.
Config real
Un ACF Block moderno se registra vía block.json con callback de render en PHP:
// 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>Bloque nativo de Gutenberg, editable en el editor estándar, renderizado con PHP que cualquier dev del equipo entiende y mantiene. Sin cadena de build de React, sin maquetador propietario.
Activo del cliente, no lock-in
El miedo legítimo con cualquier herramienta de contenido es el aprisionamiento. Con ACF, la respuesta es honesta: los campos y el contenido viven en la base de datos del propio cliente. Los datos son un activo suyo — siguen accesibles en las tablas de WordPress, exportables, migrables.
Dependes del plugin para editar y renderizar los campos con comodidad, es cierto. Pero eso es muy distinto del lock-in visual de un maquetador, donde el contenido queda incrustado en shortcodes y markup propietarios que se vuelven basura el día que el maquetador se va. Con ACF, el peor escenario es reescribir la capa de visualización — el contenido en sí nunca estuvo atrapado.
El runner-up y los que quedaron fuera
WP Rocket — condicional, no fijo
WP Rocket es el mejor plugin de page cache del mercado y nuestro runner-up. No entra en el trío fijo porque la capa de page cache muchas veces ya está resuelta en el servidor. El caso más claro: en hosting LiteSpeed, LiteSpeed Cache es gratuito e integrado al servidor web — instalar WP Rocket encima sería pagar por algo que la infraestructura ya entrega.
La regla: si el servidor no ofrece page cache nativo, WP Rocket entra como cuarto plugin. Si lo ofrece (LiteSpeed, o caché de página a nivel del host), WP Rocket no es necesario. Una capa resuelta fuera de WordPress es una capa que no se convierte en plugin.
Por qué Wordfence, UpdraftPlus y Query Monitor no entran
Tres sospechosos habituales de toda lista genérica que, deliberadamente, quedan fuera de nuestro trío:
- Wordfence (seguridad): la seguridad de verdad se resuelve mejor en la capa de host e infraestructura — firewall en el servidor, WAF, actualizaciones gestionadas, permisos de archivo correctos. Un plugin de firewall corre dentro de PHP, después de que la petición ya llegó; la protección más fuerte está antes de eso. Útil en algunos contextos, indispensable como plugin fijo no lo es.
- UpdraftPlus (backup): el backup es indispensable como función, no como plugin. Los snapshots a nivel de servidor y los backups gestionados por el host son más fiables y no pesan en el PHP del sitio. Preferimos resolver el backup fuera de WordPress siempre que el hosting lo permite.
- Query Monitor (debug): es una herramienta excelente — de desarrollo y staging. En producción no debe quedar activa: añade overhead y expone detalles internos. Activa cuando necesitamos investigar, desactivada enseguida. Una herramienta de dev no es un plugin de producción.
Fíjate en el hilo común: ninguno de estos es inútil. Simplemente resuelven capas que o viven mejor fuera de WordPress (seguridad, backup) o no pertenecen a producción (debug). Por eso el trío fijo es fijo — y el resto es situacional.
Cuántos plugins instalar, al final
No existe número mágico. Lo que decide no es la cantidad, es la calidad y la necesidad real de cada plugin. Como referencia práctica: los sitios pequeños suelen funcionar bien con unos 5 a 10 plugins, y ~20 es un techo práctico antes de que el sitio se vuelva un problema de mantenimiento. Cada plugin instalado es un coste de rendimiento sumado a una superficie de mantenimiento y seguridad — instala por necesidad comprobada, nunca por costumbre.
Nuestro trío — Yoast, Redis Object Cache, ACF Pro — es la base porque cada uno resuelve una capa crítica e insustituible. A partir de ahí, cada añadido debe justificarse: qué capa resuelve, y por qué no puede resolverse fuera de WordPress.
Un sitio lento o roto casi nunca es falta de plugins. Es exceso — y el patrón de errores de WordPress lo confirma cada día. Menos plugins, mejor elegidos, es la decisión de rendimiento más barata que existe. Y mantener ese recorte a lo largo del tiempo es parte de lo que hacemos en mantenimiento de WordPress — igual que en todo proyecto de desarrollo WordPress que entregamos.
Tres plugins. El resto es bloat hasta que se demuestre lo contrario.