Categoría: Web y aplicaciones
WordPress y WooCommerce gestionados: rápidos, actualizados y con copias probadas
Vuestra web o vuestra tienda en un servidor que pagáis vosotros, rápida en hora punta, con las actualizaciones probadas antes de tocar producción y una copia que sabemos que vuelve porque la restauramos.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source: WordPress, GPLv2 o posterior; WooCommerce, GPLv3
En resumen
WordPress es el gestor de contenidos de código abierto más usado, y WooCommerce es su extensión de tienda online. Los montamos en vuestra cuenta con PHP-FPM ajustado, caché de objetos con Redis o Valkey, caché de página y CDN si aporta. Mantenemos un entorno de staging donde probamos cada actualización de núcleo, plugins y tema antes de producción, y hacemos copias fuera del servidor que restauramos en pruebas.
¿Qué nos encargamos de mantener?
Instalar WordPress lleva cinco minutos; mantenerlo rápido y seguro durante años es otra cosa. Cada plugin añade código que se actualiza a su ritmo, la base de datos crece con cada pedido y basta una actualización mal probada para dejar la tienda sin botón de pago. Esto es lo que dejamos bajo control:
WordPress y WooCommerce
Núcleo, plugins y tema al día, con la configuración del servidor descrita en código.
Rendimiento
PHP-FPM, OPcache, caché de objetos con Redis o Valkey y caché de página ajustados a vuestro tráfico.
Staging
Una copia de producción donde probar actualizaciones y cambios de vuestra agencia antes de publicar.
Base de datos
MariaDB o MySQL con consultas lentas revisadas y tablas de opciones y sesiones a raya.
Seguridad
Acceso al panel restringido, doble factor, permisos de archivos correctos y plugins vulnerables detectados.
Monitorización
Tiempo de respuesta, errores PHP, proceso de compra, disco y certificados, con alertas.
¿Cómo conseguimos que vaya rápido?
La mayor parte de la lentitud de WordPress no está en el servidor, sino en el trabajo que hace PHP en cada visita. Lo atacamos por capas:
Caché de página
El visitante anónimo recibe una página ya generada. En WooCommerce excluimos carrito, pago y cuenta, que siempre van en vivo.
Caché de objetos
Redis o Valkey guardan los resultados de consultas repetidas entre peticiones, lo que más se nota en el panel y en la tienda con sesión iniciada.
PHP-FPM y OPcache
Número de procesos según la memoria disponible, OPcache con espacio suficiente y la versión de PHP más reciente que soporten vuestros plugins.
CDN opcional
Imágenes, hojas de estilo y scripts servidos desde cerca del visitante cuando vuestro público está repartido.
Si queréis Redis o Valkey también para otras aplicaciones, con réplica y persistencia, lo tenéis en Redis y Valkey gestionados. La base de datos, cuando pesa, se trata como en MySQL y MariaDB gestionados.
¿Qué problemas encontramos más a menudo?
- Plugins abandonados: siguen activos años después de su última versión, con vulnerabilidades conocidas.
- Actualizaciones a ciegas: se actualiza todo desde el panel en producción y el pago deja de funcionar.
- WP-Cron que depende de las visitas: las tareas se retrasan de noche y se amontonan en hora punta.
- Tabla de opciones inflada: datos cargados en cada petición que nadie limpia.
- Copia del hosting que nunca se probó: solo los archivos, o solo la base de datos, o del mismo servidor.
- Panel de administración abierto: el inicio de sesión recibe intentos de acceso a todas horas.
¿Cómo probamos una actualización antes de producción?
Staging es una copia de producción en el mismo tipo de servidor, con los correos salientes desactivados y los pagos en modo de pruebas, para que no salga nada a clientes reales. Antes de cada tanda de actualizaciones refrescamos staging desde producción, actualizamos allí núcleo, plugins y tema, y repasamos las páginas importantes. En una tienda, además, añadimos un producto al carrito y completamos un pedido con la pasarela en modo de pruebas. Solo entonces actualizamos producción, con una copia hecha justo antes. Las versiones con parches de seguridad urgentes se adelantan, pero pasan por el mismo camino.
¿Cómo hacemos las copias y la restauración?
La copia lleva la base de datos y la carpeta de contenidos, donde están las subidas, los plugins y el tema. Va cifrada a un almacenamiento de objetos fuera del servidor, con varios días de retención. Periódicamente restauramos una copia en un servidor de prueba y comprobamos que la web carga, que se puede entrar al panel y, en una tienda, que los pedidos recientes están. Con WooCommerce hay un matiz: restaurar una copia de anoche significa perder los pedidos de hoy, así que ante un problema preferimos recuperar solo lo que falta y dejamos la restauración completa como último recurso.
¿Cómo protegemos WordPress?
El acceso al panel queda restringido por IP o detrás de un inicio de sesión con doble factor, y la edición de archivos desde el panel, desactivada. El usuario del sistema que ejecuta PHP no puede modificar el código de WordPress, solo la carpeta de subidas, y en esa carpeta no se ejecuta PHP. Revisamos cada semana los plugins instalados contra las bases de vulnerabilidades conocidas; ese seguimiento continuo encaja con la gestión de vulnerabilidades. Si queréis que alguien responda de la web y del servidor cada mes, está en el SRE como servicio.
- CDNOpcional, estáticos
- NginxHTTPS y caché de página
- PHP-FPMWordPress y WooCommerce
- RedisCaché de objetos
- MariaDBCopias fuera
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Servidor cloud o dedicado con Nginx, PHP-FPM, MariaDB y Redis o Valkey, y copias en Object Storage de Hetzner, compatible con S3. | Buena relación entre CPU y coste para tiendas con picos de tráfico. |
| AWS | EC2 con PHP-FPM y Nginx, base de datos en RDS for MariaDB o MySQL si encaja, y copias y medios en S3. | Vigilamos la transferencia de salida; con muchas imágenes, un CDN suele salir más barato. |
| Google Cloud | Compute Engine con la pila completa o con Cloud SQL para MySQL, y copias en Cloud Storage. | |
| DigitalOcean | Droplets con la pila completa, o con MySQL gestionado de DigitalOcean, y copias en Spaces. | |
| OVH | Instancias de Public Cloud o servidores dedicados, con copias en Object Storage de OVHcloud. | |
| Servidor propio | La pila en vuestro servidor o en una máquina virtual, publicada a través de un proxy o un túnel. | Las copias salen siempre fuera del edificio. |
Qué incluye
- Servidor con Nginx, PHP-FPM y MariaDB o MySQL dimensionados para vuestro tráfico, en vuestra cuenta y a vuestro nombre.
- Caché de objetos persistente con Redis o Valkey, y caché de página para el tráfico anónimo.
- CDN opcional delante para estáticos e imágenes, con reglas que no cachean el carrito ni la cuenta del cliente.
- Entorno de staging con una copia reciente de producción para probar cambios.
- Actualizaciones de núcleo, plugins y tema probadas antes en staging y aplicadas en una ventana avisada.
- Tareas programadas de WordPress con el cron del sistema, no con las visitas.
- Copias diarias de base de datos y archivos fuera del servidor, con restauración de prueba periódica.
- Monitorización del tiempo de respuesta, el pago, los errores PHP, el disco y los certificados, con alertas.
Preguntas frecuentes
¿Activáis las actualizaciones automáticas de plugins?
No para todo. Las versiones menores de seguridad del núcleo se aplican solas. Los plugins y el tema pasan antes por staging: actualizamos allí, recorremos las páginas clave y, en una tienda, hacemos una compra de prueba. Si todo funciona, aplicamos en producción en una ventana avisada; si un plugin rompe algo, se queda en la versión anterior hasta que haya arreglo o alternativa.
¿Nos ayudáis si nuestro WordPress va lento?
Sí. Empezamos midiendo: qué páginas tardan, qué consultas a la base de datos se repiten y qué plugins añaden más trabajo a cada visita. A menudo la mejora viene de la caché de objetos, de ajustar PHP-FPM y de limpiar tablas de opciones infladas, más que de cambiar de servidor. Si un plugin es el problema, os lo decimos con datos.
¿Os encargáis del diseño o del contenido de la web?
No. Nos ocupamos del servidor, el rendimiento, las actualizaciones, la seguridad y las copias. El diseño, los textos y la maquetación siguen siendo cosa vuestra o de vuestra agencia; trabajamos con ellos y les damos acceso a staging para que prueben sus cambios antes de publicar.
¿Qué pasa con las licencias de plugins y temas de pago?
Siguen a vuestro nombre. WordPress y WooCommerce son software libre, pero muchos plugins y temas premium venden la licencia y las actualizaciones aparte. Las claves las guardáis vosotros; nosotros las usamos para mantener esas piezas al día y os avisamos si alguna licencia caduca y deja un plugin sin parches.
¿Podemos migrar nuestra web desde un hosting compartido?
Sí. Copiamos la web a vuestro servidor nuevo, la probamos con un dominio temporal y cambiamos el DNS cuando responde igual. En una tienda elegimos un momento de poco tráfico y congelamos los pedidos el rato del cambio, para que no se pierda ninguno entre los dos servidores.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
- WordPress Developer Resources: Advanced Administration Handbook
- WordPress Plugin Handbook: Hooking WP-Cron into the system task scheduler
Revisado el