Website unreachable: systematically diagnosing hosting errors

If your website suddenly becomes unreachable, it can have very different causes. Examples include DNS problems, incorrect domain assignment, SSL issues, PHP errors, a faulty .htaccess, WordPress issues, or reached resource limits.

Therefore, the crucial thing is not to change settings immediately, but first to determine, at which technical level the error occurs.

This guide walks you through the most important checks in CURIAWEB web hosting step by step and helps you narrow down the cause.

Important: „Website not reachable“ is initially just the visible symptom. Note the exact error message before you make any changes to DNS, PHP, WordPress, or your hosting.

What does „website not reachable“ actually mean? #

To visitors, many technical problems look similar: the desired website is not displayed.

Technically, however, completely different errors could be behind this:

Domain not resolving
        ↓
DNS problem

Domain points to wrong server
        ↓
DNS/configuration problem

HTTPS connection fails
        ↓
SSL/certificate problem

403 Forbidden
        ↓
Access denied

404 Not Found
        ↓
Resource not found

500 Internal Server Error
        ↓
Server-side processing fails

503 Service Unavailable
        ↓
Service temporarily unavailable

508 Resource Limit Is Reached
        ↓
CloudLinux resource limit reached

That is why we do not begin the diagnosis with a repair, but with an assessment.

1. Note down the exact error message #

Open the website and note down exactly what is displayed.

Examples:

Server not found

DNS_PROBE_FINISHED_NXDOMAIN

ERR_NAME_NOT_RESOLVED

ERR_CONNECTION_TIMED_OUT

ERR_CONNECTION_REFUSED

ERR_TOO_MANY_REDIRECTS

403 Forbidden

404 Not Found

500 Internal Server Error

503 Service Unavailable

508 Resource Limit Is Reached

You should not simply summarize a certificate warning as „website offline“ either.

The more precise the report, the faster the cause can be narrowed down.

2. Note the affected URL #

Also note the complete URL.

For example:

https://example.ch

or:

https://www.example.ch

or:

https://shop.example.ch

This is important because it's the main domain, www-hostname and subdomains can use different DNS records or configurations.

3. Check if the entire website is affected #

Test several areas of the website.

For example:

https://example.ch/
https://example.ch/kontakt/
https://example.ch/wp-admin/

Check:

• Is no URL reachable at all?
• Does the home page work, but a subpage does not?
• Does the frontend work, but the admin area does not?
• Is only one subdomain affected?
• Is only a specific function affected?

If only a single page fails, a complete hosting outage is much less likely.

4. Check if only you are affected #

Test the website in a private browser window and, if possible, also via a different internet connection.

A simple comparison might look like this, for example:

WLAN → Website not reachable
Mobile network → Website works

Then you should consider that the problem might only affect your connection, your DNS resolver, or your public IP address.

Practical Tip: A mobile network test is particularly useful because it typically gives you a different internet connection and a different public IP address.

5. Check if cPanel is accessible #

If your website is not working, but cPanel is still accessible, you can start troubleshooting right there immediately.

Working cPanel access doesn't prove that the website is configured correctly, but it does show that your hosting account is basically reachable.

That helps narrow it down.

6. Check domain and DNS as the first technical layer #

Before a website can be accessed, the domain name must be resolved.

Simplified:

example.ch
    ↓
DNS
    ↓
IP address
    ↓
Web server
    ↓
Website

If DNS resolution already fails, the request does not even reach the website.

Typical signs of a DNS problem #

Messages such as:

DNS_PROBE_FINISHED_NXDOMAIN

ERR_NAME_NOT_RESOLVED

Server not found

point more toward name resolution than PHP or WordPress.

In this case, you shouldn't disable plugins or change PHP settings first.

7. Account for recent DNS changes #

If DNS records or nameservers were changed immediately before the problem occurred, this temporal connection is particularly important.

DNS changes cannot become visible everywhere at the same time due to caches.

Therefore, check:

• Have the nameservers been changed?
• Has an A or AAAA record been changed?
• Has a CNAME been changed?
• Has the domain recently been switched to different hosting?
• Has a new subdomain been set up?

We explain how to control DNS records within cPanel under Using the DNS Zone Editor in cPanel.

8. Check if cPanel is even responsible for DNS #

The DNS zone in your cPanel is only relevant if the domain is actually using the corresponding authoritative nameservers or this DNS infrastructure.

