7 Things Vibe-Coded Websites Get Wrong, and How to Check Yours

I use AI tools every day. They are good at producing pages and first-draft copy fast. The step they skip is the review, where someone reads what actually got published and confirms Google can read it. If you want a sense of what a reviewed site looks like, I wrote about what real web design looks like.

For the State of Local Business Websites 2026, I ran 90,632 automated audits against 58,541 local business websites across the United States. The typical local business site scored 51 out of 100, barely halfway to what search engines reward. Four out of five fail a basic mobile usability check, on the device most local searches happen on. And 20% leave the WordPress admin login open to the public internet.

Here are seven problems that turn up on sites published without that review, and how to check your own.

Content that only exists after JavaScript runs

On many generated sites I review, the text lives in JavaScript, not in the raw HTML. When a crawler requests the page, it gets a shell and a script. Google does render JavaScript pages, but not instantly. Google Search Central explains that Googlebot queues all pages with a 200 HTTP status code for rendering, and the page may stay on that queue for a few seconds, but it can take longer than that. If your content is not in the initial HTML, you are waiting on a queue.

It gets worse for AI crawlers. Vercel reported in December 2024 that none of the major AI crawlers currently render JavaScript, and that ChatGPT and Claude don't execute JavaScript, so any important content should be server-rendered. If you want your business to show up when someone asks an AI assistant for a recommendation, your text needs to be in the HTML those crawlers actually read.

Check it yourself: open your homepage in a browser, right-click, and choose View Page Source. Search for a sentence from your own copy. If you cannot find it in the raw HTML, your content is JavaScript-only.

The same title tag on every page

A builder that reuses one template for every page can give every page the same <title> element, or a title that is just your business name repeated. Google's guidance on title links is direct: avoid repeated or boilerplate text in title elements. When every page says the same thing, nothing in the title tells Google or a searcher which page is which.

Our audit found that 37% of local business sites have no meta description at all, the short summary Google can show under your name. That is a related symptom of the same skipped step: nobody looked at the page-level metadata after the builder generated it. Check it yourself: view the source on your homepage, your services page, and your contact page. Look at the <title> tag in each. If they are identical or nearly identical, fix them one at a time. Each page should name the page and the business, not just the business.

No LocalBusiness structured data

Structured data is a block of code that tells Google what your page is about in a format it can parse. Google's Local Business structured data documentation says you can use it to tell Google about business hours, different departments within a business, your physical address, and a primary phone number. Confirm two things: that the block exists, and that its address and phone match your contact page. Without it, Google works your name, address and hours out of the visible text.

To find it, view the source and search for "LocalBusiness" or "application/ld+json". If you find nothing, you have no structured data. If you find a block, read it and confirm the address and phone number match what is on your contact page.

Images without width and height attributes

When an image loads without declared dimensions, the browser does not know how much space to reserve. The page renders, the image arrives, and everything below it jumps. web.dev calls this cumulative layout shift, and sites should strive to have a CLS score of 0.1 or less. The same page notes that the cause of layout shifts might be images or videos with unknown dimensions, and the fix is simple: always include width and height size attributes on your images and video elements.

Generated pages I review often carry <img> tags with a source and alt text but no width or height. The page looks fine in a fast preview; on a phone over a slower connection, the text jumps as each image arrives. Check it yourself: view the source and look at a few <img> tags. If they lack width and height attributes, that is the issue. You can also load the page on your phone over cellular and watch whether text moves as images appear.

The same page live on more than one hostname

Your site might be reachable at both example.com and www.example.com, or at a preview URL the builder generated and never removed. Google treats those as separate addresses for the same page. Its guidance on consolidating duplicate URLs says canonical signals help consolidate signals for similar or duplicate pages, and its example lists https://home.example.com and https://www.example.com as alternate addresses for one page. The advice is to pick one canonical version and redirect the others.

When both versions load the same content with no redirect, the signals Google uses to rank the page are spread across two addresses instead of one. A preview or staging address left live does the same thing. The test takes thirty seconds: type your domain with www and without www into a browser. If both load the same page and neither redirects, you have a duplicate hostname problem. Pick one, set a 301 redirect from the other, and confirm it works.

A noindex tag left over from staging

Preview and staging builds are often marked noindex so they stay out of search before launch. The problem is a page that keeps the tag after launch. Google's documentation on blocking search indexing with noindex is blunt: Google will drop that page entirely from Google Search results, regardless of whether other sites link to it. There is a second trap: the page must not be blocked by a robots.txt file, because if it is, the crawler will never see the noindex rule, and the page can still appear in search results. Blocking a page in robots.txt is not the same as keeping it out of search.

View the source and search for "noindex". If you find it on a page that should be indexed, remove it. Then check your robots.txt file to make sure it is not blocking the page from being crawled at all.

API keys and secrets sitting in the page code

This one matters for your wallet more than your rankings. A site that calls an AI or mapping service from the browser can end up with a key that should have stayed on the server written into the page, where anyone who views the source can copy it. In a September 2025 report, RedHunt Labs, a security vendor, collected more than 130,000 sites published on 13 popular platforms for vibe-coded sites and reported that one in every five exposed at least one sensitive secret, roughly 25,000 unique secrets for services like OpenAI, Google and ElevenLabs. That is the vendor's own scan, not an independent study, but the check is the same either way.

A leaked key gets used on someone else's project, and the bill comes to you.

Search your page source for "api_key", "sk-", "AIza" or "Bearer". A match is a lead, not a verdict: some keys, such as a restricted maps key, are meant to be public. If what you find is a secret key that grants access or spends money, revoke it in the provider's dashboard and move that call to server-side code.

If you would rather not do this yourself

I run these checks as part of the web design work I do in Lynchburg and Roanoke. If you want a second set of eyes on a site you built or bought, request a free teardown and I will walk through what I find. Or get in touch and tell me what you are working with. No pitch, just a look at the code.