Read the store’s identity
We give the strongest weight to the page title and the store’s own meta description because these usually state its primary retail proposition.
Technical score v0.1 is a 0–100 homepage health score. Once a website is observed, its earlier baseline is replaced with the following reproducible calculation.
score = availability + HTTPS + speed + title + description + commerce schemaSpeed points are calculated as max(0, 20 − floor(response_ms ÷ 250)). Scores are capped at 100. Ties are ordered alphabetically.
One server-side homepage request cannot describe checkout quality, mobile usability, delivery experience or business popularity. A “No” for commerce schema means it was not detected on the homepage; it does not prove that individual product pages lack Product markup. It is useful as a technical observation, but it is not yet a complete commerce index.
The active scoring formula is applied consistently across country indexes. Local categories and market context can differ, but a technical signal has the same definition and weight wherever it is observed.
Our crawler requests the public HTTPS homepage, follows redirects, reads at most 512 KB of HTML and stops after a bounded timeout. It does not sign in, add products to a cart, place orders or attempt to bypass access controls. Our separate discovery classifier places potential stores into an internal review queue; discovery does not automatically create a listing or ranking. Read the crawler transparency policy.
Each observation stores the time, response status, response duration, detected metadata and the score produced by that methodology version. A refreshed observation can move a score in either direction.
Global methodology does not imply a single worldwide leaderboard. Rankings are published within countries and relevant categories only when coverage is broad enough. We disclose tracked and observed counts, and retain the prototype label while most entries remain baselines.
A category describes the store’s dominant commercial purpose, not every product it happens to sell. Each listing receives one primary category for country-directory navigation and category comparisons.
We give the strongest weight to the page title and the store’s own meta description because these usually state its primary retail proposition.
Repeated category language in menus and prominent headings provides stronger evidence than an isolated product card.
Product and collection terms across the public homepage support the decision, but their contribution is capped so one item cannot determine the entire store category.
All supported categories are scored. We select the leading category only when it clears a minimum evidence threshold and has a meaningful lead over the runner-up.
Mixed or weak evidence is labelled Other internally and kept for editorial review rather than being auto-published into an unreliable category.
Owners, managers and employees can challenge a category using a verified business-domain email. Editorial corrections retain an audit trail.
A category changes where a store appears in the directory; it does not add or remove ranking points. Commercial relationships and paid services do not influence category assignment.
This is a proposed framework, not the formula currently used on store profiles. We will validate weights against collected data and publish changes before activating them.
Availability over time, HTTPS behavior and carefully selected public security controls.
Mobile LCP, INP and CLS from eligible Chrome UX Report data, with lab data labelled separately.
Product discoverability, working catalogue signals, structured product data and transparent policies.
Indexability, metadata, canonicals, sitemaps and durable category/product information architecture.
Visible contact, returns, delivery and privacy information—not subjective reputation claims.
Observation freshness, repeatability, coverage and owner-verified facts, with explicit confidence.
Traffic or market-reach rankings require sufficiently representative, country-level evidence. We will not reverse-engineer visits from technical signals or mix self-reported analytics with unverified estimates. If introduced, popularity will be a separate dimension with its own confidence and methodology.
Real-user experience metrics and the rationale for evaluating their 75th percentile.
Chrome UX ReportCrUX methodology ↗Eligibility, collection and aggregation constraints for public field data.
Google Search CentralMerchant listing structured data ↗Product and Offer markup used to describe purchasable products.
OWASPSecure Headers Project ↗Vendor-neutral guidance for interpreting public HTTP security controls.
Tranco research rankingRanking methodology ↗Research on stability, aggregation and manipulation risks in popularity lists.
HTTP ArchiveWeb Almanac methodology ↗Large-scale public web measurement and documented dataset limitations.