Los errores web pueden impedir el acceso a una página, dificultar una tarea o interrumpir el funcionamiento de un negocio. Antes de cambiar configuraciones, conviene identificar qué falla, desde cuándo y a quién afecta. Un mensaje parecido puede tener causas distintas, por lo que aplicar una solución encontrada para otro sitio puede empeorar la incidencia.
Esta guía reúne errores frecuentes y un orden de comprobación para webs con WordPress. Empieza conservando la información del fallo y una copia adecuada antes de cualquier intervención. Si hay una tienda en funcionamiento, coordina las pruebas para no interrumpir pedidos ni modificar datos reales sin control.
El código de respuesta es una pista para diagnosticar, no una explicación completa de la causa.
Errores web: qué revisar antes de intentar una solución
Anota la URL, la hora aproximada y la acción que produjo el error. Comprueba si ocurre en una sola página, en toda la web o únicamente al iniciar sesión. Revisa también si comenzó después de una actualización, una migración o un cambio de configuración.
Prueba desde otra conexión o navegador cuando sea pertinente, sin asumir que limpiar la caché resuelve cualquier problema. Conserva capturas sin datos personales y comparte con soporte la información necesaria. Cambiar varias cosas a la vez dificulta saber cuál era la causa y cómo volver atrás.
Error 404: la página no se encuentra
Una respuesta 404 indica que el recurso solicitado no está disponible en esa dirección. Puede deberse a un enlace incorrecto, una URL modificada o un contenido eliminado. No todos los 404 requieren una redirección: una dirección inventada o una página sin sustituto puede devolver correctamente ese estado.
Revisa los enlaces que llevan a la URL y comprueba si existe un recurso equivalente. Si cambió la dirección de una página importante, prepara una redirección pertinente y actualiza las referencias internas. Evita enviar todos los errores a la portada, porque el usuario seguiría sin encontrar lo que buscaba.
Error 403: acceso no permitido
Un 403 señala que el servidor no permite acceder al recurso en esas condiciones. Puede relacionarse con permisos, reglas de acceso o medidas de protección. No lo soluciones asignando permisos amplios de forma indiscriminada ni desactivando toda la seguridad de la web.
Comprueba si afecta a usuarios concretos, a una acción o a una ruta. Revisa los registros y los cambios recientes con la persona que administra el alojamiento. Si una regla está bloqueando una petición legítima, debe ajustarse de forma específica y conservar las protecciones necesarias.
Errores 500 y 501
El error 500 indica un fallo interno del servidor, sin identificar por sí mismo la causa. En WordPress puede aparecer tras un conflicto, un error de código o un problema del entorno. La información útil suele estar en los registros correspondientes, no únicamente en el mensaje visible.
Un 501 tiene otro significado: el servidor no admite la funcionalidad necesaria para atender la solicitud. No debe tratarse automáticamente como un conflicto de plugins. Comunica el método, la URL y el contexto a soporte para investigar qué componente devuelve esa respuesta.
Errores 502 y 503
Un 502 suele indicar que un intermediario ha recibido una respuesta no válida del servidor al que consulta. Un 503 indica indisponibilidad del servicio, que puede ser temporal. En ambos casos hay que revisar el origen de la respuesta, los registros y el estado de los servicios involucrados.
Si el fallo aparece bajo carga, estudia recursos, procesos y tareas que coinciden con la incidencia. No atribuyas el problema al tráfico sin comprobarlo. Una caché o una ampliación de alojamiento pueden ayudar en determinados casos, pero no corrigen necesariamente una consulta o un proceso defectuoso.
Error 521 cuando interviene Cloudflare
Un 521 es un código asociado a Cloudflare que indica que el servidor de origen rechaza la conexión, como explica la documentación oficial del error 521. La comprobación debe centrarse en la disponibilidad del origen y en las reglas que puedan impedir esa comunicación. No significa que el navegador haya conectado correctamente con WordPress.
Revisa con el proveedor el estado del servicio y las restricciones aplicables. Evita publicar direcciones o detalles internos innecesarios en una conversación abierta. Si no utilizas Cloudflare, confirma qué sistema está mostrando el mensaje antes de aplicar instrucciones específicas de ese servicio.
Pantalla en blanco y errores críticos de WordPress
Una pantalla vacía o un aviso de error crítico puede relacionarse con código, incompatibilidades o recursos, entre otras causas. Comprueba los registros y las notificaciones de recuperación cuando existan. La guía de errores comunes de WordPress ofrece puntos de partida para distintos casos.
Prueba cambios en un entorno de ensayo cuando sea posible y conserva una vía de recuperación. No elimines plugins ni archivos sin saber qué función cumplen. Desactivar un componente puede afectar formularios, pagos o contenido, aunque la portada parezca seguir funcionando.
Ejemplo visual de un mensaje de error crítico.
Depuración sin mostrar información al público
La depuración puede ayudar a identificar un error, pero no conviene mostrar mensajes técnicos a los visitantes. La documentación oficial de depuración distingue el registro de errores de su visualización y advierte sobre su uso en producción.
Si se necesita activar un registro temporal, debe protegerse, revisarse y retirarse cuando termine el diagnóstico. Puede contener rutas u otra información sensible. Evita dejar configuraciones de prueba activadas o publicar fragmentos completos sin eliminar datos que no sean necesarios para resolver la incidencia.
Problemas de conexión con la base de datos
WordPress necesita conectar con su base de datos para mostrar y gestionar contenido. Un fallo puede deberse a credenciales, disponibilidad o límites del servicio. Antes de editar la configuración, comprueba si hubo cambios de alojamiento o de acceso.
No ejecutes reparaciones ni sustituyas datos sin una copia recuperable y un diagnóstico. Si el problema está en el servidor de base de datos, cambiar repetidamente la configuración de WordPress no lo resolverá. Facilita al proveedor la hora y el alcance del fallo para revisar sus registros.
Mensaje de referencia de un problema de conexión con la base de datos.
HTTPS, certificados y contenido mixto
Si aparece un aviso de certificado, comprueba dominio, vigencia y configuración del servicio. No aconsejes a los visitantes saltarse la advertencia. Una instalación con varios dominios o una migración puede necesitar revisar qué nombre utiliza cada recurso.
El contenido mixto aparece cuando una página segura intenta cargar determinados recursos mediante HTTP. Revisa las referencias y la configuración de origen. No hagas sustituciones masivas en la base de datos sin respaldo y una herramienta que respete las estructuras almacenadas; podrías dañar ajustes del sitio.
Una advertencia de certificado requiere comprobar la conexión y el dominio.
Revisa los recursos que se intentan cargar de forma insegura.
Imágenes que no suben o no se muestran
Comprueba formato, peso, dimensiones y el mensaje exacto. Los límites dependen del alojamiento y de la configuración, por lo que no existe un tamaño máximo universal para todas las instalaciones. Revisa también espacio disponible, permisos y procesamiento de imágenes.
Antes de aumentar límites, valora si el archivo es adecuado para la web. Una imagen muy grande puede necesitar preparación y compresión. Si el problema empezó tras mover el sitio, comprueba las rutas y los archivos que se trasladaron.
Ejemplo de la selección de archivos al subir imágenes.
Formularios que no entregan los mensajes
Que un formulario muestre «enviado» no demuestra que la consulta haya llegado al buzón de destino. Realiza una prueba completa y revisa registros, destinatarios y correo no deseado. La autenticación del dominio y el sistema utilizado para enviar también pueden influir.
No uses la dirección del visitante como remitente de un dominio que la web no controla. Configura el envío con un servicio autorizado y utiliza la respuesta al visitante donde corresponda. Nuestro artículo sobre SPF, DKIM y DMARC explica estas piezas de autenticación.
El envío del formulario debe configurarse con un servicio autorizado.
Lentitud, caché e indexación
Una web lenta requiere revisar qué recursos y procesos retrasan la tarea del usuario. Diferencia datos de pruebas de laboratorio y experiencia real cuando esté disponible. No atribuyas una posición en Google a un único tiempo de carga ni prometas resultados por alcanzar una puntuación.
Si una página no aparece en búsqueda, comprueba acceso, directivas e información de Search Console. Publicar y solicitar revisión no garantizan indexación inmediata. Una exclusión deliberada y un fallo de acceso necesitan acciones diferentes.
Recuperación del acceso y contenido de prueba
Si no puedes entrar al panel, utiliza el procedimiento oficial de recuperación y comprueba el dominio al que accedes. No compartas contraseñas en documentos abiertos ni las incluyas en una captura. Si el correo de recuperación no llega, revisa la cuenta y solicita ayuda a quien administra el sitio antes de modificar datos directamente.
Antes de dar una página por terminada, busca contenido de prueba, imágenes provisionales y enlaces que no conducen al destino correcto. Revisa también mensajes automáticos y formularios: un texto de ejemplo visible puede generar confusión aunque la web no muestre un error técnico.
Comprueba siempre la dirección del acceso y utiliza la recuperación oficial.
Revisa que no queden textos provisionales visibles en la web.
Un procedimiento de mantenimiento útil
- Prioriza incidencias que impiden comprar, contactar o consultar información importante.
- Conserva una copia y un registro de los cambios realizados.
- Prueba la solución en las páginas y dispositivos afectados.
- Comprueba formularios, pagos y correo después de cambios relevantes.
- Retira configuraciones temporales y documenta cómo detectar una repetición.
Un servicio de hosting y mantenimiento del alojamiento ayuda a coordinar el diagnóstico del servidor con la web. Si la incidencia requiere cambios en la estructura o el comportamiento del sitio, conviene trabajar también el desarrollo. Resolver el mensaje visible es solo una parte: hay que verificar que la tarea del usuario vuelve a funcionar.
