Innosearch Review: mixed performance (55/100)

Fact	Value
Domain	innosearch.ai
Category	AI shopping assistant for product comparison, price discovery, and accessible shopping
Pricing	Unknown; price range not supplied
Pages crawled	34
Crawl date	2026-10-12

Innosearch has a credible shopping-assistant proposition, but its 55/100 score reflects a gap between the idea and the site’s delivery. Positioning and audience messaging are the strongest public dimensions at 78/100 and 76/100, backed by clear product-comparison and accessible-shopping coverage. The homepage also records a Lighthouse accessibility score of 91, although the broader accessibility score is 58/100.

The weaker pattern is operational. Usability scores 63/100, while design execution and writing quality score 58/100 and 56/100. The supplied mobile lab run is the sharpest constraint: LCP is about 23.3 seconds, FCP is 19.8 seconds, and the page transfers about 4.9 MB over 407 requests. Technical SEO scores 39/100, with unknown URLs returning the homepage as a 200 soft-404 and key shopping pages relying heavily on client-side rendering.

Innosearch scores 78/100 here because the category is clear: it is a shopping assistant for comparing products, finding prices, and making purchase decisions. Its most ownable proof is accessibility-focused work and phone-based shopping support documented in the corpus. Bring that proof into the primary product story rather than leaving it mainly in the blog.

The 76/100 audience score reflects broad practical coverage: product comparison, price finding, product information, and top-rated-product content, alongside accessible shopping and phone-based experiences. The remaining messaging decision is hierarchy. The site should state whether general shoppers are primary, whether blind and low-vision shoppers are a core audience, or whether accessible multimodal shopping is the central promise for everyone.

Usability scores 63/100. The route set is reasonably connected, but the first task is diluted by competing service cues — Shop, Fly, Eat, Stores, and Donate — while the sampled homepage outline starts with Blogs. Contact and trust evidence are easier to find from the blog than from the product entry. Mobile completion is further constrained by 32 small targets and slow loading. Put a concise product-and-audience statement and one primary Start shopping action in the first viewport, expose Contact and About from the main navigation, and raise key controls to comfortable touch sizes.

Accessibility scores 58/100 despite a strong homepage Lighthouse score of 91. The most consequential defect is the contact form: 7 of 15 inputs lack a label or ARIA name, including fields represented only by placeholders such as “Full name” and “Message.” The shop sample has two similarly unnamed inputs, and PSI reports ARIA validity and accessible-name mismatches. Fix these programmatic names, reduce pages to one coherent H1, and manually test focus, announcements, dynamic widgets, and error states. Empty alt values should be retained only where the images are genuinely decorative.

Design execution scores 58/100. The editorial card grid and featured-content treatment are recognizable, and the 390px capture does not horizontally overflow. Execution is held back by 32 undersized mobile controls, a homepage H1 of “Blogs” that does not describe the commercial purpose, and substantial token drift: 180 colors, 65 font sizes, 35 radii, and 18 font families in the supplied extraction. Fix touch and input sizing first, then establish one descriptive H1 and consolidate the visual vocabulary into governed semantic tokens.

Performance is the sharpest delivery constraint, scoring 34/100. In the supplied mobile lab run, the homepage reaches FCP at 19.8 seconds and LCP at 23.3 seconds, transferring about 4.9 MB over 407 requests, including 349 blocking requests. GTM contributes 508 KiB, and image delivery has an estimated 454 KiB of savings. Identify and preload the LCP asset, serve responsive AVIF/WebP at the rendered size, defer below-fold media, and move nonessential third-party work off the critical path. These are lab measurements; no CrUX field data was supplied.

Writing quality scores 56/100. The corpus contains valuable mission proof, including “8,419 Blind and Low Vision Users Served” and “8,993 Orders Completed in 2025,” but the presentation buries it: the homepage is recorded as one 442-word paragraph, flights as one 221-word paragraph, and donate as one 361-word paragraph. Split mission, proof, features, and actions into short page-specific blocks. Also replace the repeated 245-character meta description, shorten overlong titles, and give every route one descriptive H1.

Risk and stability scores 42/100. No traffic loss can be measured because Search Console is unavailable, but two credible technical risks are observable: the guaranteed-nonexistent URL returns the homepage with HTTP 200, and the /us/shop template is 92.2% JavaScript-only by the supplied raw/rendered comparison. Fix the soft-404 and render essential shopping content and links in initial HTML before drawing conclusions about traffic impact.

Editorial QA scores 52/100. The sample contains specific mission proof, but repeated multiple-H1 flags, titles from 87–149 characters, a shared 245-character meta description, and two-hop redirects show that a final route-level QA gate is not consistently catching mechanical defects. Preserve the concrete impact figures with source context, while enforcing one H1, sequential headings, page-specific metadata, paragraph segmentation, and canonical internal links before publication.

Technical SEO scores 39/100. HTTPS and robots access are present, but the guaranteed-nonexistent URL soft-404s, host consolidation takes two hops through HTTP, and key shopping pages depend heavily on client rendering: /us/shop has 12 raw words versus 244 rendered, while /us/flights has 12 versus 243. The supplied sitemap facts report zero URLs across the 34-page inventory. Return a real 404, use one direct HTTPS 301 to the canonical host, server-render primary content and links, and publish and declare a valid XML sitemap.

Innosearch is best suited to shoppers who want product and price research, especially when accessible shopping matters. The site communicates a distinct category and has strong accessibility proof, giving it a sound basis for trust.

The verdict is held back by three fixable weaknesses: mobile delivery is very slow; technical SEO includes a 200 soft-404 for unknown URLs and heavy client-side rendering on key shopping pages; and editorial and design consistency remain uneven. The next gains should come from reducing the critical path, tightening URL and rendering behavior, and making the primary audience hierarchy explicit.

This 13-dimension review combines the supplied crawl, public dimension score table, simulated walkthrough findings, and the supplied mobile lab run. Innosearch was crawled across 34 pages on 2026-10-12. Pricing was not supplied, and Search Console access was unavailable, so traffic loss could not be measured.

Dimensions 12 (Decision-support surfaces) and 13 (Review-content integrity) were excluded as not applicable. Enrichment remains pending for Search Console connection and access. See How SiteList scores for the review method.