The cases where you do not own the site
An agency taking on a client and working out why nothing ranks, before any access has been granted. A developer inheriting a site with no documentation. Someone evaluating a competitor to see which sections they keep out of search. A buyer doing diligence on a site before acquiring it. An engineer checking whether a supplier has accidentally blocked the endpoint an integration depends on.
None of those can use a tool that requires verified ownership, and all of them are asking a question about a file that is deliberately public. Robots.txt is served to every crawler on the internet by design, so reading it is not an intrusion.
The mistake that removes a site from search
A staging site is built with a robots.txt that disallows everything, which is correct. Then it is promoted to production, and the file comes with it. The site is live, complete, and invisible - and the symptom is simply an absence of traffic, with nothing anywhere announcing the cause.
It is worth checking immediately after any launch, migration or replatform, and worth checking on any site that lost its traffic overnight. Two characters in one file, and it happens to organisations with experienced teams several times a year.
Robots.txt does not do what most people think
It controls crawling, not indexing. A page blocked in robots.txt can still be listed in search results if other pages link to it - the crawler respects the block, does not fetch the page, and lists the URL anyway with no description because it was never allowed to read one. To keep a page out of the index you need a noindex directive, and that only works on a page the crawler is permitted to fetch.
Blocking a URL in robots.txt and putting noindex on it is therefore self-defeating: the block prevents the crawler from ever seeing the noindex. It is also not a security control. The file is a public list of the paths you would rather nobody visited, which is the opposite of concealment for anything genuinely sensitive.