Buyers evaluating runtime entitlements and monetization tooling are increasingly starting in an AI assistant rather than a search box — and in a category this young, the vendors that establish citation visibility now lock in an advantage that compounds before the rest of the market notices. Before we run the audit, we need to make sure we're asking the right questions about the right competitors to the right buyers. This document presents what we've learned about Schematic's market — your job is to tell us what we got right, what we got wrong, and what we missed.
Before we measure how often AI assistants cite Schematic in runtime entitlements and monetization conversations, these three signals tell us whether those assistants can reach, parse and trust schematichq.com at all. All three are derived mechanically from the August 6, 2026 crawl of 50 pages.
ld+json tag. Also high: nine commercial pages render no H1, and all 17 product and pricing pages are 10–12 months old.Schematic sells into a category it still partly has to define — a runtime entitlements and monetization platform that sits between a SaaS or AI product and its billing system, so pricing, packaging, limits and feature access can change without shipping code. That is exactly the kind of category where AI assistants do the most work on the buyer's behalf, because there is no settled vocabulary and no obvious incumbent to anchor on: an engineering leader asking an assistant how to stop hard-coding plan logic is asking it to name the category and its vendors in the same breath. Early citations in a young category compound — the domains assistants learn to treat as authoritative on a topic get returned again — and that is a position a well-funded startup can take from much larger billing incumbents before the category consolidates.
This Foundation Review presents the inputs that determine what the audit actually measures. The competitive set defines which vendors Schematic is tested head-to-head against and which are tested only for category awareness. The buyer personas define whose search intent the queries model — the technical evaluator and the commercial owner of pricing ask very different questions about the same product. The feature and pain point taxonomies supply the language those queries are written in. Underneath all of it sits the Layer 1 technical baseline: whether AI crawlers can reach schematichq.com, and whether what they retrieve is structured enough to cite. This is what we're validating together before the audit runs.
The validation call is a working session with real consequences, not a review of a document. Two kinds of decisions get made there. First, input validation: are the right buyers and the right competitors in the right tiers, and is our outside-in read of Schematic's capabilities honest? Every correction redirects query budget — a merged persona or a demoted competitor moves whole clusters of queries somewhere more useful. Second, engineering triage: the Layer 1 findings are independent of everything we decide about the query set, so your engineering team can start on them the day this document lands. The specific items on both sides are in the Pre-Call Checklist near the end.
next/script; the markup is already written, it just never reaches a non-browser crawler.Three things to know before you read the rest.
Purpose This is the input layer for Schematic's GEO visibility audit. Everything below — the competitors, the buyers, the capabilities, the buyer frustrations — becomes the raw material for the buyer queries we run against AI assistants. If our read of the runtime entitlements and monetization market is off, the audit measures the wrong thing precisely. That's why this document exists before the audit rather than after it.
Your Job Read for what's wrong, not for what's right. Every section ends with a specific question in purple — those are the places where our confidence is lowest or the downstream consequence of being wrong is highest. You don't need to prepare a written response; the Pre-Call Checklist at the end collects every question in one place so you can walk into the call with answers.
Confidence Badges Every entity carries a confidence badge showing how directly it was sourced. High means it came from a first-party source — Schematic's own site, docs, or published comparison content. Medium means it was inferred from category listings, competitor-authored content or secondary review coverage. Worth knowing: G2 and Crunchbase both returned HTTP 403 to automated fetches during research, so no first-party review-platform mining was possible — anything review-derived here is medium confidence by definition. Medium-confidence items are where your correction is worth the most.
The company profile sets the entity we track across every AI response — the name variants below are literally how we detect a Schematic mention in an answer that never links to you.
→ Schematic's own pages describe the product two ways — entitlements (a developer primitive: check whether this customer can do this thing right now) and monetization (a revenue lever: change pricing and packaging without a deploy). Which one do buyers actually type into an assistant first, or do the technical and commercial buyers each arrive through their own vocabulary? If it's genuinely both, we build two query clusters instead of one and split the budget between them. Secondary check: the seed URL resolves to schematichq.com, and the crawl and every tracked name variant are keyed to that bare domain — if schematic.com is also owned and canonical for marketing, tell us before the audit runs.
5 personas: 2 decision-makers, 2 evaluators, 1 influencer — each modelled as a distinct search intent, because the queries the audit runs are written in their language, not Schematic's.
Critical Review Area Personas are the single highest-leverage thing you can correct in this document. Each one drives a distinct cluster of queries; a persona that doesn't exist in your deals burns query budget, and a persona we've missed is a set of buyer questions the audit will never ask. Read these five for who is duplicated and who is missing before you read them for accuracy.
Data Sourcing Note Name, role, department, seniority, influence level, veto power and technical level come directly from the knowledge graph — all five are grounded in real named titles on schematichq.com/testimonials (a CTO at Makeswift, a VP Engineering at GreyNoise, a VP Product at Slang.ai, an Engineering Manager for Monetization formerly at Calendly, and CMO / pricing-COE voices at Automox and Insight Partners). The role descriptions, buying jobs and query focus areas are synthesized by us from those attributes plus the pain points each persona is linked to. Correct the synthesized lines freely — they're our interpretation, not your data.
→ Do seed-stage founding CTOs and mid-market VPs of Engineering actually evaluate Schematic differently, or is that one technical buyer wearing two titles? If it's one, roughly a fifth of the query budget is currently spent twice, and we'd redirect it to a buyer we haven't covered.
→ Setting aside whether Guillermo and Miriam are one buyer: he's the persona attached to both the vendor-lock-in / Stripe-dependency pain and the enterprise-contracts pain, so is his veto usually exercised on deployment grounds (self-hosting, non-Stripe, procurement) or on integration cost grounds? The first pulls a whole query cluster toward "self-hosted" and "not on Stripe" phrasings; the second doesn't.
→ Dana is linked to seven of the ten pain points — more than either persona that holds veto power — yet she's recorded with no budget authority. Does the VP of Product own the monetization tooling line item in your deals, or does it always sit under engineering? If it's Product, we promote her to decision-maker and add validation-stage queries on procurement, pricing and internal business case.
→ Aubrey is the only persona rated medium influence, yet she's linked to six of the ten pain points — more than Guillermo Santos, who holds veto power. Does she originate the search and build the shortlist, or only get pulled in once two vendors are already on the table? If she originates it, we promote her to evaluator and weight the discovery-stage queries toward implementer language rather than executive language.
→ Justine is the only medium-confidence persona in the graph — a composite of CMO and Head-of-Pricing signals rather than one attested title. Is pricing owned by a dedicated pricing and packaging lead in your deals, or by a CMO or CFO who inherited it? Those two search in different vocabularies — packaging mechanics vs. revenue outcomes — and we'd build separate query clusters rather than one blended set.
Missing Personas? These roles sometimes appear in monetization-platform deals — do they show up in yours? CFO / VP Finance or RevOps — invoicing, tax and revenue recognition are rated absent in the taxonomy by design, and the enterprise-contracts pain point ends with finance tracking commits in a spreadsheet; if finance sits on the committee, we need queries that probe the Stripe boundary rather than assuming buyers accept it. Head of Security or IT procurement — the vendor-lock-in and self-hosting pain is the classic procurement objection, and it's the one place a competitor like Lago wins on deployment model alone. Founder / CEO — at seed-stage accounts the CTO persona and the economic buyer may not be the same person. Who else shows up in your deals?
5 primary + 5 secondary competitors identified — primary means direct head-to-head testing in the audit, secondary means category-awareness testing only.
Why Tiers Matter Tier assignments decide where roughly 30–40 of the audit's head-to-head queries land — phrasings like "Stigg vs Schematic", "Chargebee alternatives for feature entitlements", "best runtime entitlement platform for AI products" and "Stripe usage metering alternative". Five primary competitors at six to eight queries each consumes that entire budget; secondary vendors get tested only for whether Schematic surfaces alongside them in category questions. One primary — Orb — was tiered from category listings rather than from observed deal overlap and carries medium confidence; if Orb rarely appears in your actual evaluations, moving it to secondary frees six to eight queries for Stigg or Metronome.
→ Three things to settle. (1) Stripe Billing's dual role: in live deals, is Stripe something you compete against — "we'll just build it on Stripe ourselves" — or purely the partner you sit on top of? It's tiered primary, which allocates it six to eight head-to-head queries; if buyers never frame it as an either-or, that budget is better spent on Stigg, Metronome or Orb. (2) Orb's tier: it's the only primary competitor at medium confidence and was tiered from category listings rather than observed deal overlap — does Orb actually appear in your evaluations, or is Metronome the metering-depth competitor you really face? (3) Who's missing or irrelevant: the graph has no AI-native billing entrant and no open-source option beyond Lago — is a vendor showing up in your deals that isn't on this list, and is anything here a vendor you have never once lost to?
12 buyer-level capabilities mapped — 5 strong, 5 moderate, 1 weak, 1 absent — and each becomes a capability query written in the buyer's words, not Schematic's.
One place to define our plans, add-ons, limits, trials and credits instead of having the truth scattered across Stripe, our database and hardcoded conditionals
Check in real time whether this customer is allowed to use this feature right now, fast enough to sit in the request path and safe when the network fails
Let our go-to-market team change what's in each plan, move a feature between tiers or adjust a limit without filing an engineering ticket or waiting for a deploy
Drop in a working pricing table, checkout, upgrade flow and customer portal instead of building and maintaining our own billing screens
Native SDKs for the languages we actually run in production, with local evaluation, offline fallbacks, multiple environments and an event log we can debug against
Keep our billing system as the source of record and have plans, subscriptions and entitlements stay in sync automatically — and work just as well if we're not on Stripe, or need to self-host
Meter millions of usage events a day accurately enough to bill on, without dropped events or lag between what the customer consumed and what we can enforce
Sell prepaid credit bundles that burn down at different rates per action, handle promotional and expiring credits, and show customers exactly what's left
Use the same system to gate paid features and to roll out or experiment with new functionality, rather than running a separate feature-flag vendor alongside it
See which accounts are hitting their limits, which features drive upgrades and where revenue is leaking, without exporting everything to the warehouse first
Handle multi-year commits, minimum drawdowns, custom negotiated rate cards, parent-child account hierarchies and multi-schedule contract pricing for our largest deals
Generate and send the invoices, calculate global sales tax and VAT, run dunning, and produce the revenue recognition schedules our finance team closes the books on
Prioritization The audit tests all 12 capabilities, but competitive differentiation queries will emphasize 3. Five are currently rated Strong:
Which three of these best represent where Schematic actually wins deals — the capability that closes the deal, not the one that demos best?
→ Three ratings to pressure-test. (1) Usage Metering & Event Ingestion at Scale (moderate) is the only capability in the taxonomy sourced from review mining rather than first-party material, and it rests largely on competitor-authored criticism from Flexprice and Stigg rather than your own benchmarks — do you have throughput and lag numbers that would move it to strong against Orb and Metronome specifically? (2) Enterprise Contract Structures (weak) is rated against Metronome's and Zuora's commit and drawdown handling; if you've shipped custom plans that cover this, the audit is about to hunt for a vulnerability gap you've already closed. (3) Billing System Integration (moderate) is deliberately one blended rating — Stripe sync is genuinely strong while non-Stripe support and self-hosting are weak — so if most of your pipeline is already on Stripe, argue for splitting it into two capabilities and raising the Stripe half. And separately: is anything here really two capabilities, or any two entries here really one?
10 pain points: 7 high, 3 medium severity — the buyer-language quotes below are literally how the audit's problem-stage queries will be phrased.
→ Severity is unusually flat: seven of ten pain points are rated high, which leaves the audit no ranking to work from — if everything is urgent, nothing is prioritized, so which three of those seven actually open your discovery calls? Buyer language: these quotes are reconstructed from your testimonials and case studies rather than recorded from sales calls — does "we've refactored our billing system every six months" sound like your buyers, or is the real phrasing closer to "our pricing is hard-coded"? The exact wording matters because it becomes the query. Missing pains: three that plausibly belong in this category but aren't here — migration risk (the fear of moving live entitlement state off a working homegrown system without breaking paying customers), latency and availability anxiety (putting a third-party service in the production request path, which is Guillermo Santos's veto territory), and finance reconciliation (entitlement state and the billing ledger disagreeing at close). Do any of those come up?
Nine findings across 50 pages fetched without JavaScript on August 6, 2026 — three high, four medium, two low, and no critical blockers.
Actionable Now — Engineering There is no critical blocker here: robots.txt is confirmed open to every AI crawler we checked, both hosts publish a live llms.txt, and primary body copy is server-rendered. Two of the three high-severity items belong to your engineering team and can start immediately. First, server-render the JSON-LD — the schema is already written but is staged inside the Next.js flight payload and injected after hydration, so schema coverage measures 0.00 across all 50 pages. Second, fix the missing and duplicate H1s on the eight /use-cases pages, /developers, /testimonials and /roadmap — these are template-level changes in the Makeswift layouts, not eleven separate page edits. The third high-severity item is owned by content, not engineering: put the 17 product, pricing and use-case pages on a refresh cadence; they carry sitemap lastmod dates of 2025-08-12 and 2025-08-22 and are the only pages on the site that define what Schematic sells. The remaining items — DOM source order, case study heading structure, the U+FEFF characters and the sitemap's uniform priority — are lower severity, and three of those four are under a day each.
What we found: We fetched the raw HTML of 47 schematichq.com pages and 3 docs.schematichq.com pages without executing JavaScript. Not one of the 50 pages contains a literal <script type="application/ld+json"> tag. On schematichq.com the schema does exist, but only as escaped strings inside the Next.js React flight payload (self.__next_f.push(...), nodes id="schema-jsonld-0" / "schema-jsonld-1"), which a next/script component injects into the DOM only after the page hydrates in a browser. The types staged there are WebSite, WebPage, Organization and BreadcrumbList on marketing pages, and BlogPosting plus Person on blog, case study and /pricing-resources pages. The docs subdomain emits no structured data in any form.
Why it matters: Structured data is the most reliable way to tell an answer engine what an entity is, who published a page, and when it was last updated. Crawlers that fetch HTML without running JavaScript — which includes most non-browser AI retrieval agents — see zero structured data on every page of the site. The BlogPosting datePublished on the blog is exactly the freshness signal that citation-weighted retrieval leans on, and it is invisible in the served HTML. This is a high-leverage fix because the markup is already written; it only needs to be emitted server-side.
Recommended fix: Render the JSON-LD inline in the server component instead of through next/script — a plain <script type="application/ld+json" dangerouslySetInnerHTML={{__html: JSON.stringify(schema)}} /> inside the page's server-rendered tree will appear in the initial HTML. While making the change, upgrade the types: SoftwareApplication or Product on /products/* and /pricing (with offers reflecting the $0 / $200/mo / Enterprise tiers), FAQPage on /pricing and on the FAQ blocks that already exist on the blog and /pricing-resources pages, and BlogPosting with an explicit dateModified on every dated article. Verify each template with Google's Rich Results Test and by running curl on the URL and grepping for ld+json.
What we found: Nine of the 50 pages render zero <h1> elements: /developers and all eight /use-cases/* detail pages (billing-tools-for-spiky-ai-usage, credit-burndown-billing, easy-usage-based-pricing, enterprise-pricing-exceptions, feature-entitlements-without-code, stripe-usage-metering-alternative, usage-limits-and-caps, api-usage-metering). On those pages the visually dominant line — for example "What billing tools work for AI companies with spiky usage patterns?" — is marked up as an H2, so the document has no top-level heading. Separately, /testimonials and /roadmap each carry two H1s, the second being the boilerplate call to action "Start using Schematic for free".
Why it matters: The H1 is the primary label a retrieval system uses to decide what a document is about before it reads the body. The /use-cases pages are the only place on the site that carries head-to-head capability tables against Stripe, Orb, Metronome and Stigg, so they are the pages most likely to be retrieved for comparison questions — and they are the pages with no topical anchor. A duplicated H1 that reads "Start using Schematic for free" actively mislabels /testimonials and /roadmap as conversion pages rather than evidence pages.
Recommended fix: Promote the leading question on each /use-cases/* page and the "Decouple business logic from code" line on /developers to H1, and demote the following section labels one level so the hierarchy runs H1 to H2 to H3. On /testimonials and /roadmap, change the trailing "Start using Schematic for free" block from H1 to a non-heading element or an H2. These are template-level changes in the Makeswift layouts, not per-page edits.
What we found: Sitemap lastmod timestamps put all five /products/* pages at 2025-08-22 (349 days before analysis), /pricing, /use-cases and all eight /use-cases/* detail pages at 2025-08-12 (359 days), and the homepage at 2025-10-01 (309 days). None of the 17 product_commercial pages in the inventory scores above 0.2 on freshness, giving that category an average of 0.20 against a content_marketing average of 0.53. The lastmod values are trustworthy on this site — blog lastmods track their visible bylines to within a day (for example /blog/chargebee-alternatives shows 07/02/2026 and reports lastmod 2026-07-03), so these are genuine last-edit dates rather than build artifacts. The gap is visible in the content too: /products/metered-pricing and the /use-cases pages still describe the Stripe integration in terms that predate the official Stripe App announced in the April 2026 launch week.
Why it matters: Freshness is a heavily weighted retrieval signal — AI-cited content averages 25.7% fresher than content appearing in traditional Google organic results (Ahrefs, August 2025), and 76.4% of ChatGPT's most-cited pages had been updated within the previous 30 days (ConvertMate, ~Q4 2025; ChatGPT-scoped). The practical effect here is that the blog, which is refreshed constantly, is the only part of the site competing on recency, while the pages that actually describe what Schematic sells look abandoned. Product pages carry the entity-defining claims; when they go stale, answer engines fall back to third-party descriptions of the product.
Recommended fix: Put the five /products/* pages, /pricing and the /use-cases cluster on a scheduled refresh — at minimum a quarterly pass that folds in shipped capability (Stripe App, MCP tooling, custom plans) and re-emits lastmod. Pair this with a dateModified field in the structured data once the JSON-LD server-rendering fix lands, so the refresh is machine-visible rather than only visible in the sitemap.
What we found: Extracting all visible text from the served HTML gives /products/plans-entitlements 169 words, /products/revenue-insights 177 words, /use-cases/usage-limits-and-caps 175 words, /use-cases/enterprise-pricing-exceptions 172 words and /products/metered-pricing 262 words. Roughly 130 of those words on every page are the shared header and footer link lists, so the actual body copy runs from about 40 to 130 words. /products/plans-entitlements — the page for the company's lead product — reduces to four short claims plus one customer quote. The substance lives in animated product visuals and screenshots, which carry no extractable text. By contrast the blog averages roughly 2,100 words per post.
Why it matters: An answer engine cannot cite a claim it cannot read. Asked "how does Schematic handle plan and entitlement management", the richest source on schematichq.com is a blog listicle or a competitor's comparison page, not the product page itself. This is the mechanism by which a company loses its own branded and category queries: the pages carrying the strongest first-party claims have the least citable text on them.
Recommended fix: Add 300 to 500 words of specific, self-contained body copy to each /products/* page — what the primitive is, how the check works at runtime, what the limits and latency characteristics are, what it does not do. Give every product screenshot a real caption and alt text so the visual content becomes extractable. The /pricing page shows this is achievable in this design system: it scores 0.65 on depth because it publishes concrete numbers (500K and 10M events/month, 10 and 100 monetized subscriptions, $200/mo Growth, $500/mo add-on bundle).
What we found: Six case studies emit no <h2> at all. On /case-studies/a-paradigm-shift-in-monetization-makeswift-schematic the body has no headings whatsoever — "Customer Overview", "Before Schematic", "Challenges" and "Value Delivered" are styled paragraphs, and the only H3s on the page are the four footer column labels. On the Automox, FavorDrops, Zep, Pagos and JourneyTMS studies the section labels are H3s that sit directly under the H1 with no intervening H2, so the document jumps two levels. Only the Plotly and Flashnet studies (the two most recent, 2026) use a proper H1 to H2 structure.
Why it matters: Case studies are where the specific, attributable outcome claims live — "it took us 2 years to build this internally", "shipped usage-based billing in a day", the Plotly credits rollout in two weeks. Passage-level retrieval uses headings to decide where a citable passage starts and ends. When the before/after structure is invisible in the markup, the whole study becomes one undifferentiated block and the outcome claim is much less likely to be extracted as a standalone answer.
Recommended fix: Standardise the case study template on the structure the Plotly page already uses: H1 for the title, H2 for each narrative section (At a glance, The challenge, The evaluation, The solution, Results), H3 only for sub-points. Backfill the six older studies — this is a markup change, not a rewrite.
What we found: On every Makeswift-built marketing page — homepage, all /products/*, /pricing, /developers, /use-cases and its eight detail pages — the header navigation block ("AI Products Developers Pricing Book Docs Resources Sign in Sign Up") appears part-way through the document body rather than at the top, and section headings are separated from the copy they introduce. On /products/plans-entitlements the H2 "Schematic is your source of truth on customers" and its supporting sentence are emitted several hundred characters apart with the nav block between them. The blog, case study and /pricing-resources templates do not have this problem — their source order is correct. The cause is absolutely positioned and animation-driven layout, where visual order is produced by CSS rather than by document order.
Why it matters: A retrieval system reading the HTML sees the document in source order, not visual order. Interleaved navigation splits what a human reads as one coherent section into fragments separated by boilerplate, which is why the marketing pages score 0.25 to 0.45 on passage extractability against 0.80 for the blog. Even after the thin-content fix, added copy will be fragmented the same way unless the source order is corrected.
Recommended fix: Have engineering review the Makeswift page templates so the DOM order matches reading order: header first, then each section as a contiguous block with its heading immediately followed by its copy, then the footer. Use semantic landmarks (<header>, <main>, <section>, <footer>) so boilerplate is separable from body content. Verify by curling the page and reading the extracted text top to bottom — it should read like the page looks.
What we found: U+FEFF (zero-width no-break space) appears inside heading text on 16 of the 50 pages and in body text on 20 — for example the H1 "Define and Manage Plans & Limits" on /products/plans-entitlements, "Unlock monetization as a growth lever" on the homepage, and "Testimonials" on /testimonials. On the /use-cases pages the character also appears in runs between table cells, producing sequences such as "Real-time usage metering" followed by three consecutive invisible characters. These are CMS editor artifacts from the Makeswift rich-text fields.
Why it matters: The characters are invisible to a human reader but land inside the extracted string a crawler stores. They break exact-match comparison between a heading and a query, and they show up inside any passage quoted from these pages. The impact is small on its own but it degrades every other structural improvement made to these same pages.
Recommended fix: Run a one-time strip of U+FEFF (and U+200B if present) across Makeswift rich-text content, and add a save-time filter in the CMS or a build-time check so the characters do not reappear.
What we found: https://schematichq.com/sitemap.xml lists 309 URLs. All 309 carry <priority>0.75</priority> and 308 carry <changefreq>hourly</changefreq>, while the actual lastmod values on those same URLs range from 2024-06-11 to today. The sitemap also lists non-commercial URLs alongside product pages: seven /authors/* pages, five open job postings (/founding-account-executive, /staff-engineer-*), /waiting-room, /roadmap-v0, /poc, /papareact and /lp/wtp-download. The docs subdomain publishes its own sitemap at https://docs.schematichq.com/sitemap.xml, which is correctly referenced from the docs robots.txt but is not linked from the main sitemap.
Why it matters: Uniform priority tells a crawler nothing about which of 309 URLs matter, and a changefreq of "hourly" on a page last touched in June 2024 is a signal a crawler learns to ignore. Mixing job postings and author stubs into the same flat list dilutes crawl budget away from the product, use-case and comparison pages that carry commercial value. The lastmod values, by contrast, are accurate and should be doing the work here.
Recommended fix: Drop changefreq entirely and let the accurate lastmod values speak, or set it per section (daily for /blog, monthly for /products and /pricing, yearly for policy pages). Differentiate priority — 1.0 for the homepage and /products/*, 0.8 for /pricing, use cases and comparison content, 0.3 or lower for author, careers and utility pages, or exclude those from the sitemap. Add a sitemap index at the root that references both the marketing sitemap and https://docs.schematichq.com/sitemap.xml.
The following item could not be assessed through our analysis method (rendered markdown). We recommend your engineering team verify it manually before the validation call.
What to check: Primary body copy and headings are present in the server-rendered HTML on every page we fetched, so the site is not client-side rendered in the ordinary sense — this is good, and it is why the content scores in this analysis are meaningful. But several high-value regions are React components whose fully hydrated state we could not observe without a browser: the interactive pricing table and portal builder on /products/billing-components, the SDK code-sample tabs on /developers (only the React sample is in the initial HTML), the emoji-based capability comparison tables on the /use-cases pages, and the JSON-LD injection described above. We also could not confirm whether Google or any AI crawler executes that injection. If a comparison table or a code sample only exists after hydration, it is invisible to any retrieval agent that does not run a headless browser — and the /use-cases comparison tables are the only first-party head-to-head content on the site.
Recommended action: Load each of the four page types in a browser with JavaScript disabled and note what disappears. Run the pages through Google's Rich Results Test and the URL Inspection tool's rendered-HTML view to confirm whether the injected JSON-LD is picked up. Crawl the site with Screaming Frog in both raw-HTML and JavaScript-rendering modes and diff word counts per URL — any large gap marks a region that needs to be server-rendered.
Partial Sample This analysis covered 50 pages — the commercially relevant marketing, product, use-case, case study, blog and docs templates — out of 309 URLs in the sitemap. The findings are template-level, and the affected-scope counts reflect the full templates; but page-level counts (for example "20 pages contain U+FEFF") are counts within the 50-page sample, not across the whole site. Three structural/reference pages returned no detectable date and are excluded from the freshness averages.
Why Now
The full audit measures how AI assistants answer the questions your buyers actually ask in the runtime entitlements and monetization category — from problem-stage phrasings like "our pricing is hard-coded and every plan change needs a deploy" and "how do we sell credits for an AI product without building a ledger", to head-to-head phrasings like "Stigg vs Schematic" and "Chargebee alternatives for feature entitlements". You'll see exactly which of those queries return answers that name Stigg, Metronome, Orb, Chargebee or Stripe but not Schematic — and what specifically it would take to appear in them. Fixing the Layer 1 findings now means the audit measures a baseline you've already improved rather than one you'll wish you had.
45–60 minutes. We walk through this document together, settle the open questions in the Pre-Call Checklist, and lock the inputs the query set is built from.
We generate buyer queries from the validated personas, competitors, features and pain points, then run them across the selected AI platforms and capture every response.
Visibility analysis, competitive positioning against the primary set, and a three-layer action plan prioritized by which gaps actually cost you citations.
Start Now — Engineering Three Layer 1 items your engineering team can begin before the validation call. (1) Server-render the JSON-LD — move the existing schema out of next/script and into the server-rendered tree so it appears in the initial HTML; the markup is already written, and this is the single change that moves schema coverage off 0.00. (2) Fix the H1 structure — promote the leading question to H1 on the eight /use-cases pages and /developers, and demote the duplicate "Start using Schematic for free" H1 on /testimonials and /roadmap; these are Makeswift template edits, not eleven separate page edits. (3) Run the JavaScript-dependency verification — load /products/billing-components, /developers and a /use-cases page with JavaScript disabled, and check the injected JSON-LD in Google's URL Inspection rendered-HTML view; it's under a day, and it tells you whether the /use-cases comparison tables are a schema problem or a rendering problem. Two further sub-day items — stripping the U+FEFF characters and differentiating sitemap priority — fit in the same sprint. None of these depend on the rest of the audit, and they will improve your baseline visibility before we even measure it. One thing you do not need to chase: robots.txt is confirmed open to GPTBot, ClaudeBot, PerplexityBot, ChatGPT-User, Google-Extended, Googlebot and Bytespider, and both hosts serve a live llms.txt — that setup is worth preserving as the site changes.
Two jobs before we meet. The questions on the left require your judgment — no one knows your business better than you. The engineering tasks on the right don't require the call at all.
next/script