Cloud SOP and knowledge-base software for dental practices is a narrow enough category that the shortlist an AI assistant returns is being formed right now by a handful of vendors — companies that establish visibility while that list is still forming lock in a structural advantage before the market catches up. 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 Flomo'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 name Flomo in dental SOP and knowledge-base software conversations, three signals tell us whether those systems can reach and read useflomo.com at all. All three are derived mechanically from the July 30, 2026 crawl — no interpretation, no softening.
Dental practice owners and office managers are increasingly starting vendor research inside an AI assistant rather than a search box — 87% of B2B software buyers say AI chatbots are changing how they research vendors, and half now begin in a chatbot rather than Google (G2, October 2025). In a category this narrow, that shift matters more than it does in a crowded market: when an assistant is asked what a dental office should use to organize its procedures, it returns a short list of names, and early citations compound as platforms accumulate evidence about which domains to trust. Flomo enters that window as a startup with a focused, dental-native product and almost no public footprint to draw on — a disadvantage today, and an opening if it moves before the category's shortlist hardens.
This document contains three things we need you to check. The competitive set determines which vendors we test Flomo against head-to-head and which we treat as category context. The buyer personas determine whose search intent we model — a practice owner, an office manager and a compliance lead do not phrase the same problem the same way, and each phrasing produces a different query cluster. The technical baseline determines whether AI platforms can access and read useflomo.com at all, which is a precondition for everything else. This is what we're validating together before the audit runs.
The validation call is a working session with real consequences, not a walkthrough. Two kinds of decisions come out of it. First, input validation: are the right entities in the right tiers, and are the ones we flagged as uncertain actually real? Your answers set the buyer query set we run across the selected AI platforms, and a wrong tier or a phantom persona spends query budget on conversations your buyers never have. Second, engineering triage: which technical work starts immediately rather than waiting for results to come back. The specific items for both are in the Pre-Call Checklist near the end of this document.
llm_inference entity in the knowledge graph, and nothing in Flomo's own material puts an external IT advisor in the buying committee; if he isn't consulted, we drop the vendor-security and BAA query cluster and reweight toward the office manager.Three things worth knowing before you read the rest of this document.
What This Is This is the knowledge graph the audit will run against. Everything downstream — the buyer queries we generate, the competitors we test head-to-head, the language we phrase prompts in — is derived from the personas, competitors, capabilities and pain points on these pages. It was built outside-in for the cloud SOP and knowledge-base category in dentistry: from Flomo's own product surface, competitor positioning and category listings, without access to your CRM or win/loss records. In Flomo's case there is one additional constraint worth stating plainly — there is no review corpus to draw on. Flomo has no G2, Capterra, Gartner or TrustRadius listing, so nothing here is sourced from customers describing you in public. And because useflomo.com serves no readable HTML, the product detail in this document was reconstructed by parsing the site's JavaScript bundle directly. That is more than an AI system can see today, which is useful information in itself. It also means you know things we cannot.
What We Need From You Read the purple boxes. Each one names a specific entity we are uncertain about and states what changes in the audit if our reading is wrong. You do not need to review every card in detail — the purple questions are where your answer actually moves something. Everything else is here so you can check our work if you want to. The Pre-Call Checklist near the end collects every question in one printable list.
Confidence Badges Every entity carries a confidence badge. High means it came straight from a primary source — Flomo's own product and pages, or a competitor's published positioning. Medium means we triangulated it from more than one indirect signal. Low means we inferred it and are asking you to confirm or kill it. Low-confidence items are not filler; they are the specific places where your judgment beats our research.
This profile anchors every query we generate — the category phrasing in particular determines how a buyer's question gets worded before it is ever asked.
→ Question The name "Flomo" currently resolves publicly to at least three unrelated entities — the flomo / flomoapp note-taking app, which dominates every search for the bare term; FloMo Dental, an unrelated practice in Flower Mound, TX, which is the dangerous one because it is also dental; and FLOMO USA, a party-goods wholesaler. Your own og:title reinforces the confusion by shipping the internal project slug "flomo-sop-flow" on every page. Should the audit count only useflomo.com as you, and which spellings do your buyers actually type or say — "Flomo", "FloMo", "Flomo SOP"? Whatever rule we agree becomes the entity-normalization rule in Step 6, and without it the audit will either credit you for a note-taking app's citations or miss real mentions written as "FloMo".
5 personas: 3 decision-makers with veto power and 2 high-influence evaluators — and each one phrases the same dental SOP problem differently, which is what produces distinct query clusters.
Critical Review Area Personas drive the query set more directly than anything else in this document — if a persona is wrong, every query we write in their voice is wasted budget. One pattern is worth your attention up front: three of these five personas carry veto power. That is a high concentration. In most deals at this price point there is one person who can actually kill the purchase, and if that person is the owner dentist alone, the compliance and IT-security query clusters shrink considerably.
Data Sourcing Note Role, department, seniority, influence level, veto power and technical level come straight from the knowledge graph. The role descriptions, buying jobs and query focus areas below are synthesized — we inferred them from the role and the product surface, not from a stated source. Confidence badges reflect the knowledge graph's provenance on the persona itself: four came from Flomo's own product and category research, one (Owen Castellanos) is an inference we are explicitly asking you to confirm or kill.
→ Dr. Ellery is rated technical level low yet holds the only clear budget veto — does he personally evaluate tools, or does he approve what the office manager brings him? If he only approves, we drop feature-comparison queries at his altitude and phrase his cluster around cost, staff turnover and regulatory risk instead.
→ Renata carries the highest evaluation load of any persona but the knowledge graph gives her no veto — at $249/mo, does she buy on her own authority, or does every purchase route through Dr. Ellery? If she can buy, we promote her to decision-maker and the majority of the query set shifts to her phrasing rather than his.
→ This persona was inferred from the multi-location screens in your application rather than from any customer you've named — is the DSO or multi-location group a segment you sell to today, or a roadmap ambition? If it's roadmap, we cut the multi-location query cluster entirely and My Dental SOP, which sells explicitly to DSOs and dental consultants, drops in head-to-head weight.
→ Tasha is the only persona with veto power but merely medium influence — an unusual pairing. Does she actually block a purchase over missing attestation records, or does she simply inherit whatever the practice buys? If she blocks, compliance queries land directly on Flomo's one weak-rated capability and become a defensive priority in the audit rather than a secondary cluster.
→ This is the only llm_inference persona in the knowledge graph — does an outside IT or technology consultant actually get a say in your customers' purchases, enough to block one over security or a BAA? If not, we delete the vendor-security query cluster and reallocate that budget to Renata Diaz, who drives most of the evaluation.
→ Missing Personas? Three roles sometimes appear in dental SOP and practice-operations deals — do they show up in yours? The dental practice consultant or coach (My Dental SOP sells directly to consultants, which suggests they may recommend or resell systems into their client practices — if so, they're a distinct query audience with distinct language). The lead hygienist or clinical director (if sterilization and clinical protocol content is owned separately from front-office procedure, that's a different search intent than Tasha's compliance framing). The front-office lead or treatment coordinator (if insurance verification and scheduling procedure is where the pain actually starts, the entry query changes shape). Who else shows up in your deals?
6 primary + 5 secondary competitors identified, spanning dental-native SOP platforms, horizontal process tools, and the compliance vendors that already own the binder.
Why Tiers Matter Tier assignment decides where query budget goes. Primary competitors get head-to-head treatment — queries like "SOP software for a dental office", "best dental SOP software" and "Trainual alternatives for a dental practice" — at roughly 6–8 queries per pairing, so six primaries commit approximately 36–48 queries to direct competitive differentiation. Secondaries are tested for category awareness only. Three of the six primaries carry medium confidence on that assignment: SweetProcess, Whale and Process Street were tiered from category listings and "SOP software" search behaviour rather than from your deals. If they rarely come up in practice, moving them to secondary frees roughly 18–24 queries to deepen the head-to-head against SOPHIE AI and My Dental SOP, the only two dental-native competitors in the set.
→ Question Six primaries is a wide head-to-head set for a category this narrow, and three of them — SweetProcess, Whale and Process Street — were tiered primary because dental buyers demonstrably reach them through "SOP software" and "Trainual alternatives" searches, not because we've seen them in your deals. Which of the six actually get named in your sales conversations, and does anyone come up who isn't on this list at all? If only SOPHIE AI, My Dental SOP and Trainual are real, the other three drop to secondary and roughly 18–24 queries reallocate to deeper differentiation against the dental-native two. Separately: is any vendor here irrelevant enough that testing against it wastes budget? Abyde and Gamma Compliance Solutions compete for the same budget line rather than on features — if practices don't actually treat that as an either/or, they should come out.
12 buyer-level capabilities mapped — 6 strong, 3 moderate, 1 weak, 2 absent — and these ratings determine which capability queries the audit tests and where it probes for weakness.
Give me ready-made dental SOPs I can edit instead of writing every procedure from scratch — clinical, front desk, OSHA, HR and financial
Let a non-technical office manager write a step-by-step procedure, a daily checklist, a training guide or a reference doc in a couple of minutes, with photos and video
Organize everything the office knows into libraries and folders so procedures actually have a home instead of living in twelve places
Make sure the front desk sees front desk procedures and only managers see HR and payroll documents
Change a policy, a medication or a departed employee's name everywhere at once instead of editing forty documents by hand
One predictable price for the whole office — don't charge me per seat or hit me with a setup fee just to add my hygienists
Assign procedures to a new hire and see who has actually read and completed them, not just who I told
Let anyone on the team find the right procedure in seconds during a patient visit instead of interrupting the manager
Roll one standard out to every office while still letting each location keep what is genuinely different about it
When an inspector walks in, prove every staff member was trained on the current policy and show me the dated record
Describe a procedure in a sentence and have the software draft the SOP for me, then let me correct it
Connect to Dentrix, Open Dental or Eaglesoft and push reminders into the tools my team already has open all day
Which Three Do We Lead With? Six of the twelve capabilities are rated strong. The audit tests all 12, but competitive differentiation queries will emphasize 3. Our proposed picks — chosen because they are the strong capabilities linked to the most high-severity buyer pains in the knowledge graph — are marked below, but this is your call, not ours:
Which of these best represents where Flomo actually wins deals?
→ Question Every one of these twelve ratings was derived from Flomo's own product surface with no customer review corpus anywhere — no G2, no Capterra, no third party describing what you're good at — which makes the six "strong" ratings the least externally corroborated claims in this document. Two specific challenges. Is Bulk Search & Replace genuinely a differentiator buyers name, or a feature you like that they never ask about? And is OSHA / HIPAA Compliance Evidence really weak — we rated it that way on the absence of a compliance calendar, attestation reporting and risk assessment relative to My Dental SOP, Abyde and Gamma Compliance, but if you have evidence workflows we couldn't see from outside, we're setting the audit up to probe a weakness that doesn't exist. Also: is anything missing from this list, and should Global Search & Findability and Library & Folder Organization be merged, since a buyer asking "can my team find the right procedure fast" is asking about both at once?
→ Question Flomo AI and Flomo Marketplace both render in-app as "Coming Soon", so we rated AI-assisted SOP generation absent — while SOPHIE AI and Whale both lead with AI drafting. Will Flomo AI ship during the audit window, or is it more than a quarter out? If it ships mid-audit, the "absent" rating and every query we write to probe where you lose that comparison goes stale on delivery; if it's further out, we treat it as a durable gap and test how competitors exploit it.
12 pain points: 8 high and 4 medium severity — and the buyer language below is literally how the audit's queries get phrased, so if it doesn't sound like your customers, the queries won't either.
Practice knowledge lives in the heads of a few long-tenured staff; when the office manager or lead assistant leaves, the process leaves with them.
Onboarding is done by shadowing whoever is free, so every new hire learns a slightly different version of the job while productive staff lose chair time training them.
SOPs exist but sit in a three-ring binder or an unstructured shared drive that staff never open at the moment they need an answer.
Procedures go out of date the moment a policy, insurance contract, product or staff member changes, and updating them means opening every affected document by hand.
The practice cannot produce dated evidence that each staff member was trained on the current OSHA or HIPAA policy, turning an inspection or audit into a fire drill.
In a multi-site group each office has drifted into its own version of the same process, so quality and patient experience vary by location and nothing rolls up.
The office manager already runs scheduling, billing and staffing; writing a hundred procedures from a blank page never reaches the top of the list, so SOP projects stall after two weeks.
Horizontal SOP tools ship as an empty workspace with no clinical, OSHA or front-desk content, so a dental team has to invent the entire taxonomy before the tool does anything — and abandons it.
SOP and training platforms price per seat and add onboarding or setup fees, so a fourteen-person practice pays more to include the very hygienists and assistants the content is written for.
Documents kept in a shared drive expose HR, payroll and financial material to the whole team because folder permissions are never maintained.
Procedures live in a separate system nobody opens during a clinical day, so the tool becomes an archive rather than something used at the moment of work.
Practice documentation references patient workflows and staff records, so the buying committee's IT advisor must vet the vendor's security posture and willingness to sign a BAA before anything is uploaded.
→ Question Eight of these twelve are rated high severity and none is rated low — a distribution that flattens prioritization, because if everything is urgent the audit has no basis for choosing what to test first. Which three of the eight actually close deals for you? We'd expect "no time to write SOPs from a blank page" and "generic tools don't fit dentistry" to be the real entry wedges given your template library, but that's inference, not evidence. Second: does the buyer language ring true — would a practice owner really say "three months to get them useful", or is the ramp shorter and the number wrong? We phrase queries in exactly these words, so a number that's off makes the query sound like a vendor wrote it. Third, three dental-specific pains we did not include — do they belong? Insurance verification and claims-process drift causing write-offs (if the money leak is what triggers the SOP project, that's a different entry query entirely); state dental board inspection prep (distinct from OSHA and HIPAA, and state-specific); and absorbing an acquired practice's procedures (if DSO buyers arrive through acquisition integration rather than standardization, Priya Raghunathan's query cluster changes shape).
12 findings from the July 30, 2026 analysis of all 6 public routes — 1 critical, 3 high, 5 medium, 3 low. These are technical and structural items your engineering team can act on now; nothing here waits on the audit.
Engineering — Start Immediately One finding gates everything else, and engineering should start on it this week: every URL on useflomo.com returns the same 1,479-byte JavaScript shell, so a content-extracting fetch of the homepage returns exactly one word — "Flomo". The good news is that this is not an access problem. robots.txt exists and explicitly allows GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, Google-Extended, Googlebot and Bytespider; nothing is being blocked. The content simply isn't in the response. Three items are worth starting in parallel because they are small and independent: publish a real XML sitemap and configure nginx to serve /sitemap.xml and /robots.txt from disk before the SPA catch-all rewrite (today /sitemap.xml answers 200 with HTML, as does every alternate location we tested); return genuine 404 status codes on unmatched paths instead of 200 for every URL ever requested; and replace the placeholder scaffold meta tags — a title of "Flomo", a description of "Softmind sol Generated Project", an author of "Lovable" and an og:title of "flomo-sop-flow", identical on all six routes. None of these require anything from the validation call.
What we found: useflomo.com is a client-side-rendered React single-page application built on the Lovable scaffold. Every URL on the domain — the homepage, /pricing, /terms-and-conditions, /registration, /login, and any nonexistent path — returns byte-for-byte identical HTML: 1,479 bytes containing an empty div with id="root", a module script reference to /assets/index-BPkauV8u.js, and a stylesheet link. There is no noscript fallback and no server-side or pre-rendered content of any kind. We confirmed this two ways: a direct HTTP fetch of the raw HTML source, and a content-extracting fetch of the homepage, which returned exactly one word of readable text — "Flomo". The actual site content (the hero, six feature cards, a twelve-item FAQ, the founders' story, a 1,050-word bylined article, two customer testimonials, and the pricing table) exists only inside the JavaScript bundle and is assembled in the browser after execution.
Why it matters: The AI crawlers that build answer engines do not execute JavaScript. GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot, and Bytespider fetch raw HTML and index what the server returns. For useflomo.com that is a single word. This means 100% of Flomo's marketing content — every product claim, every FAQ answer, the entire pricing model, the founder credibility story — is invisible to ChatGPT, Claude, and Perplexity, regardless of how good that content is. robots.txt allows every crawler, so nothing is being deliberately blocked; the content simply is not there to read. This is the single highest-leverage issue on the site, and it is consistent with useflomo.com having essentially no presence in AI answers: a web search for the exact domain returns the unrelated flomo note-taking app, FLOMO USA party supplies, and a FloMo dental practice, but not this site. Every other recommendation in this audit is gated behind fixing this one.
Recommended fix: Serve HTML that already contains the page content. In order of preference: (1) migrate the marketing surface to a server-rendered or statically generated framework (Next.js, Astro, Remix) so the homepage and pricing page ship complete HTML; (2) if the React app must stay as-is, put a prerendering layer in front of it (Prerender.io, a hosting platform's prerendering feature, or a headless-Chrome render cache in the existing nginx layer) that serves fully rendered HTML to crawler user-agents; (3) as an interim stopgap that can ship in a day, hand-author a static HTML version of the homepage content — hero, features, FAQ, pricing, founders — and serve it as the server response with the React app hydrating over it. Option 3 alone would take Flomo from zero indexable words to a few thousand.
What we found: https://useflomo.com/sitemap.xml returns HTTP 200 with Content-Type: text/html and the same 1,479-byte application shell served at every other path. It is not an XML sitemap and it is not a 404. We tested the common alternate locations — /sitemap_index.xml, /sitemap-index.xml, /sitemap_1.xml, /page-sitemap.xml — and every one returns the same HTML shell with a 200 status. robots.txt contains no Sitemap: directive. There is also no /llms.txt; it too returns the shell with a 200.
Why it matters: A sitemap is how a crawler learns which URLs exist and when each one last changed, and it is the primary discovery mechanism for a site that has no external inbound link graph. Because the SPA catch-all intercepts the request and answers 200 with HTML, a crawler does not learn that the sitemap is absent — it receives what looks like a valid response containing no URLs, which can be cached as a successful fetch. Combined with the client-side rendering issue, useflomo.com currently gives crawlers no path to discover any URL beyond the homepage: no sitemap, no server-rendered internal links, and no meaningful external link graph.
Recommended fix: Add a real XML sitemap served with Content-Type: application/xml, listing the public routes (/, /pricing, /terms-and-conditions, /registration, /login) with accurate lastmod values, and exclude authenticated application routes. Configure nginx to serve /sitemap.xml and /robots.txt from disk before the SPA catch-all rewrite so the fallback cannot shadow them. Add a Sitemap: https://useflomo.com/sitemap.xml line to robots.txt. Once the content surface grows, regenerate the sitemap at build time rather than by hand.
What we found: The server rewrites every unmatched path to index.html with a 200 status. We requested https://useflomo.com/this-page-does-not-exist-xyz and received HTTP 200 with the standard 1,479-byte shell — identical to the homepage response, down to the byte count and the Last-Modified header. The React router does define a catch-all NotFound component, but that only changes what a browser displays after JavaScript runs; the HTTP status code sent to crawlers is 200 for every URL that has ever been requested, valid or not.
Why it matters: Search and AI crawlers rely on the 404 status to prune their index and to stop re-fetching dead URLs. When every path answers 200, a crawler has no way to distinguish a real page from a typo, a stale link, or a probe. This wastes crawl budget on a site that has very little content to begin with, and it means Flomo can never signal that a page has been removed. It also compounds the missing-sitemap problem: a crawler that guesses at URLs gets positive confirmation for all of them.
Recommended fix: Maintain an explicit allowlist of valid public routes in the nginx configuration. Serve index.html with a 200 for those paths only; return a genuine 404 status for everything else. If the SPA must own routing, have the server render the NotFound response with an HTTP 404 status code rather than 200. Verify with a HEAD request to an invalid path that the response line reads 404.
What we found: We read the raw HTML source directly. Every URL on the domain serves the same head block, containing: a title of "Flomo"; a meta description of "Softmind sol Generated Project"; a meta author of "Lovable"; and an og:title of "flomo-sop-flow". The remaining Open Graph and Twitter Card tags (og:description, og:type, og:image, twitter:card, twitter:site, twitter:image) are present but commented out in the markup, so they are never emitted. There is no canonical link, no meta robots directive, and no per-route metadata: we searched the full 3.98 MB JavaScript bundle and found no react-helmet or equivalent head-management library, only four bare document.title assignments that run client-side and are therefore invisible to non-executing crawlers.
Why it matters: The title and meta description are the two strongest server-visible signals of what a page is about, and on this site they say nothing about dental practices, SOPs, or software — they say "Flomo" and "Softmind sol Generated Project", which is leftover build-tool boilerplate. The og:title of "flomo-sop-flow" is the internal project slug. This actively worsens the brand-collision problem the knowledge graph flagged as its highest-priority item: when a model or a search engine has only the word "Flomo" and a generic placeholder description to work with, it has no signal to distinguish this company from the flomo note-taking app or FLOMO USA. Because all six public URLs emit identical tags, nothing differentiates the pricing page from the login page either. The commented-out OG tags also mean every link shared to Slack, LinkedIn, or iMessage renders without a preview image or description — a direct loss on the referral channel a founder-led startup depends on.
Recommended fix: Replace the scaffold defaults with real, per-route metadata. At minimum, set the homepage title to something that carries the category and the buyer language — for example "Flomo — SOP and Knowledge Base Software for Dental Practices" — and write a meta description that names the product, the audience, and the price. Remove the Lovable author tag and the flomo-sop-flow og:title. Uncomment and populate the Open Graph and Twitter tags with a real og:image. Add a self-referencing canonical to each route. Because these tags must be visible without JavaScript, emit them server-side as part of the rendering fix above; a client-side head manager will not solve this for AI crawlers.
What we found: We searched the raw HTML of every public route and the full JavaScript bundle plus all lazy-loaded chunks for JSON-LD. There are zero occurrences of application/ld+json and zero occurrences of @context. No Organization, SoftwareApplication, Product, Offer, FAQPage, or Article markup exists, and none is injected client-side. This is a definitive absence rather than an unassessed signal — we inspected the served source and the shipped JavaScript directly rather than a rendered approximation.
Why it matters: Structured data is how a machine reads a page without having to interpret prose: it states unambiguously that this is a software product, that it costs $249 per month, that the organization is called Flomo, and that these twelve questions have these twelve answers. Flomo is leaving unusually easy wins on the table here. The homepage already contains a well-formed twelve-question FAQ — exactly the content FAQPage markup exists to describe, and exactly the kind of question-and-answer pair AI answer engines cite. It also has a single clearly priced offer, two attributed testimonials, and a bylined article, all of which map cleanly onto standard schema types with no new writing required. Organization markup with a sameAs list is also the most direct technical lever available against the brand-name collision, because it lets Flomo assert its own identity rather than leaving models to guess which Flomo is meant.
Recommended fix: Add JSON-LD to the server-rendered HTML, in priority order: (1) Organization on every page, with name, url, logo, description, foundingDate, founders, and a sameAs array pointing at Flomo's real social and directory profiles — this is the entity-disambiguation lever; (2) FAQPage on the homepage covering all twelve existing Q&A pairs, which needs no new content at all; (3) SoftwareApplication with applicationCategory and an Offer carrying the current price and currency; (4) Article with author, headline, and datePublished on the Dentaltown onboarding piece once it has its own URL. Validate with Google's Rich Results Test and the Schema.org validator.
What we found: Reconstructing the homepage's heading tree from the component source, we found three issues. First, the single H1 is "Helping Dentists Thrive With Less Stress." — a brand slogan that contains no product noun, no category, and no searchable capability language; the words SOP, software, knowledge base, and platform appear nowhere in it. Second, the pricing section inverts its heading levels: an H3 reading "PRICING" is rendered above the section's H2 ("Get Started, First Month Free. Cancel anytime."), so the outline nests a level-3 heading above a level-2. Third, two section headings are bare all-caps single words used as visual labels rather than descriptive phrases — "FEATURES" and "PRICING" — which carry no standalone meaning when read out of context. The FAQ section is the counter-example and is well built: twelve H3s, each a complete natural-language question.
Why it matters: Headings are the labels an extraction system uses to decide what a passage is about and whether it answers a given question. An H1 is weighted most heavily of all, and Flomo's spends that weight on an emotional promise rather than on the thing a buyer would search for. When someone asks a model for "SOP software for a dental office", nothing in Flomo's most prominent heading matches the request. The inverted H3-above-H2 breaks the document outline, and single-word labels like "FEATURES" give a passage extractor nothing to anchor on. This matters more than usual here because the homepage is the entire commercial surface of the site — there are no other pages to carry the category language.
Recommended fix: Rewrite the H1 so it names the product and the category while keeping the brand voice — for example "SOP Software Built for Dental Practices", with the existing slogan demoted to the supporting paragraph directly beneath it. Fix the pricing section so "PRICING" is either styled text or an H2 with the offer line as an H3 beneath it, restoring a monotonic outline. Replace "FEATURES" with a descriptive H2 such as "What Flomo Does for Your Practice". Keep the FAQ structure exactly as it is — it is the strongest part of the page. Note that none of this becomes visible to AI crawlers until the rendering fix ships.
What we found: Five of the six public pages score below 0.4 on content depth: /pricing at 0.25, /terms-and-conditions at 0.15, /registration at 0.15, /login at 0.10, and /forgot-password at 0.05. Only the homepage clears the threshold, at 0.65. Within the homepage, the features section — the closest thing Flomo has to product documentation — devotes exactly one sentence to each of its six capabilities; the entire treatment of Quick-Swap, for instance, is "Update a protocol once and automatically push changes to every manual and checklist instantly." The publicly routable /pricing screen is an in-application Stripe plan selector carrying four bullet fragments ("Unlimited SOPs & Articles", "Unlimited Users", "Multi-Tenant Workspaces", "24/7 Support") rather than a marketing pricing page. /terms-and-conditions is roughly 51 words of beta-programme housekeeping, not terms of service.
Why it matters: A one-sentence feature blurb is too short to be cited. An answer engine asked how a tool handles updating a procedure across an entire library needs a passage it can quote that explains the mechanism, the scope, and the constraint; "update once, push everywhere" is a claim with no substance behind it, and it is indistinguishable from what every competitor says. Because Flomo's entire commercial surface is two pages, there is no deeper page for a crawler to fall through to — the shallow treatment is the only treatment. This is a large part of what separates Flomo from competitors like Trainual and My Dental SOP, whose feature depth gives models something concrete to quote.
Recommended fix: Give each of the six existing feature claims a real body — the mechanism, a concrete dental example, and the limitation. Build a genuine public pricing page that explains what per-office pricing means for a fourteen-person practice, rather than exposing the in-app Stripe selector at /pricing. Replace the beta note at /terms-and-conditions with actual terms of service and move the beta agreement into the signup flow where it belongs. Sequence this after the rendering fix — deepening content that no crawler can read produces no visibility gain.
What we found: The single entry bundle at /assets/index-BPkauV8u.js is 3.98 MB uncompressed and 1.31 MB gzipped. It must download, parse, and execute before any content appears. The homepage's own content then arrives in a second request for a separate lazy-loaded chunk. The bundle carries the full application — Stripe Elements, html2canvas, DOMPurify, the authenticated dashboard, library management, and user administration — on the same critical path as the public marketing page, with no split between the marketing surface and the product.
Why it matters: Googlebot does execute JavaScript, but it does so on a deferred rendering queue with a finite time and resource budget per page. A multi-megabyte bundle followed by a second round-trip for the actual content makes a page an expensive render, and expensive renders get deprioritised or time out — a second, independent way for this content to go unindexed even by the crawlers that could in principle read it. It also makes the page slow for the human buyers who arrive from an AI answer, and page experience signals feed back into search ranking.
Recommended fix: Split the marketing surface from the application so that / and /pricing load only the code they need — ideally by moving the marketing pages to a separate statically generated build served from the same domain. Within the app, defer Stripe, html2canvas, and the dashboard behind route-level code splitting so they are never fetched by an anonymous visitor. Run a bundle analyser to find the largest contributors; a marketing page that ships under 200 KB of JavaScript is a reasonable target. If the rendering fix in the critical finding is implemented as static generation, this issue largely resolves alongside it.
What we found: Every page's HTML body ends with a module script loaded from an external development-platform CDN (cdn.gpteng.co/gptengineer.js), preceded by a source comment instructing that the tag not be removed. This is scaffolding from the tool the site was generated with, not an application dependency. The same head block also still carries the generator's author meta tag.
Why it matters: This is a low-severity hygiene item rather than a visibility blocker. It adds a third-party request and a third-party origin to every page load, which is a small performance and supply-chain consideration, and it is a visible signal to any technically literate visitor — including the IT advisor persona in the knowledge graph, who has veto power over vendor selection — that the site is running unmodified low-code scaffolding. For a vendor asking dental practices to trust it with their operational documentation, that reads as less mature than the product actually is.
Recommended fix: Remove the gptengineer.js script tag and the Lovable author meta tag from the production build. Confirm the application still builds and runs, since this tag is only required by the authoring environment, not at runtime. Fold this into the same change as the meta tag cleanup.
What we found: https://useflomo.com/llms.txt returns HTTP 200 with the SPA HTML shell rather than a plaintext file — the same catch-all behaviour described in the soft-404 finding. No llms.txt exists.
Why it matters: llms.txt is an emerging convention for giving AI systems a curated, plaintext map of a site's most important content and a short statement of what the company does. Adoption is not yet universal and this is a best-practice gap rather than a blocker, which is why it is scored low. For Flomo specifically it carries slightly more value than it would for most sites, because a short plaintext file naming the company, the category, and the distinction from the unrelated flomo note-taking app is a cheap, direct way to assert entity identity — and unlike the rest of the site, a plaintext file requires no JavaScript to read.
Recommended fix: Once the sitemap serving order is fixed so static files are not shadowed by the SPA catch-all, add a short /llms.txt served as text/plain: one paragraph naming Flomo as SOP and knowledge-base software for dental practices, an explicit disambiguation from the similarly named note-taking app, and a linked list of the public pages with one-line descriptions. Keep it under a page. Sequence this after the rendering and sitemap fixes, not before.
The following items could not be assessed through our analysis method (rendered markdown). We recommend your engineering team verify these manually before the validation call.
What to check: The login flow in the JavaScript bundle constructs post-authentication redirects of the form https://{subdomain}.useflomo.com/dashboard, and the application persists a list of customer workspaces keyed by subdomain. This indicates each customer practice is provisioned its own subdomain of useflomo.com. We could not test a live tenant subdomain, because doing so requires customer credentials that are outside the scope of this analysis. What we can state is that the robots.txt we retrieved is served from the apex host only, and a robots.txt at the apex does not govern a subdomain — each host must serve its own. If tenant subdomains allow crawling or serve no robots.txt, customer practice workspaces are crawlable hosts under the Flomo brand; that is a client-confidentiality concern before it is an SEO one.
Recommended action: Verify what a tenant host returns at /robots.txt. Serve a robots.txt from every tenant subdomain that disallows all crawling, and add an X-Robots-Tag: noindex, nofollow HTTP response header on all tenant subdomain responses so the policy holds even if robots.txt is missed. Confirm no tenant subdomain is referenced from any public page or sitemap. This is a short check that either closes cleanly or surfaces something worth fixing immediately.
What to check: Because the site serves no content in its HTML, we recovered the page content by downloading and parsing the JavaScript bundle and its lazy-loaded chunks rather than by reading rendered output. This gives us high confidence about what text and which heading levels the components declare, and it is how we established the heading tree, the FAQ content, the pricing figures, and the absence of structured data. It does not let us observe the final browser-rendered DOM, confirm that every declared section actually mounts, or detect content injected at runtime from an API rather than from the bundle.
Recommended action: Load https://useflomo.com in a browser and compare the rendered outline against this report using the accessibility tree or a heading-outline extension. Then load the same page with JavaScript disabled to see exactly what a non-rendering AI crawler receives — this is the single most useful demonstration of the critical finding and takes under a minute. Re-run both checks after the server-rendering fix ships, and add a build-time assertion that the server response body contains a known content string (for example "Frequently Asked Questions") as a regression test.
Read These Scores in Context Coverage is complete — all 6 public routes were analyzed and no metric has unscored pages, so these are not sampling artifacts. But 6 pages is the entire public surface, and 4 of those 6 are login, registration, password reset and a 51-word beta note. The averages above are therefore effectively describing two commercial pages, and each individual page carries roughly a sixth of every score. The freshness result in particular should be read as "the six pages that exist are current", not as evidence of an active content operation — the content-marketing category contains zero pages.
Why Now Four reasons the timing matters more than it looks:
The full audit measures how often Flomo is named across the buyer queries that actually matter in this category — "SOP software for a dental office", "something already written that I can adjust instead of writing procedures from scratch", "Trainual alternatives for a dental practice", "software that proves my team was trained on the current OSHA policy" — across the selected AI platforms. What you'll learn that you can't know today is exactly which of those queries return SOPHIE AI, My Dental SOP or Trainual and not Flomo, and what specifically it would take to appear in them. Fixing the Layer 1 rendering issues before the audit runs raises the baseline we measure against, so the results describe a site that can be read rather than one that can't.
45–60 minutes. We walk through this document together, resolve the open questions in the Pre-Call Checklist, and lock the inputs the audit runs against.
We generate buyer queries from the validated personas, competitors, capabilities and pain points, then run them across the selected AI platforms and capture every response.
Visibility analysis, competitive positioning against the confirmed set, and a three-layer action plan prioritized by which gaps actually cost you citations.
Start Now — Engineering Three technical items don't depend on the rest of the audit and will improve your baseline visibility before we even measure it. First, ship readable HTML. The full server-rendering migration is a 2–4 week project, but the interim option in the critical finding — a hand-authored static homepage that the React app hydrates over — can ship in a day and takes useflomo.com from one indexable word to a few thousand. Second, fix the nginx serving order and the status codes. Serve /robots.txt and /sitemap.xml from disk before the SPA catch-all rewrite, publish a real XML sitemap with a Sitemap: directive in robots.txt, and return genuine 404s on unmatched paths instead of 200. Both are under three days. Third, replace the scaffold metadata and add Organization JSON-LD with a sameAs list. The placeholder title, the "Softmind sol Generated Project" description and the "flomo-sop-flow" og:title are actively working against you on the brand-collision problem, and Organization markup is the most direct technical lever you have to assert which Flomo you are. While you're in there, verify what a tenant subdomain returns at /robots.txt — that check takes minutes and either closes cleanly or surfaces a client-confidentiality issue worth knowing about now. Crawler access itself is confirmed good: robots.txt allows all seven crawlers we test for, so none of this is an access problem.
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.