The technical half is finite, so do it first

Content work never ends. This part does. Ten tasks, each with a clear definition of done, and once they are complete they stay complete, which makes them the best possible place to start.

Run the free check

The technical work that makes an app findable is a fixed list rather than an ongoing effort: serve real HTML to crawlers, connect a custom domain, publish a sitemap and robots.txt, give every route its own title and description, add structured data, fix the social preview image, verify in Search Console, add a second page, and address the three performance problems AI builders create by default.

Why this comes before the writing

There is a natural order to this work and getting it wrong wastes months.

Everything in the content half depends on the technical half. Pages that crawlers cannot read do not get indexed no matter how good they are. Pages on a free subdomain have to be moved later, and moving them costs you the little authority they accumulated. A sitemap nobody submitted describes pages nobody found.

So do the finite list first. It takes a couple of evenings, it is the kind of work builders find easy, and it converts every hour of writing that follows into an hour that counts.

The order that avoids rework

Sequence matters here for one specific reason: the domain. Every other item on this list attaches to an address, so if the address changes afterwards, most of the list has to be redone.

Connect the custom domain first, before the sitemap, before Search Console, before any structured data that names a URL. It is the cheapest item on the list and the most expensive one to postpone.

  • One: connect a custom domain, so nothing built afterwards has to move.
  • Two: make sure crawlers receive real HTML rather than an empty shell.
  • Three: publish robots.txt, and check that it is not blocking anybody you want.
  • Four: publish a sitemap, and submit it in Search Console.
  • Five: give every route its own title and description.
  • Six: add the structured data your app actually qualifies for.
  • Seven: fix the social preview image, so shared links do not look broken.
  • Eight: add a second page, because one page is one possible search.
  • Nine: fix the three performance problems that AI builders introduce by default.

How to know when each one is done

The advantage of this half of the work is that done is observable rather than a matter of judgement. Each page in this section ends with a specific check.

Rendering is done when you can fetch your page and see your content in the response, without a browser executing anything. The sitemap is done when Search Console reports it as read and lists the number of URLs you expected. Titles are done when no two routes share one. Search Console is done when the property is verified and at least one page shows as indexed.

Write the checks down and tick them off. This is not a phase you should be revisiting in three months wondering whether you finished it.

What is not on this list

Worth saying, because a great deal of technical SEO advice is written for large sites and does not apply to a small app.

You do not need a content delivery network, a log analysis pipeline, hreflang tags unless you genuinely serve multiple languages, canonical tag strategy beyond the obvious, or any of the crawl-budget management that matters when a site has hundreds of thousands of pages. Your app has twelve pages. Crawl budget is not your constraint.

You also do not need to chase a perfect performance score. Fast enough is fine, and the difference between good and perfect will not decide whether anyone finds you.

How long the whole list takes

Worth stating, because the uncertainty is what stops people starting. This is not a project, it is two evenings.

The domain is thirty minutes of work plus up to a day of waiting for DNS to propagate, and the waiting does not block anything else. Reading robots.txt is under a minute. A hand-written sitemap for a small app is about ten minutes. Search Console verification and sitemap submission together are about fifteen.

The two items that take real time are per-route metadata, which is an afternoon depending on how many routes you have, and pre-rendering, which is an evening the first time and nothing afterwards because it becomes part of the build.

Structured data, the social preview image, and the performance pass are each about an hour. The second page is as long as it takes to write one good page, which is the only item here that is genuinely writing rather than configuration.

The one that silently invalidates the rest

If you only do one thing today, read your robots.txt.

A single wrong line in that file can exclude every search engine and every AI assistant from your entire site, and nothing about your app will look broken. The pages load, the product works, the analytics shows the handful of visits you generate yourself. Meanwhile everything else on this list is being done into a room nobody can enter.

It takes thirty seconds. Open yourdomain.com/robots.txt and read it.

Doing it once, properly

The reason to treat this as a distinct phase rather than something you improve gradually is that half-done technical work behaves like undone technical work.

A sitemap listing four of your twelve pages is not a third of a sitemap, it is a sitemap that tells Google you have four pages. Titles on some routes and not others produce a site that looks partly duplicated. Structured data with a missing required property produces no rich result at all rather than a partial one.

Set aside two evenings, work down the list, and finish it. Then never think about most of it again.

Every part of this, in detail

Each section below is a full guide of its own, on one specific piece of the problem.

  • Make a SPA readable: The default output of most AI builders is an HTML file with almost nothing in it and a script that fills the page in afterwards. Here are the three ways out, in order of how much work each one is.
  • Custom domain: It is free in the sense that you do not pay money for it. You pay in credibility with every visitor who looks at the address bar, and in standing with search engines, and again later when you finally move.
  • robots.txt: It is a plain text file with a handful of lines, it sits at one fixed address, and a single character in the wrong place makes everything else on your site invisible without anything appearing to be wrong.
  • Sitemap: People treat this as a technical artefact requiring a tool. For an app with twelve pages it is a short text file you can write by hand in the time it takes to make coffee.
  • Titles and descriptions: This is the most common real defect in vibe-coded apps, it is invisible while you use the site, and it is entirely fixable in an afternoon.
  • Structured data: Adding SoftwareApplication structured data feels like a box ticked. Then nothing happens, because two properties most people omit are the ones Google actually requires.
  • Social preview: Somebody finally recommends your product in a group chat. What appears is a grey rectangle with your URL in small text. That moment costs you more than most technical problems on your site.
  • Search Console: Every third-party SEO tool is guessing about your site from the outside. This one is Google reporting on its own behaviour, it is free, and most builders have never opened it.
  • The second page: You can fix the rendering, buy the domain, submit the sitemap, write perfect titles, and still be found for nothing, because there is only one page and therefore only one search.
  • Speed: AI builders optimise for producing something that works. Nothing in that process is trying to keep your page small, and three specific problems show up again and again as a result.

Part of a larger guide

This page is one part of Vibe coding SEO. The other parts:

Questions people ask

What technical SEO does a vibe-coded app actually need?
A fixed list of nine items: a custom domain, real HTML served to crawlers, a robots.txt that does not block anybody you want, a submitted sitemap, unique titles and descriptions per route, appropriate structured data, a working social preview image, at least a second page, and the three performance fixes AI builders commonly need.
Should I do technical work or content first?
Technical first, because it is finite and everything in the content half depends on it. Pages crawlers cannot read do not get indexed regardless of quality, and pages on a free subdomain have to be moved later, which costs the authority they accumulated.
Why does the custom domain have to come first?
Because every other item attaches to an address. Sitemaps, Search Console verification, and structured data all name URLs, so changing the domain afterwards means redoing most of the list. It is the cheapest item and the most expensive one to postpone.
Do I need a CDN or crawl budget management?
No. That advice is written for sites with hundreds of thousands of pages. Your app has perhaps twelve, so crawl budget is not your constraint, and neither are hreflang tags unless you genuinely serve multiple languages.
What is the single most important check?
Read your robots.txt. One wrong line can exclude every search engine and AI assistant from the whole site while nothing looks broken, which means every other task on the list is being done into a room nobody can enter. It takes thirty seconds.
Is partially finished technical work worth anything?
Much less than it seems. A sitemap listing four of your twelve pages tells Google you have four pages. Structured data missing a required property produces no rich result rather than a partial one. This is work to finish in one pass rather than improve gradually.

Get the list scored against your own site

The free Get Found Check runs most of this list against your domain and tells you which items are already done and which are still open.

Run the free check Have Licheo do it for you