What to Do When Claude's Code Doesn't Work

The short version

Your browser is already telling you what went wrong. It writes the error, the file and the line number into a panel most people never open. In Chrome and Edge that panel is F12, or Option plus Command plus J on a Mac. Firefox uses F12 too. Safari hides it until you turn on the Develop menu under Settings and then Advanced. Open it, reload the page so you catch errors thrown during load, and read the top line.

Three failure styles cover nearly everything a small site does wrong. Loud failures throw an error and stop. Silent failures run cleanly and produce the wrong result, which is the hardest kind because nothing is logged. Conditional failures work at one window size, in one browser, or until the cache clears. Knowing which one you have cuts the list of causes down before you type anything to the model.

The least useful message you can send is that the page is broken. Claude has no view of your screen, your console or your host's dashboard, so it answers the only way it can, by guessing at the likeliest bug in code it wrote ten minutes ago. Give it the error text and the guessing stops. How you shape the request matters less here than whether the evidence is inside it.

The page is blank white

Nothing rendered means either something stopped before render, or there was nothing to render. Separate the two by viewing the page source with Command or Control plus U. Source showing your full markup means the file arrived intact and something is hiding or erasing it. Source that is empty, or a directory listing, means the problem is the file: wrong name, wrong folder, or a text editor that quietly saved page.html.txt.

With markup present, the console almost always holds an Uncaught SyntaxError and a line number. A single missing bracket in an inline script is enough to cause it. The browser parses the whole script, fails, and runs none of it, so a page that assembles its content in JavaScript ends up with an empty body. Copy the named line and the ten lines on either side of it.

Two quieter causes are worth ruling out before you ask for anything. A container set to zero opacity for a fade-in stays invisible when the script meant to reveal it never ran, so the page is technically fine and completely blank. And a file opened by double-clicking it, where the address bar reads file:// rather than http://, will refuse to fetch a local JSON or module file for security reasons. Deploying it, or running a small local server, makes that one vanish.

A button that does nothing

No error on screen, no response, no change. Click something wired to a function and nothing moves, and the console usually does have a line waiting: Uncaught TypeError, cannot read properties of null, reading addEventListener. That message has one meaning. The script asked the page for an element that did not exist at the moment it asked.

• The id changed in one place only. A rename from submit-btn to submitBtn in the markup leaves the script hunting for a name nothing has.
• The script ran too early. A script tag sitting in the head without defer executes before the body exists, so every lookup returns nothing.
• Two elements share an id. The lookup finds the first one and your listener lands on the wrong element.
• An unrelated error earlier in the same file stopped execution before the listener was ever attached. Fix the first error and the button starts working with no change of its own.

Almost none of this needs a rewrite. Send the id as it appears in the HTML and the selector as it appears in the script, on two adjacent lines, and ask which one to change. Then pick one and keep it. Renaming both halves in the same round is how you end up with a third name and the same dead button.

CSS that has no effect

Styles that refuse to apply are two problems wearing the same costume, and they need opposite repairs. Either the file never loaded, or it loaded and something else won.

Start with the Network tab, which settles the first one. Reload with it open and look for your stylesheet in the list. A red 404 means the path in the link tag does not match where the file sits: styles.css looks in the current folder, /styles.css looks at the site root, and those stop being the same place as soon as the page lives a folder deep inside the blog. A 200 that still shows old styling usually means the browser served a cached copy, which a hard reload clears.

If the file did load, select the element in the Elements panel and read the rules beside it. A rule drawn with a line through it lost to something more specific, often an inline style attribute or a later selector carrying an id. A rule missing from that list entirely never matched at all, which usually means the class name in the HTML and the class name in the stylesheet differ by one hyphen. A misspelled property voids only its own line and leaves its neighbours working, which is why the breakage looks so oddly selective.

Say which of the two you have. Fix my CSS invites a guess at both. This rule shows as struck through in the inspector, and this other one is not loading at all, describes two specific repairs and gets them.

A form that submits and delivers nothing

Some failures are not in the code, and this is the one that catches most people shipping a first site. The form looks right. The browser shows a success message. No email ever arrives, nothing appears in the console, and there is nothing in the file to repair.

On Netlify, submissions are only handled once you switch the feature on. The documentation is blunt about it: “If you would like Netlify to automatically manage your form submissions, you need to enable form detection”, done in the Forms area of the site dashboard, and it applies “Starting with your next site deploy” (Netlify forms setup). Flipping the toggle and not redeploying leaves you exactly where you started.

Three markup details sit alongside that setting. The form tag needs a data-netlify attribute set to true, or the bare netlify attribute. The form needs a name, which is also what the dashboard labels it. Every input you expect to receive needs its own name attribute, because that name is the key the submission arrives under.

