Mega Analyzer Methodology

Version 2026.05 · Updated May 11, 2026 · Changelog · By J.A. Watte

The Mega Analyzer at /tools/mega-analyzer/ grades a URL across 10 buckets in one pass. This page documents what each bucket tests, how scores are produced, and which standards each check implements. The rubric is published openly so operators can verify the score against their own reading of the page.

How the score is produced

Every check returns one of four states:

pass: full credit (1.0).
warn: half credit (0.5). Used when the signal is present but partially correct or partially deployed.
fail: no credit (0.0).
info: informational only; excluded from the score.

A check that did not run has no state at all. It shows "Not run in passive mode", is never a pass or a fail, and is left out of the score.

Each bucket's score is the unweighted average of its checks (warns count as 0.5). The overall grade is the average of the 9 audit buckets (the Mega AI Prompt bucket is output, not input), each counted once, mapped to a letter grade. There is one exception: when a page we could read has no JSON-LD at all, the Schema bucket counts at 0, with a share of 0.6 of a bucket for E-commerce, Local, YMYL and B2B pages and 0.35 for others. A blank app shell or an unreadable page stays unknown and drops out. The letter grades:

A: 90 to 100
B: 80 to 89
C: 70 to 79
D: 60 to 69
F: below 60

The "Mark It N/A" feature lets an operator exclude any check that does not apply to the site (e.g. e-commerce schema on a brochure page). N/A items are removed from both the score denominator and the AI fix prompt.

The 10 buckets

1. SEO

Title length and pixel width, meta description, canonical, indexability (robots meta + X-Robots-Tag), heading hierarchy (one H1, ordered H2 tree), word count, internal-link signal, hreflang sanity, breadcrumb continuity, and Open Graph / Twitter card completeness.

2. Schema

JSON-LD extraction with recursive walk through @graph and nested object values. Detects FAQPage, Article / BlogPosting / NewsArticle, Product (with the physical-goods gate for shipping/returns), SoftwareApplication, HowTo, BreadcrumbList, Organization, Person, LocalBusiness, Service, SelfStorage, OfferCatalog. FAQ parity diff between visible questions and FAQPage entries flags ghost entries that Google suppresses. References: schema.org.

3. E-E-A-T

Author byline detection (rel=author, visible author block, microdata), datePublished / dateModified in Article/FAQPage/WebPage JSON-LD, visible "Last updated" stamp, author URL, sameAs array on Person/Organization nodes, OG Article extension (article:author, article:published_time, article:modified_time), Person schema with knowsAbout.

4. Voice

Flesch reading ease, grade level, passive voice rate, sentence-length variance, CTA density, pronoun balance. Flags AI-generated tells without false-positive triggering on humanized copy.

5. Mobile parity

Dual fetch with desktop Chrome and Android Chrome user agents. Structured diff of word count, H1/H2, schema types, HTML size. Surfaces mobile-first indexing regressions and cloaking.

6. Performance + AI signals

Render-blocking resources, image weight, total HTML size, render hints, key AI-readiness signals (robots.txt Content-Signal directive, Link response headers, /.well-known files: api-catalog [RFC 9727], MCP server card [SEP-2127] on both Cloudflare and SEP paths, Agent Skills v0.2.0, WebMCP imperative API, OAuth metadata [RFC 8414] and Protected Resource [RFC 9728], Web Bot Auth signature directory, x402 v2, MPP, UCP, ACP), markdown content negotiation, AGENTS.md, llms-ctx.txt / llms-ctx-full.txt, JSON Feed v1.1 enrichment fields, schema:CreativeWork.usageInfo.

Color contrast, alt text coverage, heading hierarchy, ARIA validity, keyboard navigation hints, target size, form labels. Critical AA failures are rendered as a separate red-bordered section. Reference: WCAG 2.2.

8. Indexing hygiene

robots.txt presence and structure, sitemap.xml presence and lastmod truthfulness, image sitemap presence, ai.txt / humans.txt / security.txt [RFC 9116], canonicalization consistency, noindex / nofollow leakage, redirect-chain depth.

9. Retrieval (AEO)

Answer-engine and citation readiness: passage-retrievability paragraph length and self-containment, question-shaped H2/H3 framing, definition-first opening sentences, comparison-table presence, named entity density, anchor stability, llms.txt presence and shape per llmstxt.org.

10. Mega AI fix prompt

Output bucket. Assembles every fail and warn into a single prompt that is ready to paste into Claude, ChatGPT, Cursor, Windsurf, Codex, or any coding agent. Includes deeper-dive tool references for any dimension that needs more depth than the single-pass audit can give.

Agent endpoint results and listing review

The Agent Endpoint Inspector keeps completed public-file findings when a stage times out or fails. Public tool declarations are marked unconfirmed. The confirmed count stays Not run until a person enables the handshake. Partial reports name the missing stages and offer a retry. An unanswered optional or third-party file is named separately and does not remove completed scores.

