Poly earns 78/100 for a clear enterprise voice-agent platform with strong sampled technical SEO and broad evaluator coverage. Its most material weakness is mobile performance, compounded by limited pricing decision support and visible editorial QA defects.
Reviewed by SiteList Engine · 11 of 13 dimensions · published Reviewed on October 12, 2026
Is this your site?
Claim itPoly is an enterprise conversational AI and voice-agent platform for customer-service operations.
| Field | Value |
|---|---|
| Domain | poly.ai |
| Category | Enterprise conversational AI and voice agents |
| Pricing | Usage-based; per-minute model stated, public range not supplied |
| Pages crawled | 40 |
| Crawl date | 2026-10-10 |
Poly presents a clear enterprise category: voice and conversational AI agents for customer-service calls, with concrete use cases across routing, billing, and payments. Its information architecture supports evaluation through use cases, integrations, documentation, release notes, security, customer stories, pricing, and a demo path.
The strongest measured areas are sampled technical SEO at 88/100, risk and stability at 87/100, first impressions and positioning at 84/100, and usability at 82/100. Accessibility is also solid at 78/100, supported by language declarations, landmarks, skip links on most sampled pages, focus-visible rules, and zero positive tabindex values.
The main drag is mobile performance: the homepage recorded a 3697 ms lab LCP, 1236 ms total blocking time, and 5701 KB across 172 requests. Decision-support surfaces scored 68/100, while editorial QA scored 71/100, leaving practical room to improve pricing guidance and content polish.
PolyAI presents a clear B2B category: voice and conversational AI agents for customer-service calls, with concrete routing, billing, and payments use cases. The 130+ integrations claim adds operational substance. Named customer evidence is stronger: SafeRide Health handles 1M+ calls a month, saves 47,000 agent hours, and reduced speak-to-human rates from 55% to 2–3%. The crawl found no alternatives or comparison pages, leaving less help on how PolyAI differs from scripted IVR, generic chatbots, or in-house builds. Name the primary buyer in the hero and add a concise comparison framework beside a named outcome.
PolyAI gives visitors useful entry points through use cases, integrations, documentation, and customer stories. A visitor with a defined call problem can find a call-routing page framed as “Get callers the right place, every time.” Make that split visible in navigation and CTA copy. Each use case should lead to the relevant integrations, deployment scope, proof, and next action, while technical visitors receive a clearly labeled “Start building” or “Quickstart” route.
Visitors can reach pricing, integrations, documentation, release notes, security, customers, and a demo path from the core site. The main friction is task clarity at the marketing/docs boundary: navigation exposes “Documentation” and “Developers,” while docs begin with “Platform overview,” “Agent Studio,” and “Quickstart.” Mobile adds delay, with 12.1 s Time to Interactive and 1,236 ms Total Blocking Time. Add task-oriented links such as “Start building,” “Quickstart,” and “Find an integration,” and defer nonessential JavaScript.
PolyAI has strong baseline signals: language declarations, landmarks, skip links on most pages, zero positive tabindex values, focus-visible rules, and a reported homepage PSI accessibility score of 100. The confirmed issues are specific. Docs has 1 of 3 inputs without a label or ARIA name; pricing reports 1 image missing alt; integrations reports 1 missing alt among 66 images. Integrations also has a generic “read more” link, while PSI reports 6 non-descriptive homepage links. Add programmatic names, classify images, replace generic labels, and normalize documentation outlines to one logical h1 followed by ordered headings.
PolyAI presents a coherent enterprise design language: Matter SQ dominates the extracted font inventory, spacing repeats at 8/12/16/24px, and radius and shadow variables recur widely. Key mobile buttons measure 40–44px, with primary links at 308–358px wide. Runtime weight undermines the polish: mobile PSI reports performance 60, 12.1 s to interactive, 1,236 ms TBT, and 2.4 s JavaScript execution. The system is broad, with 103 colors, 51 spacing values, 32 radii, 31 shadows, and 35 !important rules. Defer below-fold modules, fix labels such as “60%less,” and consolidate repeated tokens.
The mobile homepage needs critical-path work. The lab report records LCP of 3,697 ms and TBT of 1,236 ms; the network summary reports 5,701 KB across 172 requests, including 25 blocking requests. Third-party cost includes 553 KB from www.googletagmanager.com, 522 KB from connect.facebook.net, and 375 KB from t.polyai.app. Raw and rendered word counts match, so the evidence does not indicate a JS-only rendering problem. Identify and prioritize the LCP asset, defer non-critical tags and media, review in-viewport images marked lazy, and consider performance budgets for transfer, requests, blocking work, and third-party JavaScript.
PolyAI has strong topical coverage across documentation, APIs, integrations, pricing, and use cases. The homepage opening is less direct: “The Frontier of Agentic Dialog” and “Conversation is the interface to everything” establish mood without naming the product, audience, or job quickly enough. Headings also contain spacing defects, including “in your.” Pricing uses broad language before concrete detail such as per-minute pricing, maintenance, and 24/7 support. Rewrite the hero to state enterprise voice agents, audience, and outcome, then run a copy QA pass and add a worked pricing example.
PolyAI has a clear pricing entry point and per-minute model, but the supplied surface is not a strong comparison or self-estimation tool. Buyers see the billing unit and included support, yet no visible plan tiers, worked cost example, calculator, or comparison dimensions. Add an estimator or table covering call volume, per-minute assumptions, support, implementation scope, and enterprise qualification. The “Start the conversation.” heading is not a plan-selection or estimate control. Add one explicit estimate-or-talk-to-sales CTA and show an effective date: lastmod is 2026-02-04 while the crawl started 2026-10-10.
PolyAI shows no confirmed traffic-suppressing defect in the supplied sample. The homepage returns 200 with a self-canonical, HTTP redirects to HTTPS in one 308 hop, the nonexistent probe returns 404, and sampled raw and rendered word counts match. The noindex on the gated API-key request flow is not treated as a defect. The open risk is coverage: the sitemap declares 705 URLs, only 40 pages were crawled, and GSC is disconnected. Reconcile sitemap URLs against status, canonical, robots, and indexability signals, then connect GSC before attributing traffic risk.
PolyAI’s content surface is broad, but it is not release-clean. Homepage headings should read “of Agentic,” “interface to,” and “in your.” The API reference should have one h1 element, the release overview should have a meta description, and missing alt text recurs across image-heavy templates: 13 homepage images, 26 on /agent-studio, and 16 on /security. Pricing also warrants sentence-level review: 9 sentences across 739 words produces an 82.1-word average, though the one-paragraph extraction should be confirmed in the rendered page. Correct headings, retain one semantic h1, add release metadata, audit shared image components, and split long pricing sentences.
The sampled PolyAI surface is indexable and renderable. The homepage returns 200 with a self-canonical, robots.txt allows the public site and declares the sitemap, the nonexistent probe returns 404, and raw and rendered word counts match closely on the homepage and /agent-studio. Coverage is explicitly partial: 40 pages were sampled against 705 sitemap URLs, so sitemap-wide error and canonical rates remain unverified. Missing alt text is the clearest confirmed quality issue, including 13 homepage images and 26 on /agent-studio. Normalize internal links to canonical no-slash paths such as /pricing; the trailing-slash URL returns one 308.
Poly is a strong fit for enterprise teams assessing voice agents for customer-service operations. The site explains the category clearly, supports evaluation through use cases, integrations, documentation, security, customer stories, pricing, and a demo path, and records strong scores for technical SEO, risk and stability, positioning, and usability.
The fixable weaknesses are concentrated. Mobile performance needs attention: the homepage's 3697 ms LCP, 1236 ms total blocking time, and 5701 KB load make the first visit heavier than the rest of the experience suggests. Pricing states a per-minute model but does not yet provide strong comparison or self-estimation support. Editorial QA also needs a release pass for heading concatenation, a duplicate H1 in the API reference, a missing release-page meta description, and repeated issues.
The evidence supports a capable enterprise platform site with a clear next phase: reduce mobile load, make commercial evaluation more concrete, and finish the editorial cleanup.
This is a 13-dimension review based on a crawl of 40 pages on 2026-10-10, using the supplied public dimension score table and its one-line evidence summaries. The review covers positioning, messaging, usability, accessibility, design, performance, writing quality, decision support, risk and stability, editorial QA, and technical SEO among the supplied public dimensions.
Google Search Console was not connected, so no Search Console enrichment was used. Pricing remains usage-based, with a per-minute model stated and no public price range supplied.
Read more about the review process in How SiteList scores.
PolyAI is aimed at product, customer-service, and technology teams evaluating voice agents for call routing, billing, payments, and other customer-service workflows.
The site uses a usage-based model and presents a per-minute billing entry point. The supplied review evidence does not provide a public price range.
The site makes its enterprise category clear and supports evaluation through use cases, integrations, documentation, security, customer stories, pricing, and a demo path.
The clearest priorities are mobile performance, more useful pricing decision support, and editorial QA fixes including heading concatenation, a duplicate H1, and a missing release-page meta description.