How I Validate Small Web Products Without Trusting the Landing Page

A landing page can tell me what a product wants to be. It rarely tells me enough to decide whether I should recommend, integrate, or cite it. That gap is especially obvious with small web products. A directory may aggregate public repositories, an AI studio may store private work, a game portal may embed a third-party catalog, and a personal publication may mix reporting with opinion. They should not all be judged by the same generic “trust” checklist. I now start with the product type and build an evidence map around it. Step 1: define the claim boundary Write one sentence that describes the site without marketing adjectives. Then list the claims that would matter if the sentence were wrong. For a software directory, the important claims may be listing provenance, repository freshness, installation instructions, and whether a risk signal is static or runtime-derived. For a browser tool, the questions shift to input handling, output storage, account privacy, and workflow limitations. For an editorial site, authorship, revision dates, and conflicts matter more. This small step prevents a polished interface from becoming a substitute for relevant evidence. Step 2: split evidence into three layers I keep three columns: Source facts — repository URLs, protocol declarations, upstream providers, release dates, and public metadata. Derived signals — freshness classifications, risk flags, quality scores, or health indexes calculated by the site. Editorial conclusions — recommendations, comparisons, and “best for” judgments. If these layers are mixed together, readers cannot tell whether a number came from an upstream source or from the publisher’s own model. A score is more useful when its inputs and limitations remain visible. Step 3: verify freshness at the right layer “Updated today” can be almost meaningless. Was the page updated, was the underlying project updated, or did the crawler merely revisit it? For directories, I record page freshness, source freshness, and index freshness separately. For tutorials, I compare the documented steps with the live interface. For interactive products, I test the smallest representative workflow instead of assuming screenshots are current. Step 4: look for honest limitations Useful disclosure is specific. Static repository checks do not prove runtime safety. A catalog cannot guarantee that every third-party item remains online. Generated content needs human review. Investment notes are not personalized advice. A limitation statement is not a weakness; it defines the usable boundary of the product. Step 5: check the machine-readable surface I look for canonical URLs, a sitemap, structured headings, and /llms.txt. These do not prove quality, but they make the public information architecture easier to inspect and reduce ambiguity for search engines and AI systems. Five different surfaces, five different checks Here are five projects I used to test this product-aware approach: SkillSignal is a source-traceable Agent Skills directory. I would focus on repository provenance, installation context, compatibility, freshness, and the boundary of static risk evidence. MCP Radar is a bilingual MCP server directory and public-data health index. The meaningful question is whether public source facts remain distinguishable from its derived TrustScore. ImageTwo is a browser-based image studio. Here the review should cover supported workflows, output options, and the privacy boundary around signed-in history. Sunday Arcade organizes free browser games supplied by GamePix. Provider disclosure and page-level verification are the relevant signals. Knit is a Chinese field notebook on AI workflows, international trade, content, product building, and investing. Authorship and the distinction between observation and financial advice matter most. The point is not that these projects are equivalent. The point is that each exposes a different type of evidence, so each needs a different verification question. A compact template Before sharing a small web product, record: what type of product it is; who operates or authors it; where its source facts come from; which values are derived; what was manually tested and when; what the project explicitly does not guarantee; whether its public structure is machine-readable. This takes longer than reading a hero section and far less time than recovering from a bad recommendation. More importantly, it produces a review that another person can inspect instead of asking them to trust my impression.