How to Find Bugs in a Website: 30 Practical Checks

The 30 checks below are a practical starting point for your own site or an authorized test environment. Adapt them to the features you actually have. A brochure site does not need checkout tests, and a successful homepage load does not prove that login, search or a purchase journey works.

Prepare a small, repeatable test plan

List the important templates and journeys: landing page, article, search, contact form, account and checkout where relevant. Include a recently changed page and a representative older one. Start with the tasks whose failure would prevent people using the site, lose work, send incorrect information or expose data.

Use test accounts, synthetic data and controlled inboxes for actions that create records or send messages. Use the payment provider’s sandbox for checkout scenarios. For example, Stripe’s testing documentation describes simulated transactions that do not move funds. Keep load tests and intrusive security work in a separately agreed environment and scope.

Checks 1–5: navigation and page responses

• 1. Main navigation: Follow the primary links from a fresh page. Confirm the destination and selected state, including the phone menu. A link that opens successfully but leads to the wrong page is still a defect.
• 2. Internal article links: Open contextual links, related posts and table-of-contents anchors. Check that the target exists and a sticky header does not hide the destination heading. A crawler can collect candidates; inspect important results.
• 3. Moved pages and redirects: Visit a known old URL after a migration. Confirm it reaches the intended replacement without a loop or unrelated destination, and inspect the response chain when needed.
• 4. Missing-page behavior: Visit a deliberately nonexistent path on your test site. Check the helpful error page and HTTP status. A genuine missing resource can correctly return 404; the bug may be a broken incoming link or an incorrect 200 response.
• 5. Back, forward and refresh: Navigate through a real task, then use browser history and reload. Check filters, selected items and state as the product specifies, especially after a form or client-side navigation.

MDN’s 404 reference explains that the status means the resource cannot be found. Do not “fix” every404 by redirecting it to the homepage. Investigate whether the URL was mistyped, moved, deliberately removed or incorrectly linked.

Checks 6–10: forms, accounts and transactions

• 6. Valid form submission: Use a controlled test identity and complete the normal path. Confirm the visible success state and the expected downstream record or test email; a success message alone is not proof that the request arrived.
• 7. Invalid and boundary input: Try empty required fields, whitespace-only names, an invalid email and a reasonable long value. Check clear errors, preserved valid input and correct focus, without inventing abusive payloads.
• 8. Repeat actions and failures: In a test environment, try a double activation and a failed request. Check that the interface does not silently create duplicate records, remain stuck forever or falsely report success.
• 9. Account state and roles: With authorized test accounts, check sign-in, sign-out, recovery and the specified role differences. A hidden menu item is not proof of server-side access control; report suspected authorization problems for qualified investigation.
• 10. Checkout and receipts: In the provider’s sandbox, check successful and declined payments, cancellation, totals, currency and one matching order/receipt. Verify the full state change rather than only the payment button.

Checks 11–15: mobile, layout and media

• 11. Narrow and wide layouts: Inspect representative phone, tablet and desktop widths and nearby breakpoint sizes. Look for clipped text, overlapping controls and page-wide horizontal scrolling; a table may intentionally scroll inside its own container.
• 12. Real content: Use long titles and names, empty states and available translated content. Layouts that work only with short sample text are not ready for actual data.
• 13. Menus and overlays: Open and close navigation, dialogs, consent controls and pop-ups. Check that controls stay reachable, background overlays clear, and the page can scroll again after dismissal.
• 14. Images and downloads: Scroll through the page to trigger lazy loading. Confirm the right images, useful crops, legible diagram labels and working downloads. Check important linked files as well as the thumbnails.
• 15. Audio and video: Start, pause and seek the media. Check controls and accurate captions or other appropriate alternatives, and whether a blocked embed or slow connection produces a useful state.

Chrome’s Device Mode documentation explicitly calls emulation an approximation. It is useful for exploring widths and network conditions, but does not run the page on a mobile CPU or replace checking real touch, keyboard and browser behavior. The mobile layout troubleshooting guide explains how to narrow a specific layout difference.

Checks 16–20: basic accessibility and interaction

• 16. Keyboard navigation: Put the mouse aside. Use Tab and Shift+Tab to reach controls, then the expected activation keys. Look for a visible focus indicator and a sensible order; check that users can leave menus and dialogs.
• 17. Form labels and errors: Check that each field has an understandable label, required inputs are identified, and errors explain what to correct. An error conveyed only by a red border can be missed.
• 18. Zoom and text: Increase browser zoom and test larger text. Check that content remains available and controls usable, including fixed headers, menus and form messages. Record the actual setting used.
• 19. Meaning beyond color: Inspect important status messages, graphs and controls. Use an appropriate contrast check and make sure a color change is not the only way to understand success, failure or selection.
• 20. Structure and alternatives: Check a meaningful page title, logical headings, descriptive link/control names and image alternatives appropriate to their purpose. For a diagram, provide its useful information in accessible text too.

