“The website is broken” may describe a missing image, a failed login or a button that does nothing. Before changing settings, turn the complaint into one example that another person can follow. The example is the measuring instrument for the rest of the investigation.
Write the exact page address, whether the visitor is logged in and the action that triggers the problem. State the expected result separately from the observed result. “The menu should open the services page, but opens the homepage” is clearer than “navigation is wrong.”
Include the relevant environment without collecting everything. A phone-only layout issue needs the screen context and browser. A publishing error needs the editor's role and the affected content type. An intermittent failure benefits from an approximate time and a note about how often it occurs.
If an article contains many custom blocks, make a test copy and identify the smallest combination that reproduces the issue. Preserve the original content. Removing pieces from the only live page can destroy the evidence and affect readers before you understand the cause.
Compare one variable at a time. Try the same action logged out, or on a second browser, and record the result. Do not simultaneously switch themes, deactivate plugins and clear every cache; if the problem disappears, you will not know which change mattered.
Keep observations distinct from explanations. A problem appearing after an update is a useful clue, not proof that the update is the sole cause. Record the timing and versions so someone can investigate the relationship.
Read the diagram as text
- Exact address: Copy the affected page rather than naming only the website.
- Starting state: Record the relevant role, browser, device and time of an intermittent failure.
- Smallest action sequence: List only the actions needed to reproduce the problem on a safe copy.
- Expected versus observed: Say what should happen and what actually happened, in separate statements.
Repeat this same example after each controlled change.
When the example is repeatable, use it after each controlled change. A successful homepage load does not prove that the original failing task is fixed. Close the investigation only after that task works in the relevant context and any temporary diagnostic changes have been removed or documented.
Save the short reproduction with the resolution. If the issue returns, the next maintainer can begin with a concrete test instead of reconstructing the complaint from memory.
