The Vibe Coder's Guide to Getting Found: Why Nobody Uses the Thing You Built

You built the thing. It works. You put it online, you shared it in two or three places, a few people said "this is cool", and then nothing happened. Days pass. The analytics show you, your co-founder, and possibly your mother.

This is the most common story in software right now, and it is worth saying plainly that it is not a sign you built something bad. Building got dramatically easier over the last two years. Distribution did not get easier at all. So a great many people are now arriving, all at once, at a wall that used to be reached only by the small number who could get an app finished. The wall was always there. More of us are simply reaching it now.

This guide is about getting through that wall using search, in both of its modern forms: the classical one, where somebody types into Google, and the newer one, where somebody asks ChatGPT or Perplexity or Gemini and receives an answer with a handful of sources attached.

It is long, because the honest version is long. But it is ordered, and the order matters. Do these things in sequence and you will not waste weeks on the wrong one.

Part 1: The uncomfortable diagnosis

Before anything else, go and do this. Open your app in a browser, right click, and choose "View page source". Not "Inspect", which shows you the page after JavaScript has run. "View page source", which shows you what the server actually sent.

Now look for your own words. Your headline. Your description of what the product does. The name of a feature.

If you cannot find them, and instead you see a mostly empty page with a <div id="root"></div> and some script tags, you have just discovered the thing that most commonly makes a new app invisible. That is the raw material every crawler starts from.

Now, before you panic: this test is less conclusive in 2026 than it was in 2024, and I will explain why in Part 3, because the platforms have quietly changed underneath everybody. But it is still the right first look.

Here is the full list of what typically goes wrong. Most new apps have five or six of these at once:

The content is not in the HTML. The page is assembled in the browser, so the first response contains almost nothing.
There is no sitemap. Nothing tells a search engine what pages exist.
Every page has the same title. A single-page app usually ships one set of meta tags in index.html, so every route shares one title and one description.
The site lives on a platform subdomain. Something like yourapp.bolt.host or yourapp.replit.app.
There is no structured data. Nothing tells a machine "this is a software application, it is free, here is what it does".
There is only one page. The whole product is one screen, so there is exactly one thing you could possibly rank for.
The value is behind a sign-up. A wall in front of your product is also a wall in front of every crawler.

Number six is the one people underestimate most, and we will spend real time on it, because it is where the largest and cheapest wins live.

Part 2: Why "just wait for Google" is bad advice for a new app

Everyone launching a website hears the same thing. Be patient. New domains take months. Google needs time to trust you.

This advice is not wrong exactly. It describes real behaviour. A new domain has no backlinks, because nobody has had time to link to it. It has no history of satisfying searchers, because nobody has searched and found it yet. Google is cautious with such a site, and that caution is reasonable, since the alternative is trusting every domain registered ten minutes ago.

But "be patient" has become incomplete advice, because it assumes search is only Google. And we have watched, on a site we can point at, that this assumption is now costing people their first users.

What a 26-day-old domain actually did

Kurli is an AI hairstyle advisor. You upload one selfie, your face is mapped in the browser to work out its shape and proportions, and the cuts that genuinely suit that face are rendered onto your own photo.

The domain, kurli.me, was registered on 27 July 2026. That is a matter of public record in the domain registry, so nobody has to take our word for it.

Here is where its visitors came from in the first 25 days of the domain's existence:

| Referrer | Visits | | --- | --- | | accounts.google.com | 69 | | chatgpt.com | 56 | | kurli.me | 38 | | www.google.com | 23 | | com.google.android.googlequicksearchbox | 5 |

Two of those lines are not new visitors, and it would be dishonest not to say so. The first is the Google sign-in flow, so those are people returning after logging in. The third is the site referring to itself, which is what analytics records when somebody moves from one page to another. Neither is a stranger discovering the product.

Strip those out and the picture is clear:

ChatGPT sent 56 people. Google Search sent 23. On a domain less than one month old, the AI assistant was the largest front door by more than two to one.

Let us be careful about what this does and does not prove. Fifty-six visits is not a flood, and anybody who tells you otherwise is selling something. The absolute numbers are small enough that ordinary variation moves them around. It is one site, in a consumer category where people ask very natural questions, over a short window.

But the ratio is the interesting part, and the age of the domain is what makes the ratio interesting. Twenty-three visits from Google in 25 days is not Google malfunctioning. That is Google behaving exactly as described, cautious toward a domain it met three weeks ago.

ChatGPT did not behave that way at all. It recommended the site to people while the domain was still measured in days.

