Do not start by reinstalling or restoring
First record the exact URL, error, time and last change. A restore can overwrite good data and will not fix DNS, an expired domain, a network block or an exhausted resource limit.
Fast scope check
Test the same URL from a different connection
- Open the exact address in a private browser window.
- Try mobile data as well as Wi-Fi. If only one network fails, note its public IP.
- Check whether Plesk, webmail and other websites on the same service open.
- Confirm the domain is active and that its A/AAAA records point to the intended host.
- Record what changed immediately before the fault: plugin, PHP version, DNS, certificate, files or deployment.
Read the response
The browser code tells you where to look
- DNS or server not found
- Check registration, nameservers and A/AAAA records. Allow for recent DNS changes.
- 403 Forbidden
- Check permissions, security rules and whether your IP is blocked. Do not make files world-writable.
- 500 Internal Server Error
- Inspect the domain error log and recent PHP, plugin, theme or configuration changes.
- 503 Service Unavailable
- Check maintenance mode, process/resource limits and application health. Repeated refreshes add load.
- 522 Connection timed out
- A proxy such as Cloudflare cannot reach the origin. Confirm origin IP, firewall access and web service health.
- Certificate warning
- Use the SSL troubleshooting guide.
UKC-hosted website
Use Plesk to check storage, logs and the application
- Open the service from Client Area and confirm it is active rather than suspended.
- Check disk usage and subscription limits before changing code.
- Read the domain's latest error-log entries at the exact failure time.
- For WordPress, disable only the component implicated by the log and keep a recovery copy.
- Compare DNS with the assigned UKC server before changing hosting settings.
Protect evidence
Avoid changes that make recovery harder
Do not delete logs, overwrite the live site, change nameservers, clear every cache or run several restores at once. If compromise is suspected, preserve evidence and follow the hacked website recovery guide.
A strong fault report shortens recovery
Include the exact URL, HTTP code, first observed time, last known working time, networks tested, domain route, recent changes and a short error-log extract around the failure.
Website still unavailable?
Open one ticket with the evidence above and say whether email, Plesk and other sites on the service work. Do not send passwords or make parallel changes while the fault is being investigated.
Ask the Hosting team