Retool is an internal tools platform, and that answers the question

Almost every difficulty people have getting a public Retool app found traces back to one thing, which is that public discovery was never what the product was built to do.

Claims on this page were last checked against the platform's own documentation on .

See what a crawler gets

Retool supports custom domains, configured in settings under branding, and has an external users concept for people outside your organisation. It is a client-rendered application platform rather than a content platform, and community reports indicate public Retool apps are difficult to get indexed. For anything that needs to be discovered through search, the practical architecture is a separate marketing site in front of the app.

What Retool is for

Retool exists to let a team build internal tools quickly: admin panels, dashboards, support consoles, operations screens. It is very good at that, and the people using those tools arrive because somebody sent them a link or because it is bookmarked on their work machine.

Nothing in that description involves being discovered by a stranger through a search engine. So the platform was designed without that requirement, and the consequences show up when somebody tries to use it as a public product surface.

This is worth stating plainly rather than treating as a defect, because it changes what you should do about it. A tool being unsuited to a job it was never designed for is a planning question rather than a bug report.

What the platform gives you

Custom domains are supported. Cloud organisations start on an address in the form of your organisation name followed by the Retool domain, and you can configure your own domain through the settings under branding, entering the domain and verifying it, after which people reach your organisation at your address.

There is also a concept of external users. Retool determines whether a user is internal or external using an internal domain list you specify, and it automatically creates an external users permission group into which anybody outside that list is placed.

That combination is aimed at sharing an application with people outside your company, such as clients or partners, which is a genuine and well-supported use case. It is a different thing from being found by somebody who has never heard of you.

What we can and cannot tell you about indexing

Being careful here, because the distinction between documented behaviour and community observation matters.

We have not found official Retool documentation that states a policy on search engine indexing of public apps in the way Glide's help centre does. So we are not going to claim Retool has a documented position on it.

What exists is community reporting, including an open feature request, describing public Retool pages as difficult or impossible to get indexed on the grounds that the platform is client rendered and that users cannot set metadata, meta descriptions or dynamic Open Graph tags, with the result that a crawler receives an effectively blank page. That is a community account rather than a vendor statement, and it should be weighted accordingly.

The honest position: treat public search discovery through a Retool app as unsupported until Retool documents otherwise, and verify your own case rather than trusting either us or a forum thread.

How to check your own case in a minute

This is a situation where measuring beats reading, and it is quick.

Fetch one of your public app URLs without a browser and look at what comes back. If the readable text is close to nothing, a crawler that does not execute JavaScript receives the same thing, and no amount of configuration elsewhere changes that.

Then search for your app's address with the site prefix in Google. If nothing appears after the app has been live for a while, that is your answer for your specific setup.

The crawler view tool linked at the bottom of this page does the first of those for you and reads your robots.txt at the same time. Two minutes, and it replaces a great deal of speculation.

The architecture that works

The same one that applies to Glide, and for the same underlying reason.

Keep the Retool app as the application, which is what it is good at, and build a separate site in front of it on your own domain. That site carries the pages answering the questions people search before they know your product exists, and it links into the app.

This is not a workaround or a compromise. A very large number of products are built exactly this way on purpose: an application behind a login and a marketing site in front of it, because the two have different jobs and different requirements.

The site in front does not need to be large or built on anything sophisticated. It needs to be on your own domain, serve real HTML, and answer real questions. Everything in the fixes section of this site applies to it normally.

When Retool is the right answer anyway

Worth ending here, because this page is not an argument against the platform.

If your app is genuinely internal, or is shared with named clients and partners, or is sold through conversations rather than found through search, then none of the above costs you anything. Retool is a strong choice and its indexing behaviour is irrelevant to your situation.

The mismatch only matters when the app itself was supposed to be the discoverable thing. A public directory, a catalogue, a set of reference pages, anything whose value is that strangers find its content, is asking an internal tools platform to do a job it was not built for.

Decide which of those you are, and the answer follows without much agonising.

Part of a larger guide

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

Questions people ask

Can a public Retool app be indexed by Google?
We have not found official Retool documentation stating a policy either way. Community reporting, including an open feature request, describes it as difficult on the grounds that the platform is client rendered and metadata cannot be set, so a crawler receives an effectively blank page. Treat it as unsupported until documented otherwise, and verify your own case.
How do I check whether my Retool app is readable?
Fetch one of your public URLs without a browser and look at the readable text that comes back. If it is close to nothing, a crawler that does not execute JavaScript gets the same. Then search for your address with the site prefix in Google to see what is actually indexed.
Does Retool support custom domains?
Yes. Cloud organisations start on an address made from your organisation name, and you can configure your own domain in settings under branding by entering and verifying it, after which people reach your organisation at your address.
What are external users in Retool?
Retool decides whether a user is internal or external using an internal domain list you specify, and automatically creates an external users permission group for anybody outside that list. It is designed for sharing an app with clients or partners, which is different from being found by a stranger.
What should I do if I need my Retool product found?
Keep the Retool app as the application and build a separate site in front of it on your own domain, carrying the pages that answer questions people search before they know your product. That is a normal architecture rather than a workaround, and it is how a great many products are deliberately built.
Is Retool a bad choice then?
Not at all, when the app is internal, shared with named clients, or sold through conversations rather than found through search. The mismatch only matters when the app itself was meant to be the discoverable thing, such as a public directory or catalogue.

Measure your own app rather than trusting a forum thread

The free crawler view fetches your public URL without executing JavaScript and shows you exactly what a crawler receives.

See what a crawler gets Have Licheo build the site in front