Cómo la visibilidad compartida reduce tickets de soporte, culpas y caídas en WordPress

Cuando un sitio WordPress se cae un viernes a la tarde, arrancan dos problemas en paralelo: arreglar el sitio y ponerse de acuerdo sobre quién lo rompió. Casi siempre, el segundo lleva más tiempo. El desarrollador señala la campaña que acaba de salir. El marketer apunta al servidor. La agencia recibe llamados de ambos y no tiene datos propios para responder. Para cuando todos coinciden en dónde mirar, la caída ya generó pérdidas reales, y la discusión también.

La raíz no es que los equipos no se pongan de acuerdo. Es que cada uno trabaja con una rebanada distinta de los datos. El desarrollador ve el código. El marketer ve el tráfico. La agencia ve la cola de tickets. Nadie ve lo mismo al mismo tiempo, por lo que nadie puede descartar nada.

Kinsta eligió el camino contrario: poner a todos los involucrados en el mismo pie diagnóstico. Los datos que usan los ingenieros de soporte (códigos de respuesta, rendimiento PHP, ratios de caché, logs de requests) son exactamente los mismos que ve cualquier usuario con acceso a analytics en MyKinsta. Cuando todos leen las mismas señales, un sitio roto pasa de ser motivo de discusión a ser algo que el equipo diagnostica en conjunto.

Esto también cambia cómo se interactúa con el soporte. En vez de abrir un ticket que dice “el sitio está lento”, se abre uno que dice “el slowdown está en la API de nuestro proveedor de emails, no en el servidor”. A continuación, un recorrido práctico por las herramientas de MyKinsta, qué muestra cada una y cómo usarlas como flujo de trabajo compartido.

Empezar por lo básico: ¿está roto o solo lento?

Lo primero es determinar de qué tipo de problema se trata. Un sitio lento, uno roto y uno sobrecargado piden respuestas distintas. Confundirlos es el punto donde empiezan las charlas de culpas.

En MyKinsta, la sección Analytics es el punto de partida. Para un sitio específico vas a Sites > nombre-del-sitio > Analytics. Los reportes son idénticos tanto si los mirás desde nivel compañía como desde un sitio individual, siempre que tengas acceso a analytics.

La pestaña Response responde la pregunta clave. Su gráfico central muestra la distribución de códigos HTTP. Un pico de 5xx indica problema del servidor o de la aplicación. Un pico de 4xx señala problemas de acceso a recursos. Los gráficos complementarios de Response Time y Error Rate permiten profundizar.

Cuando todos los involucrados ven el mismo breakdown, se puede trabajar directamente sobre la falla concreta en vez de debatir.

Performance: separar lentitud de errores

Un sitio que carga en seis segundos y uno que devuelve 500 errors se sienten parecidos para el visitante frustrado, pero tienen causas completamente distintas. La pestaña Performance es donde se separan.

Los reportes más útiles son:

• Tiempo promedio de respuesta
• Tiempo de respuesta por URL
• Uso de PHP y de base de datos

Juntos, te dicen si el próximo paso es optimizar la aplicación o escalar un incidente de infraestructura.

Cache: la causa más común de “¿es el hosting?”

Muchos sitios se sienten lentos por una razón que nada tiene que ver con código ni con el servidor: muy poco se sirve desde caché. Cuando el ratio de caché cae, el servidor procesa requests que no debería, y suben los tiempos de respuesta.

La sección Cache muestra cómo se resuelven los pedidos en las capas de caché de Kinsta. Cada request termina en uno de tres estados: HIT, MISS o BYPASS.

Un sitio sano tiene el gráfico fuertemente inclinado hacia HITs. Cuando sube el BYPASS, el reporte “Top server cache bypasses” nombra las rutas específicas que están saltando la caché. Algunos bypass son normales (el login de WordPress nunca se cachea). Pero si una página que debería cachearse aparece ahí, es señal de conflicto de plugin o regla de caché mal configurada.

Mirar estos reportes mientras se carga una página lenta permite ver si realmente está cacheada, en vez de asumir que el hosting es el culpable.

Top requests y recursos: identificar picos sin errores

