¿Cómo detectar problemas en WordPress antes de que los clientes los señalen?

Muchas empresas descubren que su web tiene un problema de la peor manera posible: un cliente escribe para decir que el checkout no funciona, un formulario de contacto lleva una semana sin enviar nada o la web muestra un aviso de seguridad.

Para entonces, el problema puede llevar horas o días ahí. Se han perdido pedidos, las consultas se han quedado sin respuesta y los clientes ya se han formado una impresión.

La mayoría de estos problemas pueden detectarse antes. La monitorización no evita todos los fallos, pero acorta el tiempo entre el momento en que algo se rompe y el momento en que alguien se entera.

Esta guía explica los principales tipos de monitorización para una web WordPress, qué detecta cada uno, qué se le escapa y cómo decidir quién recibe las alertas y qué debe hacer con ellas.

¿Por qué pasan desapercibidos los problemas?

Una web puede estar parcialmente rota y, aun así, parecer correcta para quienes la gestionan.

Por ejemplo:

• la página de inicio carga, pero el checkout falla en el paso del pago
• el formulario de contacto parece enviarse, pero los emails nunca llegan
• la web va rápida en la oficina, pero lenta para los visitantes de otros lugares
• la actualización de un plugin ha provocado errores solo en algunas páginas
• el certificado SSL caduca en fin de semana
• una página hackeada muestra spam solo a quienes llegan desde Google

Los propietarios y el personal no suelen visitar todas las páginas ni hacer pedidos de prueba a diario. Sin algún tipo de monitorización, la primera persona en darse cuenta suele ser un cliente.

¿Qué conviene monitorizar?

Cada comprobación detecta problemas distintos. Ninguna herramienta lo cubre todo.

Monitorización de disponibilidad

Un monitor de disponibilidad (uptime) visita su web a intervalos regulares y le avisa si no responde o si responde con un error.

Es la forma más básica de monitorización y detecta:

• la web completamente caída
• errores del servidor
• caídas del hosting
• problemas de DNS

Sus límites: la mayoría de monitores de disponibilidad solo comprueban una página, normalmente la de inicio. Una web puede responder con normalidad ahí y estar rota en otras partes. Algunos monitores también pueden comprobar que una palabra concreta aparece en la página, lo que ayuda a detectar páginas en blanco o de error que, aun así, devuelven una respuesta normal.

Alertas de caducidad del certificado SSL y del dominio

Un certificado SSL caducado hace que los navegadores muestren un aviso de seguridad en lugar de su web. Un dominio caducado puede dejar sin servicio toda la web y el correo electrónico.

Ambas cosas son totalmente previsibles. Unas alertas unas semanas antes de la caducidad dan tiempo de sobra para actuar.

Muchos certificados se renuevan automáticamente, pero la renovación automática puede fallar, por ejemplo después de un cambio de DNS o de un cambio de hosting. La renovación del dominio depende a menudo de una tarjeta de pago que puede haber caducado. Merece la pena conocer ambas fechas y saber quién recibe los emails de renovación.

Monitorización de los logs de errores

WordPress y PHP pueden escribir los errores en archivos de log del servidor. Un aumento repentino de errores suele aparecer antes de que los visitantes noten algo evidente.

Revisar los logs con regularidad, o usar una herramienta que avise de nuevos errores graves, permite detectar:

• conflictos entre plugins después de las actualizaciones
• código que dejó de funcionar tras un cambio de versión de PHP
• errores de base de datos
• problemas de memoria

Los logs necesitan a alguien que sepa leerlos. También pueden contener información sensible, por lo que el acceso debe estar limitado.

Pruebas del checkout y de los formularios

Para muchas empresas, las funciones más importantes no están en la página de inicio. Son el checkout, el formulario de reservas o el formulario de contacto.

Se pueden probar así:

• haciendo un pedido de prueba con regularidad, con un método de pago de prueba siempre que sea posible
• enviando el formulario de contacto y comprobando que el email llega
• usando una herramienta de monitorización capaz de seguir varios pasos, como añadir al carrito y llegar al checkout
• comprobando que los emails de notificación de pedidos y formularios siguen llegando