The subtler trap: detection works by parsing the built HTML, not by watching the live page. Netlify's own wording is that if you use JavaScript to render a form client-side, the build system will not find it in the pre-built files. A form assembled by script is therefore invisible to the scanner while working perfectly in front of you, and the documented workaround is a hidden static copy of it with matching input names.

That is the real lesson of this section. Claude cannot see your host dashboard, your DNS records or your deploy log, so anything living in those will survive every rewrite you request. Before the fourth attempt at the markup, ask whether the thing you are debugging is code at all.

Fine on the laptop, broken on the phone

A layout that holds at 1400 pixels and falls apart at 390 is rarely a wrong design. It is one fixed number that should have been flexible.

• A container given a width in pixels instead of a max-width, so it cannot shrink below that number and pushes the page sideways.
• A missing viewport meta tag, which makes a phone render the page at desktop width and zoom out until the text is unreadable.
• One long unbroken string, usually a URL or an email address, forcing horizontal scroll on its own.
• A grid with a fixed column count and no media query, so four columns stay four columns at phone width.
• A fixed-position header that takes a third of a short screen and covers whatever you scroll to.

Find the culprit before describing it. Drag the window narrow until the layout breaks and note the width. Open the device toolbar in the developer panel, set that width, then click through elements and watch the highlighted box: the one extending past the right edge of the screen is the one to name.

Then send the width, the element and the symptom as one sentence. At 390 pixels the pricing table runs past the right edge and the whole page scrolls sideways. That line contains everything needed to make the change. A request to make the page responsive, with no width and no element in it, produces a pile of media queries that may never touch the actual cause.

When to stop patching and start over

Before any fix, keep a copy of the file that works. Save it with the date in the name and leave it alone. This is unglamorous, and it is the one habit that separates an afternoon of debugging from a week of it.

Change one thing per round and look at the page after each one. Two changes at once means a new symptom cannot be traced to either of them. The signal that a loop has gone bad is a third round on the same symptom with fresh symptoms appearing beside it. By then the file is carrying patches that each made local sense and now interact in ways nobody is tracking.

Revert to the saved copy and ask for that one section rebuilt from scratch, describing the behaviour you want rather than correcting the code you have. Thirty fresh lines cost less than a fifth patch on a file you can no longer describe accurately. A written checklist run against the rebuilt section will catch whether the rewrite quietly reintroduced something an earlier patch had fixed.

Now and then the error belongs to nobody in your file. A script pulled from a CDN that returns 404 because that version was retired. An API key still sitting there as a placeholder. An ad blocker eating a third-party widget. The console reports these as plainly as it reports your own mistakes, which is the whole argument for opening it first every time.

Debugging without knowing how to code turns out to be mostly a description problem. The browser produces the diagnosis in plain text, for free, every time. The work is reading it, deciding which symptom family you are in, and passing along the specific line instead of the general complaint.

What none of this covers is logic that runs cleanly and returns the wrong answer. A total that adds up wrong, a filter that drops the last item, a date off by one day. Nothing is logged, nothing looks broken, and you are the only one who knows what the right answer was. Checking those by hand is the part that stays yours, which is a good reason to keep the page small in the first place. The build sequence in the original walkthrough stays deliberately plain for that reason, and what to expect from AI-written code covers the rest of the tradeoff.

Common questions

Why is my Claude-generated page completely blank?

View the page source first. If your markup is there, the cause is almost always a JavaScript error that stopped the script before anything rendered, and the console will show an Uncaught SyntaxError with a line number. If the source is empty or shows a file listing, the file itself is the problem: a wrong filename, the wrong folder, or an editor that appended .txt when it saved.

How do I see the error message in my browser?

Press F12 in Chrome, Edge or Firefox, or Option plus Command plus J on a Mac, then pick the Console tab. Safari needs the Develop menu turned on first, under Settings and then Advanced. Reload the page with the panel already open so you capture errors thrown during load, and copy the top line exactly, file name and line number included.

Should I paste the whole file into Claude or just the broken part?

Send the error text first, then the part of the file the error points at, roughly twenty lines around the named line. Re-sending a long file every round invites a rewrite of code that was working fine. Say which file and which line numbers the snippet came from, and send more only if the reply asks for it.

Why did my Netlify form stop collecting submissions?

Check three things in order: whether form detection is still enabled in the site's Forms settings, whether the form tag still carries its data-netlify attribute, and whether the site has been redeployed since the change. Detection happens when a build completes, so an edit that dropped the attribute and a setting changed without a following deploy both leave a form that looks correct and collects nothing.