A founder we worked with last spring launched their app on a Tuesday. By Friday they’d told every group chat, every LinkedIn contact, every old colleague who’d ever asked “what are you working on”. Three weeks later, they searched their own company name on Google. Nothing. Not the homepage, not a single page, not even a listing that said “this site might be relevant”. Ai app seo issues like this catch people off guard because nobody warns you about them until it’s your app that’s gone missing.
This is one of the most common calls we get, and it almost always traces back to the same root cause: the app was built as a single-page application (SPA), and nobody told the founder that SPAs and search engines don’t naturally get along.
Why client-rendered apps are invisible to Google
Most AI coding tools default to a client-side rendering pattern. The browser downloads a mostly empty HTML shell, then JavaScript runs and builds the actual page content in real time, once it’s loaded in your device. That’s fine for you, sitting in Chrome with a fast connection and JavaScript enabled. It’s a much bigger ask for a crawler.
Googlebot can execute JavaScript, but it does so in a separate rendering pass that happens later, sometimes days later, and it doesn’t always wait around or retry if something breaks. If your app fetches content from an API after the page loads, if it needs a user to click something before real content appears, or if the render takes too long, the crawler may index an essentially blank page. Other engines and AI answer bots are often worse at this than Google. Bing’s crawler has historically struggled more with JavaScript-heavy pages, and several AI-driven search tools don’t render JavaScript at all, they just read the raw HTML.
This is the technical explanation behind “why isn’t my app on Google”: the page you see in your browser and the page Google actually receives can be two completely different documents.
The difference between “loads in my browser” and “indexable”
We hear a version of this a lot: “But it works, I can see it, I sent the link to my mum and she could see it too.” Loading is not the same thing as indexing. Indexing requires three separate things to go right, and vibe-coded apps commonly fail at least one of them.
First, the crawler has to be able to fetch the page and get meaningful HTML back, not a shell. Second, the page needs proper metadata: a unique title, a meta description, canonical tags that point to the right URL rather than a generic one repeated across every route. Third, Google has to decide the page is worth including in the index at all, which depends on content quality, internal linking, and whether the site as a whole looks trustworthy.
We’ve opened up vibe-coded projects where every single page, dashboard, pricing, blog, contact, shared one identical page title and one identical meta description, because the AI tool generated a single template and never varied it per route. Google sees fifty pages that all claim to be about the same thing and, reasonably, assumes most of them aren’t worth showing. This is a classic pattern we cover in our guide on why vibe-coded apps break in production: the app is functionally fine but structurally invisible, and the two problems look nothing alike from the founder’s chair.
The fixes: pre-rendering, meta tags, sitemaps
The good news is that these problems are well understood and, in most cases, fixable without a full rebuild.
Pre-rendering or server-side rendering is the biggest lever. Instead of shipping an empty shell and letting JavaScript fill it in, the server sends fully-formed HTML on the first request. Frameworks like Next.js, Astro, and Nuxt support this natively, and it’s the difference between a crawler seeing your actual content immediately versus having to gamble on a second-pass render. If your app was built with a framework that renders everything client-side by default, adding this layer is usually the single highest-leverage fix available.
Meta tags need to be unique per page, not copy-pasted from a template variable that never got filled in. Title, description, canonical URL, and Open Graph tags should reflect what’s actually on that specific page. This sounds basic, and it is, but it’s also the thing AI tools skip most often because nobody explicitly asked for it in the prompt.
A sitemap.xml file, submitted through Google Search Console, tells crawlers which URLs exist and roughly how important each one is. Without one, Google has to discover your pages purely through links, which is slow and unreliable for a new site with a thin backlink profile.
Structured data (schema markup) is worth adding too, particularly Organization and Article schema, since it helps search engines and AI answer engines understand what your business actually does, not just what words appear on the page.
How to check if your app is actually indexed
You don’t need to guess. Search site:yourdomain.com in Google. If nothing comes back, or only one or two pages show up when you have dozens, that’s your answer.
Google Search Console is the more reliable tool. Add your property, submit your sitemap, and use the URL Inspection tool on a handful of key pages. It will tell you directly whether a page is indexed, and if not, why: “Discovered, currently not indexed”, “Crawled, not indexed”, or “Page with redirect” are the phrases you’re looking for. Each one points to a different root cause, and Search Console is honest about which one applies.
It’s also worth fetching a page’s raw HTML directly, view-source in the browser, or a simple curl request, and reading through it without letting JavaScript run. If the content you care about isn’t there in that raw response, that’s roughly what a lot of crawlers are seeing too.
What only a rebuild can fix
Some of this is a config change. Some of it isn’t. If your app’s routing is handled entirely client-side with no server rendering option at all, if the framework itself has no pre-rendering path, or if the content is deeply entangled with client-only state that can’t be reconstructed on the server, patching individual pages won’t get you there. At that point you’re looking at restructuring how the app renders, which is a bigger job but usually not a full rewrite. Our guide to taking vibe-coded apps to production walks through what that upgrade path typically involves.
It’s also worth stepping back and asking whether the underlying code quality is going to keep causing problems like this one. SEO issues are often the first visible symptom of a codebase that was built quickly and never reviewed properly. If you’re not sure how to judge that yourself, our guide for non-technical founders on assessing code quality is a reasonable place to start before you spend money on either an SEO fix or a full rebuild.
Launched but invisible on Google? We’ll find out why. Get a free assessment and we’ll tell you straight whether it’s a quick fix or something bigger.