Common website faults and sensible fixes

‘The website is broken’ is not a diagnosis. Record the exact address, time, device, browser, action and message. Check whether the fault affects one page, one user or everyone, and ask whether anything changed shortly beforehand. Save a screenshot and, for an email problem, the delivery or rejection details. This small evidence pack avoids random edits and helps a host or developer reproduce the issue. Do not clear logs, reinstall software or change DNS merely to see what happens.

A form can display a success message while the email never arrives. Submit a clearly labelled test, inspect the destination mailbox and spam folder, and confirm the configured recipient. Check whether the form stores submissions and whether its mail service reports rejection. Publish an alternative contact route while investigating. The durable repair may involve authenticated sending, corrected DNS mail records or a third-party service, but those changes should be planned with whoever manages business email. Never use a real customer’s personal data as test material.

For a blank page, layout collapse or certificate warning, try another network and browser before concluding the server is down. Check the host’s status and recent deployments. An expired certificate, full storage account, plugin conflict and domain/DNS problem require different owners. Restore from a known backup only after preserving evidence and confirming that the backup predates the fault. A restore can overwrite valid orders, enquiries or edits, so it is not a harmless first move.

Broken links should point to the intended live destination or be removed; redirect an old address only to a genuinely equivalent page. For mobile menus, overlapping controls or unreadable text, identify the shared template or style causing the fault rather than patching every page. Keyboard and zoom tests help reveal whether the problem is broader than one screen size. W3C guidance offers testable accessibility criteria, while the visible symptom gives the developer a focused reproduction case.

Before a code, plugin, DNS or database change, take an appropriate backup and note the starting state. Make the smallest justified change, then repeat the original steps on the live site. Also test a neighbouring function to catch side effects: after repairing a form, try its validation and confirmation; after a redirect, inspect the target and navigation. Record the fix, date, person responsible and rollback route. If ownership, security or data loss is uncertain, stop experimenting and escalate with the evidence already collected.