Five practical fixes for common website errors

A blank page, a warning at checkout or a link that suddenly returns an error can interrupt a working day. Repeatedly clearing caches or changing hosting settings without a diagnosis often makes the situation harder to understand. Start by recording the affected address, the time, the action that failed and the message the browser displayed. A screenshot is useful, provided it does not expose customer details, passwords or payment information.

Work through these five areas in order. Check whether the problem affects one page, one browser, one signed-in account or the whole website. Before editing configuration, take a restorable copy and record the current values. For an online shop, avoid restoring an old database over new orders while investigating a display problem. The aim is to restore the specific service that failed while preserving transactions and evidence.

1. Match the HTTP response to the fault

An HTTP status describes the result of a request; it does not by itself identify the underlying cause. A 404 means the requested resource was not found. Check the exact spelling, case and trailing slash, then confirm that the page is published at that address. If a page moved permanently, redirect its old address to the closest genuine replacement. Do not send every missing page to the homepage: that leaves visitors unable to find the material they requested.

A 403 indicates that access was refused. Check publication visibility, account permissions, directory rules and any security rule attached to the request. A logged-in session does not grant permission to every resource. If only a particular customer or staff role is affected, compare its intended access with the application’s permission checks. Avoid making directories publicly writable as a shortcut, and do not disable an entire firewall simply to test one blocked form.

A 500 is a server-side failure. Look for the application or PHP error recorded at the same time as the request. A recent deployment, incompatible extension, exhausted resource or configuration error may be involved. In WordPress, use a staging copy to isolate a suspected plugin or theme. Preserve the existing configuration before editing rewrite rules. A 502 or 504 often involves a gateway and an upstream service; the host may need to inspect that connection rather than you changing the public DNS.

When reporting an error to support, include a reproducible sequence, the affected URL, the status and a redacted timestamped message. Say whether the failure began after an update. This is more useful than “the site is down”, and it reduces the risk of unrelated changes.

2. Investigate slow loading separately from a total failure

A page can return a successful response and still be difficult to use. Test its first load and a repeat visit, on a mobile connection as well as your office network. Browser developer tools can show whether time is spent waiting for the initial response, downloading a large image, running JavaScript or contacting a third-party service. Repeat tests before attributing a result to hosting: one slow run may reflect the test connection or a temporary external request.

Start with changes that address the measured bottleneck. Resize oversized photographs, use an appropriate compressed format and reserve image dimensions to reduce movement. Remove extensions and tracking scripts that the business no longer uses. Review database queries and scheduled tasks if the server is spending time generating pages. Enable caching only where it is compatible with the page’s purpose; account pages, carts and personalised prices require particular care.

A larger hosting plan may help when the application repeatedly reaches a genuine resource limit, but it will not repair an inefficient query or an unresponsive payment API. Keep a before-and-after record using the same page and test conditions. Verify that a faster-looking page still submits forms, calculates totals and displays current information correctly.

3. Repair broken links and missing assets

Run a link check after a redesign, migration or permalink change. Inspect navigation, footer links, product buttons, article references and images. A file may exist while its path is wrong, particularly when moving between servers with different case sensitivity. Check relative paths on a nested page rather than testing only the homepage. A link such as images/photo.webp may resolve differently inside a subdirectory.

Choose the remedy according to the content. Correct a typing error at its source. Update internal links to the final canonical address. Where an established page has moved, maintain a direct redirect and avoid chains through several old locations. If material has genuinely been removed without a replacement, provide a useful not-found page with navigation and search instead of inventing an unrelated destination.

For assets, check the response type as well as the address. A missing stylesheet can be served an HTML error page, which the browser will reject as CSS. Confirm that images load at their actual URLs and that a cache has not retained an old filename. When deploying a new version, keep asset references and their files together so a page does not request code that has already been deleted.

4. Resolve HTTPS and security warnings at their source

A certificate warning is not a normal inconvenience to click through. Check that the certificate covers the precise hostname, is within its validity period and is being served with the required certificate chain. Confirm the server clock and automated renewal process. If a CDN or reverse proxy is involved, check both the visitor-facing connection and the connection to the origin server.

Mixed content is a different issue: an HTTPS page may still request an image, script or stylesheet over HTTP. Update those references and test embedded services, fonts and form destinations. Do not suppress browser warnings or replace secure URLs with insecure ones. After a correction, verify both the main hostname and any www variant used by customers, including redirects between them.

Security software can also block a legitimate action. Capture the relevant request identifier or rule reference and ask the responsible administrator to investigate a narrow exception. Keep authentication and validation in place. A bypass that makes an administrator’s test work can expose the same action to everyone else.

5. Check the browser, mobile layout and application state

If the site works in one browser but fails in another, compare browser versions, cached assets, extensions and JavaScript console errors. Use a clean test profile to separate an extension conflict from an application fault. An incognito window can help diagnose cached state, but it is not a substitute for repairing incorrect cache headers or session handling.

On mobile, inspect the actual failed task: opening a menu, selecting a billing period, reading a tooltip or submitting a form. A button may be covered by another element even though it looks correct. Test keyboard navigation and visible focus too. Correct the stacking, sizing or event handling instead of placing another transparent click target over the problem.

Finally, test the complete customer journey after a fix. Confirm that an enquiry reaches its intended destination, a cart retains its contents and the confirmation page matches the action taken. Clear test records through the application’s normal recovery process. Keep a short incident note containing the cause, the change, the verification and any follow-up monitoring. That record makes the next fault quicker to diagnose and helps prevent an old deployment from reintroducing the same problem.