To fix a vibe coded website, first figure out whether it’s actually down or just broken-looking, then check the boring stuff before you touch any code: hosting account, domain, DNS, and SSL certificate. Most “my AI-built site just broke” emergencies turn out to be hosting, domain, or certificate problems you can fix in ten minutes without reading a single line of code. Screenshot everything before you change anything, make one change at a time, and roll back to the last working version before you try to fix forward. That’s the whole method, and the rest of this guide walks it in order.
And breathe. The sites that arrive at our door truly wrecked usually didn’t get that way from the original break. They got that way from six hours of panic-fixing afterward.
Website down or just ugly? Two different emergencies
Three different emergencies hide behind “my website broke,” and they carry three different price tags. Fully down: nothing loads, the browser shows an error page. Ugly: the site loads but looks wrong, styles missing, layout blown apart, images gone. Half-broken: everything looks fine until someone submits the contact form or hits checkout, and nothing happens.
Down is usually your host or your domain. Ugly is usually the code or a failed deploy. Half-broken is usually a third-party service, an expired API key, or a form that never worked in the first place and only got noticed today.
Before declaring anything, rule out your own machine. Open the site in an incognito window, do a hard refresh (Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows), then load it on your phone with wifi turned off so you’re on a different network. A free checker like downforeveryoneorjustme.com settles the “is it just me” question in five seconds. If the site loads fine for everyone else, your emergency is a caching problem, and you can go back to lunch.
Check hosting, DNS, and SSL before you blame the code
The code is innocent more often than anyone expects. In rescue work, the pattern we keep seeing is a site that broke “for no reason,” where the reason turns out to be an unpaid invoice or a certificate that quietly expired on a Sunday. Run through these four, in order:
- Hosting account. Log into your host (Vercel, Netlify, or your WordPress host) and look for a suspended account, an expired credit card, or a free-tier limit you finally hit. Check the host’s status page too. Sometimes the outage is theirs, and your fix is coffee.
- Domain. Domains expire, and the renewal warnings love landing in spam. Log into your registrar and check the expiration date. An expired domain takes the whole site and your email down at once.
- DNS. If anyone touched nameservers or DNS records in the last two days, that’s your prime suspect. DNS changes can take up to 48 hours to settle, and a half-propagated change makes a site work on your phone while failing on your laptop.
- SSL certificate. “Your connection is not private” looks like a hack and is almost always an expired certificate. Free Let’s Encrypt certificates renew automatically every 90 days, right up until a renewal silently fails. Click the padlock or site-info icon in your browser and read the certificate dates.
None of those checks require code. All four together take about fifteen minutes, and they resolve a big share of “website broken after an AI build” panics on the spot.
How to fix a broken website: the five-minute checks
Still broken after the boring four? Now match the symptom to the suspect. Every check below is doable by a non-developer with a browser and a little patience.
| What you see | Usual suspect | First check | Time |
|---|---|---|---|
| Nothing loads, browser error page | Expired domain or DNS change | Registrar account, then a whois lookup | 5 min |
| “Your connection is not private” | Expired SSL certificate | Certificate dates behind the padlock icon | 2 min |
| Blank white page | JavaScript crash or PHP fatal error | Browser console, then hosting error log | 5 min |
| Loads, but styles are gone | Failed build or broken CSS path | Hard refresh, then the deploy log | 5 min |
| “500 Internal Server Error” | Server config or a bad update | Hosting error logs, recent changes | 10 min |
| Forms or checkout stopped working | Expired API key or third-party service | Browser console plus the service’s dashboard | 10 min |
The browser console is the one tool here worth thirty seconds of learning: right-click the page, choose Inspect, click the Console tab. Red lines are errors. You don’t need to understand them. You need to screenshot them, because they tell whoever fixes the site exactly where to start.
On Vercel or Netlify, open the deploy log for the latest build. A failed deploy means the platform is either still serving the last working version (good) or serving nothing (bad), and the log usually names the exact file that killed the build. On WordPress, a blank white screen usually means a PHP fatal error, and your host’s error log has the details.
Strange breaks are baked into how these sites get made, by the way. Vibe coding gone wrong is rarely dramatic: the model writes code that works on the happy path, nobody reviews it, and the fragile parts sit there waiting. Security has the same root cause. When Veracode ran over 100 AI models through security tests in 2025, 45 percent of the generated code samples failed. Breakage and vulnerability come from the same place: nobody read the code. We cataloged the recurring offenders in our rundown of vibe coding mistakes, and most of them are preventable in the prompt.
Screenshot everything before you touch anything
Before any fixing, become the crime-scene photographer. Error states are perishable. The moment you start clicking around, you overwrite the evidence, and whoever ends up helping you (a friend, a forum, a pro) loses the trail.
Capture these while the site is still broken:
- A full screenshot of the error in the browser, with the URL visible
- The browser console, red lines included
- The hosting dashboard, especially any failed deploy or warning banner
- The last AI chat where you asked for changes, if there was one
Then write down what changed in the last 48 hours. A prompt you ran, a plugin you updated, a DNS record you edited, a new domain you connected. Someone changing something is the leading cause of broken websites at every scale. Uptime Institute’s 2025 outage analysis found that nearly 40 percent of organizations had a major outage caused by human error over the past three years, and those are professionals with checklists. At small-site scale, “what did you change last?” solves more mysteries than any diagnostic tool.
Evidence first, fixes second. Every triage step you skip now becomes three hours of someone else’s archaeology later.
Does rolling back beat fixing forward?
Usually, yes. If the site worked Tuesday and broke Wednesday, the fastest fix is Tuesday’s version. A rollback gets you a working site now and lets you investigate calmly, instead of debugging live while customers watch the error page.
Where your rollback lives depends on the stack. Vercel and Netlify keep every previous deploy: open the deploys list, find the last one that worked, and promote it. Two minutes, no code. If your site’s in a GitHub repo, every commit is a restore point, and reverting the last one is a routine move for any developer. On WordPress, most decent hosts keep nightly backups, and restoring yesterday’s copy from the hosting panel beats hand-editing a broken theme at midnight.
Rolling back is the right call when you can name the change that preceded the break. Fixing forward is the right call when the break revealed something that was never right, like a contact form that has quietly failed since launch. No rollback restores a thing that never worked.
One warning about asking the AI to clean up its own mess. In July 2025, an AI coding agent made headlines by deleting a founder’s production database during an explicit code freeze, and per Fortune’s report, the agent then claimed the rollback wouldn’t work. He tried it anyway. It worked. Take recovery advice from your platform’s documentation, not from the tool that caused the incident. And if you do want to fix an AI generated website with more AI, commit everything to git first so each attempt is reversible, accept one change at a time, and stop after two failed rounds. The 1 a.m. loop where every “fix” rewrites two files it shouldn’t is how repairable sites turn into rebuilds.
When you can’t fix a vibe coded website yourself
Handing off well is a skill, and it’s the difference between a same-day ballpark and a week of back-and-forth emails. A good handoff package has six things:
- The URL, plus one sentence on what the site is supposed to do
- Your screenshots and console output from the triage above
- Where everything lives: hosting provider, domain registrar, GitHub repo link if there is one
- Which AI tool built the site, and the key prompts if you saved them (if it was one of our free prompts, just tell us which)
- What changed last, and when the site last definitely worked
- Access granted properly: collaborator invites on GitHub and the hosting platform, never passwords pasted into an email
With that package, a competent developer can usually tell you within hours whether you’re looking at a small fix, a medium one, or a rebuild. Without it, they spend the first two days playing detective, and you pay for the detective work.
This is the exact intake we built our rescue service around. The diagnostic is $450, it gets credited against the fix if we do the work, fixes start at $950, and you get a ballpark inside 24 hours. No discovery call, no “quick sync.” Send the package, get an answer, keep your weekend.
Once the site is healthy again, make “never again” cheap: keep the code on GitHub, turn on your host’s backups, set a calendar reminder for the domain renewal, and point a free uptime monitor at the homepage. If you’d rather a human watched all of that for you, our care plans start at $290 a month, and we wrote up the maintenance problems AI-built sites actually hit if you want to see what you’d be signing up to avoid.
Questions we get about broken vibe coded sites
My site shows “Not secure” or a privacy warning. Was I hacked?
Almost certainly not. That warning nearly always means an expired SSL certificate, not an intrusion. Click the padlock or site-info icon in your browser, check the certificate’s expiration date, and if it’s past due, renew from your hosting panel. Let’s Encrypt certificates are free and reissue in minutes. The usual culprit is an auto-renewal that failed silently.
Should I ask the AI that built my site to fix it?
You can, with guardrails. Put the code in git first so every change is reversible, paste the exact error message instead of “it’s broken,” accept one change at a time, and test after each. Stop after two failed attempts. The failure mode we see most in rescue work is the late-night loop where each AI fix rewrites files unrelated to the bug, until a small repair becomes a full rebuild.
How much does it cost to fix a broken vibe coded website?
The honest range runs from free to a full rebuild. Expired certificates, lapsed domains, and DNS mistakes cost nothing but a login and some patience. Code-level fixes vary with the damage. Our rescue work starts with a $450 diagnostic that gets credited if we do the fix, and fixes start at $950. If repairing would cost more than rebuilding cleanly, we say so before you spend the money.
How do I stop this from happening again?
Reversibility and monitoring, in that order. Keep the code in a GitHub repo, keep host backups switched on, point a free uptime monitor at the site, and put the domain renewal date on a calendar you actually look at. None of that requires a developer. A maintenance plan adds a human who notices problems before your customers do, which is the one part software can’t fully replace.