Your AI-Built Landing Page Just Broke at 9PM. Here's the Fix-It Playbook for Teams Without a Developer.

There's a genre gap in the "build your landing page with AI" content universe. Hundreds of tutorials will get you from prompt to published. Almost nothing exists for the moment three weeks later when the page is live, traffic is flowing, and something is wrong. The submit button does nothing. The mobile layout has developed a six-inch gap nobody saw on your laptop. The form says "Thanks!" and sends nothing to your CRM.

That moment hits hardest for teams without a developer, because your entire mental model of the page is "Claude wrote it, therefore it works." You didn't build it, so you don't know how it comes apart. The good news: you don't need to know how it was built to fix it. You need a diagnostic sequence and — this is the part nobody teaches — a way of describing the breakage to the LLM that gets you a working fix in one round-trip instead of six.

This is the failure-mode playbook. (The success-mode checklist — verifying everything before traffic hits — lives in The 90-Minute Pre-Flight Check: 12 Things to Verify Before Paid Traffic Hits Your AI-Built Landing Page. Different moment, different job.)

First: Figure Out What Layer You're On

Every "my page is broken" report is actually one of four problems, and misdiagnosing the layer is what turns a five-minute fix into an all-nighter. Before you touch the prompt, run this decision sequence:

1. Is the page even deployed? Open the live URL in an incognito window. If you see a 404, a hosting provider error, or a stale version of the page, this isn't a code problem — it's a deploy problem. Redeploy from your host's dashboard or re-push from Claude's build environment. Most AI-assisted hosts give you a deploy log; the error will usually be staring at you from the last line.

2. Is it broken for everyone, or just on mobile? Open the page on your phone. If it looks fine on desktop and falls apart on mobile, that's a responsive-layout problem and it gets its own section below.

3. Is it a form failure? The nastiest and most common one, because it's silent. The page looks perfect. The form thanks the visitor. No email arrives anywhere. Section three.

4. Is it a JavaScript runtime error? If a button does nothing, an animation freezes, or part of the page simply never renders, open your browser's developer console (right-click → "Inspect" → "Console" tab). You'll probably see red text. That red text is your entire bug report. Copy all of it.

The discipline here matters: do not go to Claude saying "my page is broken." That prompt starts a guessing game where the LLM rewrites chunks of your page speculatively, and each rewrite risks breaking something that was fine.

The Broken Form: The Failure Mode That Costs You Leads While You Sleep

A form that visibly errors is annoying. A form that pretends to work is a business problem — every silent failure is leads evaporating. Here's the triage order:

1. Submit the form yourself. Watch the Network tab in developer tools (the "Network" tab, filter to "Fetch/XHR"). If submitting produces a request that turns red or shows a 400/401/500 status, the problem is server-side: an expired API key, a wrong endpoint, a removed webhook.
2. Check the third-party integration first, not the page code. If your form pipes into Mailchimp, Zapier, Formspree, or a CRM webhook, the most common failure by far is their side: an expired key, a plan limit hit, a renamed webhook URL. Test the endpoint directly — most form services show recent submissions or recent errors in their dashboard. If submissions appear in the service dashboard but not in your CRM, the page code is fine and the integration chain is broken.
3. Check the thank-you behavior. If the form shows its success state but nothing arrives anywhere, the page's success handler is probably running unconditionally — a classic AI-generated-code bug where the success message fires on submit regardless of whether the request succeeded.

Then, and only then, go back to the LLM — with this kind of paste, which is the actual subject of this post:

Here's my form handling code: [paste the form's JS block]

When submitted, the browser console shows: [paste console errors]

The Network tab shows a POST to [URL] returning status [code] with
response body: [paste response]

Expected: submission stored in [service]. Actual: success message
shows but no submission appears.

Diagnose the root cause. Do not rewrite the whole file. Change only
what's necessary and tell me what you changed and why.

That last line — "do not rewrite the whole file" — is doing more work than any diagnostic step above it. A one-shot fix requires the LLM to be constrained, and a full-file rewrite is the opposite of constrained.

The Mobile Layout Shift: Why It Happens and the Three Prompts That Fix It

