When your website displays an error, it can be tempting to change settings or reinstall something straight away. A better starting point is to establish what has stopped working, when it began and what changed beforehand. A 403, 404 or 500 error points to a different situation, even if the outcome looks similar to a visitor: they cannot use the page.
The steps below help you investigate without making speculative changes and prepare useful information if you need assistance.
1. What 403, 404 and 500 errors mean
403 error: access forbidden
An HTTP 403 status means the server understood the request but refuses access. Possible reasons include security rules, unsuitable permissions, restrictions affecting particular IP addresses, or a directory without an accepted entry file. Signing in does not necessarily resolve it.
404 error: resource not found
A 404 status means the requested resource was not found at that address. The URL might contain a mistake, the page might have been deleted or moved, or routing rules might no longer work. Some applications also use this status to conceal the existence of a protected resource.
500 error: an internal problem
A 500 status indicates an unexpected condition that prevents the request from being processed. The cause may involve the application, an extension, configuration or a dependency. The browser message alone is too general to identify the component responsible.
Important: the appearance of an error page does not necessarily confirm its HTTP status. A custom page might say “404” while returning a different code. If you use your browser’s developer tools, check the main page request in the network section, rather than just requests for images or scripts.
2. Establish the scope before changing anything
Start with checks that do not alter the website. Your aim is to find out whether the problem affects one page, a particular function or the entire site.
- Open the homepage and a few familiar internal pages.
- Compare the address with a previously working link. Check the domain, path, capitalisation and parameters.
- Try a private browsing window without active extensions to help separate browser or session effects.
- Where relevant, test another device or a different trusted network.
- Note whether the error occurs only after signing in, saving content, uploading a file or performing a particular action.
Do not repeat payments, form submissions or actions that could create duplicate records. If the problem occurs on just one network, that may suggest a restriction or a caching difference, but it does not establish the cause.
Record recent changes too: updates, newly installed extensions, a site migration, changed addresses or new security rules. A close match in timing is useful evidence for investigation, not automatic proof.
3. What to check for each error type
When access is forbidden
For a 403 error, check whether the area should be public and whether access restrictions were deliberately configured. If you have file access, you can inspect the entry file and permissions without automatically changing them. Appropriate permission settings depend on the server configuration.
Do not grant write access to everyone or disable protections simply to see whether the page starts working. A security rule needs investigation, not removal without understanding its purpose.
When a page cannot be found
For a 404 error, look for the page through the site navigation or the application’s content list. Check whether it is published, whether its address has changed and whether the broken link comes from your own site or elsewhere. If the homepage works but every internal page returns 404, routing deserves investigation.
Do not automatically redirect every missing page to the homepage. If content has moved, first identify the equivalent destination.
When there is an internal error
For a 500 error, review recent updates and component compatibility. In WordPress, a plugin or theme may be involved, but disabling components on the live site can affect important features. Prefer a test environment and a controlled change with a verified way to revert it.
For platform-specific context, you can explore the information about WordPress hosting. The hosting type does not, however, replace investigation of the application and its logs.
4. How to review error logs safely
Depending on your service and access level, you may have web server logs, application logs or logs from the process that runs your code. They may be available through an administration interface, as files or on request. Consult your service documentation and the frequently asked questions, without assuming every platform provides the same options.
- Record when the error occurred and the time zones used by your browser and the log.
- Look for entries around that time associated with the affected path.
- Check the response status, technical message and any request identifier.
- Keep only the relevant extract and the surrounding context needed to understand it.
An access log shows recorded requests and responses; an error log may provide clues about a failure. A nearby message is not necessarily the cause. A missing entry does not rule out the problem either: you may be looking at a different log, or the request may have been blocked before reaching the application.
Do not enable detailed error messages for public display. If additional logging is needed, follow the documented procedure, limit how long it runs and check where the data is stored. Do not publish raw logs, passwords, API keys, cookies, tokens, personal information or configuration files.
5. What to include when asking for help
A clear request can reduce follow-up questions. Include the following in your message:
- the affected address, with secret or personal information removed from its parameters;
- the observed HTTP status and the exact error message;
- the date, time and time zone, and whether the issue is constant or intermittent;
- steps to reproduce the issue, the expected result and what actually happens;
- the affected pages, checks already completed and recent changes;
- a sanitised log extract and a request identifier, if available.
Check screenshots as well: the address bar, notifications and administration area may reveal sensitive information. Keep originals somewhere secure and send only what is needed through the designated private channel. Do not include passwords in your initial message or publish administrative access details on forums.
6. The practical approach: observe first, then act
Start by identifying the status code, establish which pages are affected, and compare the timing with recent changes and available logs. Avoid editing configuration or restoring the site without understanding the impact and having a verified way to revert the action.
If you cannot identify the cause or cannot access the information you need, share your findings through the contact page. A short, specific report with sensitive details removed provides a better starting point than a series of speculative changes.
