Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Plesk Shows the Default Page Instead of the WordPress Site

A Plesk default page means the request reached a Plesk-managed server but selected a default virtual host/document root or an index.html left in front of WordPress. WordPress files and database may be intact elsewhere.

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 cache

Test 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.html

Do 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.