Cuando algo falla en un sitio, la mayoría de la gente hace lo mismo: recarga, prueba en otro navegador, desactiva plugins a ciegas y termina abriendo un ticket que dice "no anda". Mientras tanto, en el servidor hay un archivo que registró exactamente qué pasó, a qué hora, quién lo provocó y con qué error. Aprender a leerlo cambia por completo la forma de resolver problemas: se pasa de adivinar a saber.
Los dos registros que importan
Todo servidor web mantiene al menos dos archivos de registro. El registro de accesos anota cada pedido que llega, haya salido bien o mal. El registro de errores anota únicamente lo que falló, con el detalle técnico de por qué.
La regla práctica es simple: si el sitio se ve roto o tira error 500, empezá por el de errores. Si querés entender de dónde viene el tráfico, por qué el servidor está lento o quién está intentando entrar, empezá por el de accesos.
Dónde encontrarlos
En un hosting con cPanel hay tres caminos. El primero es la sección de métricas del panel, que suele ofrecer un visor de errores recientes y la descarga de los registros crudos. El segundo es el administrador de archivos, buscando una carpeta de logs dentro del directorio de la cuenta. El tercero, si tenés acceso por línea de comandos, es leer el archivo directamente.
Además, WordPress puede llevar su propio registro si lo activás. Es útil porque anota los errores de PHP con el archivo y la línea exacta, algo que el registro general del servidor a veces no detalla.
Anatomía de una línea del registro de accesos
Una línea típica se ve así, más o menos:
190.55.12.4 - - [17/Aug/2026:14:22:31 -0300] "GET /blog/mi-articulo/ HTTP/1.1" 200 45213 "https://google.com/" "Mozilla/5.0..."
De izquierda a derecha: la dirección de quien pidió, la fecha y hora con la zona horaria, el método y la ruta pedida, el código de respuesta, cuántos bytes se enviaron, desde qué página venía y con qué navegador o robot.
De todos esos campos, el que resuelve más problemas es el código de respuesta. Un 200 significa que salió bien. Un 404 que el recurso no existe. Un 301 o 302 que hubo una redirección. Un 403 que el servidor se negó por permisos. Un 500 que algo explotó del lado del servidor. Y un 503 que el servicio no estaba disponible, típicamente por sobrecarga.
Cómo buscar sin ahogarte
Un registro de accesos de un sitio con tráfico moderado tiene decenas de miles de líneas por día. Abrirlo entero no sirve de nada. La técnica es filtrar.
Si tenés acceso por línea de comandos, buscar todas las líneas que contengan un código de error concreto te deja solo los casos relevantes. Contar cuántas veces aparece cada dirección te muestra al instante si hay alguien golpeando el servidor. Y filtrar por una ruta específica te dice si el problema afecta a una sola página o a todo el sitio.
Si solo tenés el panel, descargá el registro y abrilo con un editor de texto que soporte archivos grandes, usando la búsqueda para el mismo fin. No lo abras con una planilla de cálculo: se va a colgar.
Los patrones que vas a reconocer enseguida
El escaneo automatizado. Cientos de 404 seguidos desde la misma dirección, pidiendo rutas que nunca existieron: paneles de administración de otros gestores, archivos de configuración, copias de bases de datos con nombres genéricos. Es un robot probando puertas. Molesto, pero normal en internet.
La fuerza bruta. Muchísimos pedidos a la página de acceso, casi siempre por método POST, desde una o varias direcciones. Si ves esto, es hora de limitar los intentos y activar segundo factor.
El enlace roto interno. Un 404 que se repite y cuyo campo de procedencia apunta a una página tuya. Eso significa que vos mismo estás enlazando a algo que no existe. Es de los hallazgos más útiles: se arregla en un minuto y mejora la experiencia real.
El robot que te está comiendo el servidor. Un navegador identificado como robot pidiendo miles de páginas por hora. Puede ser un buscador legítimo rastreando demasiado rápido, o un raspador copiando tu contenido. En el primer caso se ajusta la velocidad de rastreo; en el segundo, se bloquea.
El registro de errores, que es donde está la respuesta
Este archivo es más corto y mucho más denso. Cada línea suele traer la fecha, el nivel de gravedad, el mensaje y, si es un error de PHP, el archivo y el número de línea donde ocurrió.
Ese último dato es oro puro. Cuando el sitio muestra una pantalla en blanco y el registro dice que hubo un error fatal en un archivo de un plugin concreto, en la línea 314, ya sabés qué desactivar. Sin el registro, estarías apagando plugins uno por uno durante media hora.
Los mensajes más comunes y lo que significan de verdad: que se agotó la memoria permitida quiere decir que hay que subir el límite de memoria o encontrar qué lo consume. Que se excedió el tiempo máximo de ejecución significa que un proceso tarda más de lo permitido. Que no se puede abrir un archivo suele ser un problema de permisos o una ruta mal escrita. Y un error de sintaxis casi siempre viene de una edición manual reciente.
Distinguir advertencias de problemas reales
Un registro de errores sano igual tiene ruido. Vas a ver avisos de funciones obsoletas, notas sobre variables no definidas y advertencias de plugins viejos. Nada de eso rompe el sitio.
Lo que importa son los errores fatales, que detienen la ejecución, y los mensajes que se repiten cientos de veces, porque aunque sean solo avisos, escribir en el registro también consume tiempo y disco. Un plugin que genera diez mil advertencias por hora está afectando tu rendimiento aunque el sitio se vea bien.
Una rutina de diagnóstico que funciona
Cuando algo falla, seguí este orden. Primero, reproducí el problema y anotá la hora exacta. Segundo, abrí el registro de errores y buscá esa hora: la causa suele estar ahí, literalmente escrita. Tercero, si el registro de errores no dice nada, mirá el de accesos y fijate qué código devolvió ese pedido, porque eso te indica en qué capa está el problema. Cuarto, si el código es 500 pero el registro está vacío, revisá el archivo de reglas del servidor, que es la causa más frecuente de un 500 silencioso.
Con esos cuatro pasos se resuelve la enorme mayoría de los incidentes sin tocar nada a ciegas.
Un consejo sobre el soporte técnico
Si después de leer los registros necesitás abrir un ticket, pegá las líneas relevantes en el mensaje. La diferencia entre "mi sitio no anda" y "recibo un error fatal en tal archivo, línea 314, a las 14:22" es enorme: el primero genera tres idas y vueltas antes de que alguien mire algo, el segundo se resuelve en la primera respuesta.
Vale la pena, además, elegir un hosting donde los registros sean accesibles sin pedir permiso. En BanaHosting los tenés desde el propio panel, con el visor de errores y la descarga de los registros crudos, así que podés hacer este diagnóstico vos mismo a la hora que sea, sin depender de que alguien te los mande.