If DNS management is handled by an external provider, you must make changes there.

Important: A change in the cPanel Zone Editor has no effect on public DNS resolution if a different DNS infrastructure is authoritative for the domain.

9. Check domain mapping in cPanel #

If the domain points correctly to the hosting server, it must also be set up correctly within the hosting account.

Open:

Domains → Domains

Check if the affected domain exists and which document root is being used.

You can find the complete instructions at Add and manage a domain in cPanel.

10. Check Document Root #

The document root defines the directory from which the web server serves the website for a domain.

Example:

Domain:
example.ch

Document Root:
/public_html/example/

If the actual website is located in a different directory, the domain may deliver incorrect content or no content at all.

Therefore, check whether the configured Document Root actually contains the website files.

11. Check start file #

Open:

Files → File Manager

Change to the document root of the affected domain.

Check if there is a suitable start file available, for example:

index.php
index.html

If the website files are missing or located in an incorrect subdirectory, the web server cannot serve the expected website correctly.

We explain how to use it at Use cPanel File Manager.

12. Check if files have been recently moved or deleted #

If the website went down immediately after work in the file manager, check in particular:

• Were files moved?
• Has a directory been renamed?
• Was a index.php Deleted?
• Was an archive extracted to the wrong directory?
• Has the .htaccess Changed?

Always start troubleshooting with the most recent change.

13. Check HTTPS and SSL separately #

If the domain is basically reachable, but the browser displays a certificate warning, it is a different error class than a 500 or 503 error.

Typical notices include, for example:

• Certificate expired
• Certificate does not match the hostname
• Certificate is not recognized as trusted
• Cannot establish a secure HTTPS connection properly

In this case, specifically check the SSL configuration and not PHP, WordPress, or CloudLinux on suspicion.

Test www and domain without www separately #

Test:

https://example.ch

and

https://www.example.ch

If only one variant works, you should check DNS, SSL, and redirects for the affected hostname.

A working main domain does not automatically prove that also www correctly configured.

15. Detect redirection loops #

If the browser displays a message like:

ERR_TOO_MANY_REDIRECTS

is displayed, the request is repeatedly redirected between URLs.

Simplified:

URL A → URL B
          ↓
        URL A
          ↓
        URL B
          ↓
        ...

In this case, check redirects in cPanel, the .htaccess and, if applicable, within your web application.

We explain how to set up cPanel redirects at Set up domain redirection in cPanel.

16. Using HTTP status codes as guides #

If the domain resolves and the web server returns a specific HTTP error message, you should base your further diagnosis on the status code.

Status	Further diagnosis
403	Access rights and security rules
404	URL, file, or rewrite/permalink configuration
500	Error log, PHP, application, and .htaccess
503	Service, application, processes and resources
508	CloudLinux resource limits

17. 403 Forbidden #

A 403 Forbidden means that access to a resource is denied.

Typical inspection areas are:

• File permissions
• .htaccess
• IP blocks
• ModSecurity
• Safety features

Use this for it Fix 403 Forbidden.

18. 404 Not Found #

A 404 Not Found basically means that the requested resource was not found.

If the homepage works, but individual WordPress pages generate a 404, the permalink or rewrite rules, for example, may be involved.

For WordPress, you can find the appropriate guide under Fix WordPress 404 error.

19. 500 Internal Server Error #

A 500 Internal Server Error indicates an error in server-side processing.

The status code itself does not yet state the cause.

Check in particular:

• cPanel Error Log
• PHP Fatal Errors
• .htaccess
• PHP version
• PHP extensions
• Plugins and Themes
• PHP limits

You can find the complete diagnosis at Fixing a 500 Internal Server Error.

20. 503 Service Unavailable #

A 503 Service Unavailable means that a service is currently unable to successfully process the request.

Of particular importance in the case of recurring 503 errors are:

• Error Log
• CloudLinux resources
• PHP processes
• Cron jobs
• WordPress and WooCommerce background tasks
• Maintenance states

Use this for it Fix 503 Service Unavailable.

21. Resource Limit Is Reached #

If a message such as:

508 Resource Limit Is Reached

is displayed, you should investigate the CloudLinux resource usage.

You can find the appropriate instructions at Resource Limit Is Reached: Identify and Fix CloudLinux Limits.

22. Check cPanel Error Log #

In the case of server-side errors, the error log is one of the most important diagnostic points.

Open:

Measured values → Errors