Supplemental panels review tool text, registry metadata and listing completeness. They never change the main scores. Tool text review reads titles and descriptions only, never argument names or keys. It checks for hidden or reordered characters, instructions to override earlier instructions, requests to hide something from the user, a named secret path or key file with a request to read or pass it, and a fetch piped to a shell. Emoji sequences and ordinary non-Latin scripts are not hidden-text signals. A quoted or "such as" example is treated as described text only when it is a fragment inside a sentence, not the whole sentence. Signals say "Possible signal, review it". Otherwise the panel says "No signals in the text reviewed. This reads text only and cannot catch everything." It may miss unusual phrasing or flag a security tool for review. A separate comparison saved in this browser shows tool-definition word changes.

Listing readiness uses our own weights: human title 8, useful description 12, website 8, repository 8, icon 6, tool descriptions 16, argument descriptions 16, operation hints 10, server card 8, and support plus privacy links 8. Shares receive proportional credit. Unknown tool data remains unknown; the panel shows how much was measured. These are publishing suggestions, not directory approval requirements.

At most one bounded GET, with a short-lived shared cache and request limits, searches the official MCP Registry using the site's reversed base domain namespace. A missing match in that limited search does not prove there is no listing under another name. Registry metadata is untrusted. A website claim from an unrelated publisher does not establish ownership and earns no listing-readiness credit. Namespace proof identifies a publisher namespace, not a safe server. Endpoint and version agreement are reported separately. Registry failures show Not available.

A passive run sends only GET and HEAD reads of public files and never sends a handshake, POST, OPTIONS or DELETE. It does not call tools. If a site's own public files link to an endpoint address, that address may be read by GET like any other public link. A full scan distinguishes authentication, payment, host challenges and failures, and only a full scan can try older SSE transport after streamable HTTP rejection within the existing request and time limits. Addresses that are malformed, private, reserved or placeholders are labeled not testable; this is not a finding that a deployed service failed. Setup timing is separate from ping timing. Measurements come from our hosting function; geographic region and connection reuse are shown only when known.

mcptry.com publishes an independent health and security view of registry servers. Its public methodology informed some checks here. Our implementation, wording and readiness weights are independent. The Inspector links to it without fetching its data. Read a server's permissions before using the connection examples, which were checked against official client documentation on November 6, 2026.

Passive and full scans

A default run is a passive scan: it sends only ordinary GET and HEAD reads with our normal identity. Every report says which kind of scan ran, in the same words on the Mega Analyzer, the Mega Security Analyzer and the Agent Endpoint Inspector: "Passive scan", or "Full scan, with" and what ran.

Crawlers and the agent handshake: a ticked box and a real press of Run also ask for the page labeled as search and AI crawlers, replay Meta's link-preview request, and run the agent handshake, which sends POST and DELETE requests to the agent endpoint to list what it offers. It never calls a tool. The box lasts for one run, and a link or autorun cannot turn it on. Use it only on a site you own or have permission to test.
Owner file checks: the owner box allows GET reads of a short, fixed list of file paths after a deliberate press of Run. The Mega Analyzer and the Security Analyzer share this choice for each site.
Agent endpoints in a passive scan: A passive run sends only GET and HEAD reads of public files and never sends a handshake, POST, OPTIONS or DELETE. It does not call tools. If a site's own public files link to an endpoint address, that address may be read by GET like any other public link. Whether the endpoint works reads "Not run in passive mode".
A passive and a full result are different measures. Compare a site with itself only in the same mode.

Platform defaults and store checks

Where a hosted platform sets something a merchant cannot change, the row reads "Platform default: ask [platform]", keeps the fact, leaves the score and leaves the fix list. On Shopify that covers response headers, the WebMCP rows and Shopify's own robots.txt rules. A platform's default llms.txt or agents.md is reported the same way, as an opportunity and never as a fault.

On Shopify the run also reads the public product list, the products sitemap and a capped sample of product pages, with robots.txt checked first. Products that exist but carry noindex or are missing from the sitemap count in the SEO bucket, at a weight of 60 times the hidden share, from 10 to 60, even when the page scanned is the home page. Hiding a product may be deliberate, so the row says to decide on purpose. Product data rows (price, labels, stock, barcodes, offers) are for review and are not scored.

What the tool cannot see

Security headers, CSP, 301 redirects, UA-dependent rendering, and schema injected at build time live in a hosting / CDN / SSG layer that this audit cannot directly inspect. The tool fetches raw HTML; it does not execute JavaScript. JS-rendered content that requires a headless browser to materialize is not scored. This matches how most AI crawlers actually fetch a site today.

Standards cited

Schema.org vocabulary
WCAG 2.2 (W3C)
RFC 8288: Web Linking
RFC 8414: OAuth Authorization Server Metadata
RFC 9116: security.txt
RFC 9727: api-catalog well-known URI
RFC 9728: OAuth Protected Resource Metadata
Model Context Protocol (SEP-2127 server card)
Agent Skills v0.2.0
WebMCP
llmstxt.org
AGENTS.md
x402
JSON Feed 1.1

Source

The tool itself is at /tools/mega-analyzer/. The score logic lives in the page's inline JavaScript; the rendering helpers are in /js/audit-scorecard.js, /js/audit-toolkit.js, /js/aeo-geo-checks.js, and /js/indexing-hygiene-checks.js. Each rendered finding pill links to a deeper-dive tool that focuses on the same check in isolation.