Spoken Review: focused gaps (86/100)

| Field | Value |n|---|---|n| Domain | spoken.md |n| Category | Podcast transcript retrieval API |n| Pricing | Usage-based, $15–$160 |`n| Crawl | 40 pages, 2026-10-11 |

Spoken earns 86/100 (rounded from 85.5) because it makes a technically specific offer easy to evaluate: an API for retrieving existing podcast transcripts, with speaker names and Markdown output for LLM and archive workflows. The public surface answers what the service returns, how it differs from transcription, what it costs, how to test coverage, and how to integrate.

The review records 88/100 for usability, 96/100 for accessibility and 88/100 for performance; real-user homepage p75 LCP is 1.365 seconds, INP is 63 ms, and CLS is 0. The main opportunities are narrower: mobile lab LCP is 2.633 seconds, topic indexes need more depth, some documentation pages have incomplete metadata, and /agents.md and /auth.md show mobile overflow. The retrieval-versus-transcription distinction is especially useful for teams deciding whether they need existing transcript access or a new transcription pipeline.

Spoken is clearly a podcast transcript API for developers and technical researchers, but the primary buyer is inferred rather than named. “Every episode of the shows you follow, as text you can search and ask questions of” is specific, and the site explains speaker labels, timestamps, pricing, and the constraint that a show must publish a transcript. The strongest distinction is explicit: “Spoken returns the existing transcript for a podcast episode.” Name builders of archives, RAG systems, and agents in the hero.

Spoken answers the practical questions technical buyers ask: what returns, how it differs from transcription, what it costs, how to test coverage, and how to integrate it. “Build a podcast summarizer in 20 lines of code” gives the offer a concrete mental model. The remaining gap is fit: whether a target show has a published transcript. Put that qualification beside pricing, then add a short chooser for archive, summarizer, RAG, and agent workflows.

A first-time visitor can understand the product quickly. “Podcast transcript API”, “Pricing”, “Find your show”, and “Check your show first, free” provide clear next steps, and the main evaluation pages sit one click from the homepage. Friction begins after pack selection: the crawl shows POST forms to /buy?pack=100, /buy?pack=500, and /buy?pack=2000 without account or API-key context. Add a confirmation step explaining payment, access, and delivery while preserving a fast route for returning users.

Sampled public templates show a strong accessibility foundation. Homepage, use-case, topic, comparison, and MCP pages expose landmarks, include a skip link, maintain heading structure, and report no unlabeled inputs, positive tabindex values, or generic link text. Available PSI audits score 100. The remaining recommendation is resilience: no prefers-reduced-motion support was detected in sampled CSS, and keyboard, focus, and screen-reader states still need a behavioral pass. Add the motion rule before introducing non-essential animation.

Spoken presents a consistent developer-product system: one clear H1, orderly H2/H3 hierarchy, responsive captures, and repeated templates that feel like one product. The verified execution issue is mobile interaction sizing. The 390px inventory reports 55 small tap targets, including footer links at 84×19, 43×19, and 96×19, below the 44px target-height guidance. Expand clickable blocks without enlarging text, then re-run the mobile inventory. Grouping the long FAQ and podcast examples would also improve scanning.

Real-user performance is strong: homepage field p75 LCP is 1.365 seconds, INP is 63 milliseconds, and CLS is 0. The mobile lab run is slower at 2.633 seconds, so the critical path deserves attention even though the field verdict is fast. The clearest costs are 122 KiB of estimated unused JavaScript, 8 blocking requests, and a 176 KiB Google Tag Manager request. Prioritize hero delivery, split route code, and defer non-essential tags before re-testing.

Spoken uses specific product language and pairs “Podcast transcript API” with a searchable-text promise. The summarizer page strengthens the copy with runnable Python, named tools, prices, and trade-offs. The weakest sample is /topics/news: “News Podcast Transcripts” leads to “Episodes” and a list with little orientation about scope, freshness, or API use. Add a 40–80 word context block. Also trim the /why-spoken meta description, reported at 172 characters, to the target range.

The comparison grid is unusually practical: 11 rows compare Spoken with six alternatives across billing, source, speaker names, format, and use cases. Make the implied choices explicit: Spoken fits published-episode retrieval, transcription APIs fit audio you own, and search products fit corpus discovery. Add a choose-this-when block with trade-offs and an override link. Competitor prices and capabilities are volatile, so show methodology, sources, reviewed-on dates, and mobile treatment for every high-traffic comparison surface.

The supplied evidence supports a guided review rather than broad claims. Comparison tables, dates, schema excerpts, and crawl coverage anchor the main conclusions. Two uncertainties are correctly bounded: mobile treatment is not evidenced for every comparison page, and full structured-price reconciliation is not confirmed because the supplied Offer excerpt is truncated. Preserve those caveats in publication, and keep claims tied to the supplied artifacts rather than extending conclusions to the full catalogue.

The loss-capable risk is catalogue discoverability: sitemap.xml reports 50,000 URLs while only 40 URLs were directly inspected. GSC validation of sitemap child coverage is pending; resolve any gaps found there. The supplied evidence establishes scale risk, not broken endpoints.

The sample is broadly edited and specific. The homepage and use-case pages use concrete nouns, code, prices, named tools, and explicit limitations; the comparison copy states the retrieval-versus-transcription boundary. The main QA risk is the /topics/news template, which contains a title, one sentence, and an episode list without enough scope or freshness context. Require that context on every topic page and make repeated claims add proof or a distinct use case.

The sampled surface is broadly crawlable and server-rendered: 40 URLs returned 200, raw and rendered text matched on sampled templates, public pages used self-canonicals, HTTPS consolidation was single-hop, and robots.txt permits public crawling. The main structural concern is sitemap.xml at exactly 50,000 URLs; use a sitemap index and validate child coverage. /agents.md and /auth.md report missing viewport, 980px width at 390px, and missing title, description, and H1. The crawler also reports 8 homepage images without alt text.

Spoken is a strong fit for developers, researchers and AI-agent builders who need podcast transcripts for archives, summarizers, retrieval pipelines or knowledge bases. Its clearest advantage is decision clarity: the site states that it retrieves existing transcripts, names speakers, returns Markdown and explains the retrieval-versus-transcription boundary.nnIn the reviewed material, three fixes would make the product easier to trust at scale: deepen thin topic indexes, complete metadata on documentation pages, and resolve mobile overflow on /agents.md and /auth.md. Sitemap-scale coverage, mobile measurement coverage and complete structured-price reconciliation remain items to verify.

This 13-dimension review combines the supplied crawl, public page evidence, score table and named enrichment status. It covers positioning, audience and messaging, usability, accessibility, design execution, performance, writing quality, decision support, review-content integrity, risk and stability, editorial QA, and technical SEO.nnThe crawl covered 40 pages on 2026-10-11. Remaining verification items include mobile coverage, catalogue-scale sitemap coverage, complete structured-price reconciliation, metadata on documentation pages, and documentation resilience risks.