A Plesk default page is a clue that the response comes from a hosting placeholder or a cached copy of one. Possible causes include reaching the wrong server, an incorrect domain/IP assignment, a different document root or an index file served ahead of WordPress. It does not prove that your WordPress files or database have been lost.
Do not move/delete files until the requested hostname and subscription mapping are proven.
Identify the responding layer
Record root/www, HTTP/HTTPS, headers, certificate and body. Add a request/time reference.
Check:
public A/AAAA/CNAME
served certificate/SNI
Plesk subscription/domain alias
hosting type
document root
index files
proxy/CDN cacheTest through a clean browser/network.
Verify DNS and IPv6
Confirm authoritative DNS sends root and www to this intended Plesk server. An old AAAA can affect only IPv6 visitors.
Use a hostname/SNI test against the intended IP to separate DNS from virtual-host configuration.
Do not alter mail MX/TXT records while correcting web DNS.
Check Plesk subscription and hosting type
In Websites & Domains, confirm the domain exists under the expected subscription and Hosting type is Website hosting, not forwarding/no hosting.
Domain aliases must point to the correct primary site and preserve intended SEO canonicalisation.
Avoid duplicate subscriptions/domains claiming the same hostname; Plesk may select the unexpected virtual host.
Verify document root
Inspect Hosting Settings and locate the directory containing WordPress index.php, wp-config.php and wp-content.
Common roots differ between subscriptions and subdomains. Do not assume httpdocs when a custom root was configured.
If WordPress lives in a subdirectory intentionally, preserve its home/siteurl design.
Remove the default index safely
The default page can be an index.html taking priority over WordPress index.php. Back it up/rename:
index.html -> index.plesk-default.backup.htmlDo not delete WordPress index.php. Check DirectoryIndex order and any application deployment that may recreate the default file.
Clear proxy cache after the correct index is served.
Check PHP handler and service
Once index.php is selected, Plesk still needs an enabled compatible PHP handler for the domain. Confirm PHP version/handler, FPM pool status and socket mapping.
If PHP downloads as a file, shows source or returns 502, stop and repair handler configuration immediately; source exposure can reveal configuration. Use Plesk’s PHP settings/repair tools rather than ad-hoc generated virtual-host edits. Compare web PHP with CLI before running WP-CLI.
Distinguish preview and real-domain behaviour
Plesk preview URLs and IP access may select a default subscription and use different cookies/WordPress redirects. Test the intended hostname with DNS or a local --resolve/hosts entry and correct TLS SNI.
Do not change WordPress home/siteurl to the preview URL. After cutover, remove local overrides and verify root, www, IPv4/IPv6 and CDN all reach the same subscription.
Regenerate virtual-host configuration
Use Plesk’s repair/reconfigure tools or provider support rather than editing generated Apache/Nginx files directly; panel regeneration can overwrite manual changes.
Inspect additional directives for conflicting root/proxy rules. Validate custom directives before applying.
Keep a copy/audit of intentional server customisations.
Check SSL and proxy mode
HTTPS may select a different virtual host if the certificate/domain binding is incomplete. Issue/install the correct Let’s Encrypt certificate after DNS.
When “Proxy mode” or Nginx caching is enabled, compare direct Apache/origin response through supported tools.
Do not disable TLS verification or proxy protection permanently.
Record the response that identifies the wrong host
Capture the status, Server, Location and cache headers for both HTTP and HTTPS before changing settings. A Plesk placeholder body combined with the certificate subject and response headers helps distinguish a wrong virtual host from a cached default page. Repeat the request with a cache-busting query only as evidence; it is not a repair.
Verify the WordPress application
Test homepage, inner permalinks, login, admin, media and REST. Align WordPress URLs/canonical redirects and regenerate permalinks where needed.
Monitor default-page signatures from outside. Recurring care should inventory Plesk subscription, root and certificate before migrations; the default page is a routing symptom, not missing WordPress proof.
Check the IP assigned to the domain inside Plesk
Correct public DNS is not the whole mapping. Plesk documents a default-page case where the address selected under Web Hosting Access differs from the public address to which the domain resolves. Ask the provider to verify that assignment, accounting for the server’s network design, before changing it.
Turn the symptom into a useful repair request
Record the affected public hostname, whether the result differs between HTTP and HTTPS, when the placeholder appeared and any recent move or DNS change. State whether only one domain is affected or other sites on the account show the same response. Those observations help decide who needs to investigate first.
If IP access and domain access differ, use the IP-versus-domain diagnostic guide to separate public resolution from the hosting response. A preview URL alone does not establish which site real visitors receive.
For an active outage, emergency website repair scopes the investigation, proposed correction and recovery route. Ask for verification of the real hostname and the affected form, account or checkout path. A proposal should explain any hosting-provider dependency and what remains unavailable after temporary containment.