Claude-generated pages break on mobile for one of a few recurring reasons: a fixed pixel width somewhere that should be relative, an absolutely-positioned element that ignores screen size, an image with no max-width, or a two/three-column grid that doesn't collapse. You can usually fix all of these without understanding CSS, but you have to give Claude eyes.

Here's the workflow that works:

Step 1: Reproduce it in a screenshot. Open the page on a real phone (or in DevTools' device mode — toggle the little phone icon in your browser's inspector). Screenshot the broken view. If you're using Claude, paste the screenshot directly — it reads images, and a screenshot of the broken mobile layout is worth a thousand words of your attempted description.

Step 2: Prompt with the symptom, not a guessed cause. Something like:

Here's the desktop layout working correctly [screenshot] and here's
the broken mobile view [screenshot]. On mobile there's [describe:
a large empty gap / overlapping text / horizontal scrolling].

The page's viewport meta tag is: [paste it]

Find the CSS causing this and fix it with a mobile-first approach.
List every rule you changed.

Step 3: Verify the two usual suspects yourself. Before or after, check two things in the page source that account for a huge share of mobile breakage in generated pages: that <meta name="viewport" content="width=device-width, initial-scale=1"> is present, and that images have a max-width constraint. If either is missing, that's plausibly your entire bug, and you can ask Claude to confirm in one message.

Step 4: Check horizontal scrolling. Swipe the page sideways on mobile. If it moves at all, something is wider than the viewport. Prompt: "Something on this page overflows the viewport horizontally on mobile. Find all elements wider than 100vw and constrain them." This is one of the rare bugs where the prompt alone reliably finds the culprit, because it's a mechanical condition, not a judgment call.

The One-Round-Trip Fix: What to Actually Paste

The difference between a six-message debugging slog and a single fix is almost always the quality of the evidence you hand over. Build a habit around three artifacts:

1. Console errors, verbatim. Copy the red text exactly, including line numbers. Line numbers let Claude map the error to the actual code.
2. The relevant code block, not the whole file. If the form is broken, paste the form's markup and its submit handler. Whole-file pastes invite whole-file rewrites, and whole-file rewrites are where previously-working features get collateral damage.
3. Symptom vs. expectation, stated separately. "I expect the form to send an email and show a success message. It shows a success message but sends nothing." Two sentences. Vague symptom descriptions are what force the LLM to guess.

And one more: keep your original build prompt. When Claude rebuilt the page from a fresh session, having the original prompt plus the current file lets it reason about intent, not just syntax. Save every build conversation as a document the way you'd save credentials.

Version Control Without a Developer: Your Undo Button

Here's the thing that turns a 9PM emergency into a shrug: knowing you can revert. You don't need Git mastery — you need one habit and one tool.

The habit: before every AI-suggested fix, copy the current live file and save it as page-YYYY-MM-DD-before-fix.html somewhere you can find it. Thirty seconds. This is your undo button, and it matters because AI fixes occasionally fix the reported bug while breaking a different feature you didn't mention.

The tool: if your host deploys from a connected project (most AI-assisted hosts keep a history of deployments), the "roll back to previous deployment" button in your dashboard is the fastest revert that exists — no file juggling at all. Learn where it is now, at 2PM on a calm Tuesday, not at 9PM on launch night.

After the Fix: Prove It, Then Watch

Two closing habits that separate teams that fix pages from teams that rediscover the same bug:

Reproduce the original failure before declaring victory. Submit the form three times. Resize the browser window across widths. Check the phone. A fix you haven't reproduced the failure against isn't a fix — it's a hope with better grammar.

Watch the form from the outside. Once a week, submit your own test entry and confirm it lands where it should. Silent form failures are the one bug class that costs money while you're not looking, and a 60-second weekly self-test catches nearly all of them. If you're running paid traffic to this page, the math on that habit is brutal and one-sided: one caught week of silent failure pays for months of testing.

None of this requires you to learn to code. It requires you to change what you paste into Claude — evidence instead of panic, symptoms instead of guesses, constraints instead of open-ended rewrites. The build was one hour. The maintenance is a playbook. Now you have both.