Website not opening after a domain change: a layered checklist

When a newly connected domain fails to open, do not start by deleting every DNS record. Record the complete URL, the error, when it occurred and whether another network shows the same problem. Separate DNS, HTTPS, hosting routes and application behavior instead of describing every failure as propagation.

Confirm the exact hostname

The root domain, www and campaign subdomains are distinct hostnames. Binding example.com does not prove www.example.com is also bound. Check spelling, whether the browser is returning to an old address and whether the intended hosting project is public. Confirm that the DNS dashboard you edited is authoritative for the domain.

Separate missing answers from old answers

When there is no DNS answer, check the domain state, delegation and required records. When an old target is returned, compare authoritative answers with the recursive resolver actually used; caching may then be relevant. Repeatedly changing IP addresses or nameservers without a diagnosis makes the situation harder to understand.

If one network works and another fails, record that difference and inspect caching and the network path. A single local lookup does not represent every region, while a successful diagnostic tool does not invalidate an error in a real browser.

Check the hostname binding and certificate

HTTPS certificates must cover the requested hostname. If the host reports certificate validation in progress, inspect its validation requirements and binding status. Do not ignore a browser certificate warning and call the launch successful: visitors still face the problem. Check for records pointing to an old project or proxy settings conflicting with the intended hosting setup.

Distinguish routing problems from application errors

Publishing website files does not connect business APIs automatically. If the homepage works while domain search, login or payment fails, inspect that operation's endpoint and processing state. DNS changes cannot repair application logic.

Save a repeatable launch check

Record results for the final homepage, one article, an image, language switching and the relevant user action. For support, provide the complete URL, the time of the error and a description that excludes sensitive information. Never share passwords, verification codes or wallet recovery phrases. Retaining the previous deployment and configuration helps the team trace a new failure.

After fixing access, inspect canonical references, the sitemap and old URL redirects. A reachable website and a page indexed by a search engine are separate outcomes and should be validated separately.