Every score on StackScope is computed from publicly observable signals. We analyse HTTP headers, rendered page content, DNS records, TLS certificates, and well-known files. Nothing is subjective. Scores are deterministic and reproducible.
StackScope Score (0-10)
Our headline score. A single number that captures a site's production-readiness posture, based on four weighted components:
Security (~28.6%): security headers present out of 6.
Launch Readiness (~28.6%): page basics, social tags, responsive design, production hygiene.
Legal (~21.4%): privacy policy, terms of service, no unfilled template placeholders.
Web Standards (~21.4%): robots.txt and sitemap.
The score is displayed as 0-10 with one decimal place. A score of 9+ means the site is well-built across all dimensions.
Files like /.well-known/security.txt and llms.txt are detected and shown on the launch page as optional best practices, but they do not affect the StackScope Score. A perfect 10 is still reachable without them. We surface them because they're useful signals to founders, not because we penalise their absence.
2026-04-23 change: the Vibe Score (formerly "Authenticity", 30%) was removed from the composite. It is still computed and shown on every launch page as informational context, but no longer affects the StackScope Score. The 30% weight was redistributed proportionally across the four remaining buckets.
Vibe Score (0-100)
Measures how strongly a site's code matches patterns we've empirically observed in AI-assisted builds. A higher score means more of those patterns are present. This is a pattern match, not a verdict: we compare each site against signals we saw consistently across hundreds of controlled AI-generated sites and report how many of those signals are present here. Whether the site was actually built with an LLM is a separate question we can't answer from the outside.
Our detection is informed by controlled research: we generated hundreds of sites using isolated instances of multiple AI models with identical prompts, then analysed the output for statistically consistent patterns. The Vibe Score reports how many of those patterns we find on a given site, blending several independent families of signals drawn from that research. Known CMS and website-builder platforms are accounted for so their templates don't trigger false positives.
The Vibe Score is not a judgement. Using LLMs as a build tool is a legitimate choice and plenty of well-crafted sites use AI assistance. The score simply reflects how many of the fingerprints we catalogued are present on a given page. No single signal is conclusive; the score only gets high when multiple independent signals align. A score of 0 means we detected none of the patterns, which does not necessarily mean the site wasn't AI-assisted, only that we didn't find our fingerprints. Treat it as an observation, not a grade.
Launch Readiness (0-100)
Measures whether a site is properly prepared for launch day. The basics that visitors, search engines, and social platforms expect. We check for:
Custom page title and meta description
Social sharing tags (Open Graph, Twitter cards)
Canonical URL
Mobile responsiveness
Production hygiene (no debug artifacts, no localhost URLs, no saved-from-browser HTML)
Basic branding (favicon)
Semantic HTML (proper use of nav, main, article elements)
Score is normalised to 0-100. A perfect score means all checks pass. Privacy policy and unfilled-placeholder checks are scored in the Legal bucket instead of Readiness so each signal counts toward the composite StackScope Score exactly once.
Security Headers (0-6)
Counts how many recommended security headers are present in the HTTP response. We check for six modern security headers that protect against common web vulnerabilities. The legacy X-XSS-Protection header is tracked but not scored as it has been deprecated in favour of Content Security Policy.
Some large platforms (e.g. Google, Cloudflare) handle security at infrastructure level rather than through HTTP headers. A low header score on these sites does not necessarily indicate poor security, just that the protections are applied at a layer we cannot observe.
Performance (0-100)
An indicative grade of how the page performed when we crawled it. We render every site once in a headless browser and grade what that single visit observed. The grade is a weighted blend of whichever of these measurements are available:
Largest Contentful Paint (30%): time until the main content is visible, using the Core Web Vitals thresholds. Under 2.5 seconds is good, over 4 is poor.
Page weight (20%): total bytes transferred to render the page. Under 1 MB is light, over 3 MB is heavy.
Image weight (20%): bytes spent on images alone. Under 500 KB is light, over 2 MB is heavy.
Cumulative Layout Shift (15%): how much the layout jumps around while loading, again on the Core Web Vitals thresholds. Under 0.1 is good, over 0.25 is poor.
Server response (15%): how quickly the server answered our first request. Under 500 ms is fast, over 1.5 seconds is slow.
We also audit images (missing dimensions, missing alt text, oversized files) and list first-party requests that failed during the render. Those feed the tips on the launch page but do not move the grade.
This is one automated visit from one machine in Europe. It is not a Lighthouse run and not field data; treat it as a smoke test, not a benchmark. Launches crawled before we captured browser metrics show a reduced panel based on server response time alone. An owner-triggered recrawl fills in the rest.
Performance is deliberately not part of the StackScope Score. Sites are only re-measured when someone requests a recrawl, so folding performance into the composite would change launch scores without any action by the site owner and break comparability between old and new launches.
Infrastructure
For each site we collect infrastructure data from public sources:
ASN & Hosting: IP address resolved via DNS, then mapped to its hosting provider and country.
SSL Certificate: TLS handshake to extract the certificate issuer, expiry date, and Subject Alternative Name count.
Domain Age: registration and expiry dates via RDAP (the modern WHOIS replacement). Registrar name where available.
Some TLDs (.io, .co, .me) do not support RDAP and will not have domain age data. Sites hosted on platform subdomains (e.g. .vercel.app, .netlify.app) show the platform's domain data, not the project's.
AI Stance
Classifies a site's position on AI crawlers based on their public declarations:
Open: actively provides content for AI systems (e.g. has an llms.txt file)
Blocking: explicitly blocks known AI crawlers in robots.txt
Confused: blocks AI crawlers in robots.txt and publishes an llms.txt welcoming them
No stance: no public declaration either way
We also capture the Content Signals Policy directive if a site ships one in its robots.txt: the Content-Signal: ai-train=yes|no, search=yes|no, ai-input=yes|no line (specified in the ongoing IETF AI-preferences draft). When present it appears on the launch page under AI Stance as a finer-grained declaration of how the site is happy to have its content used after access (training, search indexing, or as input to agents).
We also record RFC 8288 Link response headers that advertise agent-relevant resources (service-doc, sitemap, privacy-policy, api-catalog, terms-of-service). Very few sites ship these today; when present they indicate the origin is making its own docs / policies / APIs machine-discoverable without requiring the agent to parse HTML. The canonical vocabulary of rel values lives in the IANA Link Relations registry.
Technology Detection
StackScope uses its own fingerprint detection engine: a curated catalogue of 9406 technology fingerprints with 24603 detection rules, built from real crawl observations and continuously growing. Rules match against a range of publicly observable surfaces. We render every page in a real browser with JavaScript executed, so detection sees what a visitor sees, not just the static HTML, and a technology is only reported when its rules match.
The fingerprint catalogue is not based on Wappalyzer or any third-party pattern database. Every rule is derived from observations in our own crawl data, verified by human review, and tested against the live corpus. New fingerprints are added daily as the crawler discovers new technologies in the wild.
Catalogue growth
Detection rules (24,603)Fingerprints (9,406)
Product category
Unlike the scores above, a launch's product category is not a deterministic check. It is a prediction. A machine-learning text classifier reads the launch's tagline and page description and assigns one of sixteen product categories, such as developer tools, marketing, or finance.
Because it is a prediction rather than an observable fact, we only show a category when the model is confident. Every prediction carries a confidence value, and a category is displayed publicly only above a high threshold, where it agrees with our human-reviewed labels about 98% of the time. Launches where the model is unsure show no category at all rather than a guess, and the catch-all "other" bucket is never surfaced.
Treat the category as a way to browse and group launches, not a definitive statement about any single product. Aggregate figures should be read over the high-confidence set only.
Screenshots
We capture a viewport screenshot of every site using a headless browser. This gives an accurate representation of how the page actually renders, including JavaScript-rendered content. Screenshots are taken at 1280x800 resolution.
Data Sources
We discover new product launches daily from the public launch communities where indie founders ship, then crawl each product's own website.
StackScope also finds launches itself, without waiting for a platform post. Launches found this way are labelled StackScope Discovery and are reviewed before they join the public catalogue; new sites that are not indie product launches feed aggregate statistics only, labelled StackScope Wider Web. What gets a public page, what stays aggregate-only, and how review works are covered on the StackScope Discovery page.
Sites on major platforms (e.g. Amazon, Netflix, Apple) and marketplace listings (e.g. Shopify app store, Chrome Web Store) are filtered out. We focus on independent products with their own websites.