Añádelo como fuente preferida en Google
Una agencia gestiona 35 sitios web de clientes con un pequeño equipo de desarrollo. Los sitios están online, la infraestructura aguanta y, a simple vista, no parece haber nada especialmente urgente.
Sin embargo, dentro de la agencia, las grietas se ven más claramente. Por ejemplo:
- Un antiguo desarrollador sénior sigue teniendo acceso de administrador de la empresa a todos los sitios web de la cuenta, incluso después de llevar seis meses fuera.
- Hay un entorno staging de WooCommerce, pero nadie sabe a ciencia cierta si se corresponde con la web de producción actual.
- Las actualizaciones de los plugins se están acumulando en las instalaciones de los clientes, y el equipo se encarga de ellas cuando alguien tiene tiempo.
Técnicamente, todavía no hay ningún problema, pero cada nuevo cliente genera más roces internos. Hay más credenciales, entornos staging, decisiones sobre actualizaciones, traspasos y dudas sobre el uso, el rendimiento y el coste.
Para las agencias de WordPress, el crecimiento suele poner de manifiesto problemas en los flujos de trabajo antes de que surjan problemas de alojamiento. En este artículo te contamos cuáles son los cinco puntos críticos más comunes, sus causas y cómo sería una configuración más adecuada en Kinsta.
El problema oculto: la deuda de flujo de trabajo
Los flujos de trabajo de las agencias pequeñas suelen empezar con atajos prácticos:
- Acceso compartido
- Aprobaciones por Slack
- Actualizaciones manuales
- Pautas de staging que se han conservado
- Conocimientos específicos del cliente que solo tienen una o dos personas
Eso funciona cuando la lista de clientes es pequeña, porque el equipo puede estar al tanto de todos los detalles. Pero a medida que la agencia crece, esos atajos se vuelven más pesados.
Más sitios web, colaboradores externos, entornos, aprobaciones y tareas de mantenimiento hacen que la forma antigua sea más difícil de gestionar. Puede que la agencia siga teniendo suficiente capacidad de alojamiento, pero el equipo tiene menos claro cómo actuar.
Eso es la deuda de flujo de trabajo. Se acumula cuando la gente tiene que acordarse del proceso antes de poder seguirlo.
1. El problema del acceso: todo el mundo tiene demasiado acceso
Las agencias pequeñas suelen dar un acceso muy amplio porque parece más rápido, pero esa comodidad genera riesgos a medida que la agencia crece. Por ejemplo, que antiguos miembros del equipo sigan teniendo acceso durante demasiado tiempo, o que los clientes puedan ver entornos a los que no deberían tocar.
El daño rara vez es una filtración de datos. Lo más habitual es que se trate de un riesgo invisible que permanece en la cuenta hasta que alguien realiza un cambio irreversible.
Un flujo de trabajo más eficaz empieza por un acceso que se adapte al papel real de cada persona. La gestión de usuarios de MyKinsta permite a las agencias asignar permisos a nivel de empresa o de sitio web, con roles distintos para cada uno:
Para el trabajo diario con WordPress, MyKinsta también ofrece el inicio de sesión automático en WP Admin, lo que puede reducir la necesidad de compartir credenciales. Cuando alguien ya tiene el acceso adecuado a MyKinsta, puede iniciar sesión en WordPress sin tener que pasar las credenciales de administrador de forma separada.
2. El problema del caos en el entorno staging: nadie sabe qué entorno está actualizado
El staging se complica cuando el equipo crece más rápido que el proceso. Un desarrollador puede crear un entorno staging para un rediseño, y otro puede hacer un arreglo rápido en la web en producción. Al poco tiempo, ya nadie está del todo seguro de qué entorno refleja el sitio actual.
Con cinco clientes, el equipo puede tenerlo todo en la cabeza. Con 20 clientes, ya no pueden.
Una configuración más sólida asigna a cada entorno una función clara. Por ejemplo, el desarrollo local sirve para crear y probar, el staging es para la revisión interna, la aprobación del cliente y las comprobaciones previas al lanzamiento, y el uso en producción es solo para el trabajo ya aprobado.
Kinsta te ayuda con ese flujo de trabajo gracias a DevKinsta para el desarrollo local.
Y entornos de staging para cada instalación de WordPress. Además, tener URLs de staging uniformes facilita los ciclos de revisión, ya que tanto los clientes como los equipos internos saben dónde buscar.
El proceso de push (paso a producción) también es importante. Gracias a las opciones de push selectivo, las agencias pueden trasladar archivos, la base de datos o ambos entre entornos. Ese control resulta especialmente útil para tiendas de WooCommerce, sitios de membresía y otras páginas en las que los datos en tiempo real cambian constantemente.
Para proyectos más grandes o más delicados, los Entornos Staging Premium ofrecen a las agencias una configuración de pruebas que se asemeja mucho más al entorno de producción. Esto puede ser de gran ayuda para sitios con mucho tráfico, tiendas de comercio electrónico, sitios de membresía y trabajos en los que el rendimiento es clave.
Aun así, las herramientas solo sirven de ayuda si el equipo las usa de forma constante. Las agencias necesitan convenciones de nomenclatura, normas de revisión y permisos de envío claros para que todo el mundo sepa qué entorno está actualizado y quién puede publicar los cambios.
3. El problema de la acumulación de actualizaciones: el mantenimiento se convierte en un trabajo a tiempo completo
En la mayoría de las trayectorias de crecimiento de las agencias llega un momento en el que alguien se da cuenta de que las actualizaciones de los plugins se han convertido en una tarea a tiempo completo. Alguien del equipo va entrando en un panel de control tras otro, ejecutando actualizaciones, comprobando que todo siga funcionando y pasando al siguiente sitio web. Con 40 sitios web de clientes, eso puede llevarte fácilmente entre tres y cuatro horas a la semana.
Luego está la cuestión de las vulnerabilidades. A gran escala, una agencia puede tener sitios que ahora mismo ejecutan plugins obsoletos con problemas de seguridad conocidos, y no tener forma de identificar rápidamente cuáles son.
Si un desarrollador dedica cuatro horas a la semana a las actualizaciones manuales, con un coste total de 60 dólares por hora, eso supone 240 dólares a la semana y 12.480 dólares al año en mano de obra, un gasto que un proceso de actualización estructurado elimina en gran medida.
En MyKinsta hay dos cosas que se combinan para solucionar esto.
La primera es el filtro de vulnerabilidades de la lista de sitios. En MyKinsta, las agencias pueden filtrar toda la lista de sitios para que solo se muestren aquellos que tengan plugins o temas vulnerables.
La segunda opción son las Actualizaciones Automáticas de Kinsta (3 $ al mes por entorno). Incluyen pruebas de regresión visual que comparan capturas de pantalla de antes y después de cada actualización y revierten los cambios automáticamente si se produce algún fallo visual.
Las actualizaciones también se pueden programar para evitar las horas de mayor tráfico y las ejecuciones en modo de mantenimiento, para que los visitantes no vean el sitio web dañado.
Para las agencias que quieran crear sus propios flujos de trabajo de mantenimiento, la API de Kinsta también ofrece acceso programático a los datos de los plugins y las plantillas de todos los sitios de la cuenta, de modo que los equipos puedan consultar el estado de las actualizaciones en todo el portfolio sin tener que abrir cada panel de control individualmente.
4. El problema del traspaso: el onboarding(incorporación) y la salida de empleados ponen de manifiesto los fallos de los sistemas
La incorporación y la salida de clientes revelan cómo funciona realmente una agencia.
Cuando se incorpora un nuevo cliente, el equipo migra la web, prepara el entorno staging, configura los accesos, se lo asigna al desarrollador adecuado y lo etiqueta correctamente en el panel de control. Si se hace bien, se sigue siempre el mismo procedimiento; si no, se va improvisando un poco cada vez, con pequeñas variaciones que acaban generando deuda operativa.
Con cinco clientes, improvisar no supone un problema. Un desarrollador se acuerda de los plugins que hay. Un gestor de proyectos sabe dónde están las credenciales. Sin embargo, con 40 clientes, ese modelo basado en la memoria deja de funcionar.
El problema de la salida de clientes suele ser aún peor. Un cliente se va, el sitio tiene que trasladarse a su propio alojamiento y la agencia tiene que separar sus credenciales de la instalación de WordPress, desactivar el entorno staging, revisar quién sigue teniendo acceso y hacer el traspaso sin perder nada importante.
Kinsta ayuda a las agencias a crear una versión más ordenada de ambos procesos.
Las migraciones gestionadas gratuitas eliminan el mayor pico de trabajo durante la incorporación. A partir de ahí, las agencias pueden seguir una configuración coherente: entorno staging, roles de acceso asignados y etiquetas del sitio que organizan el portfolio por cliente, nivel de servicio o estado de la cuenta.
A la hora de dar de baja un sitio, la transferencia de sitios ofrece a las agencias un proceso de traspaso sencillo. Un sitio se puede transferir a otra cuenta de Kinsta o a alguien que no sea usuario de Kinsta, a quien se le pedirá que se cree una cuenta. Los registros DNS gestionados en MyKinsta se transfieren junto con el sitio. Los add-ons como Redis y Staging Premium se transfieren automáticamente.
Para las agencias que gestionan un gran volumen de altas, la API de Kinsta permite a los equipos crear nuevas páginas de WordPress, establecer entornos staging y configurar el acceso mediante código, lo que elimina los pasos manuales en el panel de control de un proceso que se repite con cada cliente.
5. El problema de la visibilidad: el uso, los bots y los costes para los clientes son cada vez más difíciles de explicar
Cuando el uso de un cliente empieza a subir, pero las conversiones se mantienen estables y los ingresos no varían, la agencia tiene que explicar un aumento de costes sin un resultado empresarial claro que lo justifique.
Esa conversación se complica cuando el equipo no puede ver rápidamente qué ha provocado el pico. Puede que una campaña haya generado tráfico real. Puede que los rastreadores de IA hayan escaneado gran parte del sitio. Puede que bots no deseados hayan accedido a las mismas páginas una y otra vez. Puede que los rastreadores de búsqueda, las herramientas de monitorización y los visitantes legítimos hayan contribuido todos a la vez.
Los matices importan. No todo el tráfico automatizado es malo. Los motores de búsqueda necesitan rastrear las páginas de los clientes. Las herramientas de tiempo de actividad deben comprobar la disponibilidad. Algunas herramientas de comercio electrónico, seguridad e integración también dependen de la actividad automatizada. Bloquearlo todo crea sus propios problemas. Permitir todos los bots por defecto hace que el uso sea más difícil de gestionar y que las explicaciones sean más complicadas de dar.
Las agencias necesitan visibilidad antes de poder dar a los clientes una respuesta útil.
La Protección contra bots de Kinsta ofrece a las agencias controles por sitio para el tráfico automatizado. Esto es importante porque cada sitio de cliente puede necesitar un enfoque diferente. Un cliente puede querer bloquear los rastreadores de IA. Otro puede necesitar excepciones para herramientas de monitorización, integraciones o la automatización típica de WordPress.
La protección contra bots incluye informes para que los equipos puedan ver cómo afecta el tráfico automatizado a cada sitio web, en lugar de tener que adivinar qué ha pasado tras los picos de tráfico.
Desglose de la caché te da más información. Si el tráfico sube pero la eficacia de la caché baja, el equipo puede analizar si el problema viene de peticiones que no se han almacenado en la caché, de la actividad de los bots o de un problema de configuración del sitio, en lugar de achacarlo todo al crecimiento orgánico.
Cuando cambia el uso, alguien tiene que explicarlo con claridad. Una mayor visibilidad ayuda al equipo a relacionar el tráfico, los bots, el almacenamiento en caché y los costes de una forma que los clientes puedan entender. Sin ese contexto, cada pico se convierte en un juego de adivinanzas.
Unos flujos de trabajo más sólidos hacen que el crecimiento sea menos frágil
El crecimiento de una agencia no siempre afecta primero a la infraestructura de WordPress. La mayoría de las veces, lo que se rompe son los flujos de trabajo informales que antes mantenían todo en su sitio.
Las agencias en crecimiento no necesitan complejidad por el simple hecho de tenerla. Necesitan sistemas más claros para el trabajo que ya hacen cada día, como asignar accesos, probar cambios, gestionar actualizaciones, incorporar clientes, transferir la propiedad y explicar el uso.
Si tu agencia está consiguiendo clientes de WordPress a un ritmo más rápido del que tus flujos de trabajo pueden soportar, el alojamiento para agencias de Kinsta y el Programa de socios para agencias están diseñados para adaptarse al modelo operativo que necesitan las agencias en crecimiento.
