How AppClap works
AppClap is a catalog of web apps. Every fact on a product page is read from the vendor's own website by a crawler, extracted by a language model and shown with the date we last looked. There are no star ratings, no reviews and no sponsored results. This page says where the data comes from, how results are ranked, what claiming a listing does and does not do, and what happens when we do not know something. The same catalog answers AI agents over MCP under the same rules.
Catalog
How products enter the catalog
Most apps were seeded from public software directories. From there, every listing is built from the vendor's own site in four steps.
- 1
Crawl
We fetch the homepage and up to six more pages when we can find them: pricing, features, about, security, docs and changelog. The crawler respects robots.txt.
- 2
Extract
A language model reads the fetched pages and fills a fixed schema: tagline, description, use cases, platforms, pricing, features, integrations. The output is validated against that schema before anything is written.
- 3
Hold or write
An app is held back when the crawl came back thin, when the extractor's confidence is low, or when the pages carried instructions aimed at AI tools. Held apps stay out of the catalog until a later pass clears them.
- 4
Embed
A short functional summary of the listing is turned into a vector for search. It is used for retrieval only and is never shown.
An app is shown when its status is active or beta, its listing has been extracted and it has a current search embedding. Search covers web apps; desktop and mobile apps are catalogued but not searchable yet. When a search finds nothing good enough in the catalog, a live web lookup can suggest candidates. They appear with a “verifying” label until the full crawl has run.
Anyone can . A submission is a signal, not data: we crawl the site and list what we find there.
Prices
How prices are checked
Prices come from the vendor's own pages: the homepage and the pricing page the crawler found. Each plan is read with its price, currency and billing basis, and the pricing model is summed up in a short note in plain words.
Listings are re-crawled in batches, not on a fixed schedule, so check the date on the product page. Product pages are cached for up to 24 hours, so a page can lag the catalog by a day.
What we keep
Each plan with its price, currency and billing basis, plus a short note in plain words. The date the app's pages were last fetched, shown on the product page as "Last checked N days ago". A price history row whenever a price changes between crawls.
What we do not keep
A source URL or check date per plan: the date is per app. An archive copy of the pricing page. A converted price: non-USD prices stay in their own currency, and we never show an approximate conversion.
What an unknown looks like
A plan without a published price shows "Quote". An app with no pricing data shows "Pricing unknown". A price is never guessed, and a re-crawl never replaces a known price with an empty one.
Ranking
How ranking works
Results are ranked relative to your query, not by rating, review count or payment. A plain-language search goes through five steps.
- 1
Retrieve
Your words are matched two ways: by meaning, through a vector index over each app's listing, and by keyword, through full-text search over names, taglines and descriptions.
- 2
Merge
The two candidate lists are merged, so an app that only one method found still gets a look.
- 3
Rerank
A reranking model scores every candidate against your query. That score is the match percentage on each card.
- 4
Apply the floors
A result needs a strong enough match to appear. If even the best candidate is a weak fit, we show nothing rather than pad the list.
- 5
Order
Within the same match band, apps are ordered by how confidently the extractor read their site. Price does not enter the default order.
Two shortcuts
“Alternatives to X” ranks by similarity to X's own listing, and a bare category name lists that category ordered by extraction confidence. A query that asks for the cheapest or most affordable option is sorted by affordability on the engine instead.
Fits your ask and Caveats
Both are written per search by a small language model from your query and the app's stored record only. They are cached per query and app and cleared when the app is re-crawled.
Sorts and filters
“Cheapest” and “Most established” reorder the results already on the page. Cheapest puts free plans first, then the lowest monthly price, unknown prices last. Most established sorts by Tranco rank; unranked apps keep their fit order at the end. The free, open source and self-hostable filters only include apps where the fact is confirmed.
For builders
Claiming never changes rank
A claim proves you make the app. Sign in to the Builders Portal with a work email on the app's own domain and the claim is accepted at once. Any other address goes to a person who checks it against the site. No meta tag, no DNS record.
What a claim gives you
- A “Claimed by its makers” mark on your product page.
- Rankings: we write 10 to 15 searches from your listing and run them through AppClap's real search every week.
- Badges: “Listed on AppClap” and one rank badge drawn from those checked searches, served as an SVG you can embed.
- A direct line for corrections.
What it does not give you is an editor. Listing data is read from your site, so to change a fact, change your site and ask us to re-check, or email us. A correction is reviewed and the app's site re-crawled; it never supplies the value.
Ranking never reads the claim. Results are ordered by how well they fit the search, and there are no paid placements and no sponsored results. A claimed listing is ranked and linked exactly like an unclaimed one.
Every product page links to your site. The domain link is a normal followed link; the Visit button goes through a short redirect that counts the click and sends the visitor on.
The badge
Your slug and the rank badge are in the portal. The image never breaks: an app we do not list gets the plain badge, never a made-up rank.
<a href="https://app-clap.com/software/your-slug">
<img src="https://app-clap.com/badge/your-slug.svg"
alt="Listed on AppClap" />
</a>Unknowns
What we do not know
“We could not determine this” is a normal state here. Yes-or-no facts such as free tier, free trial, open source and API are stored as yes, no or unknown, and the extractor may only set them when the site says so. On a product page a badge appears only when the fact is confirmed; unknown shows nothing. Empty fields are left out, never filled with a guess. Over MCP a missing fact is reported as “not stated”.
One known gap: “self-hostable” is derived from the deployment model and reads as no when that model is unknown, which is why it is only ever shown as a positive badge.
Corrections
How to report an error
Use “Suggest an edit” at the bottom of any product page, or “Report wrong or missing info” on a result card. A report is reviewed and the app's site re-crawled; your note tells us where to look but never supplies the value.
Over MCP the same thing is the report_app_issue tool. For anything else, email hello@app-clap.com.
Citation
Cite this page
https://app-clap.com/methodology
Last updated November 5, 2026
AppClap, "How AppClap works - methodology", https://app-clap.com/methodology, updated November 5, 2026.Come find your next tool
Tell us what you're trying to solve, and we'll point you at the right software.