Vibe-coded website isn't performing: 7-point first-aid checklist
A website built with an AI tool can be live in hours - that is the point of vibe-coding. Fixing an AI-built website does not mean a full rewrite in the vast majority of cases. You need to systematically check seven areas: Core Web Vitals and speed, HTTPS and basic infrastructure, code security, SEO structure, technical debt, accessibility, and updates with a backup plan. You can catch most critical errors in an AI-generated site in a single afternoon - without a complete rebuild from scratch.
What is a vibe-coded website and why it underperforms
Vibe-coding is a way of building websites and applications where you describe what you need in plain language to an AI tool - such as Cursor (AI code editor), Lovable (AI app builder), Bolt by StackBlitz, or v0 by Vercel - and the tool generates working code. The result looks finished at first glance: registration works, content displays, payments go through. Behind this facade, however, are problems that only surface after deployment in real production conditions.
AI generates code that works - not code that is optimised for production. The generator does not know anything about loading speed on your customers' mobile phones, about security standards for your type of application, about the SEO structure Google evaluates in 2026, or about the cost of maintaining the code three years from now. These gaps are not fatal, but they need to be found and closed - and that is what a systematic audit is for.
Vibe-coding exploded in 2025 and 2026. According to the ProjectDiscovery „2026 AI Coding Impact Report" - a survey of 200 security professionals across North America and Western Europe - 100% of respondents reported an increased volume of code produced in the past 12 months, with nearly half (49%) attributing most of this growth to AI-assisted tools. Security teams at mid-sized companies feel it most: 69% of them report increasing difficulty keeping up with security reviews of the growing volume of AI code.
For small businesses that had a vibe-coded website built at a significantly lower cost than custom development, this means one thing: the site runs, but probably not as well as it could. And code vulnerabilities are a real risk.

7-point audit checklist: overview
Before going into the detail of each point, here is a complete overview of the audit in one table. Each area has its own severity level: critical means the issue can cause a security incident or direct loss of customers; high is a condition that damages performance or SEO; medium may not have an immediate impact, but the burden grows over time.
| # | Audit area | What you look for | Tool | Severity |
|---|---|---|---|---|
| 1 | Core Web Vitals | LCP below 2.5 s; INP below 200 ms; CLS below 0.1 | PageSpeed Insights | Critical |
| 2 | HTTPS and infrastructure | Valid SSL; HTTP redirects; mixed content | Browser, SSL Checker | Critical |
| 3 | Code security | Exposed API keys, authentication, OWASP A01-A03 | Manual audit, SCA tools | Critical |
| 4 | SEO structure | H1, meta, sitemap.xml, schema markup | Search Console, Rank Math | High |
| 5 | Technical debt | Outdated dependencies, dead code | npm audit / WP Scanner | High |
| 6 | Accessibility (A11y) | Alt texts, ARIA, colour contrast, keyboard nav | Lighthouse, axe DevTools | Medium |
| 7 | Updates and backups | Update cadence, backup plan, monitoring | WP-CLI, uptime monitor | High |
Points 1 and 2: Speed, Core Web Vitals, and infrastructure
Website speed is not an aesthetic question - it is a direct ranking signal. Google evaluates every page according to Core Web Vitals, collecting data from real browsers of actual visitors through the Chrome User Experience Report. The thresholds are precisely defined in the Google Search Central documentation:
- LCP (Largest Contentful Paint) - loading time for the main visual content of the page: below 2.5 seconds for a good result.
- INP (Interaction to Next Paint) - website responsiveness during interaction (click, key press): below 200 milliseconds.
- CLS (Cumulative Layout Shift) - visual stability during loading, the extent of unexpected element shifts: below 0.1.
What these metrics mean in practice and why they matter for both Google and conversions is explained in the companion article What are Core Web Vitals and why they matter. If you are not sure where your metrics stand, see the step-by-step guide in How to quickly check whether my website is slow.
AI-generated websites typically fail to meet these values right after the first launch for two reasons. First, images are not compressed and do not have dimensions set correctly in the HTML - the AI generates <img src="hero.jpg"> without width, height, or a WebP variant. Second, JavaScript loads in a render-blocking way because the generator does not know which scripts are critical for the first render and which can wait for defer or async.
What to do: Run PageSpeed Insights (pagespeed.web.dev) on the homepage and on three representative sub-pages. Any score below 50 on mobile is a rescue signal. The specific steps for fixing speed - from image compression through lazy-loading to critical CSS - are within reach for most WordPress administrators without a developer. You just need to know exactly what PageSpeed is showing you.
HTTPS is mandatory, not optional. Modern browsers mark websites without a valid SSL certificate as insecure - every visitor sees this warning directly in the address bar. Check three things: (1) the certificate is valid and not expired, (2) all HTTP addresses redirect to HTTPS including the variant without "www", (3) no resources - images, scripts, styles - load over unsecured HTTP (mixed content).
Point 3: Code security - fixing an AI website is also a security audit
Security is the area where AI-generated code most frequently falls short. The reason is systemic: an AI model optimises for „working code" during generation, not for „secure code in a production environment". These two things are the same in basic testing, but in real load they differ substantially. Here are the four most common issues we find in audits:
Exposed secrets and API keys
AI generators tend to place API keys, tokens, and database passwords directly in source code - sometimes in files that end up in a public Git repository. The basic procedure: check every configuration file and .env files, verify that .env is in .gitignore and has not been committed, and review commits in the repository history. If a key has leaked, it must be revoked immediately and a new one issued - fixing the file alone is not enough.
Authentication and authorisation (OWASP A01:2025)
According to OWASP Top 10:2025, Broken Access Control (A01) ranks first among the most critical web application vulnerabilities. AI-generated code typically implements a login page but forgets to verify permissions on every API endpoint. The result: an unauthenticated user can retrieve another customer's data or execute an operation reserved for administrators. Test manually - try accessing protected URLs without authentication and observe what the server returns.
Security misconfiguration (OWASP A02:2025)
A02 in OWASP Top 10:2025 covers incorrect server and application configuration - the second most common issue in web projects. AI sets default configurations that are not suitable for production: debug mode enabled in production, verbose error messages displaying stack traces to the public, unchanged default database passwords, or test accounts with elevated privileges left active.
Injection attacks and input validation
AI generates SQL queries as strings, not as parameterised queries with prepared statements - the classic foundation for SQL injection. This is especially true for frameworks where the AI does not say „I will use an ORM with automatic escaping" but simply generates code such as „SELECT * FROM users WHERE email = '" + email + "'". Check every form and every endpoint that accepts user input.
For auditing WordPress projects we recommend the Patchstack scanner, which checks for vulnerable plugins and themes. Our experience with systematically cleaning up code during migrations from outdated architecture is also described in the article on migrating from Elementor to a clean WordPress theme - the audit principles are largely the same.