Reproduce the error and then compare the timestamp with the latest relevant entries.

You can find our detailed guide at Read cPanel Error Log and find website errors.

Practical Tip: The newest log entry doesn't automatically have to be related to your problem. Compare the timestamp, URL, file path, and error message with each other.

Use recent changes as a diagnostic aid #

If a website used to work, ask yourself:

What was changed immediately before the outage?

Examples:

• WordPress is updating
• Plugin updated
• Theme changed
• PHP version changed
• .htaccess edited
• DNS changed
• Domain redirected
• Files moved
• Website migrated
• Cron job set up

A close temporal correlation is often more valuable than a long list of theoretically possible causes.

24. Check .htaccess #

A faulty .htaccess can cause various issues, including redirect loops, 403, or 500 errors.

If the problem started immediately after making a change to this file, check that exact change first.

We explain how to do this safely at .htaccess explained and safely edited.

25. Check file permissions #

If files or directories are not provided with appropriate permissions, the web server may not be able to access them correctly.

For typical websites, the following values can often be found:

Files:       644
Directories: 755

However, these values should not be blindly applied to all content.

You can find the complete instructions at How to correctly set file permissions 644 and 755 in cPanel.

Attention: Do not set files and directories globally to 777, just because the website is not working. That is not clean troubleshooting and can cause security risks.

26. Check PHP version #

If a PHP-based website stops working after a PHP version change, check the version being used and the compatibility of the application.

In CURIAWEB, you generally manage the PHP version via:

Software → MultiPHP Manager

You can find the instructions under Change PHP version in cPanel.

Do not switch PHP versions randomly. Check the error log and your application's requirements first.

27. Consider PHP extensions #

After a PHP version change or a migration, an application may require functions that are not available in the PHP environment being used.

Typical error messages include, for example:

Call to undefined function ...

Class ... not found

requires ext-...

You can find more information at Enabling and Managing PHP Extensions in cPanel.

28. Check PHP limits #

If an error occurs only during certain resource-intensive actions, PHP limits may be relevant.

Examples are:

memory_limit
upload_max_filesize
post_max_size
max_execution_time
max_input_time

If the error log, for example:

Allowed memory size exhausted

reports, that is a concrete indication of the PHP memory limit.

We explain the settings under Set PHP memory limit, upload size, and execution time.

29. Controlling CloudLinux Resources #

If the website is only intermittently unavailable, you should check the resource utilization at the same time.

Open:

Metrics → Resource Usage

Check in particular whether faults or conspicuous values are present.

We explain how to interpret the data at Understanding CloudLinux Resource Usage in cPanel.

30. Check storage space #

A fully occupied hosting account can impair various writing processes.

Depending on the application, this can include, for example:

• Uploads
• Updates
• Cache files
• temporary files
• Logs
• Backups
• Email storage

You can check the storage space usage under:

Files → Storage usage

You can find more information at Check disk space and bandwidth in cPanel.

31. Isolate WordPress as a potential source of errors #

If other content or domains work in the hosting, but a specific WordPress installation does not, you should investigate the application itself.

Typical areas are:

• Plugins
• Themes
• WordPress Core
• .htaccess
• PHP compatibility
• Database
• individual code

32. WordPress critical error #

When WordPress reports:

There has been a critical error on your website.

there is often a PHP error within WordPress, a plugin, theme, or custom code.

Use this for it Fix WordPress critical error or white screen.

33. Check WordPress plugins and themes #

If the problem began immediately after the installation, activation, or update of a plugin or theme, this chronological correlation is important.

Check the error log for paths like:

/wp-content/plugins/...
/wp-content/themes/...

We explain the systematic diagnosis at Identify and resolve WordPress plugin and theme conflicts.

34. Using WordPress debugging #

If the standard error log does not provide enough information, controlled WordPress debug logging can provide additional clues.

WordPress can find errors, for example, under:

wp-content/debug.log

log.

We explain the secure setup at Using WordPress debugging and error logs.

35. Test WordPress login separately #

If only the registration at:

https://example.ch/wp-admin

or rather

https://example.ch/wp-login.php

not working, but the public website is accessible, it is not a complete website outage.

Use in this case WordPress login is not working.

36. Consider cron jobs and background tasks #

If the website regularly shows problems at the same time, you should check scheduled processes.

Open:

Advanced Options → Cronjobs

Compare the time with:

