Cuando una web WordPress empieza a ir lenta, recibir errores puntuales o quedarse corta durante una campaña, la conclusión rápida suele ser: “necesitamos un VPS”. A veces es correcto. Otras veces, el cambio solo traslada el mismo problema a un servidor más caro y con más responsabilidades.
Un VPS aporta aislamiento y capacidad de configuración, pero no corrige por sí solo consultas lentas, bots, un plugin defectuoso, copias ejecutadas a horas inadecuadas o una caché mal definida. Antes de migrar conviene saber qué está limitando el sitio, qué recursos necesita realmente y quién va a operar el nuevo entorno.
Esta guía ayuda a decidir con criterios prácticos. No busca enfrentar hosting compartido y VPS como si uno fuera siempre superior: la pregunta útil es qué necesita tu WordPress hoy y qué riesgo estás dispuesto a gestionar mañana.
Índice
- Qué cambia realmente al pasar a un VPS.
- Señales que sí justifican estudiar la migración.
- Problemas que un VPS no arregla por sí solo.
- Qué medir antes de contratar nada.
- Recursos y arquitectura: cómo dimensionar sin adivinar.
- La parte que suele olvidarse: operar el VPS.
- Plan de migración sin improvisar.
- Cuándo quedarse en hosting compartido es la decisión correcta.
Qué cambia realmente al pasar a un VPS
En un hosting compartido, varias webs conviven en una misma infraestructura y comparten una parte de los recursos y límites operativos. En un VPS, la máquina virtual tiene una asignación definida de CPU, memoria y almacenamiento, además de un mayor control sobre su configuración.
Ese control puede permitir ajustar PHP-FPM, cachés, reglas de Nginx o Apache, tareas programadas, copias, firewall y monitorización. También permite separar servicios o adaptar el entorno a una aplicación con necesidades concretas.
Pero un VPS no es una web más rápida por definición. Un servidor con recursos dedicados puede rendir peor que un hosting compartido bien gestionado si nadie revisa actualizaciones, copias, alertas, límites de PHP, consumo de disco o seguridad. El cambio de plataforma convierte parte de las limitaciones del proveedor en tareas propias.
La decisión no debería basarse solo en la etiqueta “VPS”. Debe responder a tres preguntas:
- ¿Existe un problema de capacidad o aislamiento comprobado?
- ¿La configuración adicional resolverá ese problema?
- ¿Hay una persona o servicio responsable de operar el servidor?
Señales que sí justifican estudiar la migración
No hace falta esperar a que una web se caiga para valorar un VPS. Hay situaciones en las que el hosting compartido puede dejar de encajar con la carga o con la criticidad del proyecto.
El sitio choca repetidamente con límites del plan
Errores 503, 504, procesos terminados, límites de CPU o RAM, colas de PHP-FPM y avisos recurrentes del proveedor son señales que merecen una revisión. Antes de cambiar de plan, pide datos concretos: cuándo se alcanzó el límite, qué proceso estaba consumiendo recursos y si el problema afectó a una URL, una tarea automática o a todo el sitio.
Un pico aislado durante una actualización o una copia no demuestra que haga falta un VPS. Un patrón repetido, documentado y ligado a la actividad normal del negocio sí puede justificarlo.
Necesitas un entorno que el plan actual no permite configurar
Hay proyectos que requieren reglas de servidor, versiones de PHP compatibles con una aplicación concreta, un servicio de caché de objetos, tareas programadas controladas o límites de ejecución que un hosting compartido no permite ajustar con precisión.
Esto es frecuente en tiendas con procesos intensivos, integraciones que sincronizan inventario, aplicaciones con varias webs, miembros o idiomas, o servicios que necesitan tareas en segundo plano previsibles.
La web depende de disponibilidad y observabilidad
Si una caída tiene impacto directo en ventas, reservas, soporte o campañas, no basta con mirar si “abre”. Conviene disponer de alertas, métricas, registros y un procedimiento de respuesta.
Un VPS permite construir ese entorno, pero solo aporta valor si se configura y se revisa. Migrar sin monitorización equivale a tener más controles sin mirar ninguno.
Hay varias aplicaciones que necesitan aislamiento operativo
Concentrar varias webs en un mismo hosting puede ser cómodo, pero aumenta el impacto de una mala configuración, de un pico de consumo o de un incidente. Un VPS no elimina el riesgo de compartir recursos entre aplicaciones, pero permite separarlas mejor mediante usuarios, pools PHP, bases de datos, límites y políticas de copia.
Problemas que un VPS no arregla por sí solo
El error más caro es migrar para evitar diagnosticar. Antes de contratar infraestructura, descarta causas que seguirán presentes después del cambio.
Bots, rastreadores y tráfico no deseado
Un VPS con el doble de CPU puede aguantar más peticiones, pero no hace que un bot deje de pedir páginas caras. Si el origen son ataques al login, scrapers, XML-RPC, URLs sin caché o peticiones automatizadas, la solución puede requerir reglas en CDN o WAF, limitación de tasa, caché y análisis de registros.
La guía sobre cómo distinguir tráfico, bots y un problema de PHP ayuda a separar estas causas antes de invertir en recursos que quizá solo retrasen el siguiente cuello de botella.
Consultas lentas y plugins que ejecutan trabajo innecesario
Una consulta de base de datos sin índice, un plugin que llama a un servicio externo en cada visita o una tarea que procesa miles de registros puede consumir más recursos en cualquier servidor. El VPS reduce la presión durante un tiempo, pero no convierte un proceso ineficiente en uno correcto.
Mide qué endpoint, consulta o proceso coincide con la lentitud. Revisa también si el problema aparece solo en el administrador, en un cron, en el checkout o después de una actualización concreta.
Una caché mal planteada
La caché puede descargar el servidor, pero si se aplica a sesiones, carrito, precios dinámicos o formularios, puede crear fallos funcionales. Aumentar recursos sin delimitar qué se puede cachear y qué no deja intacto ese riesgo.
Copias, escaneos y cron concentrados
Las copias de seguridad, escaneos, importaciones y sincronizaciones pueden generar picos legítimos. Si se ejecutan al mismo tiempo, el problema puede ser el horario y no la capacidad permanente.
WP-Cron depende de las peticiones al sitio y no funciona como un demonio continuo. Para tareas que deben ejecutarse con regularidad, WordPress documenta el uso de un programador del sistema y la desactivación del disparador ligado a cada carga de página, siempre que esa configuración se pruebe correctamente.[1]
Qué medir antes de contratar nada
No necesitas un observatorio complejo para empezar, pero sí evidencias que permitan comparar. Recoge datos durante varios días y anota los picos, cambios de tráfico, campañas, tareas internas y errores.
Métricas útiles
- CPU y memoria. Comprueba si el consumo es constante, puntual o si agota la memoria antes de que suba la CPU.
- Procesos PHP-FPM. Revisa cuántos procesos hay activos, si se forman colas y qué URLs coinciden con ellas.
- Base de datos. Observa consultas lentas, bloqueos, tamaño de tablas y procesos que se prolongan.
- Disco e inodos. Las copias locales, logs sin rotar y cachés pueden llenar un disco aunque la CPU esté libre.
- Tiempos de respuesta y errores. Diferencia la portada cacheada de procesos como login, carrito, checkout, administración y formularios.
- Registros de acceso. Identifica IPs, agentes, rutas y patrones que concentran peticiones.
- Tareas programadas. Anota copias, cron, actualizaciones, escaneos y sincronizaciones con su horario y duración.
No uses una sola cifra como veredicto. Una CPU al 90% durante un minuto puede ser normal; una cola de procesos que coincide con pedidos perdidos o errores para visitantes requiere otra prioridad.
Preguntas que conviene responder por escrito
Antes de pedir presupuestos, intenta responder:
- ¿Qué componente se agota primero: CPU, memoria, procesos, disco o base de datos?
- ¿En qué franja horaria ocurre y qué tráfico o tarea coincide?
- ¿Qué parte de la web falla: todo el sitio, el administrador, una tienda o una integración?
- ¿El problema mejora al bloquear un bot, ajustar caché o cambiar el horario de una tarea?
- ¿Qué capacidad adicional haría falta y durante cuánto tiempo?
Estas respuestas permiten elegir un servidor con fundamento y también saber si una optimización previa puede resolver el problema sin migrar.
Recursos y arquitectura: cómo dimensionar sin adivinar
No existe una cifra universal de RAM o CPU para WordPress. Una web corporativa cacheada, una tienda con carrito, una membresía y una instalación con procesos de importación pueden necesitar recursos muy distintos aunque reciban un número parecido de visitas.
En lugar de elegir un VPS por una tabla genérica, parte de la carga observada y deja margen para picos, actualizaciones y recuperación. El objetivo no es comprar el servidor más grande, sino evitar que el servicio opere continuamente al límite.
CPU y memoria
La CPU está relacionada con el trabajo que se ejecuta: PHP, consultas, compresión, cifrado, imágenes, copias y procesos de sistema. La memoria condiciona cuántos procesos pueden coexistir sin que el sistema tenga que terminar procesos o intercambiar memoria con disco.
Configurar demasiados procesos PHP-FPM en una máquina pequeña puede provocar que todos compitan por memoria. Configurar muy pocos puede formar una cola aunque haya CPU disponible. Por eso los límites deben ajustarse a lo que consume realmente cada proceso y al comportamiento de la aplicación.
Almacenamiento y copias
No calcules el disco solo con el tamaño actual de wp-content. Incluye base de datos, imágenes, registros, caché, actualizaciones, espacio temporal y copias. Decide además dónde se guardarán las copias: mantenerlas únicamente dentro del VPS deja expuesto el plan de recuperación si falla el servidor o se pierde el acceso.
Red, CDN y caché
Muchas webs no necesitan servir cada visita desde PHP. Una CDN y una caché bien configuradas pueden reducir peticiones al origen, mejorar tiempos de carga y amortiguar picos. No sustituyen un servidor sano, pero evitan dimensionarlo para atender solicitudes que no deberían llegar a la aplicación.
La parte que suele olvidarse: operar el VPS
Un VPS administrado y un VPS autogestionado no son lo mismo. Antes de migrar, deja claro quién se ocupa de:
- Actualizar el sistema operativo y los paquetes del servidor.
- Aplicar actualizaciones de seguridad urgentes.
- Revisar alertas, capacidad de disco y copias.
- Renovar certificados y supervisar los servicios web.
- Ajustar PHP, base de datos y caché cuando cambie la carga.
- Investigar errores, picos de consumo o una posible intrusión.
- Probar restauraciones fuera de producción.
Tener acceso root sin un procedimiento de mantenimiento no es una ventaja automática. En proyectos críticos, suele ser más útil combinar el VPS con una gestión técnica clara que depender de intervenir solo cuando la web ya falla.
El servicio de servidores y VPS gestionados está pensado precisamente para esta parte: infraestructura, seguridad, copias, monitorización y soporte deben trabajar como un conjunto, no como decisiones aisladas.
Plan de migración sin improvisar
La migración no debería ser el primer momento en que pruebas el nuevo servidor. Prepara el entorno, replica el sitio y valida sus funciones antes de dirigir tráfico real.
1. Define qué se mueve y qué no
Documenta dominio, DNS, correo, base de datos, archivos, cron, certificados, caché, CDN, plugins de pago, integraciones externas y servicios de copia. Muchas incidencias posteriores no se deben a WordPress, sino a una clave SMTP, un webhook o una regla DNS que no se trasladó.
2. Prepara el VPS con seguridad básica
Crea usuarios individuales, evita usar la cuenta principal para tareas diarias, configura acceso SSH con claves cuando corresponda, aplica actualizaciones y limita los servicios expuestos. Prepara monitorización, copias externas y un método probado para recuperar acceso.
3. Replica y prueba antes del cambio DNS
Carga una copia reciente del sitio en el nuevo entorno y pruébalo con un dominio temporal o una resolución local controlada. No te limites a comprobar la portada. Verifica formularios, acceso, áreas privadas, pedidos, correos salientes, tareas programadas, imágenes, redirecciones y cualquier integración crítica.
4. Planifica la ventana de cambio
Reduce el riesgo de pérdida de datos evitando cambios de contenido o pedidos durante el tramo final, o prepara una sincronización final de base de datos y archivos. Reduce el TTL DNS con antelación suficiente si procede, sin eliminar registros que aún sean necesarios.
5. Valida después de publicar
Tras el cambio, monitoriza errores, tiempos de respuesta, entregas de correo, registros y consumo. Conserva el entorno anterior durante un periodo acordado y con acceso controlado, por si hay que recuperar datos o comparar configuraciones. No lo mantengas indefinidamente como un segundo punto de exposición olvidado.
Cuándo quedarse en hosting compartido es la decisión correcta
Un hosting compartido puede ser suficiente cuando la web es estable, tiene una carga moderada, cuenta con caché adecuada y el proveedor resuelve correctamente sus necesidades de PHP, copias, seguridad y soporte.
También puede ser la mejor elección si el proyecto no necesita configuraciones especiales y no existe una persona responsable de mantener un VPS. Pagar por más control que nadie va a usar no mejora la continuidad del negocio.
La decisión correcta no es la que suena más técnica. Es la que permite que la web funcione con margen, que sus riesgos estén controlados y que haya un responsable claro cuando algo cambie.
Antes de migrar, diagnostica
Migrar a un VPS tiene sentido cuando hay un límite real, una necesidad concreta de configuración o una exigencia de aislamiento y control que el hosting compartido no cubre. Si el problema es un bot, una consulta lenta, una tarea mal programada o una caché defectuosa, primero hay que resolver esa causa.
Antes de contratar, reúne evidencias. Antes de mover DNS, prepara pruebas y copias. Y antes de asumir un servidor propio, decide quién lo va a cuidar cuando no haya una incidencia visible.
Si tu WordPress consume recursos de forma recurrente o necesitas valorar una migración, el primer paso no es elegir un plan: es entender la carga real y diseñar una infraestructura que puedas mantener.
Sources
[1] https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler