Guía para decidir mejor
Cómo interpretar los registros de acceso y error del servidor
Une la petición del visitante con el error correspondiente y conserva evidencia.
Los registros de acceso y error del servidor cuentan historias distintas. El de acceso indica qué URL se pidió, cuándo, desde dónde y con qué respuesta; el de error ayuda a explicar por qué falló una petición. Leerlos juntos permite localizar un 500, un 404 tras migrar o un pico de tráfico sin culpar automáticamente a WordPress o al hosting.
Prepara una pregunta y una hora concreta
Define el síntoma: «el formulario dio 500 a las 12:04», «el checkout tardó 15 segundos» o «/producto/ devolvió 404». Anota zona horaria, dominio y ruta; convierte las horas si el panel guarda UTC. Pide acceso autorizado y conserva una copia breve del tramo relevante. Los logs pueden contener IP, URL con parámetros, agentes e incluso identificadores; trátalos como datos sensibles, evita publicarlos íntegros y aplica la retención que corresponda.
Qué mirar en el registro de acceso
Localiza la solicitud y observa método, ruta, código HTTP, duración si el formato la incluye, tamaño y origen. Un 301/302 indica redirección, un 403 denegación, un 404 ausencia de ruta, un 500 fallo interno y un 503 servicio temporalmente no disponible; el código no identifica por sí solo la capa responsable. Si hay CDN o proxy, el origen puede registrar la IP del intermediario; no uses esa columna para bloquear tráfico sin conocer los encabezados confiables. Agrupa por ruta e intervalo para distinguir un pico de bots de una campaña legítima.
Relaciona con el registro de error
Busca la misma hora y, cuando exista, identificador de solicitud. Un permission denied apunta a acceso de archivos o configuración; un fatal PHP puede aparecer en el registro PHP, no en el acceso; un timeout del proxy puede indicar que el origen tardó o no respondió. Revisa también logs de WAF, PHP-FPM y base si el error de servidor solo muestra el síntoma. La guía del registro WordPress cubre la capa de aplicación.
Ejemplo: el acceso muestra 503 solo en /checkout/ durante una promoción y el log de PHP-FPM informa de procesos máximos. Investiga concurrencia y trabajo de esa ruta antes de aumentar CPU; la guía de procesos PHP explica el siguiente paso. Otro caso: un 404 del servidor para todas las rutas interiores tras migrar apunta a reescritura y no a contenidos borrados.
Conserva evidencia y verifica el cambio
Registra hipótesis, prueba aplicada y resultado con la misma URL y hora. No borres ni alteres logs originales para «limpiar» una incidencia; rota y protege según política. Tras corregir, confirma que el código y duración volvieron a lo esperado y que no aparecieron bloqueos de usuarios reales. Si usas ese panel, consulta dónde leer los logs en Plesk. Para soporte, envía un extracto saneado con intervalo y código, nunca contraseñas ni URLs con tokens. La revisión tras migrar indica qué rutas conviene muestrear.