Skip to content
App Builder Index

Guides

What actually gets indexed: AI app builders and search

We disabled JavaScript and looked at what was left. Two site builders passed every check. Two well-known full-stack builders failed most of them.

Ines Varela · · Updated

Search visibility is the axis buyers most often discover too late, usually about four months after launch when someone asks why the product does not appear for its own name.

Our test is deliberately unglamorous. For every builder we generated the same public marketing page plus one dynamic detail page, then checked seven things.

The seven checks

  1. Server rendering. Does the primary content appear in the initial HTML response.
  2. No-JavaScript legibility. With scripts disabled, is the page still readable and navigable.
  3. Per-page metadata. Can you set a unique title, description and canonical URL on every route.
  4. Structured data. Is there correct JSON-LD, and can you add your own.
  5. Sitemap and robots. Is a real sitemap generated, does it list every published URL with an accurate last modified date, and does robots.txt point at it.
  6. Heading and landmark structure. One h1, sensible order, semantic landmarks.
  7. Page speed on a mid-range mobile device.

The results were not where we expected

The highest score on this axis went to a front-end specialist, and two site builders finished ahead of four full-stack platforms. The reason is architectural. Tools that generate a server-rendered framework by default pass check one and two without trying. Tools that generate a client-rendered single-page application fail both, and no amount of metadata configuration fixes it.

Three builders produced pages where the main content was entirely absent from the initial HTML. One produced a sitemap that listed only the home page. Two offered no way to set a canonical URL at all, which quietly guarantees duplicate content problems the moment you have a filtered list view.

Generative engine optimisation is mostly the same work

There is a lot of noise about optimising for answer engines and language models as though it were a separate discipline. In our testing it is largely the same seven checks with two additions.

The first is machine-readable data. A page that states a rating in an image is invisible; a page that states it in text with structured data attached is quotable. The second is a plain, stable summary of what the page is, near the top, in prose. Models extract those summaries reliably and they are also good for human readers, which is a rare alignment.

We also publish a plain text description of this site at our llms.txt route and a machine-readable dataset endpoint, because we would rather be cited accurately than paraphrased badly. If you are building something you want answer engines to reference, doing the same costs an afternoon.

What to ask before you buy

Ask for a live URL built on the tool, then view source. If the content is not in the HTML, you have your answer in ten seconds. Ask whether you can set a canonical tag. Ask to see the generated sitemap.

Any vendor whose answer to those three questions is a support ticket rather than a documentation link is telling you where search sits on their roadmap.

The per-tool scores on this axis are in the full index, and the weighting, thirteen percent, is explained on our methodology page.