Why we kept our new CMS SEO engine client-side instead of burning LLM tokens
Hey Indie Hackers!
When users ask for "AI-powered SEO" in your software, the knee-jerk reaction is often to throw an LLM prompt behind every input field. But doing that for real-time content analysis introduces two major traps:
High API bills on every draft revision.
Noticeable keystroke latency inside the visual editor.
While shipping the latest milestone for NextBlock CMS, we took a deterministic approach:
AST Traversal Over LLMs: We analyze the live Tiptap JSON document tree in the browser debounced at 300ms. We calculate Flesch Reading Ease scores, sentence lengths, heading depths, and focus keyphrase density completely on the client side at zero cost.
Selective AI Execution: AI is strictly reserved for remediation. If a sentence is flagged as too dense or an image lacks accessibility context, the user clicks "Fix with Cortex AI" to resolve that specific node.
Integrated Technical Directives: We paired this with edge-executed 301/302 redirects in middleware and dynamic robots routing, so creators don't need a stack of third-party plugins just to handle basic crawl directives.
The result is instant feedback, privacy by default (data stays local until requested), and zero token overhead for standard writing sessions.
Check out the live sandbox and let us know what SEO metrics matter most in your workflow:
👉 https://nextblock.dev
We came to the same split from the extension side: deterministic filters run everywhere, the model only touches the final step. Moving detection out of the model flattened the cost curve and made the whole thing feel instant. Something you did not mention yet: deterministic scores are explainable, so users argue with them less. AI everywhere sounds great in marketing, but the products that feel fast treat AI as the exception handler, not the engine.