If your website is still opening the old version after a migration, DNS update, or hosting change, the most common reason is that some part of the internet is still resolving your domain to the previous server. This can happen even when the files and database have already been moved correctly to your new hosting account. In most cases, the issue is temporary and related to DNS propagation, cached records, browser cache, local DNS cache, or an email or subdomain record that still points to the old destination.
For websites hosted on European infrastructure, this can be more noticeable when visitors use different internet providers, DNS resolvers, or corporate networks. One person may already see the new site, while another still sees the old server for several hours or, in some cases, up to 24–48 hours.
Why the website may still load from the old server
When you change hosting or update DNS records, you are not changing a single global switch. You are updating records that are cached at several layers. If any of those layers still contains the old IP address or host target, the website may continue loading from the previous server.
Common causes
- DNS propagation is still in progress after an A record, AAAA record, or nameserver change.
- Your device or browser cache still stores the old site version or DNS response.
- Your ISP or public DNS resolver has not refreshed the record yet.
- The domain’s nameservers are still pointing to the old provider or were not changed correctly.
- The A record points to the old server IP, even if the website files were moved.
- There is an AAAA record that still points to the old server over IPv6.
- CDN, proxy, or cache layer is serving the previous version.
- Subdomains or the www record still point to the old host while the main domain was updated.
- Application-level cache in WordPress, Magento, Laravel, or another app has not been cleared.
- Hosting control panel settings in Plesk, cPanel, or another panel still reference the previous document root or domain target.
First checks to confirm what is actually happening
Before changing anything else, confirm whether the domain still resolves to the old server or whether you are only seeing a cached version locally. This saves time and helps isolate the issue.
Check the current DNS target
- Look up the domain’s A record and verify that it matches the new server IP.
- If you use IPv6, check the AAAA record as well.
- Verify www, subdomains, and any custom hostnames used by the application.
- If nameservers were changed, confirm that the domain is using the correct nameserver set at the registrar.
Check from multiple networks
- Test from your office or home connection.
- Test from mobile data to bypass your router cache.
- Test from a different public DNS resolver.
- If possible, ask a colleague in another location to check the same domain.
Compare the resolved IP with the old and new server
If the domain resolves to the old IP on some networks and the new IP on others, the problem is almost certainly DNS propagation or resolver caching. If it resolves correctly everywhere but the site still looks old, then you are likely dealing with browser cache, application cache, or a CDN/proxy layer.
How DNS propagation works
DNS changes do not update everywhere at the same moment. When a DNS record is changed, recursive resolvers around the world keep the old response until the record’s TTL expires. A low TTL can speed up refresh times, but it does not guarantee an instant switch for every visitor.
Typical propagation time depends on:
- the TTL of the old record;
- the caching behavior of the visitor’s ISP or DNS resolver;
- whether you changed the nameservers or only a record;
- the presence of IPv6, CDN, or proxy services;
- how often the local network refreshes DNS information.
In practice, many changes are visible within a few hours, but some users may keep seeing the old server for up to 48 hours.
Step-by-step troubleshooting
1. Confirm the domain’s A and AAAA records
Log in to your DNS zone management area or hosting control panel and inspect the records for the affected domain. Make sure the domain points to the new server IP address.
- A record for the root domain should point to the new IPv4 address.
- AAAA record should be updated or removed if the new server does not use IPv6.
- www CNAME should usually point to the root domain or to the correct target, depending on your setup.
- Check any additional subdomains such as shop, blog, or app.
If you moved the site but forgot the AAAA record, some visitors may still reach the old server over IPv6 even though IPv4 is already correct.
2. Verify nameservers at the registrar
If you changed hosting providers, make sure the domain registrar is using the intended nameservers. When nameservers are still set to the old provider, DNS records from the new host will not be used.
- Check the domain registrar panel.
- Confirm the authoritative nameservers listed there.
- Compare them with the nameservers provided by your current hosting company.
- If you are using external DNS, make sure all records are created in the correct DNS zone.
It is common to update records in the hosting panel but forget that the domain still delegates DNS to a different provider.
3. Clear browser cache and test in a private window
Sometimes the browser shows a stored copy of the site, especially if the previous server returned long cache headers or if a service worker is involved.
- Open the site in a private or incognito window.
- Hard refresh the page.
- Clear cached images and files if needed.
- Try another browser.
If the private window shows the new site but the normal browser does not, the issue is local caching rather than DNS.
4. Flush your local DNS cache
Your device may keep an old DNS response even after the record was updated. Flushing the local DNS cache forces the system to query DNS again.
- Restart the browser.
- Restart the device if needed.
- Flush the OS DNS cache where applicable.
- Re-test after reconnecting to the network.
This is especially useful when you recently changed the domain’s A record or nameservers.
5. Test the site with a direct hosts-file check or temporary URL
If your hosting provider gives you a temporary URL or a preview hostname, use it to confirm that the site files and application are working on the new server. This helps separate DNS issues from application issues.
- If the temporary URL shows the new site correctly, your migration is probably fine.
- If the temporary URL also shows the old content, the issue may be with the application, document root, or database.
In managed hosting environments and panels like Plesk, the preview domain can be useful for verifying the new deployment before DNS fully switches over.
6. Check for CDN, proxy, or caching services
If you use a CDN or proxy layer, the public DNS may point to the CDN rather than directly to the server. In that case, the edge cache may still deliver old content even though the origin server is already updated.
- Purge the CDN cache.
- Verify the origin IP in the CDN settings.
- Check whether the proxy is enabled or disabled correctly.
- Confirm that SSL/TLS settings match the new origin.
A stale CDN configuration can make it seem like the site is still loading from the old server when in reality the content is being served from a cache layer.
7. Confirm the web root and virtual host settings
After moving a site, the domain may be pointing to the new server IP, but the web server can still be serving a different document root or virtual host configuration.
- In Plesk, verify the domain’s hosting settings and document root.
- Check that the correct subscription or domain is attached to the site.
- Make sure Apache or Nginx is serving the intended vhost.
- Verify that the application files were uploaded to the correct directory.
If the wrong virtual host is active, you may see an older website, a default page, or the content of another domain.
Email and app-related issues that can look like old-server behavior
In the same category as DNS and app issues, email and database settings can create confusion during migration. The website may appear to load from the old server because parts of the application still rely on old environment details.
Database not fully migrated
If the files were moved but the database import was incomplete, the site may still show old content, old settings, or a previous cache version.
- Verify the correct database name, user, and password.
- Check that the application connects to the new database server if applicable.
- Confirm that tables were imported successfully.
Email records still pointing to the old provider
MX, SPF, DKIM, and DMARC records do not affect website loading directly, but a partially updated DNS zone can indicate that other records were overlooked. During migration, check the full zone, not only the A record.
Application config still references the old URL
Some platforms store the base URL, canonical domain, or asset host in configuration files or the database. If those values still reference the previous server name or old domain setup, the site may redirect unexpectedly or load mixed content.
- Check application base URL settings.
- Search for absolute URLs in the configuration or database.
- Clear application cache after updating the values.
Practical migration checklist
Use this checklist when a website has been moved to new hosting and still seems to load from the old server.
- Confirm the new site files are present on the destination server.
- Confirm the database has been imported and the application connects successfully.
- Update the A record to the new IPv4 address.
- Update or remove the AAAA record if needed.
- Check the www record and all important subdomains.
- Verify nameservers at the registrar.
- Clear CDN and application caches.
- Check browser and local DNS cache.
- Test from multiple networks and devices.
- Wait for DNS propagation if the change is recent.
What not to do
When a site still loads from the old server, it is tempting to keep changing records repeatedly. That can make diagnosis harder.
- Do not change A records back and forth without a plan.
- Do not delete records unless you know they are no longer used.
- Do not assume the migration failed just because one network still sees the old site.
- Do not forget IPv6 when updating only the IPv4 address.
- Do not overlook www and subdomain records.
How long to wait before escalating
If the DNS change was made recently, waiting is often the correct next step. If more than 48 hours have passed and some visitors still see the old server, the cause is usually not normal propagation anymore. At that point, review the DNS zone, registrar delegation, cache layers, and application configuration.
If the domain is used for a live business site, it is a good idea to keep the old hosting active for at least a short overlap period during migration. That reduces the risk of downtime while DNS settles worldwide.
FAQ
Why do I see the new site on my phone but the old one on my laptop?
Different devices may use different DNS resolvers, cache states, and network routes. Your phone on mobile data may already see the new server while your laptop still uses a cached result from your home network.
Why does the domain work with the IP address but not with the domain name?
This usually means the web server is configured correctly, but DNS is still pointing to the old server or has not fully propagated. It can also happen when the www record or AAAA record is incorrect.
Can browser cache alone make it look like the old server is still active?
Yes. Cached assets, service workers, or aggressive browser caching can display an old version of the site even after DNS is correct. Testing in a private window is a quick way to check this.
Does changing nameservers fix the issue faster than changing A records?
Not necessarily. Nameserver changes also need to propagate and may take time. In some cases, updating the A record in the existing DNS zone is simpler and faster.
What if my hosting control panel shows the new IP but visitors still reach the old server?
That usually means the authoritative DNS is elsewhere, propagation is still in progress, or a cached resolver is serving the old data. Confirm where the domain’s DNS is actually hosted and whether the registrar points to the correct nameservers.
Should I remove the AAAA record if I am not using IPv6?
Yes, if your new server does not support IPv6 and the old AAAA record still points to the previous server, removing it can prevent part of your traffic from reaching the wrong host.
Conclusion
If your website is still loading the old server, the issue is usually one of four things: DNS is still propagating, a cache layer is serving stale data, the domain is delegating to the wrong nameservers, or one record such as AAAA, www, or a subdomain was not updated. The fastest way to resolve it is to verify the current DNS target, compare it across networks, clear caches, and check the hosting control panel for the correct document root and server mapping.
In most cases, the problem is temporary and resolves once all DNS caches refresh. If the issue continues after the expected propagation window, review the full DNS zone and hosting configuration carefully, including IPv6 and any CDN or proxy service. For managed hosting environments, keeping the old and new servers available during the transition is often the safest way to avoid downtime and confusion.