Real apps, taken apart with the numbers shown

Advice is easy to write and hard to check. A teardown of a real, named app, with every figure measured on a stated date, is harder to write and much harder to argue with.

Run the free check

Each teardown fetches a real app the way a crawler does, without executing JavaScript, and reports what came back: how much readable text, what the robots.txt permits, how many pages are in the sitemap, and what that combination explains about how the app performs. Every number is measured and dated, and nothing is estimated.

What a teardown contains

The same structure every time, so that two teardowns can be compared against each other rather than read as separate opinions.

  • What the app is, and how old the domain is, from the public registration record.
  • What a crawler receives, measured in readable words with no JavaScript executed.
  • What the robots.txt actually permits, per crawler, separated into search, user-triggered and training agents.
  • How many pages exist and what shape they take, read from the sitemap.
  • What that combination explains, and what it does not.
  • The date every measurement was taken, because a figure without a date quietly goes stale and keeps being read.

What we will not do

Worth stating plainly, because most published teardowns do at least one of these.

We will not estimate traffic. Third-party traffic estimates for small sites are unreliable, and presenting one as a finding would undermine everything else on the page. If we do not have the analytics, we say we do not have the analytics.

We will not guess at why something ranks. Where the cause is not visible in what we can measure, the honest answer is that we do not know, and that answer appears in the teardown.

We will not publish a teardown of somebody's app without their written permission. That applies even when the app is public and everything we measured is public.

And we will not use a teardown as a sales pitch in disguise. The findings are the findings, including when the answer is that the app is set up correctly and the owner should stop worrying about the technical half.

Why we started with our own

The first teardown is of Kurli, which is a site we know from the inside. That is deliberate, for two reasons.

The first is permission. We can publish every number, including the analytics figures, without asking anybody, and including the findings that are unflattering.

The second is verification. On somebody else's app we can measure what is publicly served and nothing more. On our own we can put the served pages next to the referral data and check whether the explanation actually holds, which is the part that makes a teardown worth reading rather than a list of observations.

It also means the first teardown contains a genuine defect we found in our own configuration while writing it, which seems like the right way to start.

Send us yours

We will take apart your app, publish the teardown, and charge nothing. You keep every finding and you are free to fix it yourself, hire somebody else, or ignore it.

What we need from you is written permission to publish, naming the app, and a URL. If you want to include analytics figures we will use them and attribute them to you, and if you would rather not share them the teardown covers only what is publicly measurable.

You get a right of reply before publication. If something in the draft is wrong, or a fix has shipped since we measured, we correct it or note the date the measurement was taken and what changed.

The honest reason we do this: teardowns are the most useful thing we can publish for this audience and the most persuasive demonstration of the work. Both of those are true at once, and you should know both before deciding.

Why we publish the unflattering findings

A teardown that only finds problems on other people's sites and none on ours would be marketing wearing the clothes of analysis, and it would be obvious.

The first teardown on this page reports a real defect in our own robots.txt: a file that declares one intention in its content signals and then contradicts it further down, because two tools wrote to it at different times. We found it while running our own crawler tool against our own domain in order to write the page.

That is worth publishing for a reason beyond honesty. It is the strongest possible demonstration of the thing we keep telling people, which is that this particular failure is invisible. The site works, no tool reports an error, the file reads as deliberate, and it is wrong.

So the standing rule for this series is that findings go in whether or not they are comfortable, and the teardown of our own app is held to the same standard as everybody else's.

Reading a teardown correctly

A caution, because the failure mode of this format is a reader concluding too much.

One app is one app. What worked for a specific product in a specific category does not establish a rate and should not be used to predict what yours will do. The value is in the mechanism being visible, not in the outcome being transferable.

Measurements have dates for a reason. A platform can change its rendering behaviour in a single deployment, and a site can be reconfigured the day after we look at it. A teardown describes a moment.

And an app being technically correct is not the same as an app succeeding. Several of the findings you will read amount to the technical half being finished and the harder half being untouched, which is the most common state of all.

Every part of this, in detail

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

  • Kurli: This is our own app, which means every number here can be published, including the one that turned out to be a mistake in our own configuration.

Part of a larger guide

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

Questions people ask

What is in a teardown?
What the app is and how old the domain is, what a crawler receives measured in readable words with no JavaScript executed, what the robots.txt permits per crawler, how many pages exist and in what shape, and what that combination explains. Every number is measured and carries the date it was taken.
Do you estimate traffic in teardowns?
No. Third-party traffic estimates for small sites are unreliable, and presenting one as a finding would undermine everything else on the page. Where we do not have the analytics, the teardown says so rather than substituting a guess.
Will you tear down my app?
Yes, free, and you keep every finding. We need written permission to publish and the URL. Analytics figures are optional, and without them the teardown covers only what is publicly measurable. You get a right of reply before it goes live.
Do you publish teardowns without permission?
Never, even when the app is public and everything measured is public information. Publishing findings about somebody's business without their agreement is not something we are willing to do regardless of whether we could.
Why is the first teardown of your own site?
Permission and verification. We can publish every number including the unflattering ones without asking anybody, and we can put the served pages next to the referral data to check whether the explanation actually holds, which is the part that makes a teardown worth reading.
How much can I conclude from one teardown?
Less than the format tempts you to. One app in one category establishes no rate and predicts nothing about yours. The value is that the mechanism becomes visible, and measurements carry dates because a platform can change its rendering behaviour in a single deployment.

Run the measurements on your own app first

The free Get Found Check covers most of what a teardown measures, immediately, without waiting for us to write one.

Run the free check Offer your app for a teardown