How to Find Bugs on a Website: A Practical Guide

To find bugs on a website, pick a specific page and task, reproduce the problem, inspect browser errors and network requests, check performance and accessibility, then report the exact steps and evidence. Browser tools reveal clues; they do not automatically diagnose every issue. Test only sites you own or are authorized to evaluate.

1. Reproduce one specific problem

Start with a page and a task, such as submitting a form, opening a menu, changing a setting, or loading an image. A focused test is easier to repeat and gives you a better chance of connecting a symptom to its cause.

Write down the page URL and the user action you are checking.
Record what you expected to happen and what actually happened.
Repeat the same steps. If the issue is intermittent, note how often it occurs and any conditions that seem to matter, such as a particular account state or viewport size.
When possible, compare the affected page with a similar page or repeat the task in a second browser.

A page that looks wrong can have several causes: a script error, a failed request, a timing problem, unexpected content, or a browser-specific issue. Preserve the original symptom before changing settings or clearing data.

2. Inspect errors and requests in Chrome DevTools

Check the Console

Open the page in Chrome.
Open DevTools with F12 or Ctrl+Shift+J on Windows/Linux; on macOS, use Command+Option+J.
Select the Console tab, clear old messages, and repeat the problem.
Note new errors and warnings, especially those that appear at the same time as the failure.

A console error is a lead, not proof that the message caused the visible problem. Third-party scripts can produce unrelated warnings. Connect an error to the reproduction steps before treating it as the diagnosis.

Inspect the Network panel

Open DevTools, select Network, and enable Preserve log if navigation is part of the problem.
Reload the page and repeat the action. Filter by resource type or search for a request name if the list is large.
Look for failed requests and unexpected status codes. Select a request to inspect its headers, response, initiator, and timing.
Compare the request with the expected URL, method, payload, and response. Redact tokens, cookies, and personal data before sharing evidence.

Chrome’s Network panel guide explains how to record and inspect requests; its network activity guide covers loading-condition workflows. A request can fail for reasons outside the page code, such as authentication, connectivity, or server behavior, so inspect its details and reproduce the symptom.

Check slow or cache-dependent behavior

If the defect concerns loading, use the Network panel’s throttling control to try a slower connection. You can also disable the browser cache while DevTools is open and reload. These settings help expose race conditions, missing loading states, and resources that only appear to work because they are cached. Restore normal conditions after the check and record which setting changed the result.

3. Establish a Lighthouse baseline

Run Lighthouse in Chrome DevTools on the page and state you are investigating. Its report covers performance, accessibility, best practices, and SEO. Save the baseline, make one change at a time, then run the audit again to see whether that change affected the result. This follows Chrome’s Lighthouse workflow.

Use audit findings to choose what to inspect next. A score is a snapshot under specific conditions, not proof that the site is bug-free or accessible. Record the page, browser conditions, and relevant findings so later comparisons are meaningful.

4. Check accessibility with automation and people

Automated accessibility checks can flag potential barriers efficiently, but they cannot evaluate every aspect of accessibility. W3C states that no tool alone can determine whether a website meets accessibility standards. Use tools as one part of evaluation, alongside human review and testing with the ways people use the site. See W3C’s Evaluating Web Accessibility Overview and guidance on selecting evaluation tools.

Manual checks to include

Navigate with the keyboard alone. Can you reach interactive controls, see focus, and operate them in a sensible order?
Check that form fields have understandable labels and that errors are communicated clearly.
Inspect headings, link purpose, image alternatives, and whether important information depends only on color.
Where appropriate, include assistive-technology review and feedback from people with relevant access needs.

Choose tools based on purpose, coverage (including authenticated pages if needed), supported standards, reporting, cost, and the skill of the people doing the evaluation. W3C’s evaluation tools directory lists options; its entries can change, so check current capabilities before choosing. A team that needs repeatable automated checks can integrate scans into browser tests. The Playwright accessibility testing guide shows an axe-based approach. Automation complements manual evaluation; it does not replace it.

5. Separate security testing from general bug finding