Why the two systems behave so differently

This difference is not an accident or a temporary bug, and understanding why tells you what to do about it.

Google ranks largely on accumulated authority. Who links to you, how long you have existed, whether people who found you were satisfied. These are, by definition, things that take time to accumulate. It is a reputation system, and reputations are slow.

A language model with browsing is not running a reputation system in that sense. It has a question in front of it and it is looking for the clearest available answer. It has no equivalent instinct to distrust a page because the domain is young. If your page is genuinely the best explanation of what haircut suits a heart shaped face, the age of your SSL certificate does not enter into the calculation.

For anyone launching something new, this is a significant opening. The channel that traditionally takes six months to open was, in this case, outperformed in the first 25 days by the channel most people are still treating as an experiment.

That window will not stay open forever. It is open now because most sites are still built as though Google is the only reader.

Part 3: What actually changed on the vibe coding platforms in 2026

Here is where a lot of the advice online is now simply out of date, and following it will send you to fix a problem you may not have.

If you search for "Lovable SEO" you will find a stack of articles, many written in 2025, all explaining that your app is an empty shell that crawlers cannot read. That was true when they were written. It is substantially less true today, and the details matter enormously, because they determine whether you need to do anything at all about rendering.

We checked each platform's own current documentation rather than repeating what other articles say.

Lovable

According to Lovable's own documentation, new apps created from 13 May 2026 use TanStack Start with server-side rendering. In their words, "Every request returns fully rendered HTML, for humans and crawlers."

Older projects, the ones created before that date, get something different: on-request pre-rendering on deployed public URLs, "served only to verified search and AI crawlers", where the verified list includes Google, Bing, social preview bots, and the AI engines specifically, ChatGPT, Perplexity, Claude and Gemini.

Now here is the detail that saves people a week of unnecessary panic, and it is stated plainly in Lovable's documentation: "Third-party SEO scanners will see the regular SPA shell, not the pre-rendered HTML."

Read that again, because it explains an experience thousands of people have had. You build on Lovable. Somebody tells you to run a free SEO checker. The checker reports that your site is empty, has no content, and cannot be indexed. You conclude your app is broken.

The checker was looking at the shell. Google was not. The tool told you the truth about what the tool saw, which was not the truth about your site.

What Lovable does not do for you automatically, again from their documentation: sitemaps, robots.txt and metadata "are not always generated up front". Unique Open Graph titles, descriptions and images per route are your job. Structured data must be added deliberately.

Bolt

Bolt's SEO capability is called SEO Boost, and their support documentation is specific about it. It serves "a pre-rendered HTML version of your pages to web crawlers" rather than your JavaScript application.

Three conditions attach to that, and each one catches people out:

SEO Boost is available with a paid plan.
It requires a custom domain to enable. Your free bolt.host address will not do.
It is not automatic. You have to ask Bolt to set the metadata you want, page title, description, Open Graph tags, Twitter card tags, canonical URL, structured data. It does not infer them.

And explicitly, from the same documentation, Bolt "only supports SEO Boost for pre-rendering. It can't run custom pre-rendering workflows or tools like react-snap." Sitemaps and robots.txt are not generated for you.

So if you are on Bolt's free tier, on a bolt.host address, the old advice does still describe your situation. Crawlers are getting your JavaScript shell. The fix is a custom domain and a paid plan, and then actively asking for the metadata.

Replit

Replit gives every deployment a free address on .replit.app, and supports custom domains through the Deployments settings, using A and TXT records at your registrar, on Autoscale, Reserved VM or Static deployments.

Rendering on Replit depends entirely on what you built, since Replit runs your code rather than imposing a framework. A Next.js app with server rendering is fine. A Vite React SPA has the same empty-shell problem as anywhere else, and the fix is the same as it would be on any host.

What this means for you

The practical takeaway is that you should find out which situation you are actually in before you fix anything.

New Lovable app, made after mid-May 2026? Rendering is handled. Skip to Part 4.
Older Lovable app? Rendering is handled for real crawlers, but do not trust third-party scanners to tell you so.
Bolt on the free tier or on a bolt.host address? Rendering is not handled. This is your first job.
Bolt on a paid plan with a custom domain? Rendering is handled, but your metadata is not, unless you asked.
Replit, or your own Next.js or Vite app? Depends on your framework. Use the view-source test from Part 1, which is reliable in this case.

Notice that in most of these situations, rendering is no longer the problem. Which brings us to what actually is.