These are initial checks, not a declaration of conformance. W3C WAI’s Easy Checks warns that a page can pass a quick review and still contain significant barriers. Combine automated findings with manual assessment, assistive-technology testing and user involvement appropriate to your product.

Checks 21–25: content, search and data

• 21. Search results: Try a known title, a partial phrase and a query with no match. Check relevant results, a clear empty state and filters that do what their labels say.
• 22. Dates, times and numbers: Check the displayed timezone and locale, date boundaries and any booking or price calculation using known expected values. Do not assume the tester and customer share the same timezone.
• 23. Uploads and downloads: Use benign test files within and just outside the specified size/type limits. Check validation, completion and retrieval. This functional check does not establish that the upload pipeline is secure.
• 24. Content and metadata: Verify important facts, prices, contact details, links and page-specific titles/descriptions. Confirm that intended public pages have the correct canonical and indexing settings, particularly after template or migration changes.
• 25. State persistence: Save an allowed preference or draft in a test account, navigate away and return. Check the specified behavior after refresh and in the intended account; verify that another test user does not see the wrong person’s information.

Checks 26–30: diagnostics, performance and retesting

• 26. Console evidence: Open the browser Console before reproducing the task. Note relevant errors and their timing. A warning or third-party error is a clue to investigate, not automatic proof of the root cause.
• 27. Network evidence: With the Network panel open, reload or repeat the failing action. Inspect failed requests, status, response, timing and initiator. A 200 response can still contain incorrect data; an intentionally blocked request may be expected.
• 28. Performance conditions: Test representative pages under recorded conditions. Use page diagnostics and available real-user data to investigate slow rendering or interactions, keeping controlled lab results separate from visitors’ actual experience.
• 29. Supported browsers and devices: Repeat critical journeys in the combinations your product supports and visitors use. Record the exact combinations checked. Passing one desktop browser does not establish Safari, Firefox or physical-phone coverage.
• 30. Fix verification: Re-run the original failing steps after the change, then check nearby flows that use the same component. Record the new build and result; distinguish a verified fix from an issue that simply stopped reproducing once.

Use browser diagnostics to explain a symptom

The Chrome Console exposes logged messages and JavaScript errors. The Network panel shows request activity and response details. Open the relevant panel before reproducing the issue so the evidence covers the failing action. Record only information needed for the report and remove credentials, tokens and personal data before sharing logs.

For example, if Send appears to do nothing, first check whether input validation prevented submission, a script failed before a request, the request returned an error, or the server accepted it but the success state did not appear. These are different failures with different fixes. Do not rewrite a component just because an unrelated console message is red.

For performance, PageSpeed Insights separates lab diagnostics from field data, which may be unavailable or represent the origin rather than a single page. A high score does not prove a checkout works, and one low run is not a complete diagnosis. Record the page, device/network conditions and comparable before/after measurements.

Write a bug report another person can reproduce

A precise report reduces the time spent guessing. Give each issue one clear title and include the environment, relevant state, numbered steps, expected result, actual result, frequency and evidence. Link related symptoms instead of combining several unrelated failures into one ticket. A spreadsheet can work; a dedicated tracker is optional.

Prioritize, fix and automate the right things

Assess user impact separately from scheduling priority. An exposed private record or a broken core transaction may need immediate containment; a cosmetic alignment issue may wait. Record affected users, scope, workaround, confidence and dependencies. Give each issue an owner and a next action rather than labeling every red tool finding critical.

Security work needs more than this checklist. The OWASP Web Security Testing Guide is a resource for developers and security professionals. Use a qualified review with agreed authorization and scope for authentication, authorization, sensitive data and other security concerns. HTTPS or a successful role-menu check alone cannot establish application security.

Automate stable, valuable regression checks after you know their expected results: a critical form, a known redirect, a calculation or a previously broken flow. Keep exploratory review for new behavior and human judgment for content, accessibility and meaningful visual changes. Avoid tests that merely confirm an element exists when the user needs a task completed.

Before publishing a fix, test in the relevant environment, review the change and keep a rollback path appropriate to the release. After deployment, verify the affected public behavior and monitor for related failures. Keep a coverage record: passed, failed, blocked and not tested. No finite test pass proves a website is completely bug-free.

Website bug finding FAQs