Para resolver un error de una web, empieza por identificar qué falla y desde cuándo. Cambiar varias cosas a la vez dificulta conocer la causa y puede añadir nuevos problemas. Reúne evidencias antes de modificar o restaurar el sitio.
Qué información recoger primero
- URL exacta y función afectada.
- Mensaje de error y hora aproximada.
- Dispositivo, navegador y si ocurre con o sin sesión.
- Últimos cambios conocidos: configuración, actualizaciones o proveedores.
- Impacto: lectura, contacto, compra, reservas o acceso interno.
Una captura ayuda, pero no sustituye la URL y el contexto. No compartas contraseñas, datos de clientes ni registros completos con información sensible en un canal público.
Síntomas habituales y primera comprobación
| Síntoma | Qué comprobar | Qué evitar |
|---|---|---|
| Error 500 o pantalla en blanco | Alcance, hora y último cambio; registros del proveedor si están disponibles | Suponer una causa única sin evidencias |
| Enlace que devuelve 404 | Dirección exacta, existencia del contenido y redirecciones | Redirigir todo a la portada |
| Formulario sin recepción | Validación, respuesta del servidor y proveedor de entrega | Dar por enviado un mensaje solo porque aparece un aviso |
| Contenido antiguo | Cachés y respuesta desde otra sesión | Confundir una copia almacenada con un fallo de publicación |
| Redirección desconocida | Configuración y posibles cambios no autorizados | Limitarse a ocultar el síntoma |
Un HTTP 500 indica un problema del servidor, no identifica por sí solo qué componente lo provoca.
Cómo hacer una comprobación acotada
- Reproducir el fallo sin introducir cambios.
- Separar si afecta a toda la web, a una ruta o a una función.
- Revisar las evidencias disponibles y plantear una hipótesis concreta.
- Probar una intervención controlada y documentarla.
- Comprobar el recorrido completo, no solo que la portada cargue.
Si no dispones de acceso o conocimiento suficiente, detenerte y pedir ayuda puede evitar agravar el incidente. Un proveedor debe explicar qué pretende comprobar y qué riesgos tiene la intervención.
Cuándo tratarlo como un incidente de seguridad
Usuarios desconocidos, contenido ajeno o redirecciones no autorizadas justifican investigar un posible compromiso. No todos los errores son ataques, pero tampoco conviene descartar esa posibilidad solo porque la web vuelva a cargar.
Consulta la guía para una web comprometida y las medidas de seguridad para agencias antes de dar el incidente por cerrado.
Pedir soporte con un alcance claro
Un encargo puntual debe definir el problema a investigar, los accesos autorizados, las comprobaciones y la forma de comunicar el resultado. No implica arreglos ilimitados ni un plazo fijo para cualquier incidencia.
El soporte técnico freelance de El Gabli sirve para plantear incidencias y proyectos. Si necesitas una operación continuada para tu cartera, consulta el mantenimiento WordPress para agencias y sus planes.
Preguntas frecuentes
¿Tengo que desactivar todo para encontrar el error?
¿Un aviso de éxito demuestra que el formulario entregó el correo?
¿Todos los errores se resuelven con mantenimiento?
Fuentes y referencias
Documentación consultada para esta revisión, 2026-09-10.
¿Necesitas llevarlo a tu empresa o a los clientes de tu agencia?
Ver el servicio relacionado