A good bug report lets a developer reproduce the problem without asking a single question. This template is the same spreadsheet SignalCrawler produces from an audit, emptied out with one example row. It opens in Excel and in Google Sheets (File → Import), and its status, priority, device and owner columns have drop-down lists with colours.
The columns
| Column | What to write |
|---|---|
| Status | New, In progress, Fixed or Won't fix |
| Priority | When to fix: Pre-launch, P0 (now) to P3 (when there is time), Optional |
| Severity | How bad it is: Critical, High, Medium, Low, Improvement |
| ID | A short unique code, so you can refer to it in chat |
| Area | Part of the site: checkout, mobile menu, product page |
| Bug Description | One sentence: what is wrong and where |
| Page | The URL where it happens |
| Device | Desktop, Mobile or both, plus browser and width if it matters |
| Pages affected | One page, or how many share the problem |
| Since last audit | Whether it is new or was there before |
| Owner | Who fixes it: developer, content, SEO, DevOps |
| Screenshot | A picture with the problem marked |
| How to fix | Steps to reproduce, expected and actual result, and the fix if known |
| Acceptance Criteria | How you will check that it is fixed |
| Parent Action | The task it belongs to, if several bugs share one fix |
| Report | A link to where the bug is documented, such as an audit finding or a ticket |
| Rule ID | The check that found it, for bugs that come from an audit; empty for your own |
How to write a bug that gets fixed
- Title it by symptom and place: “Checkout button hidden behind cookie banner on iPhone”, not “Checkout broken”.
- Give the exact steps: open this URL, at this width, click this, type that.
- Say what you expected and what happened. Both, every time.
- Add the environment: device, browser and version, screen width, logged in or not.
- Attach a screenshot or a short video with the problem marked.
- One bug per row. Two problems in one report means one of them gets forgotten.
- Set severity by impact, and leave priority to whoever plans the work.
Severity versus priority
Severity is how much the bug hurts: a broken checkout is critical, a typo is low. Priority is when to fix it, which also depends on how many people meet it and what else is planned. A low-severity typo on the homepage can be a high priority; a severe bug in a page nobody visits can wait.
Fill it automatically
A SignalCrawler audit fills this same template for you: every confirmed finding becomes a row with its page, device, severity, screenshot, how to fix and acceptance criteria, ordered by the audit's plan. You keep the status column up to date as bugs are fixed.