Cuando un sitio no devuelve errores pero consume más ancho de banda o capacidad de la esperada, la clave está en el reporte Top requests. Los picos de recursos son los más difíciles de ubicar porque suelen no generar códigos de error.

Tres reportes convierten la adivinanza en nombres concretos:

• Top requests by bandwidth
• Top slowest requests
• Top requests by volume

Juntos revelan si el pico viene de un archivo multimedia pesado, un endpoint descontrolado o un crawler que golpea la misma ruta miles de veces. Desde ahí, la solución suele ser optimizar el asset, pasarlo por CDN o corregir el endpoint.

Si el responsable es tráfico de bots, la herramienta Bot Protection de Kinsta permite identificarlos, clasificarlos y bloquearlos directamente desde MyKinsta sin instalar plugins ni abrir tickets.

APM: entender el porqué, no solo el qué

Los reportes de Analytics te dicen qué está pasando. La herramienta APM (Application Performance Monitoring) te dice por qué. Donde Analytics muestra que el tiempo de respuesta PHP subió a las 14 hs, APM muestra qué función de plugin, query de base de datos o llamada a API externa fue la responsable.

APM viene incluido en todos los planes de Kinsta y se ejecuta dentro de MyKinsta. A diferencia del dashboard de Analytics que corre en segundo plano, el agente APM agrega carga de CPU y memoria, por eso Kinsta recomienda activarlo solo mientras se está diagnosticando activamente.

Para iniciar una sesión: Sites > nombre-del-sitio > APM > Enable APM y elegís una ventana de monitoreo (2, 4, 12 o 24 horas). Se desactiva solo al terminar.

Los datos se organizan en cuatro pestañas: Transactions, WordPress, Database y External. Empezá por Transactions para encontrar las requests más lentas. Al hacer clic en una, se abre una línea de tiempo que marca los spans más pesados. La pestaña External es especialmente útil para descartar al hosting: si la demora viene de una API externa, queda explícito en los datos.

Logs y Activity Log: reconstruir la línea de tiempo

Resolver un incidente suele depender de saber qué pasó y en qué orden. Dos registros ayudan a reconstruirlo:

El Log viewer muestra lo que el sitio reporta (no cómo performa). Tenés disponible error.log, kinsta-cache.log y access.log. El visor integrado carga hasta 20.000 líneas y tiene campo de búsqueda. También podés descargarlos vía File Manager.

El Activity Log registra cada acción realizada en MyKinsta por cualquier usuario. Se encuentra en Sites > nombre-del-sitio > User activity. Cada entrada muestra la acción en lenguaje claro, quién la hizo, timestamp y un ícono de éxito o fracaso. Al combinarlo con el error.log en la misma ventana temporal, es fácil ver qué cambios humanos coincidieron con los errores.

Monitoreo de uptime y alertas preventivas

Todas las herramientas anteriores son reactivas. El monitoreo de uptime las vuelve proactivas. Kinsta chequea cada sitio unas 480 veces por día. Con las notificaciones activadas en User Settings > Notifications, recibís email después de tres chequeos fallidos consecutivos, lo que filtra falsos positivos.

Además, las alertas de límites del plan avisan cuando estás cerca de consumir los recursos contratados. Eso te permite investigar con los analytics si el motivo fue una campaña que generó más tráfico del previsto o actividad de bots.

Convertir la visibilidad en rutina

Un sitio roto cuesta más tiempo en discutir responsabilidades que en arreglarlo. Con los reportes de MyKinsta, todos pueden ver si el problema es lentitud, errores o sobrecarga. Combinando APM, logs, activity log y monitoreo, el equipo se entera del problema al mismo tiempo que el hosting y puede ponerse a trabajar sin esperar en una cola de tickets.

La recomendación práctica es acordar de antemano qué reportes se van a mirar cuando algo falla y asegurarse de que todos los roles tengan acceso a analytics. De esa forma, la conversación se mantiene como diagnóstico y no se transforma en discusión.

Si administrás sitios donde varios equipos comparten responsabilidad, el hosting administrado de Kinsta pone a cada uno en la misma mesa de diagnóstico. Para quienes manejan decenas de clientes, el programa Agency Partner agrega herramientas de acceso compartido y co-gestión que facilitan exactamente este flujo de trabajo.

Fuente original (julio 2026).