What happens when you audit a URL?

The pipeline is short and has no hidden steps. Each stage reads only the output of the stage before it.

  1. Fetch. The app sends one HTTP GET to the URL you typed, follows redirects, and records status code, response time, Content-Type, X-Robots-Tag, and HTML size.
  2. Parse. The delivered HTML is parsed into a document. The app extracts title, meta description, canonical, robots directives, viewport, language, charset, headings, links, images, JSON-LD blocks, lists, tables, cite and blockquote elements, author and date markers, and word count of the body text.
  3. Score. Fixed rules turn those facts into twelve sub-scores: three for SEO, three for AEO, three for GEO, and three for Local. Sub-scores roll up into the SEO, AEO, GEO, and overall scores.
  4. Findings. Each failed rule becomes a finding with a code, severity, plain-language detail, a recommendation, and the evidence string that triggered it.
  5. Store. The run, page, scores, and findings are written to a SQLite database in your user profile. History and comparisons are computed from that file.

Why is the scoring deterministic?

Deterministic scoring means the same HTML always produces the same scores and the same findings. There is no language model in the loop and no sampling. This matters for three reasons. You can reproduce a client's score on your own machine. You can diff two runs and attribute every change to a change in the HTML or the response. And you can read the rule behind any score instead of trusting a black box.

What exactly is fetched?

The app reads what a crawler without a JavaScript engine would read. It performs an HTTP GET with a standard browser-like user agent, follows redirects, and keeps the final response body. It does not run a headless browser, does not execute scripts, does not load images or stylesheets, and does not submit forms. If the page's meaningful content only appears after JavaScript runs, the source HTML will look thin and the app reports CLIENT_RENDERED_SUSPECTED rather than guessing at the rendered result.

How are the scores built?

Each score starts from a base and moves by fixed amounts. The full list of checks and thresholds is on the checklist page. In summary:

ScoreSub-scoresMain inputs
SEOTechnical, on-page, contentStatus, HTTPS, title, description, canonical, robots, viewport, language, H1 count, internal links, alt text, word count
AEOSchema, answer patterns, entity coverageJSON-LD validity and @id, count of question-led headings, lists and tables, word count, external links
GEOExtractability, entity clarity, source qualityAnswer patterns plus depth, schema plus sameAs, external links, quotations, author, date
LocalNAP, schema, relevanceLocalBusiness entity, address, telephone, service area, sameAs, geo coordinates

Word count bands are shared across content depth and entity coverage: under 150 words scores 25, 150 to 299 scores 45, 300 to 599 scores 65, 600 to 999 scores 80, and 1,000 or more scores 90.

What does "evidence" mean in a finding?

Every finding carries the specific value the rule saw. A title-length finding includes the character count and the title text. A client-rendering finding includes the source word count, script count, and whether an application mount point was detected. A missing-canonical finding tells you no link rel="canonical" was present. The evidence is stored with the finding so you can verify it against the page yourself.

What are the limitations of this method?

The method is honest about what one HTTP response can and cannot show.

  • No JavaScript rendering. Single-page applications are flagged, not rendered. Verify them with a real browser and your search console's URL inspection.
  • No live engine sampling. The app does not query ChatGPT, Perplexity, Gemini, or Google to see whether you were cited. It checks whether the page is structured to be citeable.
  • Limited backlink discovery. The Backlinks tab checks pages you provide and searches websites and profiles linked from your site. It can confirm links, but it does not provide a complete web index or a domain-authority score. Backlinks do not change the page scores.
  • No Core Web Vitals. Response time and HTML size are recorded as rough hygiene signals. Lab and field performance data are not measured.
  • No log-file analysis. The app does not know which crawlers actually visited your server.
  • Heuristic answer detection. A heading counts as question-led if it ends in a question mark or starts with a question word. The app does not yet measure the length of the answer paragraph under it.

How do page audits and site crawls differ?

A single-page audit scores one URL and shows the findings and local history. A site crawl follows links automatically, with no page-count setting. It finishes when no eligible pages remain or stops after 30 minutes, saving the pages checked so far and explaining incomplete coverage. It adds site-level findings such as duplicate titles, canonical conflicts, sitemap gaps, and orphan pages, and stores per-page evidence for every URL checked. The page rubric is identical in both.

Open Backlinks to verify a page you expect to link to your site, or start a search from the websites and profiles your site links to. Sources are saved with their latest result so you can see confirmed links and pages that need another look. Discovery finishes when its connected pages have been checked or after 30 minutes; results found before the time limit are saved. A missing result does not mean no one links to your site.