Ir al contenido

El medio de los artesanos de la web miércoles, 19 de agosto de 2026

MailStudio

Autoalojar sus WordPress: la guía

El modelo de alojamiento, la pila que aguanta en un VPS, la trampa de las cachés apiladas, la base de seguridad y los límites del autoalojamiento.

Autoalojar sus sitios WordPress no es un ejercicio de estilo ni un ahorro marginal: es un arbitraje entre la comodidad de una plataforma gestionada y el dominio de la propia pila. Esta guía describe la configuración que aguanta en un servidor privado virtual, los componentes que la constituyen y los puntos en los que el autoalojamiento cuesta más de lo que aporta.

Qué abarca «autoalojar»

Coexisten tres modelos, y confundirlos falsea toda comparación de costes.

ModeloLo que usted gestionaPertinente cuando
CompartidoNada, salvo el sitioUn sitio, poco tráfico, ninguna competencia de sistemas
WordPress gestionadoEl sitio y su contenidoPresupuesto mensual cómodo, ninguna gana de administrar
VPS autoadministradoSistema, servidor web, base de datos, copias, seguridadVarios sitios, soltura con el terminal, necesidad de control

El tercer modelo solo es razonable a partir del momento en que se sabe leer una configuración de Nginx y un registro de errores. Por debajo, el ahorro aparente se paga en indisponibilidad.

La pila que aguanta

El panel: ligero antes que exhaustivo

Los paneles históricos facturan una licencia, movilizan de 1,5 a 2 GB de memoria antes de servir una página e interponen una abstracción entre el operador y el servidor. En un VPS que se administra uno mismo, esa abstracción se convierte en el principal obstáculo al diagnóstico.

Leer: CloudPanel: WordPress autoalojado sin panel pesado — requisitos, comparación con cPanel y Plesk, procedimiento de instalación y límites del producto.

Los componentes y su función

  • Nginx en frontal, con un host virtual legible y sobrecargable.
  • PHP-FPM, con una versión por sitio — imprescindible para que convivan un PrestaShop antiguo y un WordPress reciente.
  • MariaDB o MySQL, elegido explícitamente en la instalación.
  • Redis para la caché de objetos: es el componente que produce la ganancia más neta en WordPress, antes que cualquier caché de página.
  • Una caché de página — caché FastCGI de Nginx o un reverse proxy. Una sola, nunca dos.
  • Let’s Encrypt con renovación automática.

La regla que evita más averías: una sola capa por función. Dos cachés de página que se ignoran producen páginas caducadas que nadie sabe purgar.

La trampa de las capas apiladas

Es el error más frecuente en instalaciones con años. Una caché de página en una extensión, otra en un reverse proxy, una tercera en el proveedor de CDN, más un módulo de reescritura de recursos: cada una cachea correctamente, ninguna sabe purgar a las demás. El síntoma es siempre el mismo — una modificación desplegada que sigue invisible.

La configuración sana se resume en tres decisiones: una caché de objetos (Redis), una caché de página (una sola, purgada al publicar) y una minificación (una sola, o ninguna).

Seguridad: una base, no una fortaleza

La mayor parte de lo que golpea a un sitio pequeño es ruido automatizado. Tres piezas bastan para cortarlo: un cortafuegos aplicativo, un bloqueo a nivel de red e identificadores revocables para las integraciones.

Leer: Hardening de WordPress: la base de seguridad mínima — configuración de Wordfence, filtro Fail2ban listo para usar, trampa de las direcciones IP tras un proxy.

Copias de seguridad: la única medida que repara

Todas las demás medidas previenen; solo la copia repara. Tres exigencias la hacen útil:

  1. Fuera del servidor de producción — una copia en la misma máquina no protege de nada.
  2. Cifrada, con la frase de paso guardada en otro sitio que la herramienta de copia.
  3. Restaurada al menos una vez. Una copia nunca restaurada es una hipótesis, no una garantía.

Lo que el autoalojamiento no resuelve

  • La disponibilidad permanente: sin guardia, un incidente nocturno dura hasta la mañana.
  • El pico de carga repentino: un VPS único tiene un techo, y la orquestación multinodo es otro oficio.
  • El correo: alojar el propio servidor de envío expone a problemas de entregabilidad desproporcionados. Delegar en un servicio especializado sigue siendo la opción correcta — véase la guía de entregabilidad.

Pilotar tras la puesta en línea

Un sitio autoalojado se vigila en tres ejes solamente: disponibilidad, tiempo de respuesta y volumen de errores aplicativos. El resto corresponde al pilotaje editorial, tratado en GA4 y Search Console.

Los artículos de la sección

Esta página se actualiza al hilo de las publicaciones de las secciones DevOps y servidores y Seguridad.