Incluso una simple prueba manual periódica, anotada cada vez, es mucho mejor que nada.

Monitorización del rendimiento

Es raro que una web pase de rápida a rota de golpe. A menudo primero se vuelve más lenta.

La monitorización del rendimiento puede controlar:

• cuánto tardan en responder las páginas
• los cambios después de actualizaciones o de nuevos plugins
• las ralentizaciones en determinadas horas del día

Las ralentizaciones graduales son fáciles de pasar por alto día a día y fáciles de ver a lo largo de semanas.

Alertas de seguridad

La monitorización de seguridad puede incluir:

• alertas cuando los archivos del núcleo de WordPress cambian de forma inesperada
• notificaciones de nuevas cuentas de administrador
• avisos sobre plugins con vulnerabilidades conocidas
• análisis de malware
• alertas de un firewall o de un servicio de seguridad

Estas alertas deben llegar a alguien capaz de valorar si son reales y de actuar con rapidez si lo son.

Emails de Google Search Console

Google Search Console envía emails sobre los problemas que detecta, como problemas de seguridad, acciones manuales, problemas de indexación y páginas que no puede rastrear.

Es fácil ignorar estos emails porque a menudo parecen rutinarios. Algunos, como las notificaciones de problemas de seguridad, son importantes y urgentes.

Asegúrese de que Search Console está configurado para su web y de que sus emails llegan a alguien que los lee.

¿Quién debe recibir las alertas y qué debe hacer?

La monitorización solo sirve si las alertas llegan a la persona adecuada y esa persona sabe qué hacer.

Entre los problemas habituales están:

• alertas enviadas a un antiguo empleado o a un desarrollador con el que ya no se trabaja
• todas las alertas enviadas a un buzón compartido que nadie mira
• tantas alertas que la gente deja de leerlas
• alertas que llegan a alguien que no puede hacer nada con ellas

Una forma sencilla de organizarlo es decidir, para cada tipo de alerta:

• quién la recibe
• quién es el suplente si esa persona no está disponible
• cuál es la primera acción
• a quién contactar si no se puede resolver

Por ejemplo, el propietario de la empresa puede recibir las alertas de disponibilidad y de checkout para saber que algo va mal, mientras que un partner técnico recibe esas mismas alertas más los logs de errores y los avisos de seguridad para poder investigar.

Mantenga un número de alertas manejable. Es mejor monitorizar bien unas pocas cosas importantes que recibir decenas de mensajes que nadie lee.

¿Cómo decidir cuánta monitorización necesita?

Empiece por lo que más perjudicaría a la empresa si se rompiera sin que nadie se diera cuenta.

Webs corporativas

La monitorización de disponibilidad, las alertas de caducidad del SSL y del dominio, Search Console y una prueba periódica del formulario de contacto suelen ser una buena base.

Webs con reservas, áreas de socios o captación de contactos

Añada pruebas periódicas de los formularios y de los flujos de reserva, y compruebe que llegan los emails de notificación. Añada alertas de seguridad si los usuarios tienen cuentas.

Tiendas WooCommerce

Añada pruebas del checkout, comprobaciones de las notificaciones de pago, monitorización del rendimiento y revisión de los logs de errores. Los problemas del checkout cuestan dinero por cada hora que pasan desapercibidos.

¿Cuáles son los errores más comunes?

• Monitorizar solo la página de inicio. Las páginas más importantes suelen estar en otra parte.
• Alertas que llegan a la persona equivocada. Revise los destinatarios de las alertas cada vez que cambien las personas o los proveedores.
• Demasiadas alertas. El ruido hace que se ignoren las alertas reales.
• Ningún plan para lo que viene después. Una alerta sin responsable es solo una notificación.
• Dar por hecho que el proveedor de hosting está vigilando. La monitorización del hosting suele cubrir el servidor, no su checkout ni sus formularios.
• No probar nunca las alertas. Un sistema de alertas que nunca se ha activado puede no estar funcionando.

