Mi WordPress falla a veces: cómo investigar una incidencia intermitente

Un cliente dice que no puede abrir una página, pero cuando la revisas funciona. El botón responde unas veces y otras se queda esperando. Estos fallos son difíciles de resolver porque el estado que ve soporte puede ser distinto del que produjo la incidencia. «Ahora funciona» es una observación útil, pero no demuestra que el problema haya desaparecido.

Esta guía propone un seguimiento para responsables de pequeñas empresas: conservar evidencias, comparar situaciones y acordar qué comprobar. No exige instalar herramientas ni modificar WordPress. Si la web está completamente bloqueada, avisa por el canal de soporte acordado sin esperar a reunir una serie de pruebas.

Registra también los intentos que sí funcionan

Para un primer aviso basta con la información básica de una incidencia web. Cuando el fallo reaparece, lo que aporta valor es una pequeña cronología, no enviar de nuevo el mismo «sigue fallando».

Anota fecha, hora y zona horaria; página y acción; dispositivo, navegador y sesión iniciada o no; resultado observado. Añade si acababas de volver a la pestaña después de un rato o si era la primera visita. Registra también un intento correcto cercano en el tiempo, si se produjo de forma natural. No hace falta provocar diez fallos para demostrar que existe uno.

Ejemplo hipotético: a las 10:15, desde un móvil sin sesión, abrir una ficha deja el indicador de carga activo; a las 10:18, desde el ordenador identificado, la misma ficha abre. Esto no prueba que el móvil sea la causa. Sí permite preguntar si la diferencia depende del navegador, la sesión, la conexión o el momento.

Cambia una condición cada vez, si la prueba no tiene efectos reales

Si soporte pide una comparación, acordad primero qué se mantiene y qué se cambia. Probar otro navegador, otra conexión y otra cuenta a la vez puede confirmar que hay un recorrido que funciona, pero no permite saber qué diferencia importa.

Para una página pública de consulta, puede ser útil comparar la misma dirección en el mismo dispositivo con otro navegador. Para un pedido, una reserva o un formulario, no repitas operaciones sin comprobar qué ha quedado registrado. Un mensaje que no termina de cargar no demuestra que el servidor no haya recibido la solicitud. Antes de reintentar un pago, hay que contrastar su estado por el procedimiento adecuado.

No borres toda la caché ni cierres la sesión como primer paso automático: podrías eliminar las condiciones que permiten estudiar el fallo. Si el técnico propone hacerlo, registra el antes y el después. Una mejoría tras vaciar caché es una pista; no demuestra por sí sola la causa ni que el problema no vaya a volver.

Distingue observación, hipótesis y cambio aplicado

Mantén estas tres cosas separadas en el hilo de soporte:

• Observación: el selector no terminó de cargar en una ocasión identificada.
• Hipótesis: podría existir una diferencia entre visitantes identificados y anónimos.
• Intervención: se ajustó una configuración concreta a una hora conocida.

No conviertas una coincidencia horaria en un diagnóstico. Si se actualizan plugins, se cambia la caché y se reinicia el alojamiento a la vez, será más difícil determinar qué ayudó. Pide una secuencia de actuaciones y quién se responsabiliza de cada una. La urgencia puede justificar una medida de contención, pero conviene distinguirla de la corrección definitiva.

Qué puede necesitar el técnico para correlacionar el fallo

La hora del intento permite buscar registros de aplicación o servidor correspondientes al mismo intervalo. Hay que comprobar las zonas horarias y no confundir un aviso antiguo con el incidente actual. Un error de una petición tampoco significa necesariamente que toda la web estuviera caída.

La documentación de WordPress sobre diagnóstico describe el registro de errores y desaconseja utilizar estas herramientas en sitios en vivo como práctica habitual. Deja su configuración al responsable técnico, con las precauciones de copia y entorno de pruebas. No actives mensajes de error visibles para todos los visitantes ni publiques registros completos.

En determinados fallos, el técnico puede pedir una captura del tráfico del navegador. Chrome DevTools permite conservar peticiones entre cargas y exportarlas en formato HAR. Es información técnica, no un requisito para que te atiendan. Incluso una exportación marcada como saneada necesita revisión: eliminar ciertas cabeceras sensibles no garantiza que direcciones, parámetros o contenidos estén libres de información privada. Comparte solo lo necesario por un canal acordado, nunca en un enlace público.

Acuerda una ventana de observación que tenga sentido

Una incidencia que aparecía al comenzar la jornada no queda descartada porque una prueba al mediodía salga bien. Propón comprobar el recorrido en las condiciones en las que se observó, sin automatizar acciones comerciales ni hacer cobros reales.

La duración del seguimiento depende de la frecuencia conocida y del impacto. No existe un número universal de horas que certifique la reparación. Dejad por escrito:

1. Qué acción se ha corregido o qué medida temporal se ha aplicado.
2. Qué prueba controlada ha pasado y en qué entorno.
3. Quién observará las siguientes ocurrencias y dónde se comunicarán.
4. Qué evidencia se recogerá si reaparece, sin datos privados innecesarios.
5. Cuándo se revisará el caso y qué queda pendiente.

Si no se ha podido reproducir, ese debe ser el estado: no reproducido durante las comprobaciones, no «solucionado» sin más. Si deja de aparecer durante el seguimiento acordado, registra ese resultado sin prometer que nunca volverá.

Un responsable para seguir el problema hasta su cierre

Cuando intervienen alojamiento, un plugin y una integración externa, el negocio necesita saber quién coordina las respuestas. Un único historial evita repetir pruebas ya realizadas y perder el momento exacto de una intervención.

Nuestro mantenimiento WordPress permite organizar soporte y cambios dentro del alcance y las horas del plan. Cuéntanos qué función falla, con qué frecuencia lo has observado y qué afecta a tu actividad. Si la investigación o la corrección requiere un trabajo adicional, se valora antes de ejecutarlo. El objetivo no es acumular capturas, sino convertir un fallo difícil de reproducir en una secuencia de hechos sobre la que se pueda actuar.