YOU BUILT IT. NOW LET GOOGLE KNOW.

I have a strong dislike for the marketing term vibecoding. In my opinion it is just ai-bubble speak for being creative. In unparty.app there is no such thing as vibe coding. There's learning fast, and building out ideas that connect problem to their solutions. Connecting the gap between creatively learning and building is connecting someone who is searching for the next step to their problem and how quickly your creative solutions can get into their hands. Using AI tools for learning and ideating around a problem you want to solve can be helpful because they optimize for the demo: does it render, does it look right, does it work when you click around it yourself. However, none of that has anything to do with how someone finds the solution you are building. Can a search engine find your solution, understand it, or trust it enough to show it to anyone?

A generated app can look completely finished and still be structurally invisible to Google. Not ranked low. Invisible — as in, never indexed, never crawled correctly, or crawled as an empty page with none of the content a human sees in the browser. This isn't a ranking problem you fix later with better copy. It's usually one of a handful of specific, mechanical failures that AI-generated scaffolding produces by default because they're the easiest pattern to generate, not because anyone decided discoverability didn't matter.

• Pages that fetch their content client-side after the page loads, so a crawler sees an empty shell
• Sitemaps that only list a handful of top-level routes, missing every individual page underneath
• Zero structured data anywhere — no way for Google to know an article is an article
• Every page sharing the same generic title and description, so nothing looks unique
• Canonical URLs and social preview images silently pointing at localhost in production
• Domain redirects configured as temporary instead of permanent, which tells Google not to trust the destination

If you're a developer, you at least know to ask the question. If you're a non-technical founder, an entrepreneur, or a small business owner who built your site or app with an AI tool specifically because you don't write code, you have no way to catch any of this yourself — and no reason to suspect it's happening, because the tool told you it worked. For a small business, this isn't an abstract SEO problem. Being found on Google is often the entire acquisition channel: the customer who's already searching for exactly what you do, at the moment they need it. An invisible app doesn't fail loudly. It just quietly never shows up for the person looking for it, and there's no error message telling you that's what's happening. You just see fewer customers than you expected, and the easiest wrong conclusion is that the business idea didn't work — when the actual problem was three lines of missing metadata.

We didn't have to go looking for a hypothetical example. unparty.app had every symptom on that list, simultaneously, in production. Here's what a real audit turned up:

None of these are exotic bugs. They're the default output of optimizing for "does it look right when I look at it." Fetching data in a useEffect is the easiest pattern to generate and the easiest to verify visually — the page renders fine in a browser with JavaScript enabled, which is the only way anyone testing it will ever look at it. A generic sitemap script that lists the routes someone remembered to add is easier to write than one that walks your actual content. An unset environment variable fails silently in a way that's completely invisible until you specifically go looking for the string "localhost" in your production HTML. Every one of these shortcuts is locally reasonable and globally catastrophic for discoverability — and a tool optimizing for "ship something that works when I click on it" has no reason to catch any of them.

1. Server-render the content itself, not just the shell — a crawler that can't execute JavaScript needs the real content in the initial HTML
2. Generate the sitemap from your actual content source, not a hand-maintained list of routes someone remembers to update
3. Add real structured data (Article, BreadcrumbList, Organization) so Google knows what kind of content it's looking at, not just that a page exists
4. Give every page its own title and description sourced from what that page actually is — duplicate titles are treated as a site-wide quality signal, not an isolated issue
5. Verify canonical URLs and OG images resolve to your real production domain, not whatever the environment variable defaults to when unset
6. Make domain redirects permanent once they're final — a temporary redirect is Google being told, explicitly, not to consolidate trust in the destination yet

This isn't an argument against building fast, and it isn't an argument against using AI to do it. It's an argument against treating "it works when I look at it" as the finish line. Every fix on that list is boring, mechanical, and something a systematic build process catches before it ships — not something you discover three months later when you're wondering why nobody's finding what you built. Building in public means the failures are visible too. This is what one of them looked like, and this is exactly what it took to fix it.