La página predeterminada de Plesk indica que la respuesta procede de una página del alojamiento o de una copia en caché. Puede deberse a un servidor equivocado, una asignación incorrecta de dominio e IP, otro directorio raíz o un índice servido antes de WordPress. No demuestra que se hayan perdido los archivos ni la base de datos.
No muevas ni borres archivos hasta demostrar la asignación del hostname y la suscripción.
Identifica qué capa responde
Anota raíz y www, HTTP y HTTPS, cabeceras, certificado y cuerpo, junto con hora.
Comprueba:
A, AAAA y CNAME públicos
certificado servido y SNI
suscripción y alias en Plesk
tipo de hosting
document root
archivos index
caché de proxy o CDNRepite desde un navegador y una red limpios.
Verifica DNS e IPv6
Confirma que el DNS autoritativo dirige raíz y www al servidor Plesk previsto. Un AAAA antiguo puede afectar solo a usuarios IPv6.
Prueba el hostname y SNI contra la IP correcta para separar DNS de la configuración del virtual host. No modifiques MX ni TXT de correo al reparar el DNS web.
Revisa suscripción y tipo de hosting
En Websites & Domains, confirma que el dominio pertenece a la suscripción esperada y que Hosting type es Website hosting, no forwarding o no hosting.
Los alias deben apuntar al sitio primario y mantener la canonicalización SEO prevista. Evita dos suscripciones reclamando el mismo hostname: Plesk puede seleccionar la inesperada.
Comprueba el document root
En Hosting Settings, localiza el directorio que contiene index.php, wp-config.php y wp-content.
Las raíces varían por suscripción y subdominio. No asumas que siempre es httpdocs si antes se configuró otra ruta. Si WordPress vive intencionadamente en un subdirectorio, conserva su diseño de home y siteurl.
Retira el índice predeterminado con seguridad
Un index.html de Plesk puede tener prioridad sobre index.php. Haz copia o renómbralo:
index.html -> index.plesk-default.backup.htmlNo borres el index.php de WordPress. Revisa el orden de DirectoryIndex y procesos de despliegue que puedan recrear el archivo. Purga el proxy cuando el índice correcto se sirva.
Comprueba PHP y su handler
Después de seleccionar index.php, el dominio necesita un handler PHP compatible. Revisa versión, FPM, estado del pool y socket asignado.
Si PHP se descarga, muestra código o devuelve 502, detente y repara el handler inmediatamente: exponer código puede revelar configuración. Usa herramientas de Plesk, no ediciones improvisadas de virtual hosts generados.
Distingue preview del dominio real
La vista previa de Plesk y el acceso por IP pueden seleccionar otra suscripción y provocar redirecciones diferentes. Prueba el hostname real mediante DNS, --resolve o una entrada hosts temporal, con SNI correcto.
No cambies home o siteurl a la URL de preview. Tras el corte, elimina overrides y prueba raíz, www, IPv4, IPv6 y CDN.
Regenera el virtual host desde Plesk
Utiliza las herramientas de reparación o reconfiguración de Plesk, o soporte. Editar directamente archivos generados no es duradero porque el panel los sobrescribe.
Revisa directivas adicionales que cambien root o proxy y valida las personalizaciones antes de aplicarlas. Conserva un registro de cambios intencionados.
Comprueba SSL y proxy
HTTPS puede seleccionar otro virtual host si el certificado o la vinculación están incompletos. Emite Let’s Encrypt después de corregir DNS.
Si Proxy mode o la caché Nginx están activos, compara con el origen mediante herramientas compatibles. No desactives permanentemente TLS ni protección del proxy.
Conserva la respuesta que identifica el host
Antes de cambiar, guarda estado, Server, Location, caché y sujeto del certificado para HTTP y HTTPS. Juntos distinguen un virtual host erróneo de una página predeterminada cacheada.
Una query distinta sirve como evidencia, no como reparación.
Verifica WordPress
Prueba portada, enlaces internos, login, administración, medios y REST. Alinea URLs y redirecciones canónicas y regenera enlaces permanentes si procede.
Monitoriza desde fuera la firma de la página de Plesk. Esa página es un síntoma de routing, no una prueba de que WordPress se haya perdido.
Comprueba la IP asignada al dominio dentro de Plesk
Un DNS público correcto no completa el mapeo. Plesk documenta un caso de página predeterminada en el que la dirección seleccionada en Web Hosting Access difiere de la IP pública resuelta. Pide al proveedor que verifique esa asignación teniendo en cuenta la red del servidor antes de cambiarla.
Convierte el síntoma en una solicitud útil de reparación
Anota el dominio público afectado, si cambia el resultado entre HTTP y HTTPS, cuándo apareció la página y cualquier traslado o cambio DNS reciente. Indica si sólo afecta a un dominio o si otros sitios de la cuenta muestran lo mismo. Estas observaciones ayudan a decidir quién debe investigar primero.
Si difieren el acceso por IP y por dominio, utiliza la guía de diagnóstico de WordPress por IP y dominio para separar resolución pública y respuesta del alojamiento. Una URL de previsualización no demuestra qué sitio reciben las visitas reales.
Ante una caída, la reparación web urgente delimita investigación, corrección propuesta y vía de recuperación. Pide verificar el dominio real y el formulario, cuenta o checkout afectado. La propuesta debe explicar las dependencias del proveedor y qué seguiría indisponible tras una contención temporal.