• Cron jobs
• Important
• Export
• Backups
• Synchronizations
• WordPress background tasks

For problems with a cron job, you can find the appropriate guide under Cron job not working: Causes and solutions.

Website only temporarily unavailable #

For sporadic outages, the exact time is particularly important.

Document multiple events:

09:14 → unreachable
11:37 → unreachable
15:02 → unreachable

Then compare these points in time with:

• Error Log
• CloudLinux resources
• Cron jobs
• Background tasks
• unusual traffic

Without timestamps, sporadic issues are significantly harder to diagnose.

Website always unreachable at the same time #

A recurring time pattern often indicates a planned or regularly occurring process.

For example:

02:00 → Backup
02:00 → Import
02:00 → Synchronization
02:01 → Website not responding

That doesn't prove yet which process is the cause, but it provides a concrete starting point.

39. Website unreachable after update #

If the problem starts immediately after an update, check the updated component first.

This applies in particular to:

• WordPress
• Plugins
• Themes
• PHP version
• individual application components

Additionally, check the error log for a matching error.

40. Website not accessible after migration #

Following a migration, multiple layers could be the cause.

Check in a logical order:

Domain
  ↓
DNS
  ↓
correct server
  ↓
domain in cPanel
  ↓
document root
  ↓
files
  ↓
SSL
  ↓
PHP version
  ↓
PHP extensions
  ↓
application
  ↓
database

Do not jump straight to WordPress plugins if the domain still points to the old server.

41. Check database connection #

Many content management systems and web applications require a database.

If the application explicitly reports a database error, check:

• Database name
• Database user
• Assigning the user to the database
• Permissions
• application configuration file

We explain how to merge users and databases in cPanel at Create MySQL user and assign to a database.

Do not modify the database on suspicion #

A general website outage is no reason to delete, empty, or manually modify database tables.

Do not modify the database until there is a specific indication of a database problem.

42. Check if only a single domain is affected #

If multiple domains are operated in the same hosting account, a comparison can be very helpful.

Example:

domain-a.ch → works
domain-b.ch → works
domain-c.ch → unreachable

Then a complete failure of the hosting account is less likely.

Focus the diagnosis on:

• DNS of domain-c.ch
• Domain mapping
• Document Root
• SSL
• Files
• Application of this domain

43. Check if all domains are affected #

If all websites in a hosting account go down simultaneously, the diagnosis broadens.

Then check in particular:

• whether cPanel is accessible
• what error message the domains return
• whether all domains use the same nameservers
• CloudLinux resources
• Storage space
• shared changes to PHP or configurations

If several independent websites show the exact same error pattern at the same time, you should definitely mention this circumstance in a support request.

44. Properly categorizing connection timeouts #

A message like:

ERR_CONNECTION_TIMED_OUT

is not the same as an HTTP 500.

With an HTTP 500, an HTTP response has already been received from the server. In contrast, in the event of a connection timeout, the connection or request could not be completed in time.

Therefore, note the exact browser error.

45. Correctly Classify Connection Refused #

A message like:

ERR_CONNECTION_REFUSED

also differs from a normal application error.

The browser was unable to establish the requested connection as expected.

The same applies here: Do not change WordPress plugins or PHP settings before it is clear that the request even reaches the corresponding web application.

46. Isolate browser cache as a source of error #

Test the website additionally in a private browser window.

If necessary, use a second browser or another device.

With that you can rule out certain local effects.

However, a browser cache does not cause a genuine server-side PHP fatal error and does not lift a server-side access restriction.

47. Consider local DNS cache #

After DNS changes, your device or DNS resolver may still have older information cached.

If the website is already reaching the new server via mobile data, but not yet via your normal internet connection, a DNS cache may be playing a role.

In this case, do not automatically wait for any fixed number of hours. The actual cache duration depends, among other things, on the respective DNS record and its TTL.

48. Do not change DNS immediately when an HTTP error appears #

For example, if your website already:

500 Internal Server Error

is displayed, a web server was reached.

Although DNS can still point to the wrong server after a migration, a real HTTP error should first be diagnosed on the server actually reached.

49. Do not change PHP immediately if DNS is not working #

Conversely:

If the domain does not resolve at all, switching from PHP 8.x to another PHP version will have no effect on this DNS issue.

The sequence of the diagnosis therefore saves a lot of time.

50. Do not disable all security features #

When access is denied, you should not disable ModSecurity, security plugins, or other protection mechanisms across the board.