Points 4, 5, and 6: SEO, technical debt, and accessibility
SEO structure - the foundation for visibility in Google
AI can generate content, but SEO metadata is often generated generically or is missing entirely. Key items to check in the SEO structure:
- Every page has a unique <title> (50-60 characters) and meta description (150-160 characters) - not the same template copied across all URLs.
- Each sub-page has exactly one <h1> - not zero, not three.
- Images have alt texts with a real description of the content, not just „img_1234.jpg" or an empty attribute.
- A sitemap.xml exists at /sitemap.xml and is correctly registered in Google Search Console.
- robots.txt does not accidentally block indexing of important sub-pages.
- Canonical URLs are set correctly for duplicate content (e.g. URLs with parameters).
In 2026, Google AI Mode is also changing SEO dynamics - for vibe-coded websites, correct semantic HTML structure and clearly answering content blocks are essential for citations in AI responses. We covered this in detail in the article Google AI Mode is replacing traditional search: what it means for your website. If you need a complete SEO audit, our SEO optimisation service covers technical analysis and content recommendations.
Technical debt - the invisible burden
AI-generated code grows with every iteration of requirements: each fix adds new code without removing the old. After several months of work you have a project with a substantial proportion of dead code, several versions of the same library, and dependencies no one has updated. This is technical debt - and you pay for it every month in the form of a slower website, harder maintenance, and a larger attack surface for security threats.
What to do specifically: Run npm audit (for Node.js projects) or the Patchstack scanner (for WordPress), identify vulnerable packages, and set up a regular update process. Review CSS/JS files and remove unused styles and scripts. Check that the CMS core and theme are on the current version.
Accessibility (A11y) - an SEO factor and a legal consideration
WCAG 2.1 at level AA is the standard for business websites and also an SEO factor - Google evaluates the semantic quality of HTML when determining content relevance. AI generators typically omit: ARIA labels on interactive elements (buttons without visible text, modal windows), sufficient colour contrast (minimum ratio of 4.5:1 for regular text), keyboard navigation, and alt texts for functional images. A Lighthouse audit in Chrome DevTools will show most of these issues in a minute - the „Accessibility" tab gives you precise errors with links to solutions.
Point 7: Updates, backups, and post-launch monitoring
A vibe-coded website does not take care of itself after launch. Neglecting updates is one of the most common reasons AI-generated websites go down or get compromised in the first 6-12 months after launch. Here are the specific steps to set up:
- Backups: daily database and file backups to a separate location (different server or cloud storage). A backup on the same server as the website makes no sense - if the server goes down, you lose both.
- Updates: update the CMS core, plugins, and theme without delay when a security patch is released. We recommend monitoring notifications in the WordPress admin panel or setting up automatic updates for security patches.
- Uptime monitoring: free tools like UptimeRobot send a notification to email or Slack when the website goes down - you do not have to wait for a customer to alert you.
- SSL certificate: monitor the expiry date, set up auto-renewal. Let's Encrypt certificates are valid for 90 days - if auto-renewal fails (e.g. after a DNS change), the website falls into an HTTPS error.
- Error monitoring: set up logging for server errors (PHP errors, 404 pages, failed logins) and review them regularly.
When to fix and when to rebuild from scratch?
Not every vibe-coded website is worth fixing - sometimes a new custom website is more economical. This is not a blanket answer: it depends on the severity of findings, the business context, and the age of the project. Here is an indicative decision framework:
| Situation | Fix | Partial rewrite | New website |
|---|---|---|---|
| Security issues in isolated parts of the code | Yes - targeted patches | For extensive auth bugs | Rare |
| Performance (CWV score below 50 on mobile) | Image optimisation, lazy-load | Refactor JS/CSS bundles | Only for fundamental arch. flaw |
| SEO structure completely absent | Add meta, schema, sitemap | URL restructuring | Rare case |
| Technical debt over 50% of the code | Selective refactor piece by piece | Migrate gradually | When changing the entire stack |
| Business change or core functionality change | No | Partial redesign | Yes - new requirements |
Note: These are indicative scenarios for a general idea - a specific recommendation depends on the project scope and the audit results.
The general rule that applies when auditing websites: if the vibe-coded website solves the right business problem, has good content, and passes at least 4 of the 7 checklist points after its first launch, fixing it is the more economically sensible choice. If it fails on security points 2 and 3 simultaneously and the code architecture does not allow an isolated fix, investment in a new custom website delivers more return over a 2-3 year horizon.
If you are deciding whether your website has reached the point where fixes are no longer sufficient, read our overview of 5 signals that it is time for a website redesign - several of these signals apply equally to vibe-coded projects.

