What the evidence supports
Runwiv pages should help runners make practical decisions. This methodology explains how claims, comparisons, route facts, and event guides are reviewed before publication.
Read editorial policyUse a product specification for a documented capability, an organiser publication for event details and appropriate health sources for general health information. None of those proves a Runwiv customer result. Record actual testing separately from intended behaviour.
Website checks cover response status, canonical URLs, internal links, navigation and selected mobile workflows. Calculator tests cover conversion arithmetic and edge cases. Passing these checks does not establish outdoor GPS accuracy, clinical validity or that a page will rank.
A worked arithmetic example is illustrative. A hypothetical club brief describes a possible workflow. Neither should use invented named customers or be presented as an observed improvement in performance, revenue or wellbeing.
Date a substantive article revision honestly. Inspect primary documentation again when an integration changes. Current weather, closures, event details, price and stock require current checks rather than a permanent claim in an evergreen article.
The website records confirmed signup events after consent and distinguishes public-site events from app activity. Optional tool analytics records the tool action, without sending calculator inputs or session-brief text. Traffic, conversion and AI-referral changes require sufficient observed data before drawing conclusions.
No. Sourcing, editorial review, independent expertise and hands-on testing are different forms of evidence.
No. Technical checks establish specific behaviours; search engines decide discovery, indexing and ranking.
Get email updates when the iOS and Android apps become available. The waitlist is free; no payment required.