La página predeterminada de Plesk indica que la petición llegó a un servidor gestionado por Plesk, pero seleccionó otro virtual host o document root, o encontró un index.html antes que el index.php de WordPress. Los archivos y la base pueden seguir intactos en otra ruta.
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.