How to Debug Common Website Issues

To debug a common website issue, reproduce it, collect the browser evidence, and follow that evidence to the relevant code or request. In Chrome, start with the Console for JavaScript errors, Network for failed or slow resources, and Issues for browser-detected problems. Use Lighthouse for a broad audit and a Performance trace when you need to investigate runtime behavior in detail.

This workflow helps narrow down browser-visible problems. It does not determine the correct fix for every server or hosting failure; when the evidence points upstream, take the URL, time, request status, and browser error to the documentation for your application and infrastructure.

1. Reproduce the issue and record the conditions

A useful diagnosis begins with a symptom another person can reproduce. Before changing code, note:

The affected URL and the exact action that triggers the problem.
Whether it happens during the initial page load or after an interaction.
The browser and relevant page state, such as whether you are signed in.
What you expected and what happened instead.
The time of the occurrence, especially if you will need to correlate it with server-side logs.

Open Chrome DevTools before reproducing the issue. If it occurs during load, keep DevTools open and reload the page: some browser-detected issues may become visible after a reload. Change one condition at a time so you can tell whether the symptom changes with it.

2. Check the Console for JavaScript errors

Open the Console and reproduce the failing page or interaction. Browser and site code can both produce Console messages. Start with errors that appear at the same time as the symptom, then inspect the message’s source link and call stack to find the associated code.

Clear or note existing messages so old errors do not distract from the reproduction.
Reload the page if the failure occurs on load; otherwise repeat the action that triggers it.
Open the relevant error and follow its source link or stack frames into the code.
Check whether the error is the cause of the visible failure or merely another problem on the page.

A Console error is a lead, not proof that it is the only cause. If the source location is in a bundled script, use the source maps available for your project, when configured, to navigate to the original code. If the error appears only after a particular action, trace that action’s event handling and the data it uses.

Chrome’s Console guidance describes how browser errors are logged and how to use their source links and call stacks.

3. Inspect failed or slow requests in Network

The Network panel records page activity and lets you inspect requests, response codes, and resource details. Use it when an image, script, stylesheet, font, or API response is missing, incorrect, or slow.

Open Network, reproduce the issue, and reload if necessary so the request appears in the log.
Find the request associated with the missing content or delayed behavior. Filter by resource type or inspect likely requests.
Check the HTTP status, request URL, and loading details. Open the request for its response and other available details.
Correlate the request with Console errors and the visible symptom.

A 404 means the requested resource could not be found. Check the requested path and the resource’s deployment or server configuration in the relevant code and environment. For a failed API request, inspect which endpoint was requested and its response status before deciding whether the problem is in the page, the API, or an upstream service.

Chrome’s Network guide explains how to inspect network activity and resources.

4. Use Issues for browser-detected problems

Open the Issues panel to review structured explanations for problems Chrome detects. Documented issue types include cookies, mixed content, CORS, stylesheet loading, and Content Security Policy (CSP). Expand an issue, read its context, and follow links to affected resources where available.

Reload with DevTools open if you do not see an issue that occurs during page load. The categories and details shown can vary with the Chrome version. An Issues entry helps explain a browser finding, but you still need to determine how it relates to the page’s behavior and what change is appropriate for your application.

Chrome’s Issues guide describes the panel and its browser-detected issue explanations.

5. Diagnose slow pages with audits and traces

Use Lighthouse to get a broad audit and a baseline. It audits performance along with accessibility, best practices, and SEO. Use the Performance panel when you need a more detailed investigation of runtime activity. The two tools answer different questions: Lighthouse gives a broad assessment; a trace helps you inspect recorded activity, including main-thread and network work.

Run Lighthouse on the affected page and keep the report as a baseline.
For a specific delay, record a Performance trace while reproducing the slow load or interaction.
Inspect the recorded activity and use Network details to investigate resources that appear related to the delay.
Make a change, then repeat the measurement under consistent conditions: the same page, browser state, and throttling setup.

Do not compare results from runs with materially different conditions and attribute every difference to a code change. If Lighthouse itself errors, its tutorial recommends trying a clean Incognito window with no other tabs open, since extensions can interfere with an audit. That checks the audit environment; it does not fix the website.

Chrome’s Lighthouse tutorial covers audits and baselines. For deeper performance debugging, see Chrome’s Performance guide and web.dev’s overview of Network and Performance tools.

Common website issues and what to inspect

Symptom	First evidence to collect	Next step
A button or interaction does nothing	Console errors during the action	Follow the source link and call stack; check whether the failure occurs only after that interaction.
An image, script, or stylesheet is missing	Its Network request and response status	For a 404, verify the requested path and resource deployment or server configuration.
Page data or an API-backed feature fails	The related Network request and response status	Correlate the request with Console output; take upstream failures to the relevant API or infrastructure documentation.
Cookie, CORS, mixed-content, CSP, or stylesheet warning	The Issues panel’s explanation and affected-resource links	Inspect the affected resource and the relevant browser or application configuration.
Page load or an interaction is slow	Lighthouse baseline, then a Performance trace	Inspect recorded main-thread and network activity; compare repeated runs under consistent conditions.
Lighthouse audit errors	Whether the failure follows the audit environment	Retry in a clean Incognito window with no other tabs open to check for extension interference.

Turn browser evidence into a useful escalation

If the browser evidence points to a response, server, or hosting issue, include the affected URL, timestamp, request status, and browser error when consulting the documentation for that application or infrastructure. This makes the report actionable without guessing at platform-specific server commands that depend on your stack.

Performance, reliability, and cost considerations

Performance: Lighthouse is useful for a broad baseline; use a Performance trace for a detailed investigation. Repeat comparisons with the same page, browser state, and throttling setup.
Reliability: Reproduce the same action and preserve the browser evidence. A single message or audit result may not establish the cause; correlate Console, Network, and Issues findings.
Scope: Chrome DevTools explains browser-visible behavior. It cannot by itself prescribe a platform-specific server or hosting fix.
Cost: The workflow uses Chrome DevTools and its built-in audit tools; the cited workflow does not require a paid debugging product. If you need automated page captures for a debugging record, ScreenshotNeo has a free plan described below.

Or skip the browser setup

For a clean screenshot of a page while documenting or comparing a visual issue, ScreenshotNeo is a website screenshot API and MCP server. It accepts one GET request with a URL and returns an image or PDF. A screenshot can preserve what the page looked like, though it does not replace Console, Network, Issues, Lighthouse, or Performance evidence when diagnosing the cause.

See the ScreenshotNeo API documentation for request options. This cURL request saves a WebP screenshot of the target page:

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

Equivalent Python:

import requests

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

Equivalent 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}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Replace the example URL with the page you want to capture. Keep the API key private; do not expose it in client-side code.

Cookie and consent banners are accepted like a visitor; more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture. Each of those steps can be turned off.
Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Responses include X-Page-Verdict and X-Billed headers.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; yearly billing gives two months free, and every feature is on every plan.

Create a free ScreenshotNeo account for 1,000 screenshots a month with no card.

FAQ

Do I need to install Chrome DevTools?

No. DevTools are built into Chrome. Open them on the page you are investigating.

Does a screenshot tell me why a page is broken?

No. A screenshot records appearance. Use Console, Network, Issues, Lighthouse, and Performance evidence to investigate behavior and loading problems.

Should I fix every Console message?

Prioritize messages that correlate with the reproduced symptom, then investigate their source and call stack. A message alone does not establish the cause.