The Playable‑First QA Checklist: 14 Preflight Tests to Keep Installless Demos Indexable, Accessible, and Review‑Safe

Why it matters: A playable demo only converts if search engines can find and index it. Single‑page apps, heavy client rendering, and incorrect headers often hide content from crawlers. These tests focus on making the demo appear in search results and preserve linkability.

Tests and exact commands: (A) Server headers: curl -I https://your-demo.example/path — expect HTTP 200 and no X-Robots-Tag: noindex; (B) Fetch as Google simulation: curl -L -A "Googlebot" https://your-demo.example/path — expect same HTML payload or server‑side rendered content; (C) Prerender / SSR check: view page source in browser and verify meaningful, crawlable content appears in the initial HTML (not only in console-rendered DOM).

Why it matters: Demos are often embedded or framed. Ensure the demo has a stable canonical URL, exposes clean metadata, and won't be blocked accidentally by robots.txt or meta tags.

Tests and exact commands: (A) robots.txt check: curl -I https://your-demo.example/robots.txt — ensure no Disallow for the demo path; (B) meta robots: view page source and search for <meta name="robots"> — it should be absent or allow indexing; (C) canonical: check <link rel="canonical"> points to the public demo URL to avoid duplicate content or indexing under ephemeral query params.

Why it matters: Playable demos are often used without full onboarding. Quick accessibility regressions — keyboard traps, missing alt text, poor contrast — break usability for many users and create legal risk. This section lists small, exact tests that catch the most common issues.

Tests and exact commands: (A) Keyboard navigation: Tab repeatedly from page load — expected: every interactive element receives a visible focus and no trapped focus. (B) Screen‑reader smoke test: With NVDA or VoiceOver, open the demo and confirm primary headings and controls are announced in logical order. (C) Color contrast: use an online contrast checker (e.g., WebAIM) on heavy-use text areas — expect ratio ≥ 4.5:1 for normal text.

Why it matters: Playables often collect telemetry, crash data, or optional emails. That microcopy — what you show near a consent checkbox or input — determines reviewer trust and user comfort. Keep collection minimal, explicit, and actionable.

Tests and exact commands: (A) Data map review: list every API the demo calls and what data it sends (e.g., IP, user agent, optional email). If you collect PII, the demo must show a clear privacy link with a short one‑line explanation. (B) Consent microcopy check: Any opt‑in must be explicit and not prechecked. (C) Network inspection: open DevTools Network tab, interact once, and confirm no unexpected outbound requests to analytics or ad domains.

Why it matters: Many teams later package a playable demo into an app shell. Apple and other stores enforce rules around minimum functionality, deceptive behavior, and data collection. Failing to validate this now creates rejection risk later.

Tests and exact commands: (A) Minimum functionality alignment: review Apple’s App Review Guidelines sections on Minimum Functionality and Web Content — if your demo is the app’s core, ensure the app has native value beyond just hosting a website. (B) Content and privacy checks: ensure any collection complies with the store’s requirements (privacy policy link, account deletion flow if you collect accounts). (C) Simulate wrapped behavior: load the demo inside a WebView on a local test app and verify user-visible consent, navigation, and that no external installers or calls to bypass app store flows exist.