How to fix a website that is not loading (2026)

Overview

A website that will not load can fail for several different reasons, and the fastest fix comes from narrowing down where the fault sits. In practice, most cases fall into a few groups: browser or device issues, local network or DNS problems, expired or broken SSL certificates, web server outages, application or database errors, or a bad change to code, plugins, themes, firewall rules, or hosting settings. The key is not to change everything at once. Test whether the site fails for only you or for everyone, then check whether the domain resolves correctly, whether the server responds, and whether the application itself is returning an error. If you manage the site, review recent changes first because many loading failures start immediately after updates, deployments, DNS edits, or security rule changes. If you do not manage the site, your useful checks are more limited: device, browser, cache, network, and public status checks. This guide focuses on a practical order of diagnosis, with fixes matched to the most common causes, so you can avoid wasting time on the wrong layer.

Who this is for

Website owners, developers, administrators, and non-technical users trying to work out why a website will not open or only partly loads.

What you’ll need

• Access to the website URL
• A second browser or device
• A second internet connection if possible, such as mobile data
• Access to hosting control panel, DNS provider, or server logs if you manage the site
• Recent deployment, plugin, theme, or configuration change history if available

Before you start

Check whether the problem affects one page or the whole site, one user or all users, and whether anything changed recently such as DNS records, hosting, SSL, plugins, code, or firewall settings. If the site handles live orders, bookings, or customer logins, avoid random fixes on production before checking logs and making a backup or rollback plan.

Step-by-step

1. 1

   Confirm who is affected

   Open the site on another browser, another device, and another network if possible. Ask a colleague in another location to test it, or use a reputable public status checker. Note exactly what happens: blank page, timeout, DNS error, certificate warning, redirect loop, or server error.

   Why: This tells you whether the fault is local to your device or network, or whether the website itself is down for everyone.

2. 2

   Rule out browser and local device problems

   Hard refresh the page, open it in a private window, disable extensions for the test, and clear browser cache if the issue persists. If only one browser fails, update it and test again. If mixed content or blocked scripts appear in browser developer tools, review recent front-end changes.

   Why: Corrupt cache, stale assets, extensions, and browser-specific issues can stop a site loading even when the server is healthy.

3. 3

   Check DNS and domain status

   Verify that the domain has not expired and that the DNS records point to the correct host. Use your DNS provider’s dashboard or command-line tools such as nslookup or dig to confirm the domain resolves consistently. If you recently changed DNS, wait for propagation and avoid making further edits unless you know they are wrong.

   Why: If the domain does not resolve to the correct server, the browser cannot find the website at all.

4. 4

   Test SSL and the basic server response

   Check whether the site loads over HTTPS and whether the certificate is valid for the domain. Inspect the response headers with your browser tools or a command-line request to see whether the server returns a normal response, a redirect loop, or an error code. If the certificate is expired, misconfigured, or missing an intermediate chain, renew or reinstall it through your hosting or certificate provider.

   Why: Many modern browsers will block access or show severe warnings when HTTPS is broken, and redirect mistakes can trap visitors in loops.

5. 5

   Review server health and logs

   If you manage the hosting, check whether the web server, application runtime, and database are running, and whether resource limits have been hit. Review access and error logs around the time the problem started. Look for application crashes, database connection failures, permission errors, blocked requests, or exhausted memory or worker limits.

   Why: Logs usually show whether the request reaches the server and what fails next, which is the quickest route to the right fix.

6. 6

   Undo recent changes safely

   If the issue started after a deployment, plugin update, theme change, configuration edit, firewall rule, or CDN setting change, roll back that specific change first. Disable new plugins or custom code one at a time, switch to a known-working configuration if your platform supports it, and redeploy only after confirming the site loads.

   Why: A recent change is often the cause, and targeted rollback is faster and safer than guessing across multiple systems.

7. 7

   Check external dependencies and security layers

   Test whether the issue is caused by a CDN, web application firewall, third-party scripts, APIs, or payment or login providers. Temporarily bypass the CDN if your setup allows it, review firewall events for blocked legitimate traffic, and remove or defer failing third-party scripts that block page rendering.

   Why: A site can appear down even when the origin server is healthy if an external layer blocks or breaks requests.

8. 8

   Escalate with evidence

   If you still cannot identify the cause, gather the URL, exact error message, time of failure, screenshots, recent changes, DNS details, SSL status, and relevant log extracts. Send these to your host, developer, platform support, or network administrator.

   Why: Clear evidence shortens diagnosis time and reduces the risk of support teams asking you to repeat checks you have already done.

Why this works

Website loading depends on a chain: browser, network, DNS, HTTPS, server, application, and external services. Troubleshooting in that order helps you isolate the broken link instead of making unrelated changes.

Common mistakes to avoid

• Changing DNS, hosting settings, plugins, and code all at once, which makes the real cause harder to find
• Ignoring the exact error message and only describing the site as down
• Clearing server caches or restarting services before saving logs or noting when the issue began
• Assuming it is a server problem when the fault is only in one browser, extension, or local network
• Renewing a certificate without checking whether the domain, redirect rules, and certificate chain are all correct

Troubleshooting

Compare your options

Alternatives

• Restore the site from a known-good backup if a recent change clearly caused the failure and a clean rollback is not possible
• Temporarily serve a maintenance page from your hosting or CDN while you investigate a deeper application fault
• Fail over to a standby environment if your setup supports high availability

Pro tips

• Write down the exact wording of any error message before refreshing or changing settings
• Check the simplest recent change first, especially plugin updates, deploys, DNS edits, and firewall rules
• If the site is business-critical, announce a maintenance status message rather than leaving users with repeated failures
• Keep DNS, SSL, hosting, and deployment access details documented so you can act quickly during an outage
• Use one change at a time during testing so you know which fix actually worked

Safety notes

• Do not disable security tools permanently just to make the site load; if you must test without them, re-enable them immediately after diagnosis
• Back up site files and databases before major rollback or repair work
• Avoid editing production configuration without a record of the previous settings
• Protect logs and screenshots that may contain personal data, session details, or internal system information

Legal & regulatory notes

If the website handles personal data, payments, health information, or regulated services, outage handling may involve contractual, privacy, or incident-reporting duties. Follow your organisation’s data protection, security, and customer communication obligations and use your official legal or compliance guidance for the exact requirements.

Cost considerations

Simple fixes such as browser, cache, DNS, or certificate corrections may cost little beyond staff time. Costs usually rise when the cause is emergency developer work, premium hosting support, prolonged downtime, SSL replacement through a paid provider, malware cleanup, or infrastructure scaling.

Frequently asked questions

Sources & references

Guidance on this page is traced to documented sources. Last checked 25 September 2026.

• MDN Web Docs · industry

  Supports using browser developer tools to inspect network failures, console errors, and blocked assets when a page does not load correctly.

• ICANN · industry

  Supports checking domain registration details and status as part of diagnosing domain and DNS-related loading failures.

• Let's Encrypt · industry

  Supports checking SSL certificate validity, renewal, and HTTPS configuration issues that can prevent browser access.

Related guides