Table of Contents
AImpactScanner started with a simple question: what does AI actually see when it looks at your website? Not what Google sees — that's been well-understood for twenty years. What does ChatGPT see? What does Perplexity see? When an AI system evaluates your site for potential citation, what signals does it find, and which ones are missing?
Note, September 2026. This article was written while AImpactScanner was running. The tool was switched off in August 2026. The code is open at github.com/TheWayWithin/aimpactscanner-mvp under the MIT licence. The thinking in the article still stands.
The answer, for most sites, was: not much. And there was no tool that could tell them specifically what to fix. That's the gap AImpactScanner was built to fill.
The Gap We Set Out to Fill
When we started building AImpactScanner, the AI search optimisation landscape had a specific problem: diagnosis tools existed for traditional SEO (Google Search Console, Ahrefs, Semrush), but nothing existed for AI-specific visibility factors.
You could check whether Google could index your pages. You couldn't check whether ChatGPT could find, understand, and cite them. The factors that matter for AI citation — structured data quality, entity recognition, authorship signals, content architecture, llms.txt presence — weren't being evaluated by any mainstream tool.
The scanner drew 27 checks from the MASTERY-AI Framework, which today defines 149 atomic factors across 8 pillars in v3.2.0. The question was whether these factors could be automatically evaluated in a way that gave businesses actionable guidance — not just a score, but a specific roadmap for improvement.
Connecting Analysis to Action: llms.txt Integration
The first major milestone beyond basic scanning was llms.txt integration. After running an analysis, users could generate optimised llms.txt files directly from their scan results.
That connected two previously separate workflows. Before integration, the process was: scan your site with one tool, identify issues, then use a separate tool to generate your llms.txt file. The problem was that the llms.txt generator didn't know anything about your scan results. It generated files without context about which pages scored well for AI readability and which didn't.
With integrated generation, the llms.txt file reflected actual content quality. Pages that scored highly for AI citation potential were prioritised. Pages with structural issues were noted. The file became a curated guide rather than a URL dump, because the scanner had already evaluated every page against the full MASTERY-AI Framework.
The integration was built on LLM.txt Mastery's API, with custom Edge Functions handling the analysis, generation, and download workflow. The dashboard panel showed usage statistics, progress tracking, and a direct download.
Technical Decisions Along the Way
Building a tool that scans websites at scale involves decisions that aren't obvious from the outside but have significant impact on the quality of results:
Edge Functions vs. Dedicated Backend
The initial architecture used serverless Edge Functions for scanning. This worked for basic analysis but hit limitations quickly — specifically a 60-second timeout that wasn't enough for JavaScript-heavy sites or thorough analysis. The migration to a dedicated backend with a proper async job queue eliminated this constraint and enabled the full 27-factor evaluation.
Authentication Architecture
Detecting which plan an account was on sounds trivial but proved tricky in practice. The initial implementation had a bug where every account displayed as unpaid: the dashboard component wasn't receiving the account's plan data, so the top-level component was missing a prop and the value fell back to the default. A small fix with significant UX implications. Paying users were seeing limits that shouldn't have applied to them, and raising support requests.
Staging and Production Isolation
Running separate staging and production environments seems like standard practice, but in the context of a scanning tool, it's essential. A bug in the scanning logic that produces incorrect scores can't be tested in production — it would give paying users wrong information. Proper environment isolation with dedicated staging allowed us to catch scoring issues before they reached real users.
What Makes This Different
The AI visibility tool market has grown rapidly, and most tools in it focus on a single capability: generating llms.txt files. AImpactScanner took a different approach by treating llms.txt as one component of a larger diagnostic workflow.
The core difference was that AImpactScanner started with diagnosis, not generation. It evaluated sites against 27 factors first, identified specific gaps, then generated an llms.txt file informed by that analysis. The file reflected what the scanner found, not just what URLs existed.
This matters because a good llms.txt file can't compensate for a poorly structured site. If your content lacks authorship signals, your schema is incomplete, and your pages aren't structured for AI readability, an llms.txt file won't fix those problems. It'll just direct AI to pages that aren't ready to be cited.
The value of the full loop — diagnose, optimise, generate, track — is that each step informs the next. You knew what to fix before you generated, and what had improved after you fixed it.
What Came Next
The roadmap at the time included JavaScript rendering for every account, expanded factor coverage as AI systems evolved their citation preferences, and integration with monitoring tools for ongoing citation tracking. The goal was a complete AI visibility platform: not just a scanner, but a continuous feedback loop between a site's AI readiness and its actual citation performance.