In the event of a 403, it should first be determined which specific rule or access control is involved.

51. Do not change multiple things at the same time #

A typical bad debugging process looks like this:

Website unreachable
        ↓
Change DNS
Switch PHP
Delete .htaccess
Deactivate plugins
Change permissions
Install cache

If the website works again after that, you don't know which change was relevant – and you may have created new problems.

The better approach:

Determine the error precisely
        ↓
Narrow down the technical layer
        ↓
Check logs and metrics
        ↓
Formulate a concrete hypothesis
        ↓
Make a change
        ↓
Test again

Basic rule: Work from the outside in: domain and connection first, then web server and HTTP status, and finally PHP and application. This way, you avoid making changes at a technical level that have nothing to do with the actual problem.

Website unreachable: Diagnosis in the correct order #

1. Note the complete URL and exact error message.
2. Check multiple pages or areas of the website.
3. Test using a private browser window.
4. Test via a second internet connection if possible.
5. Check if cPanel is reachable.
6. Classify a potential DNS error.
7. Account for recently made DNS or nameserver changes.
8. Check the domain under Domains → Domains.
9. Check the document root.
10. Check the file manager to see if the website files are there.
11. Distinguish SSL issues from HTTP errors.
12. Check the actual HTTP status code.
13. Open on server-side errors Measured values → Errors.
14. Compare the error with recently made changes.
15. Check if necessary .htaccess and file permissions.
16. Check PHP version, extensions, and limits in PHP applications.
17. Check WordPress plugins, themes, and debug logs.
18. Check the CloudLinux resources in case of sporadic issues.
19. Take cron jobs and background tasks into account.
20. Check the storage space.
21. Always change only one possible cause at a time.
22. Then test the exact same error pattern again.

Quick diagnosis: Where should you start? #

Error pattern	First checkpoint
DNS_PROBE_FINISHED_NXDOMAIN	Check domain and DNS
Website shows wrong content after DNS change	Check DNS target and document root
Certificate warning	Check SSL certificate and hostname
ERR_TOO_MANY_REDIRECTS	Check redirects and .htaccess
403 Forbidden	Check permissions and security rules
404 Not Found	Check URL, files, or rewrite rules
500 Internal Server Error	Check error log and PHP/application errors
503 Service Unavailable	Check error log, application, and resources
508 Resource Limit Is Reached	Check CloudLinux resources
only WordPress admin area broken	Check WordPress, plugins and error log
only unreachable at certain times	Check resources and background tasks
only unreachable via own internet connection	Check local network, DNS and potential IP block

What you shouldn't do during a website outage #

Avoid in particular:

• Change DNS records on suspicion
• Switch PHP versions randomly
• .htaccess delete without backup
• File permissions across the board to 777 put
• disable all security features
• delete multiple plugins at once
• modifying database tables on suspicion
• reconfigure SSL certificates even though there is a PHP error
• perform multiple technical changes simultaneously

What information helps CURIAWEB support? #

If you cannot isolate the cause yourself, as precise information as possible will help with the technical analysis.

Note:

• affected domain
• full affected URL
• exact error message
• Date and exact time
• whether the website is permanently or sporadically unavailable
• whether only one page or the entire website is affected
• whether other domains work in the same hosting
• whether the website can be reached via another internet connection
• relevant error log entries
• Unusual CloudLinux values or faults
• recent changes

For a reproducible error, you should also provide the exact steps that can be used to trigger the issue.

Summary #

If a website is down, you shouldn't immediately make changes to WordPress, PHP, or DNS. First, you need to determine at what technical level the error is occurring.

Start with the exact error message and the affected URL. Then check whether only you, a single page, a domain, or the entire hosting account is affected.

In case of DNS errors, name resolution must be investigated first. If the web server is reached, HTTP status codes such as 403, 500, 503, or 508 serve as guides for further diagnosis.

For server-side issues, the cPanel Error Log and—in the case of sporadic errors—CloudLinux resource usage are among the most important diagnostic tools. For PHP applications, the PHP version, extensions, and limits also come into play. For WordPress, you should additionally consider plugins, themes, and debug logs.

The temporal context is always particularly valuable: when the website [crashes/stops working] immediately after a DNS change, a PHP switch, plugin update, or a change to the .htaccess has failed, begin the investigation right there.

The most important rule is: First determine where the request fails – then investigate precisely that technical layer.