Trust methodology
What “verified” means in LISTDIR
Verification is a documented review of a submission surface—not a promise that a third party will approve, publish, link to, or send traffic to your product.
LISTDIR field note
Built for deliberate distribution: prepare once, keep account control, and record only outcomes you can prove.
Discovery is not verification
LISTDIR can discover many directory URLs from research, public lists, and historical catalogs. Discovery creates a candidate only. A successful DNS or HTTP response can show that a host exists, but it cannot prove that submissions are open, relevant, free, permitted, or likely to create a public profile. Candidate counts are therefore kept separate from the smaller verified cohort shown to users.
Evidence required for a verified target
A reviewer must capture a current official or first-party source that supports the destination and submission workflow. The record includes the observed submit URL, review date, reviewer identifier, authentication type, signup requirement, CAPTCHA likelihood, fee model, eligibility notes, form requirements, human checkpoints, automation policy, expected review range, and likely link type. Network probes never promote a candidate by themselves.
Freshness and re-review
Directory forms change without notice. Verified records carry a freshness timestamp and can become stale, inactive, broken, unexpectedly paid, or duplicated. Operations tooling schedules rechecks and stores evidence separately from availability observations. A stale record must be downgraded or re-reviewed before it supports a public verified claim.
Duplicates and intentional variants
Two URLs on the same host may represent the same form, a redirect, a language variation, or genuinely different communities. LISTDIR assigns a canonical surface key, selects one primary destination for accidental duplicates, and marks deliberate variants explicitly. Package credits must not be inflated by aliases that lead to the same submission work.
Fit, value, and ranking
Recommendations combine product category, tags, eligibility, pricing fit, evidence status, authority indicators, traffic estimates, support risk, and expected value. These are decision aids rather than guarantees. Authority and traffic figures can be estimates from third parties; approval, a dofollow link, search performance, and referral traffic always remain under the directory operator’s control.
Automation policy
Each target is classified according to what can be prepared or filled safely. Public APIs and ordinary fields may support stronger assistance. Login, email verification, OAuth consent, CAPTCHA, legal terms, payment, community posts, and final submission remain human checkpoints. If a destination prohibits automation, LISTDIR must use guidance and copy tools only.
Outcome standard
Ready means the target can be worked. Opened means a user began the workflow. Needs authentication records a blocking account step. Submitted requires explicit confirmation. Accepted and live require a public listing URL, while rejected needs a reason. Backlink checks parse actual anchor destinations on live listing pages; the product does not count a hostname merely mentioned in page text.
Corrections
Directory operators and users can report outdated requirements through support@listdir.app. A correction should include the destination, observed change, date, and a public source when possible. Material corrections are reviewed before the catalog record is promoted again. We do not accept payment for a favorable verification state or hide known mandatory directory fees.