Finding visible failures and probing for security weaknesses are different activities. Only perform security tests on systems where you have authorization and an agreed scope. For that specialized work, use the OWASP Web Security Testing Guide as a starting reference.

6. Write a bug report someone can reproduce

Turn observations into a compact report. Include the evidence that helps another person reproduce and investigate the issue, while removing secrets and personal information.

Page: URL or page name, with sensitive query parameters removed.
Environment: browser and version if known, device or operating system, viewport, and relevant account state.
Steps: numbered actions that reliably lead to the problem.
Expected and actual: what should happen and what happened instead.
Frequency: consistent, intermittent, or observed once, including conditions that change it.
Evidence: screenshot, relevant console message, or request details. Redact credentials, session identifiers, personal data, and private response content.

Keep the report focused on observed behavior. If the cause is uncertain, label it as a hypothesis and include the clue that led you there rather than presenting it as fact.

7. Automate checks that need to repeat

For a single investigation, DevTools and a concise report may be enough. When the same user flow needs checking after many code changes, automate a small, stable set of browser steps and assertions. Add accessibility scans where they fit the team’s workflow, then retain manual checks for issues automation cannot judge. Keep test data and authentication handling safe, and make failures produce enough context to reproduce them.

Or skip the browser setup

ScreenshotNeo captures a page through one API request and can provide a screenshot or PDF. Use a real page URL to make a visual record of the state you are investigating; a screenshot can support a bug report, but it does not replace Console, Network, or accessibility checks.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

See the ScreenshotNeo API documentation for request options. Cookie and consent banners are accepted or removed before capture, along with supported newsletter popups and chat widgets; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing status. ScreenshotNeo also has an MCP server for AI agents, with tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Create a free account and start with 1,000 screenshots a month, no card required.

Common problems and fixes

Symptom	Likely clue	Next step
No error is visible, but a control does nothing	The handler may not run, or a request may be delayed or blocked.	Reproduce with Console and Network open; check whether the action triggers a request.
A request is red or has an unexpected status	The response, access state, or connection may differ from expectations.	Inspect request and response details, then repeat under the same account and conditions.
The issue appears only on a slow connection	Timing, loading state, or a dependency may be involved.	Throttle the connection, preserve the log, and record which resource or action stalls.
The issue disappears after reload	It may depend on cached state, timing, or a one-time server response.	Repeat with cache disabled and record whether the result changes; do not assume cache is the cause.
Lighthouse or an accessibility scan is clean	Automated checks have limited coverage.	Continue with manual keyboard and user-experience checks.
A report cannot be reproduced	Steps or environment details may be missing, or the issue is intermittent.	Add exact actions, browser/device details, frequency, and conditions; capture evidence on the next occurrence.
A screenshot capture is blank or fails	The target may be blank, blocked, timing out, or failing to load.	Open the page directly, confirm the URL is reachable, and inspect the response verdict and billing headers.

Performance, reliability, and cost

Keep investigations repeatable: use the same page, task, browser conditions, and account state when comparing runs. Network timing and Lighthouse results vary with cache, connection, server load, and page state, so treat a single run as evidence rather than a universal measurement. Change one factor at a time when isolating a cause.

Browser inspection and Lighthouse are available within Chrome DevTools. Automated accessibility services and broader testing platforms have differing coverage and pricing; compare current capabilities against the site scope and need rather than assuming a paid tool is necessary. For ScreenshotNeo, every plan includes every feature: Free is 1,000 shots per month with no card; Starter is $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Only clean shots are billed; failed and cache-hit outcomes are free.

FAQ

Can I find every bug with browser tools?

No. They expose useful browser-side evidence, but some defects require server logs, code inspection, user feedback, or specialized testing.

Does a high Lighthouse score mean a site has no bugs?

No. Lighthouse audits selected quality areas under a particular run’s conditions; it does not certify the site as defect-free.

Should I start with an automated accessibility scanner?

It can help identify potential issues, but pair it with keyboard testing and human evaluation from the start.

What should I attach to a bug report?

Include a screenshot or relevant console/network evidence when it helps, after removing credentials, session data, and private information.