Si la web acaba de dejar de funcionar, no empieces escribiendo a nadie. Empieza por diez minutos que convierten un aviso de «la web no funciona» en un reporte al que se puede responder con algo concreto. Este centro te guía por ese triaje, te enseña dónde están los logs y qué buscar en ellos, dice exactamente qué enviar y describe qué ocurre por nuestra parte al recibir el mensaje. Si tienes más prisa que ganas de leer, baja a la sección «Qué enviar en el reporte» y copia la lista.
Antes de escribir: diez minutos de triaje
Cuatro preguntas, en este orden. Sus respuestas suelen señalar la causa más rápido que cualquier herramienta.
Qué es exactamente lo que falla. ¿Toda la web, una sola página o solo el panel de administración? Abre la dirección en una ventana privada y desde otra conexión, por ejemplo en el móvil con datos móviles. Si en la ventana privada la web funciona, el problema está en la caché del navegador o en tu sesión, no en el servidor. Si funciona en el móvil pero no en la oficina, revisa el DNS y el firewall de tu lado antes de que nadie empiece a hurgar en WordPress.
Cuál es el mensaje exacto. «No funciona» son cinco fallos distintos. La pantalla en blanco suele ser un error de PHP con la visualización de errores desactivada. El error 500 es un error del servidor, casi siempre un plugin, el tema o el límite de memoria. «Error establishing a database connection» es la base de datos, o sea un camino completamente distinto. Un error 403 al iniciar sesión suele ser una regla de seguridad, no una avería. Anota el código y el texto completo, incluido el número de línea si aparece.
Qué cambió justo antes. Los fallos rara vez llegan solos. Actualización de un plugin, actualización del núcleo, cambio de versión de PHP por parte del alojamiento, caducidad de un certificado, cambio de un registro DNS, fin de la vigencia del dominio, límite del alojamiento superado. La fecha y la hora del último cambio suelen ser el dato más valioso de todo el reporte.
Si tienes copia de seguridad. No la restaures por reflejo, pero confirma que existe y de cuándo es. Si el alojamiento hace copias nocturnas, mira en el panel cuándo fue la última. Ese dato decide si la reparación es arriesgada o reversible.
Mensaje de error, capa, primera acción
Esta tabla acorta la etapa más larga de cualquier incidencia, que es adivinar dónde hay que mirar siquiera.
| Qué ves | Capa más probable | Primera acción |
|---|---|---|
| Pantalla completamente en blanco | PHP, error crítico con el mensaje oculto | Activa el registro de errores en un archivo y recarga la web |
| HTTP 500 | Servidor web o PHP | Lee el error_log del directorio de la web |
| HTTP 502 o 504 | PHP-FPM, timeout, API externa | Revisa el tiempo de respuesta y los límites del proceso |
| Error establishing a database connection | Base de datos | Revisa las credenciales en wp-config.php y el estado del servicio MySQL |
HTTP 403 en /wp-admin | Regla de seguridad, firewall de aplicación | Revisa los logs del firewall y la lista de IP bloqueadas |
| La web tarda muchísimo en cargar | Base de datos, API externa, falta de caché | Mide el TTFB y compara el front con el panel |
| Redirección a un dominio ajeno | Infección o plugin sustituido | No borres archivos, asegura una copia como prueba |
| «Tu conexión no es privada» | Certificado TLS | Comprueba la fecha de validez del certificado |
| La web muestra la oferta del registrador | Dominio caducado | Comprueba la fecha de caducidad en la base whois |
La columna central importa más que la derecha. La mayor parte del tiempo perdido en una incidencia viene de reparar la capa equivocada: alguien desactiva plugins cuando el problema está en el DNS, o migra el alojamiento cuando la culpa es de un único plugin que consulta una API externa.
Dónde están los logs y qué buscar en ellos
Sin log, el diagnóstico es adivinar. Hay tres sitios, en este orden de utilidad.
Log de errores de PHP. En la mayoría de alojamientos compartidos está como error_log en el directorio de la web o en el panel, en la sección de logs. Buscas las últimas entradas PHP Fatal error de la hora del fallo. Una entrada así contiene el archivo y el número de línea, y eso suele señalar el plugin culpable en el primer segundo.
Log de WordPress. Si el alojamiento no da log de PHP, activa el tuyo. En wp-config.php, por encima de la línea con el comentario «That’s all, stop editing»:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Los errores irán a wp-content/debug.log y los visitantes no verán nada. Después del diagnóstico desactívalo y borra el archivo; un log dejado un mes en producción puede crecer hasta varios gigabytes y convertirse él mismo en la avería.
Log del servidor web. Nginx y Apache registran el acceso y los errores por separado. Te interesa el segundo, en la hora del suceso. En un alojamiento con acceso a la shell basta con tail -n 100 /ruta/a/logs/error.log. Si solo tienes panel, descarga el archivo y ábrelo en un editor de texto, no en una hoja de cálculo, porque las líneas largas quedarán cortadas.
Qué buscar en los tres: una marca de tiempo que coincida con el momento del fallo, la misma línea repetida (eso suele ser un bucle, no una casualidad) y el nombre de la carpeta de un plugin dentro de la ruta del archivo. Qué no hacer: no pegues en el reporte un archivo entero de diez mil líneas. Veinte líneas alrededor de la primera aparición del error valen más que el conjunto completo.
Los cuatro fallos más comunes y sus primeros auxilios
Los pasos siguientes son seguros, reversibles y no requieren un programador. Si alguno se sale de tu zona de comodidad, párate y escribe; una reparación interrumpida es más fácil de terminar que una reparación agravada.
Pantalla en blanco o error 500 tras una actualización. Primero desactiva el plugin actualizado en último lugar. Si no tienes acceso al panel, cambia el nombre de su carpeta en wp-content/plugins/ desde el gestor de archivos del alojamiento o por FTP; WordPress lo desactivará. Si eso no ayuda, cambia el nombre de toda la carpeta plugins por plugins-off, comprueba la web y restaura el nombre. Eso resuelve en un minuto si la culpa es de un plugin o del tema. Cuando tienes acceso a la línea de comandos, wp plugin deactivate --all hace lo mismo de forma más limpia y permite reactivar los plugins de uno en uno.
Web de repente lenta. Comprueba si lo lento es la carga de la web o el panel. Un panel lento con un front rápido suele ser la base de datos o una API externa, por ejemplo un plugin que consulta el servidor de licencias en cada visita. Un front lento con un panel rápido suele ser la caché, las imágenes o el alojamiento. Mide antes de optimizar: PageSpeed Insights muestra a la vez el resultado de laboratorio y los datos de usuarios reales de CrUX, y estos últimos importan más, porque describen lo que experimentan las personas y no una simulación. Aparte, comprueba el tiempo de respuesta del propio servidor, por ejemplo curl -o /dev/null -s -w "%{time_starttransfer}\n" https://tudominio.es/. Un resultado por encima de un segundo indica un problema del lado del servidor, no en las imágenes ni en los scripts.
No puedo iniciar sesión. Antes de considerarlo una avería, comprueba tres cosas: si un plugin de seguridad ha cambiado la dirección de acceso, si tu IP ha quedado bloqueada tras intentos fallidos y si el reloj del servidor se ha desajustado, porque eso rompe las sesiones. El restablecimiento de contraseña por formulario necesita que el correo funcione, así que si los mensajes no salen, no servirá. Salida de emergencia: wp user update admin --user_pass=NuevaClave desde la línea de comandos, o cambiar la contraseña directamente en la base de datos con la función MD5, que WordPress acepta en el primer inicio de sesión y sustituye de inmediato por su propio hash.
Sospecha de infección. Síntomas: redirecciones a un dominio ajeno solo desde los resultados de búsqueda, administradores nuevos que tú no creaste, un aviso en Search Console, spam en el contenido visible únicamente para Googlebot. Revisa la lista de usuarios con rol de administrador y las fechas de modificación de los archivos, por ejemplo find . -type f -mtime -7 -name "*.php", para ver qué ha cambiado en la última semana. No borres archivos ni restaures copias hasta determinar la fecha de la primera entrada; una copia de hace una semana suele contener ya el mismo agujero. Cambia las contraseñas, incluidas las de la base de datos y el FTP, y escríbenos indicando la infección.
Una incidencia en una tienda WooCommerce lleva otro orden
En una tienda, el reflejo de «desactiva todos los plugins» sale caro, porque junto con el diagnóstico desactiva los pagos, los envíos y las integraciones de almacén. El orden es el inverso al de una web de presentación.
Primero determina si entran pedidos. La lista de pedidos de la última hora responde a eso más rápido que cualquier log. Si entran y los clientes reportan problemas, el fallo está en las notificaciones o en el pago, no en la tienda en sí. Si no entra ninguno, revisa la página del carrito y la de finalización de compra en una ventana privada, porque ambas quedan fuera de la caché y se rompen de forma distinta al resto de la web.
Las notificaciones por correo son un fallo aparte, muy frecuente, que parece un fallo de la tienda. Comprueba si el correo sale siquiera y si no acaba en el spam del destinatario. Tres registros DNS lo deciden casi por completo: SPF, DKIM y DMARC. Si la tienda envía correo directamente desde el servidor del alojamiento sin esos registros, parte de los mensajes no llegará y ningún cambio en el plugin lo arreglará.
Si el fallo afecta a un solo método de pago, comprueba en el panel del proveedor si no ha caducado la clave de API o el certificado de la integración. Es la situación en la que la web funciona bien, los logs están limpios y las ventas están paradas, así que sin comprobarlo del lado del proveedor se pueden pasar horas buscando en el código propio.
Cuándo no se trata siquiera de un fallo de la web
Cuatro casos en los que WordPress es inocente y diagnosticar de su lado solo hace perder tiempo.
Dominio caducado. Síntoma: en lugar de la web se ve la oferta del registrador o una página vacía. Lo compruebas en la base whois, con una sola consulta, y ves la fecha de caducidad. La renovación suele funcionar en unos minutos, aunque en casos extremos el dominio entra en periodo de rescate y cuesta bastante más que una prórroga normal.
Un cambio de DNS que todavía no se ha propagado. Síntoma: parte de la gente ve la web nueva y parte la antigua. dig tudominio.es +short muestra a qué dirección apunta el dominio desde tu perspectiva. Los cambios se propagan según el valor del TTL, así que si alguien lo puso en un día, eso es lo que durará y no se puede acelerar desde la web.
Certificado caducado. Síntoma: aviso del navegador sobre una conexión no confiable. La fecha de validez la lees con openssl s_client -connect tudominio.es:443 2>/dev/null | openssl x509 -noout -dates. La renovación automática puede fallar cuando entretanto ha cambiado el DNS o se ha añadido una redirección que bloquea la verificación.
El alojamiento ha suspendido la cuenta. Síntoma: un mensaje del alojamiento en lugar de la web, a veces tras superar el límite de transferencia o tras una factura impagada. Aquí no hay nada que reparar en el código, solo una conversación con el alojamiento, pero después conviene revisar qué generó ese tráfico, porque con la misma frecuencia se trata de un bot y no de clientes.
Qué enviar en el reporte
Cuanto más de esta lista aportes desde el principio, menos rondas de preguntas y antes recibirás una respuesta de fondo en lugar de una petición de datos.
| Dato | Por qué hace falta |
|---|---|
| Dirección de la web y de la página concreta con el error | Reproducimos el problema en nuestro entorno antes de cambiar nada |
| Nombre del alojamiento y tipo de cuenta | Los límites, la versión de PHP y el acceso a los logs varían entre alojamientos |
| Fecha y hora del fallo | Permite localizar el evento en los logs del servidor |
| Texto exacto del error | El código y el mensaje indican la capa: PHP, base de datos, servidor web, red |
| Veinte líneas de log alrededor del error | Acorta el diagnóstico más que cualquier descripción escrita |
| Último cambio antes del fallo | La causa más frecuente y la vía más rápida para revertir |
| Quién más tiene acceso | Descarta que dos personas trabajen a la vez sobre la misma web |
| Si existe copia y de cuándo | Decide si la reparación es reversible |
| Si las ventas están paradas | Fija el orden de los trabajos antes de empezar |
Lo que no hay que enviar en el primer mensaje: contraseñas. Los accesos se acuerdan después del alcance y preferiblemente como una cuenta de administrador aparte que borras al terminar los trabajos. Si el asunto es urgente, dilo con claridad e indica qué significa urgente en tu caso: que la tienda no acepte pedidos no es lo mismo que un formulario de contacto que envía dos veces.
Qué ocurre por nuestra parte
El reporte llega a una sola persona, no a una cola de primera línea, así que no explicas el caso dos veces. La primera respuesta contiene lo que hemos podido deducir de tu descripción y una pregunta solo por lo que realmente falta.
Después viene el diagnóstico. Es una etapa aparte y cerrada, con su propio precio, así que sabes a qué accedes antes de que nadie toque la web. Su resultado es la causa, el alcance de la reparación y el coste, por escrito. Los trabajos arrancan tras la confirmación del alcance, no tras un «adelante» de palabra. Si por el camino aparece algo fuera del alcance, nos paramos y lo presupuestamos aparte, en lugar de añadirlo a la factura a posteriori.
La reparación la hacemos sobre una copia o en un entorno de pruebas siempre que es posible, y los cambios en producción entran en un único despliegue con opción de revertir. Al terminar recibes una explicación de cuál fue la causa y de qué hacer para que no vuelva. Esto último suele importar más que la reparación en sí, porque un fallo que regresa dentro de tres meses cuesta una segunda vez.
Qué no hacemos
No hacemos diseño gráfico. El layout y la colocación de los elementos en cada vista, es decir el wireframe, los aporta el cliente; nosotros implementamos a partir de ahí la interfaz responsive, las integraciones y la capa de rendimiento. Para recoger la estructura tenemos una plantilla de hoja de cálculo que enviamos al inicio.
No tenemos guardia nocturna ni de fin de semana y no vendemos tiempos de respuesta que no podamos cumplir. Si tu tienda necesita una ventana de respuesta garantizada, eso es un contrato de mantenimiento aparte, no una nota al pie de un reporte de incidencia.
No hacemos cosas «de paso». Cada asunto nuevo que aparezca durante el trabajo recibe su propio presupuesto. Suena rígido y en la práctica evita a ambas partes una factura que nadie esperaba.
Tampoco vendemos una reconstrucción como respuesta a una incidencia. Si la web se puede reparar en unas horas, lo decimos, aunque una propuesta de migración nos resultara más rentable. La migración tiene sentido cuando el coste de mantener la solución actual supera el coste del cambio, y eso se puede calcular, no intuir.
Si la web ha vuelto sola, el caso no está cerrado
Un fallo que ha pasado sin intervención es peor que uno que sigue activo, porque desaparece junto con las pruebas y vuelve en el peor momento. Las tres causas más frecuentes de fallos intermitentes se ven idénticas desde fuera.
La primera es el límite de recursos. El alojamiento compartido asigna a la web un número determinado de procesos PHP simultáneos y, superado ese número, rechaza las peticiones siguientes, normalmente con un error 503 o 508. Basta con que un bot recorra la tienda con los filtros para que durante tres minutos la web no responda a nadie. En el log de acceso verás entonces una serie de peticiones desde una misma dirección en el mismo segundo.
La segunda es una tarea programada. WordPress ejecuta su propio planificador aprovechando las visitas, así que una tarea pesada, por ejemplo generar un informe o sincronizar con el almacén, le toca a un usuario cualquiera y le bloquea la web. Síntoma: fallos a horas regulares o siempre después de la misma acción en el panel.
La tercera es una API externa sin límite de tiempo. Un plugin consulta el servidor del proveedor, el proveedor tiene una avería y tu web espera la respuesta tanto tiempo como permita la configuración de PHP. Entonces la web no está rota, solo esperando, y vuelve sola cuando aquel servidor se recupera.
Qué hacer para capturarlo la próxima vez: activa el registro de errores en un archivo antes de que vuelva, anota las horas exactas de los últimos días y comprueba si forman un patrón. Tres marcas de tiempo y un log son el conjunto con el que se puede trabajar. Sin ellos solo queda esperar a la siguiente vez.
Adónde ir después
Si ya sabes qué necesitas, ve directamente a la página adecuada en lugar de escribir un reporte genérico.
- Avería, error, algo ha dejado de funcionar: reparación, servicio y soporte técnico
- Mantenimiento continuo, actualizaciones, copias y monitorización: mantenimiento de webs WordPress
- Sospecha de intrusión o auditoría previa a una publicación: auditoría de seguridad WordPress
- La web funciona, pero va lenta: optimización de velocidad WordPress
- Proyecto nuevo o rediseño: página de contacto
Dos cosas que conviene hacer hoy, antes de que algo se rompa
Comprueba si tu copia de seguridad se puede restaurar. No si existe, sino si funciona. Una copia que nadie ha restaurado nunca es una suposición, no una protección, y el momento del fallo es el peor para descubrirlo. El procedimiento lleva media hora: monta un entorno de pruebas en el mismo proveedor de alojamiento, restaura allí la última copia, entra en el panel, abre tres páginas al azar y comprueba si el número de entradas y de pedidos coincide con producción. Apunta cuánto ha tardado, porque ese es tu tiempo real de recuperación tras un fallo y es mejor conocerlo por un ensayo que por una avería.
La segunda cosa lleva un minuto: apunta dónde está el dominio, dónde el alojamiento, quién tiene acceso a ellos y cuándo caducan. Sorprendentemente a menudo la avería no es una avería, sino un dominio o un certificado caducado, y responder a «¿dónde está contratado esto?» lleva medio día porque la persona que lo dio de alta hace tiempo que no trabaja en la empresa. En ese mismo papel anota quién es administrador en WordPress y si cada una de esas cuentas sigue siendo necesaria. Las cuentas de antiguos colaboradores son la entrada más habitual que nadie vigila.
