Start with the page the browser actually receives
A default page can mean the request reached a different server, hostname, document root or cached version than expected.
A placeholder page means the browser reached a web response, but it does not identify the folder you uploaded to. The browser may be reaching an old server, a different hostname, another domain directory or a cached response. Record the full URL, the time, whether the page appears on both HTTP and HTTPS, and whether the root and www hostnames behave alike. Save a copy of the unexpected page or its response headers before changing files.
This guide starts after a completed upload. If you have not yet transferred the deployable build, use the static-site upload guide first. Work only in the domain and DNS zone you are authorised to manage.
Check which server and hostname answered
Compare the current authoritative A and AAAA answers for the exact hostname with the destination supplied for the hosting service. Check both address families: a stale AAAA record can send some visitors elsewhere even when the A record is correct. If a proxy or CDN is in front, identify which layer served the placeholder before attributing it to DirectAdmin. An unchanged DNS answer is not a reason to change MX or mail records.
Open the hostname from a second network or use an authorised DNS/HTTP test and compare the result. A cached browser page can be ruled out with a private session and a fresh request; a persistent response from multiple networks needs host and file checks.
Locate the actual entry page
In the account’s domain view, confirm the selected domain and effective web root. DirectAdmin’s usual per-domain public_html location can be customised by an administrator. Look for the intended index.html in that root, not only inside a nested build folder or another domain. Check that the file has the expected contents and that the public hostname is mapped to the same domain. Do not edit administrator skeleton files or generated virtual-host configuration to force the result.
If both a default index.html and your new entry file are present, establish which filename the configured server chooses. Remove or rename only a known obsolete placeholder after retaining a copy. A missing index, a 403 or a 500 response is a different symptom and has its own guide.
For example, a test file appearing on the apex but not www suggests different host mappings. Compare DNS and the served root for both names; remove the test file afterwards.
Make one correction and verify it
If the DNS target is wrong, restore the recorded correct web address for that hostname and allow for resolver caching. If the files are in the wrong directory, move the complete deployable set to the confirmed root while retaining the previous content. If only the browser has a stale copy, confirm with a fresh request before purging broader caches. Test the exact HTTPS URL and several assets after each single change so you know which correction worked.
Stop if the host mapping, effective root or default template is controlled by the provider. Send support the hostname, timestamp, DNS answers, file path and response evidence; do not broaden file permissions or edit server-wide configuration.
Frequently asked questions
Why does the new site work at a temporary URL but not at my domain? The temporary URL may use a different host mapping. Test the real hostname against the intended target.
Will a hard refresh fix DNS? It can bypass a local page cache, but it cannot change an authoritative DNS record or another resolver’s cached answer.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.