Skip to main content
Industry Updates

AImpactScanner Analysed Every Website — React, Vue, SPAs and More

Jamie Watters 7 min read
Table of Contents

AImpactScanner launched with a straightforward goal: scan any website and evaluate its AI search visibility across the MASTERY-AI Framework. It worked well — for sites built with traditional server-rendered HTML. But a growing percentage of scans were returning artificially low scores, and the reason was clear: JavaScript.

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.

Sites built with React, Vue, Angular, and other single-page application (SPA) frameworks render their content in the browser, not on the server. When AImpactScanner fetched these pages, it saw the initial HTML shell — an empty <div> and a script tag — not the actual content. The scores reflected a blank page, not the site users actually see.

That was fixed. AImpactScanner rebuilt its entire backend with full JavaScript rendering and expanded its evaluation from 19 factors to 27.

The Problem with JavaScript-Heavy Sites

Single-page applications are everywhere. React, Vue, Angular, Next.js, Nuxt, SvelteKit — these frameworks power a significant portion of modern websites. They deliver fast, interactive experiences for users. But they create a problem for any tool that needs to read the page programmatically.

A traditional server-rendered page sends complete HTML to the browser. Every heading, paragraph, and image is in the source code. A JavaScript SPA sends a minimal HTML shell and a bundle of JavaScript that builds the page after it loads.

Most web analysis tools — including the previous version of AImpactScanner — only see the initial HTML. For a React app, that's typically just:

<div id="root"></div>
<script src="/bundle.js"></script>

No headings. No structured data. No content. The scan would report missing schema, no author signals, thin content — not because the site lacked these things, but because the scanner couldn't see them.

Full JavaScript Rendering

The fix required rebuilding the scanning infrastructure from the ground up. AImpactScanner migrated from serverless edge functions to a dedicated backend running Puppeteer — a headless Chrome browser that executes JavaScript exactly as a real browser does.

The new scanning process works in three steps:

  1. Detection — The scanner identifies whether the page is server-rendered or a JavaScript SPA by analysing the initial HTML response
  2. Rendering — For SPAs, Puppeteer loads the page, waits for JavaScript to execute, and captures the fully rendered DOM — the same content a real user sees
  3. Analysis — The 27-factor evaluation runs against the rendered page, not the raw HTML shell

This meant a React marketing site, a Vue e-commerce store, or an Angular SaaS dashboard received the same thorough analysis as a static HTML site. The score reflected actual content and structure, not a blank shell.

From 19 Factors to 27

The original AImpactScanner evaluated 19 factors across the MASTERY-AI Framework — all focused on AI-specific visibility signals. During development, a pattern became clear: sites with poor traditional SEO almost always had poor AI visibility too.

AI SEO is fundamentally limited by basic SEO. If search engines can't index your site, AI systems can't cite it. If your pages load slowly, AI crawlers may time out. If you have broken links, AI can't follow your content architecture.

The expanded evaluation covered 27 factors, grouped by the scanner into the framework's 8 pillars plus a ninth group of its own for the 8 traditional SEO checks it had added. That ninth group was the scanner's grouping, not part of the MASTERY-AI framework.

The 8 New SEO Factors

Each new factor addresses a foundational issue that, when broken, undermines every AI-specific optimisation you've implemented:

  • Indexability Status — Can search engines actually index your pages? Noindex tags, canonicalisation errors, and crawl restrictions can make your content invisible to both search engines and AI.
  • Mobile-Friendliness — Google's mobile-first indexing means the mobile version of your site is the version that matters. AI systems inherit these signals.
  • Page Speed — Slow pages get crawled less frequently and may time out during AI retrieval. Core Web Vitals directly affect how often your content is available for AI citation.
  • Broken Links — Broken internal and external links signal neglect and reduce crawl efficiency. AI systems use link structure to understand content relationships.
  • Sitemap Presence — A well-structured sitemap helps both search engines and AI crawlers discover your full content library, especially pages that aren't well-linked internally.
  • Canonical Tags — Duplicate content without proper canonicalisation splits authority signals. AI systems may cite the wrong version of your page — or avoid citing either.
  • Internal Linking — Strong internal link structure helps AI systems understand your content hierarchy and topic relationships. Orphaned pages rarely get cited.
  • Duplicate Versions — www vs. non-www, HTTP vs. HTTPS — if both versions exist without redirects, you're splitting every signal in half.

These aren't glamorous factors. They're plumbing. But broken plumbing undermines everything built on top of it.

Built-In llms.txt Generation

Users could generate llms.txt files directly from their scan results. After AImpactScanner analysed a site, it used the same data to identify which pages had the highest AI citation potential and generated a prioritised llms.txt file.

This connected two previously separate workflows: diagnosing AI visibility issues and optimising a site's AI discoverability through llms.txt. The generated file reflected actual content quality, not just a URL dump, because the scanner had already evaluated every page against the full MASTERY-AI Framework.

What It Meant for a Site Being Scanned

Any score from before the rebuild was liable to read lower than it should have. JavaScript rendering meant the scanner saw what users see, and the 8 new SEO factors gave a more complete picture of AI readiness.

For sites built with React, Vue, Angular, or any SPA framework, the update mattered most. Earlier scans had evaluated an empty page. The rebuilt scan evaluated the actual content.

The expanded factor set also meant a score could shift in either direction. Sites with strong traditional SEO foundations could see their scores rise, because those signals were now counted. Sites with underlying SEO issues (broken links, missing sitemaps, duplicate versions) saw areas for improvement that weren't previously flagged.

Either way, the result was a more accurate picture of how AI systems perceive a site. And that's the starting point for everything else.