Why Your AI-Built App Is Invisible to Google and ChatGPT

You built something with an AI tool, it works, the link opens for anyone you send it to. Weeks pass and your own company name does not find it on Google. You ask ChatGPT about the thing you built and it has never heard of you. Nothing is broken, which is the confusing part.

This is one of the most common questions we get about AI-built apps, and it is rarely a content or marketing problem. It is usually that the app cannot be read by anything that is not a web browser with scripting switched on.

The test that takes thirty seconds

Open your live site, right-click, and choose view page source. You are looking at exactly what a crawler is handed before it does any further work. Now search that text for a sentence from your home page.

If you find it, your content is in the HTML and your problem is somewhere else. If what you see instead is a short file with a few script tags and an empty element, your words are not in the page at all. They are assembled afterwards, in the visitor's browser, by code that runs after the file arrives.

Twenty routes, one page

There is a second problem hiding behind the first. Most AI builders generate a single-page application: one HTML file serves every address, and the app swaps the content as you navigate. Your pricing page, your about page and each of your listings all start life as the same file.

That means they share a title and a description, if they have one at all. Search results are built from those. So even where a crawler does manage to read your app, it may find one indistinguishable page rather than the twenty distinct ones you think you published, each of which could have answered a different question someone types.

Rendering is not the same as being read

Search engines can run JavaScript. That is true and it is the sentence that misleads people. Running it is expensive, so it is deferred and queued, which means your pages may wait for a second pass that happens on someone else's schedule, and that assumes nothing fails on the way: a slow response, a script error, a resource the crawler was not allowed to fetch.

Content that exists in the HTML needs none of that. It is read on the first visit, every time. This is the same build decision we argue for in technical SEO is a build decision — this article is just what it looks like when the decision was made for you by a tool.

Assistants are a different audience

Being absent from ChatGPT is a related but separate matter, with its own rules worth knowing.

OpenAI documents several crawlers with different jobs: one that surfaces sites in ChatGPT's search features, one that gathers content that may train its models, and one that fetches a page when a user asks for it directly. Each is controlled independently in your robots.txt file, so a site can be open to one and closed to another without anyone intending that. If the crawler behind ChatGPT's search is disallowed, the site will not appear in those answers.

The second difference matters more. Assistant crawlers generally fetch your HTML and work from it; they are not browsers, and vendors do not promise to execute your scripts. A page that depends on scripts to say anything is therefore a blank page to them, not a low-ranking one. There is no second pass to wait for.

The settings that quietly make it worse

Before rebuilding anything, rule these out. Each is a one-line cause with a one-line fix, and we find at least one of them most times we look.

• A leftover instruction telling search engines not to index the site, added while it was a private preview and never removed.
• A robots.txt file, generated by the builder or copied from somewhere, that blocks more than anyone realised.
• The builder's own preview address still being the indexed one, while your real domain is treated as a separate site.
• No sitemap at all, or one listing a single address, so nothing points a crawler at the rest.
• A site so new that nothing links to it yet. Discovery needs at least one route in, and a brand-new address with no links is genuinely hard to find.

What fixing it actually involves

If the thirty-second test came back empty, the fix is to make the content exist in the HTML the server sends. For pages that must be found, that means rendering them on the server or generating them at build time, so the file that arrives already contains the words.

How large that job is depends on what the builder produced. Sometimes the public pages can be split out and served as real pages while the signed-in application stays exactly as it is, which is the cheap version and usually the right one: nobody needs your dashboard indexed. Sometimes the app's structure has to change, which is a genuine piece of engineering rather than a setting to toggle.

Either way the rest follows the same pattern: a distinct title and description per route, generated from your content rather than typed in by hand, one canonical address that everything else redirects to, and a sitemap built from the same source so a new page cannot ship missing from it.

Worth saying plainly: this is not a ranking strategy. It is the prerequisite. Doing it does not promise you positions or traffic, it only means your pages can be read by the things that decide those. Skipping it means nothing else you do about search can work.

What to do next

Run the view-source test today, then check the four settings above. That is enough to tell you whether you have a half-hour problem or an architecture one, and the answer changes what you should spend money on.

If the app also has to be made safe for real users, discoverability is one part of a larger job: seven problems we check first covers the rest, and we do that work as an AI prototype rescue. If the app is otherwise fine and it is only search and assistants that cannot see it, that is technical SEO, and it is the cheaper of the two conversations. Not sure which you need? Send us the link and we will tell you which one it is.