¿Está resolviendo el DNS de mi dominio .es?
Antes de tocar el alojamiento, hay que descartar un fallo de DNS. Un dominio .es depende de registros gestionados en el proveedor (OVH, Raiola, Arsys) que apuntan a unos servidores de nombres. Si el registro A, AAAA o CNAME falta, es incorrecto, o todavía apunta al alojamiento anterior tras una migración, los visitantes con Movistar, Vodafone u Orange verán un error aunque el servidor web funcione sin problemas.
Haz una consulta DNS y comprueba que el registro A devuelve la IP esperada, y que los registros NS coinciden con los que muestra tu proveedor de dominio. Tras cambiar de servidores de nombres, la propagación puede tardar varias horas, y algunos operadores guardan respuestas antiguas en caché más tiempo que otros.
¿Mi dominio apunta al servidor correcto?
Una vez que el DNS resuelve, toca confirmar que apunta al lugar correcto. Toma la dirección IP obtenida y revisa su proveedor de alojamiento, su ASN y su país. Si la web debería estar alojada con un proveedor español y la información de la IP muestra en cambio un centro de datos desconocido en otro país, suele significar un registro A desactualizado, un servidor de pruebas olvidado y todavía activo, o en el peor de los casos un dominio comprometido.
Este paso también detecta un caso habitual: la web carga, pero muestra todavía una versión antigua del alojamiento anterior porque el DNS no ha terminado de propagarse.
¿Qué código HTTP está devolviendo el servidor?
Si el DNS y el alojamiento están correctos, el fallo está en lo que devuelve el servidor. Un 200 significa que la página carga pero algo más va lento, como una consulta a la base de datos o un script que bloquea la carga. Un bucle de redirección 301 o 302 suele venir de una regla en el .htaccess o de un plugin que interfiere consigo mismo. Un 403 significa que el servidor se niega a servir el archivo, casi siempre por permisos o por una regla de cortafuegos. Un 404 significa que la ruta solicitada sencillamente no existe.
Los errores del lado del servidor cuentan cada uno su propia historia: el 500 es un error de la aplicación, el 502 suele indicar que un proxy inverso no pudo contactar con el backend, el 503 apunta a menudo a un pool de PHP-FPM saturado o a un modo mantenimiento que quedó activado, y el 504 significa que el backend tardó demasiado en responder.
¿Qué revelan las cabeceras de respuesta?
Las cabeceras explican el cómo detrás del código de estado. cache-control y expires indican si un navegador o una CDN está sirviendo una copia antigua. cf-ray o x-cache muestran si Cloudflare u otra CDN gestionó la petición, algo útil cuando una corrección hecha en el servidor no parece llegar a los visitantes. Un problema con set-cookie puede romper de forma silenciosa las páginas que dependen de una sesión iniciada, y la ausencia de strict-transport-security en una web que debería forzar HTTPS también merece atención.
Pega las cabeceras de respuesta tal cual y revisa cada línea explicada en lenguaje claro en vez de adivinar su significado.