In practice: what we see in the market
When auditing websites for small businesses and e-commerce stores, we encounter several recurring patterns in AI-generated projects. We describe them generically - not specific clients, but typical situations that repeat:
- Exposed API keys are the most common security finding - payment gateway or email provider keys in the repository, sometimes even in commit history, where simply deleting the file is not enough.
- LCP above 5 seconds on mobile due to a hero image with its original size of several megabytes - the AI generated an <img> without dimensions and without WebP conversion.
- Missing input field validation in forms - the contact form passes input directly to a database query or email body without sanitisation.
- A sitemap exists but is not registered in Search Console - the website „looks indexable", but Google is not actively crawling it because it has no knowledge of new content.
- Backups run on the same server - when the hosting goes down, you lose the backup too. This is one of the first configuration steps we address when taking over any website into our management.
When Denva takes over an AI-generated website for post-AI repair, we always start with a compact audit following the 7-point checklist described above. The result is a prioritised list of findings with an indicative estimate of the hours needed for each fix - no fluff, just concrete steps. Four phases, no surprises.
If your website has hit a problem that goes beyond a quick fix, consider whether a complete redesign makes sense - for example, if the business has moved beyond the original scope for which the vibe-coded project was designed.
Conclusion: from "works" to "works reliably"
A vibe-coded website is not automatically a bad website. It is a website that got a fast start and now needs routine security and performance review - just like any website launched five years ago without ongoing maintenance. The seven points in this checklist cover the vast majority of reasons why AI-generated websites stagnate in rankings, lose customers, or get compromised in their first year of operation.
If you need an independent perspective on the code and audit results - or if you do not have time to do it yourself - contact us via a no-obligation consultation. We respond within 24 hours and tell you specifically what your website needs.
Frequently asked questions.
What is a vibe-coded website?
A vibe-coded website is a site or application built primarily through an AI tool (Cursor, Lovable, Bolt, v0, and similar), where a person describes requirements in plain language and the AI generates the code. It typically takes shape faster than a custom website, but without a systematic audit it may have speed, security, or SEO issues.
Is fixing an AI-built website more expensive than building a new one?
Fixing is usually cheaper - roughly 20-40% of the cost of a new website, if the fundamental architecture holds. A new website makes sense when the vibe-coded project fails in multiple areas simultaneously or when the core business requirements have changed substantially. We will give you a specific figure after a short consultation.
How long does a vibe-coded website audit take?
A basic security and performance audit (points 1-3 from the checklist) takes 1-2 working days. A comprehensive audit including SEO structure, code review, and accessibility takes 3-5 working days. The output is a prioritised list of findings with effort estimates for each fix.
Can I fix a vibe-coded website myself?
Yes, if you have technical knowledge. Points 1 (CWV), 4 (SEO), and 6 (accessibility) are within reach of most WordPress administrators using free tools (PageSpeed Insights, Search Console, Lighthouse). Points 3 (code security) and 5 (dependencies) require programming experience or an external audit.
Is vibe-coding a safe way to build a website?
Vibe-coding is a productive way to build a prototype or MVP. For a production website with real customers and payments, a security audit is essential - not because the tool is bad, but because the AI generator does not know your specific security requirements without human review. Issues found can usually be fixed without a full rewrite.