Part 4: You have one page, and that is the real problem

Here is the thing almost nobody tells you, and it is worth more than every technical fix in this guide combined.

Most vibe-coded apps are one page. There is a headline, a demo, some feature bullets, a call to action. It is a good page. It might even be a beautiful page.

But a page can only be found for the things it talks about. One page means one topic, which means, realistically, one search you could ever show up for. And that one search is almost always the most competitive phrasing imaginable, something like "AI hairstyle tool" or "invoice app", where you are up against companies with ten years of history and a marketing budget.

Meanwhile the searches you could actually win are the specific ones. And people ask an enormous number of specific questions.

What Kurli did, concretely

Go and look at how Kurli is built. It is not one page that says "AI hairstyle tool". It has guides organised by face shape. By hair type. By length. Separately for men and for women. There are sections on hair colour, on bangs and fringes, on thinning hair, on which styles work with glasses, on beards.

Every one of those is a real question that a real person types or asks out loud. "What haircut suits a heart shaped face." "Hairstyles for fine thin hair." "What fringe suits a round face." "Do I suit a fringe with glasses."

When somebody asks ChatGPT one of those questions, the assistant is not looking for a company. It is looking for a clear answer. A site with a dedicated page answering exactly that question is a far better candidate than a homepage that says "try our AI tool".

This is why 56 people arrived from ChatGPT in less than a month, on a domain nobody had ever heard of. Not because of a growth hack. Because the site had a specific answer to a specific question, and the assistant found it.

How to find your questions

Sit down and write out every question somebody would ask that your product answers. Not questions about your product. Questions about the problem your product solves. There is a real difference, and it is the whole game.

Somebody with a problem does not search "AI hairstyle tool". They search "what haircut suits my face shape", because they do not yet know that a tool like yours exists. They cannot search for a category they have never heard of.

Aim for twenty of these. Then go and check yourself:

Type each one into ChatGPT and read the answer. What does it recommend? Who does it cite?
Type each one into Google and look at the "People also ask" box, which is a free list of the adjacent questions people really ask.
Look at the "Related searches" at the bottom of the Google results.

You will finish this exercise with a list of thirty or forty real questions. That is your content plan, and you did not have to guess at any of it.

Then build a real page for each

A real page, not a thin one. This distinction matters, because scaling out thin pages is a well-known way to get an entire site treated as low quality.

A real page for "what haircut suits a heart shaped face" explains what a heart shaped face is, how to tell if you have one, which cuts flatter it and why, which ones to avoid and why, what to say to your stylist, and what to do about it if your hair is fine, or curly, or growing out. It reads like it was written by somebody who knows the subject, because it should be.

And it links, naturally, to your tool. Somebody who has just read four hundred words about their face shape is in an excellent frame of mind to upload a selfie.

Ten pages like this will do more for you than any amount of posting on social media, and unlike posting, they keep working while you sleep.

Part 5: The technical work, in the order that matters

Assuming Part 3 told you rendering is handled, here is everything else, ordered by how much it is worth relative to how long it takes.

A sitemap

A sitemap is an XML file listing your pages. It is how a search engine learns what exists without having to stumble across every page by following links.

None of the platforms reliably generate one. Write it, put it at /sitemap.xml, list every real page with a last modified date, and reference it from robots.txt. Then submit it in Google Search Console and Bing Webmaster Tools.

If your pages are generated from a database, generate the sitemap from the same source so it never goes stale. A sitemap listing pages that no longer exist is worse than no sitemap.

A robots.txt that does not block your own site

Very short file, lives at /robots.txt. Two jobs: point at your sitemap, and do not accidentally block anything.

The failure worth checking for is a leftover Disallow: / from a staging environment. It happens more than you would think, and it silently removes you from search entirely.

While you are there, decide deliberately whether you allow the AI crawlers, GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and the rest. If you want to be recommended by assistants, you have to let them read you. This seems obvious, but plenty of sites block them by copying a robots.txt from somewhere without reading it, and then wonder why they are never cited.

A different title and description on every page

If every route shares one title, then as far as a search engine is concerned you have one page repeated many times.

Every page needs its own title, its own description, and its own Open Graph tags. On Lovable and Bolt this is not automatic and you must ask for it. In a React app the usual approach is a small hook or a head component that sets these per route.

Write the title as the answer to the question the page addresses, not as a slogan. "What Haircut Suits a Heart Shaped Face" beats "Kurli | Style Guide" every time, for both a human scanning results and a machine deciding what a page is about.

