Lattis

Lattis does not have traditional paid plans with monthly subscriptions. The product is free for any public website with automatic re-crawls, but with page limits: 500 pages for unverified sites and 2,000 pages after domain verification via DNS. For sites larger than 2,000 pages, there is no automatic ongoing monitoring tier—you must use on-demand re-crawls at $5 per crawl, which supports up to 5,000 pages per crawl. There is no subscription, no seats, and no rate cards. Your 50,000 page site would require multiple $5 re-crawls to fully cover, with no ongoing monitoring option currently offered.

Create a dedicated pricing page or FAQ entry that explicitly addresses: (1) whether sites over 5,000 pages are supported, (2) if there are any plans for subscription-based ongoing monitoring for large sites, and (3) how customers with 50,000+ page sites should think about coverage (multiple crawls, enterprise options, etc.). Currently the 'no subscription' messaging conflicts with buyer expectations for ongoing monitoring at scale.

Where we looked: /pricing, /pricing, lattis.dev, lattis.dev, /pricing

The chunks confirm that llms.txt is part of Lattis's scoring system under "Technical hygiene" (30% of score), with specific point values assigned (+1 to +3 pts depending on the site). However, the chunks do not explicitly state whether llms.txt is required versus recommended, nor do they clarify the relationship to robots.txt modifications. The "Protocol fix list" UI frames llms.txt as "Missing" when not installed, suggesting it's expected for a complete score. One chunk [18] shows a passing site with both "✓ robots.txt" and "✓ llms.txt" as separate checklist items, indicating they are distinct components. The minimum viable implementation appears to be llms.txt alone (since it's the only item with point values and explicit "Missing" status in the fix lists), but the docs don't clearly state this hierarchy.

Add explicit documentation clarifying: (1) whether llms.txt is required or recommended for scoring, (2) how robots.txt relates to llms.txt (separate, complementary, or alternative), and (3) what constitutes minimum viable implementation for users who want to maximize their score with least effort.

Where we looked: /sites/tempo.xyz, /sites/render.com, /llms-txt

For the free tier: Lattis uses "Auto re-crawl on natural change signals" — not on-demand, daily, or weekly. For paid/on-demand: re-crawls cost $5 each and are explicitly on-demand ("Full-depth crawl on demand" / "Ship a feature, hit re-crawl, your score updates within minutes"). There is no mention of a "paid monitoring tier" with scheduled re-crawls — the only paid option appears to be per-crawl billing, not a subscription tier with automatic refresh schedules.

Clarify whether there's a subscription monitoring tier with scheduled re-crawls (daily/weekly) or if all re-crawls are strictly per-crawl $5 charges. If scheduled re-crawls are only 'coming' as stated in chunk [8], make this explicit on the pricing page.

Where we looked: /pricing, /pricing, lattis.dev, /skills.md

Lattis generates a 0–100 AI Visibility Score that is weighted by question importance and rolls up into a single number you can track over time. The score is category-aware: a 'category-aware model writes the questions actual buyers in your space ask' (chunk [2], [6]). The site shows category-specific rankings (e.g., 'Top in SaaS', 'Top in Marketing Tools') with filtering and sorting by category (chunk [8], [11]). However, the chunks do not explicitly confirm whether the 'industry average' of 54 shown in individual reports is global across all indexed sites or scoped to the site's detected category, nor do they document filtering benchmarks by company size (10–50 employees) or B2B SaaS specifically.

Create a documentation page or FAQ entry that explicitly explains how the 'industry average' benchmark is calculated (global index vs. category-scoped), and whether users can filter benchmarks by company size, category, or other dimensions.

Where we looked: lattis.dev, lattis.dev, lattis.dev, app.lattis.dev, app.lattis.dev

The MCP server exposes these specific tools: lattis_search (semantic search across indexed sites), lattis_list_sites (list all indexed sites with metadata), lattis_get_site (metadata and AI Visibility Score for a single site), and lattis_get_page (full markdown of a specific page). The REST API has additional endpoints including POST /analyze to trigger new crawls and GET /analyze/:domain/status to poll indexing status. The chunks do not explicitly confirm whether the MCP server can retrieve historical scores or trigger new crawls—the documented MCP tools appear focused on current data retrieval (search, list, get) rather than write operations or historical data access. The REST API clearly supports triggering new crawls via POST /analyze.

Add explicit documentation clarifying whether the hosted MCP server supports triggering new crawls (lattis_analyze or similar) and retrieving historical score data, or confirm it is read-only current data only.

Where we looked: /docs, /docs, /docs

Lattis provides a specific comparison for a 40-page site: ~80k tokens of raw HTML without Lattis vs. ~2k tokens for the same answer with Lattis. This represents a 97.5% reduction in token usage. However, the site explicitly states these 'numbers are characteristic, not measured against a formal benchmark' and does not provide a specific percentage figure for Next.js marketing sites specifically.

Add a dedicated section with benchmarked percentage reductions for common site types (Next.js marketing sites, docs sites, e-commerce), including methodology. The current 'characteristic, not measured' disclaimer undermines buyer confidence in the 97.5% figure.

Where we looked: /builders