Why Is My Domain Pointing to the Wrong Website? A Four Layer Trace
A domain that loads someone else's site, an old version of your site, or a hosting company's placeholder is almost always a lookup problem rather than a hosting problem. Something in the chain from your registrar to the visitor's browser is producing the wrong answer, and there are only four places it can be happening.
This article traces those four layers in order: the delegation that says which nameservers answer for your domain, the records those nameservers return, the server that receives the request, and the caches sitting in front of the visitor. Working top down matters, because a problem at a higher layer makes everything below it look wrong.
Layer one: the delegation
Start here, because if this is wrong nothing else you check will make sense.
Your registrar holds a list of nameservers for your domain and passes it to the TLD registry, which publishes it. Resolvers ask the registry which nameservers to use, then ask those nameservers for your records. If the delegation points at nameservers you are no longer using, every change you make at your actual DNS provider is invisible, because nobody is asking that provider anything.
This is the single most common cause of the specific symptom where edits appear to have no effect at all. You update an A record, wait, check, and see the old destination. The record is correct where you set it, and resolvers are reading a different set of nameservers that still hold whatever was configured there months ago.
The check is to look up your domain's nameservers directly and compare them against the ones your DNS provider tells you to use. A mismatch is your answer and the fix is at the registrar. Note that this can also fail in a subtler way after a provider migration, where the old nameservers still exist and still answer, so you get a confident wrong answer instead of a failure. Our guide to DNS lookups covers how to read each stage of the chain.
Layer two: the records
If the delegation is correct, look at what those nameservers are actually returning.
The usual culprits are ordinary and easy to miss. An A record still pointing at an old host after a migration. A CNAME on the apex or on www pointing somewhere stale. Both an A record and a CNAME configured for the same name, where the resolver picks one and you were looking at the other. Multiple A records for the same name, left over from a transition, where resolvers round-robin between old and new so the site loads correctly about half the time.
That last pattern deserves attention because it is the one people misdiagnose most often. Intermittent wrongness, where refreshing sometimes fixes it, looks like caching and is frequently duplicate records instead. Caching produces a consistent wrong answer for a given resolver until it expires. Duplicate records produce an inconsistent answer from the same resolver on consecutive queries, which is a distinguishable pattern once you know to look for it.
Check the apex and www separately, because they are separate names and are routinely configured differently. A domain that works with www and fails without it, or the reverse, is telling you the two names resolve differently, which narrows the problem immediately.
Layer three: the server
If DNS is returning the address you expect and the wrong site still loads, the address is right and the server is choosing the wrong content. This is virtual hosting behaviour, and it is why a domain can land on a completely unrelated website.
A single IP address typically hosts many sites. The web server decides which one to serve by reading the Host header, matching it against its configured virtual hosts. If your domain is not configured on that server, the request matches nothing, and most servers fall back to a default site. That default might be another customer's site, a hosting placeholder, or whatever happens to be first in the configuration. The DNS is working perfectly and the server simply does not know your domain is supposed to be there.
Shared hosting and CDN platforms produce a specific version of this. Pointing a domain at a platform requires adding the domain inside the platform as well, and doing only the DNS half is a two step process with one step done. The symptom is characteristic: you reach the platform, which cheerfully tells you the site is not configured, or shows you someone else entirely.
Certificate warnings are a useful confirming signal here. If the browser complains that the certificate is for a different hostname, you have proof you reached a server that thinks it is somebody else, which is a server configuration problem rather than a DNS one.
Layer four: the caches
Only after the first three check out is caching worth investigating, and it is worth being skeptical even then.
There are several caches between a change and a visitor: the browser's own, the operating system's, the recursive resolver's, and any CDN in the path. The resolver is the one that matters, because it is the only one you cannot clear and the only one holding an answer for many people at once. Clearing your own browser and OS caches only forces your machine to re-ask the resolver, and if the resolver holds the stale answer, you get it straight back.
The clean test is to query the name against a public resolver directly and compare that with what your own resolver returns. Two different answers confirm caching and tell you which side is stale. The same wrong answer from both means the authoritative data is wrong and you should go back to layer two.
Timing bounds the possibility. An ordinary record change clears within one TTL, so if your TTL was an hour and it has been a day, caching is not your explanation. A nameserver change is the exception, because the delegation is cached in the parent zone at the registry's TTL, commonly forty-eight hours for .com. Our post on DNS propagation timing covers which clock applies to which change.
Common mistakes in diagnosing a misdirected domain
Editing records at a provider that is not authoritative. If the delegation points elsewhere, your changes are correct and irrelevant. Check the nameservers before changing anything else.
Assuming intermittent means caching. A resolver serves a consistent answer until its TTL expires. An answer that changes between consecutive queries usually means duplicate or conflicting records rather than a cache.
Checking only the apex or only www. They are different names with separate configuration. Testing both is a two second step that frequently isolates the problem on its own.
Flushing local caches as a first move. It clears your machine, not the resolver everyone else is using. It also destroys the comparison that would have told you where the stale answer lives.
Forgetting to add the domain at the platform. Pointing DNS at a host is half the job. Without the domain configured there too, you reach the right server and get its default site, which is often someone else's.
FAQ
Why is my domain pointing to the wrong website?
Most often because the delegation still points at old nameservers, so your record edits are being made somewhere nobody is asking. The other common causes are a stale or duplicate record, and a server that has no virtual host for your domain and falls back to a default site.
Why does my domain show another company's website?
That is usually virtual hosting. Many sites share one IP, the server picks one by matching the Host header, and if your domain is not configured there the request falls through to whatever default exists, which can be another customer's site.
Why does my domain work sometimes and not others?
Consecutive queries returning different answers usually means multiple conflicting records, often an old and a new A record left in place together, with resolvers alternating between them. Consistent wrongness that clears later is caching instead.
Does clearing my DNS cache fix a domain pointing to the wrong site?
Rarely. It only forces your own machine to re-ask its resolver, and if the resolver holds the stale answer you receive the same result. It also removes the comparison that would show you where the wrong answer originates.
Closing thought
The reason this problem feels so opaque is that every layer produces roughly the same symptom, which is a browser showing the wrong thing. Tracing top down converts that into a sequence of yes or no questions with a definite answer at each step, and it almost always resolves within the first two. The instinct to start at the bottom, clearing caches and refreshing, is the one to resist, because it is both the least likely cause and the step that destroys your best diagnostic comparison.
Once it is pointing where it should, the useful question becomes whether it stays there. Odown checks from seventeen locations on every plan at intervals down to one minute, which matters here specifically because a domain resolving correctly from your desk and incorrectly from another continent is exactly the pattern a single manual check will never reveal. A misdirected domain that only affects some of the world is still a misdirected domain.