¿Cómo es una buena configuración?

Una configuración de monitorización práctica suele incluir:

• comprobaciones de disponibilidad en la página de inicio y en una o dos páginas clave
• recordatorios de caducidad del SSL y del dominio con mucha antelación
• pruebas periódicas del checkout y de los formularios
• logs de errores revisados por alguien que los entienda
• alertas de seguridad que llegan a alguien que puede actuar
• Search Console verificado, con emails que llegan a una persona real
• una breve lista por escrito de quién recibe qué y qué debe hacer

Cómo puede ayudarle D4Hub

D4Hub puede ayudarle a crear una monitorización adaptada a su web sin inundarle de alertas.

Según sus necesidades, D4Hub puede ayudarle a:

• elegir qué páginas y funciones monitorizar
• configurar las comprobaciones de disponibilidad, SSL y caducidad del dominio
• revisar los logs de errores e identificar problemas recurrentes
• probar el checkout, los formularios y los emails de notificación
• revisar las alertas de seguridad y las notificaciones de Search Console
• decidir quién recibe cada alerta y cuál debe ser la respuesta
• incluir la monitorización y las comprobaciones periódicas en los planes de soporte de D4Hub

Puede solicitar ayuda en cualquier momento, tanto si necesita configurar la monitorización como si debe reaccionar a una alerta que acaba de recibir.

curl -s -o /dev/null -w "%{http_code}" https://www.example.com/

#!/bin/sh
URL="https://www.example.com/"
CODE=$(curl -s -L -o /dev/null -w "%{http_code}" --max-time 30 "$URL")
if [ "$CODE" != "200" ]; then
  echo "$(date) $URL returned $CODE" >> "$HOME/site-check.log"
fi

*/15 * * * * /path/to/check-site.sh

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -enddate

echo | openssl s_client -servername www.example.com -connect www.example.com:443 2>/dev/null | openssl x509 -noout -checkend 2592000

wp core verify-checksums

Preguntas frecuentes

¿Basta con la monitorización de disponibilidad?

Es un buen comienzo, pero solo le dice si una página responde. No le dirá que el checkout falla, que un formulario ha dejado de enviar emails o que una página ha sido hackeada. Combínela con pruebas de sus funciones clave.

¿Mi proveedor de hosting monitoriza mi web?

La mayoría de los proveedores de hosting monitorizan sus servidores y su infraestructura. Eso no es lo mismo que monitorizar el checkout, los formularios o el contenido de su web. Pregunte a su proveedor qué monitoriza y si le avisa.

¿Con qué frecuencia conviene probar los formularios y el checkout?

Depende de lo importantes que sean. Para una tienda con mucho tráfico o una web de captación de contactos, lo sensato son pruebas programadas periódicas y una prueba después de cada actualización. Para un formulario de contacto sencillo, puede bastar con una comprobación periódica y una prueba después de las actualizaciones.

¿La monitorización ralentizará mi web?

Las comprobaciones externas, como los monitores de disponibilidad, hacen una pequeña petición a intervalos, similar a la de un visitante normal. Algunos plugins de seguridad y rendimiento se ejecutan dentro de WordPress y pueden añadir carga, así que conviene elegir las herramientas con cuidado.

¿Qué debo hacer cuando recibo una alerta?

Primero, compruebe si el problema es real visitando usted mismo la web, a ser posible en una ventana privada del navegador. Si lo es, anote la hora y lo que ve, evite hacer varios cambios a la vez y contacte con quien se encargue de la web. La guía sobre qué hacer cuando una web WordPress está caída puede ayudarle con los primeros pasos.

¿Puede D4Hub recibir las alertas de mi web?

D4Hub puede ayudarle a decidir cómo gestionar las alertas, incluido si un partner técnico debe recibirlas junto con su equipo. Esto puede tratarse como parte del soporte continuado.