Structured data

Structured data is a block of JSON in the page that states plainly what the page is. It is not a ranking trick, it is a translation layer, and it removes ambiguity for a machine reading you.

For most apps you want:

SoftwareApplication on the homepage. What the app does, what category, what it costs if anything.
FAQPage on any page with real questions and answers.
Article on your guides.
Organization with your logo and your social profiles, so the entity behind the site is unambiguous.

Do not mark up things that are not on the page. It is checkable, and getting caught inventing structured data is a genuine problem rather than a small one.

The domain decision

A custom domain is worth buying, and not mainly for ranking reasons.

On Bolt it is required before SEO Boost will work at all, so on that platform it is not optional. Beyond that, a platform subdomain tells every visitor that you have not committed, it cannot be moved if you change platforms, and any accumulated reputation belongs to somebody else's domain rather than yours.

Buy the domain before you start building pages, not after. Moving later means redirects, and redirects done hastily lose things.

Speed, briefly

Speed matters, but less than the internet tells you. If your app loads in a reasonable time on a phone on mobile data, you are fine and should go and write a page instead.

The version that genuinely matters is the first screen. Do not let your largest image be a five megabyte PNG. Do not block the first paint on a font file. That is most of it, honestly.

Part 6: How to know whether any of this is working

Three things to set up, all free, and then mostly leave alone.

Google Search Console. Verify your domain, submit the sitemap, and then look at two screens. Page Indexing tells you which pages Google has actually accepted, which is the number that matters and is usually far lower than people assume. Performance tells you what people searched before they saw you, which is frequently a surprise and often better material than anything you guessed.

Bing Webmaster Tools. Worth it for a reason that is not obvious. Bing's index feeds several AI surfaces, and Bing Webmaster Tools reports AI citations, which Google does not. It is one of the very few free windows into whether assistants are actually using you.

Referrer data in your analytics. This is how you would see what Kurli saw. Watch for chatgpt.com, perplexity.ai, gemini.google.com and similar appearing in your referrers.

One warning on that last one, because it catches everybody. A large share of AI-driven traffic arrives with no referrer at all and lands in the "Direct" bucket. Somebody asks an assistant, reads the answer, and types your name into the address bar later. That visit is real and was caused by the assistant, and your analytics will file it under Direct. So whatever number you see from AI referrers, the true influence is larger. Do not conclude that the channel is small just because the referrer column says so.

Part 7: What to do in your first thirty days

If you do nothing else in this guide, do this, in this order.

Days 1 to 3, find out where you stand. Run the view-source test. Work out from Part 3 which platform situation you are actually in. Buy a custom domain if you have not. Set up Search Console and Bing Webmaster Tools.

Days 4 to 7, fix the foundation. Sitemap. Robots.txt, checked properly. Unique titles and descriptions on every route you already have. Structured data on the homepage. This is a few hours of work and it only has to be done once.

Days 8 to 14, find your questions. The exercise from Part 4. Twenty questions from your own head, expanded with People Also Ask and Related Searches. Test the important ones in ChatGPT and note who currently gets cited. Choose the ten you can answer better than whoever is being cited today.

Days 15 to 30, write the pages. One real page per question. Not thin ones. Link each to your tool and to each other where it makes sense. Add FAQ structured data where the page genuinely has questions and answers.

Then wait, because this part is genuinely slow, and the waiting is the hard bit. Google will take weeks to months. The assistants may well be faster, as they were for Kurli, but nothing here is instant.

What you will have at the end of thirty days is a site that answers thirty or forty real questions instead of one, which is a completely different object to the one you started with.

The honest summary

Getting found is not a growth hack, and anybody promising you one is not worth listening to. It is a small amount of technical hygiene, most of which the platforms now handle, plus a genuinely larger amount of writing about the problem your product solves, in the words the people with that problem actually use.

The technical part is a weekend. The writing part is ongoing, and it is the part that works.

What has changed, and what makes this a better moment than it looks, is that the AI assistants do not make you wait for a reputation before they will recommend you. If your page is the clearest answer to a real question, it can be cited while your domain is still a few weeks old. We have watched it happen on a domain registered in July.

That is not a permanent advantage. It is open right now because most people are still building one page and waiting for Google.

Want us to look at it with you?

If you have built something and you cannot work out why nobody is finding it, we are happy to go through it with you properly, on a call, and show you what the search engines and the assistants actually see when they look at your site.

Related reading:

Platform by platform:

And the two that apply to everyone: