If your domain is registered and the DNS records look correct, but the website is still not opening, the problem is usually related to DNS propagation, nameserver setup, record conflicts, or cached data on your device or network. In a hosting and control panel environment such as Plesk, the domain may also be added correctly in the panel while the public DNS still points somewhere else, or it may point to the right server but not yet to the correct hosting subscription, document root, or application.
In most cases, the issue is not that the domain is broken. It is that the internet has not fully updated where the domain should resolve, or one of the DNS records is incomplete. This guide explains how to check the most common causes, how to verify the setup in a hosting platform, and what to do when the domain is still not pointing to the website.
Why a domain may not point to the website yet
A domain can fail to load the website for several different reasons, even when the hosting account is active. The most common ones are:
- The domain uses the wrong nameservers.
- The DNS A record or AAAA record points to the wrong IP address.
- The DNS change has not fully propagated yet.
- There is a conflicting record, such as a parking record or another A record.
- The website is added in the hosting panel, but not assigned to the correct subscription or web root.
- The browser, local DNS cache, or ISP cache still shows the old destination.
- The domain is redirected elsewhere through registrar settings, DNS, or application configuration.
When you manage hosting through a control panel like Plesk, these issues often happen after a new site launch, migration, nameserver change, or when switching from one hosting provider to another in the EU region.
Check whether the domain is using the correct nameservers
The first thing to verify is where the domain is managed. If the nameservers are not set to the hosting provider’s DNS service, changes made inside the panel may not have any effect on the public internet.
What to look for
- Nameservers at the registrar should match the hosting provider’s nameservers.
- If you use external DNS, then the DNS zone must be edited there, not in the hosting panel.
- If nameservers were changed recently, propagation can take time before the new DNS becomes visible worldwide.
If the domain still uses old nameservers, the website will continue to resolve according to the old DNS zone, even if the hosting account already has the correct site configured.
How to verify in practice
- Open your domain registrar account.
- Check the current nameservers for the domain.
- Compare them with the nameservers provided by your hosting platform.
- If they do not match, update them carefully and wait for propagation.
If your setup uses a managed DNS service, make sure the full DNS zone is created and active there before moving traffic.
Confirm that the A record points to the correct server
For websites, the most important record is usually the A record, which maps the domain to an IPv4 address. If your server also supports IPv6, the AAAA record may need to be checked as well.
Common DNS record issues
- The A record points to an old server IP after migration.
- The root domain and www subdomain point to different servers.
- There is an AAAA record pointing to an unused IPv6 address.
- There are multiple A records, and one of them points elsewhere.
In a hosting panel, the domain should resolve to the IP address assigned to the correct subscription or website. If the site is hosted in an EU data centre, the public DNS record still must point to that specific server address. The location does not update automatically.
Recommended checks
- Verify the A record for your root domain, for example example.com.
- Verify the A or CNAME record for www.example.com.
- Check whether an AAAA record exists and whether it is correct.
- Remove old or duplicate records if they are no longer needed.
If your hosting provider gives you a temporary IP during setup, remember to replace it with the final production IP once the site is ready.
Understand DNS propagation and why it can take time
After a DNS change, the result may not be visible immediately everywhere. This is normal. DNS propagation depends on many factors, including the TTL value, resolver cache, local ISP cache, and how often remote servers refresh records.
What propagation means
Propagation is the process of DNS information being updated across caches around the world. During this period, some visitors may reach the new website while others still see the old destination or an error page.
How long it usually takes
- Simple DNS changes may appear within minutes.
- Full propagation can take several hours.
- In some cases it may take up to 24–48 hours.
The exact time depends on the TTL of the old records and the caching behaviour of resolvers. A lower TTL can help future changes propagate faster, but it does not guarantee instant updates everywhere.
What you can do during propagation
- Wait for the TTL period to expire.
- Test the domain from different networks.
- Clear your local DNS cache.
- Check the zone directly in your hosting control panel.
Check the domain inside the hosting control panel
Even when DNS is correct, the website may still not load if the domain is not properly attached in the hosting environment. In Plesk and similar panels, the domain must be assigned to the correct subscription, document root, and website configuration.
Things to verify in the panel
- The domain is added as a website or domain alias, not only as parked content.
- The correct PHP version or application handler is selected.
- The document root points to the right folder, usually something like httpdocs.
- The site content exists in that folder.
- The subscription is active and not suspended.
- SSL settings are not forcing a broken redirect before the certificate is ready.
If the domain points correctly but the website shows the default hosting page, the DNS may be fine and the issue may instead be that the site files are not in the active document root.
Migration-related issues
After a migration, it is common to see the domain still loading the old site or a placeholder page. This usually happens when:
- The DNS still points to the old hosting provider.
- The site files were copied but the virtual host was not updated.
- The database connection settings still reference the old server.
- The CMS cache is holding old routing information.
Make sure the domain’s DNS and the hosting subscription both match the intended live environment.
Check for conflicting DNS records
Conflicting records are a frequent reason why a domain does not point to the expected website. A single incorrect record can override the result or create inconsistent behaviour between different networks.
Common conflict examples
- An old A record still exists for the root domain.
- There is a CNAME for www pointing to another hostname with outdated DNS.
- A parking record remains active at the registrar.
- Both IPv4 and IPv6 records exist, but only one server responds correctly.
When managing DNS in a hosting platform, keep the zone clean and minimal. Only keep the records needed for the website, mail service, and any required subdomains.
Clear local cache before testing again
Sometimes the domain is already pointing correctly, but your device still shows the old result because of cached DNS data. This can happen on your computer, browser, router, or mobile network.
What to clear
- Browser cache and cookies.
- Operating system DNS cache.
- Router cache, if applicable.
- Private DNS or security software cache.
You can also test the site in a different browser, incognito window, or on mobile data to confirm whether the issue is local or global.
Useful verification tips
- Use a public DNS resolver such as 1.1.1.1 or 8.8.8.8 for testing.
- Check whether the domain resolves from multiple networks.
- Compare the IP address with the one shown in your hosting panel.
If only one device shows the wrong website, the DNS is often already correct and the problem is just cached data.
Verify www and non-www behavior
Many websites resolve correctly on the root domain but fail on www, or the opposite. This happens when the two hostnames are not configured consistently.
Best practice setup
- Set the root domain to the correct A record.
- Set www as a CNAME to the root domain or to the canonical hostname.
- Configure one preferred version and redirect the other version properly.
If your hosting platform uses automatic redirects, confirm that the redirect target is valid and that SSL is active on both hostnames.
Check HTTPS, SSL certificate, and redirect rules
Sometimes a domain appears not to point to the website because the browser blocks it due to SSL or redirect problems. This is especially common when HTTPS is enabled before the certificate is issued or when redirect rules conflict.
Possible symptoms
- Browser shows a certificate warning.
- The site loops between HTTP and HTTPS.
- The domain opens to a blank page or errors after redirect.
- The site works on HTTP but not on HTTPS.
What to check
- The SSL certificate is issued for the correct domain names.
- The certificate includes both root and www if both are used.
- The control panel redirect settings do not conflict with application rules.
- The CMS or app configuration uses the correct site URL.
In managed hosting environments, SSL provisioning may take a short time after the domain starts resolving to the correct server. Do not force redirects too early if the certificate is not ready yet.
Make sure the website files and application are present
A correct DNS setup only sends visitors to the server. The website still needs to exist there. If the site is missing, misconfigured, or broken at application level, the domain may appear to be “not pointing” even though it actually resolves properly.
Check these items
- The website files are uploaded to the correct folder.
- The homepage file exists, such as index.php or index.html.
- The CMS database connection details are correct.
- File permissions allow the web server to read the content.
- The application has no fatal errors in logs.
If you use WordPress, Joomla, Laravel, or another app in a Plesk-based hosting setup, the domain may point correctly but still show an installation error if the document root, database, or rewrite rules are wrong.
Step-by-step troubleshooting checklist
- Confirm the domain uses the correct nameservers.
- Check that the A and AAAA records point to the correct server IP.
- Remove conflicting or outdated DNS records.
- Verify the domain is attached to the right subscription or site in the hosting panel.
- Check the document root and ensure the website files are present.
- Wait for DNS propagation if changes were made recently.
- Clear local DNS and browser cache.
- Test both root domain and www version.
- Review SSL and redirect settings.
- Check logs if the domain resolves but the site still does not load.
Examples of common scenarios
Scenario 1: Domain was moved to a new hosting provider
You updated the nameservers, but some visitors still see the old site. This usually means the old DNS is still cached somewhere, or the registrar changes have not fully propagated yet. Confirm the new A record points to the EU server IP and wait for the cache to expire.
Scenario 2: Domain points to the server, but shows a default page
In this case, the DNS is likely correct. The domain may not be assigned to the proper hosting subscription, or the website files are missing from the active document root. Check the panel configuration and the site’s folder structure.
Scenario 3: Root domain works, but www does not
This is usually a record mismatch. Add or correct the www record and ensure the SSL certificate covers both hostnames. Then set one preferred version and redirect the other one cleanly.
When to contact support
Contact hosting support if you have already checked the nameservers, DNS records, and control panel settings, but the domain still does not resolve correctly after a reasonable propagation period. Provide the following details to speed up the investigation:
- The domain name.
- The expected target IP address.
- When the DNS change was made.
- Whether the issue affects root, www, or both.
- Any recent migration, SSL, or redirect changes.
- Screenshots or error messages if available.
This helps the support team check zone configuration, subscription assignment, and web server status without delay.
FAQ
How long does it take for a domain to point to a new website?
It can take from a few minutes to 48 hours depending on DNS TTL, caching, and registrar updates. Many changes appear sooner, but full propagation is not always immediate.
Why does the domain work on my phone but not on my computer?
Your phone and computer may use different DNS caches or networks. If one device sees the correct site and the other does not, local cache is a likely cause.
Why does the website show the old hosting page?
This usually means the DNS still points to the old server, or the old page is still cached somewhere. It can also happen if the domain is added in the hosting panel but not linked to the correct web root.
Do I need to change both A and AAAA records?
Only if your hosting environment uses IPv6. If an AAAA record exists and is incorrect, it can cause inconsistent results. If you do not use IPv6, remove the unused AAAA record.
Can the registrar DNS settings override the hosting panel?
Yes. If the registrar is still authoritative for the domain, changes made in the hosting panel will not be used until the nameservers are pointed to the hosting DNS service.
Conclusion
If your domain is not pointing to the website yet, the cause is usually one of four things: wrong nameservers, incorrect DNS records, incomplete propagation, or a hosting panel setup issue. Start by confirming where DNS is managed, then verify the A and AAAA records, check the domain assignment in the control panel, and test after clearing local cache. In most hosting environments, especially after migrations or new site launches, the problem is solved by correcting the DNS zone and waiting for propagation to finish.
If everything is configured correctly but the site still does not open, review the web root, SSL settings, and application logs. That will help separate a DNS issue from a website or server configuration issue.