Está migrando un WordPress compartido de OVH a un VPS. En compartido, Apache + .htaccess enmascaró una pésima configuración de enlaces permanentes. En Nginx, la página de inicio responde 404 hasta que traduzcamos las reglas de reescritura en /etc/nginx/sites-available/. No es Nginx lo que es "más difícil": es la configuración dispersa la que ya no viaja.
Apache y Nginx son dos formas de servir PHP y archivos estáticos. Para WordPress, la cuestión operativa se reduce a: quién gestiona las reglas de reescritura, cómo se aísla PHP y cómo se almacena en caché bajo carga.
mod_php, PHP-FPM: la verdadera elección
| Pila | Beneficios de WordPress | Fricción operativa |
|---|---|---|
| Apache + mod_php | Complementos .htaccess, simplicidad compartida | Memoria por proceso Apache, escalable |
| Apache + PHP-FPM | Compatibilidad .htaccess + aislamiento PHP | Dos servicios para pagar |
| Nginx + PHP-FPM | Rendimiento, tamaño reducido | Sin .htaccess; configuración de administrador |
| Nginx + servidor Apache | Raro hoy | Doble pila para mantener |
Elegir Apache “para WordPress” en 2026 a menudo significa elegir
.htaccess, no una obligación del CMS.
Apache: cuando se simplifica aún más
Clásico compartido. El anfitrión gestiona todo; subes complementos sin tocar el servidor.
Complementos que reescriben .htaccess (caché, seguridad, redireccionamientos): mientras permanezcas en Apache, “funcionan”.
Equipo sin acceso de root. No hay ningún archivo Nginx para editar.
Limitaciones: bajo carga, mod_php multiplica la RAM; Se recomienda cambiar a PHP-FPM desde un VPS.
Nginx: cuando simplifica la producción
Tráfico de medios o comercio electrónico. Menos trabajadores, mejor servicio de archivos estáticos, configuraciones TLS modernas.
Pila unificada. Incluso Nginx frente a PHP, Node o caché ascendente.
Alojamiento de WordPress administrado. Raidboxes, Kinsta, etc.: Nginx + caché integrado: no mantienes las reescrituras a mano.
Lista de verificación de migración de Apache → Nginx:
- Exportar enlaces permanentes de WordPress (Configuración → enlaces permanentes → guardar)
- Traducir el patrón estándar
try_files+@wordpress - Verifique
client_max_body_sizepara ver las cargas - Pruebe wp-admin, API REST, cron
Caché: donde se lleva a cabo la explotación
No importa el servidor web si no hay caché de página:
- Complemento (WP Rocket, etc.) + compresión Nginx gzip/brotli
- Caché de objetos de Redis para una administración intensa
- CDN para activos
Un caché agresivo compartido de Apache + a menudo supera a un Nginx desnudo mal ajustado.
La parte superior: el servidor web no es el cuello de botella habitual
Decide y avanza sin puntos ciegos
En archivos compartidos sin acceso root, a menudo se impone Apache: optimice el caché del complemento y la base de datos. En VPS con equipo de operaciones, prefiera Nginx + PHP-FPM con un modelo de WordPress documentado y versionado. Para tráfico elevado sin un equipo interno, un WordPress administrado por Nginx (consulte Caché de Raidboxes) evita la traducción manual de reglas. Pruebe la carga idéntica en ambas pilas antes de la migración. Explore el directorio y la comparación; secuencia lógica: PHP-FPM o mod_php.
Preguntas frecuentes
¿WordPress recomienda Apache o Nginx?
WordPress funciona muy bien en ambos. Apache es el valor predeterminado histórico de compartir gracias al archivo .htaccess. Nginx es común en VPS y hosting administrado orientado al rendimiento, con reglas de reescritura centralizadas.
¿Los complementos se rompen con más frecuencia en Nginx?
Los complementos que escriben reglas .htaccess no las aplican automáticamente en Nginx. Tienes que traducirlo a la configuración del servidor o utilizar un host de WordPress administrado que lo haga por ti, como Raidboxes.
¿Qué combinación para un sitio con mucho tráfico?
Nginx en proxy inverso con PHP-FPM, caché de objetos de Redis y caché de páginas mediante complemento o Varnish es el esquema más común. Apache solo con mod_php se satura más rápido en competencia.
¿Puedo mantener Apache en un VPS?
Sí, especialmente con PHP-FPM en lugar de mod_php y OPcache habilitado. No se trata del logotipo, sino del modelo de proceso, el caché y el ajuste.
Antes de migrar a Nginx, enumere los complementos que tocan .htaccess. Si son cinco, presupuesta la traducción... o la gestión.