toolkit

Scenario · Content and search

Get a second opinion on this page

A finding is disputed, or a local fetch is blocked and the page cannot be read from here.

Worth running for two different reasons: a finding gets disputed by a client or colleague, or a page simply can't be checked from here at all because something is blocking the request outright. This runs a second, independently-tuned audit on the same page and compares its findings against what was already reported line by line, turning a vague disagreement into a specific, checkable claim about one piece of the page — which is a conversation that actually ends, rather than a standoff between two tools' overall scores.

What to ask for

SuperAuditOptional integration — sends a URL to a remote SuperAudit engine (a hosted SEO/content audit service with hundreds of checks) and renders its category and check results as a PASS / REVIEW / FAIL report, with the engine's own findings and recommendations as the built-in fixes.On-page SEOOn-page SEO scan — reads a page's delivered HTML and checks the head, meta and heading signals search engines use: title presence and length, meta description, rel=canonical, meta robots (noindex), Open Graph tags, viewport, html lang, and exactly one H1, plus a structured-data summary.Page audit (all-in-one)Page QA orchestrator — run every QA tool on one URL and get one standardized report.

See it work

A real run of SuperAudit:

FAIL — 1 page(s) · 4 neutral check(s) graded
  FAIL   Technical  1✗ 0~ 1✓
      [FAIL] robots.txt reachable
  REVIEW Content  0✗ 1~ 1✓
      [REVIEW] Title tag

  report: ./out/superaudit-superaudit.html
  text:   ./out/superaudit-superaudit.txt

The captured report, exactly as a run hands it to a client —open the full report ↗

Worth running for two quite different reasons: a client or colleague disputes a finding, or the page cannot be fetched from here at all because bot protection is refusing us. The remote engine runs the fetch from its own server, which solves the second case outright.

  1. Establish which case this is. A disputed finding needs a comparison. A blocked page needs a fetch from somewhere else — and a BLOCKED verdict from a local check is an absence of evidence, not a clean result.
  2. Run the native checks and record what they say. On-page SEO, and the all-in-one page audit for the broader picture. This is the position being tested, and it has to be written down before the comparison or the comparison becomes hindsight.
  3. Run the remote audit on the same URL. It returns its own category and check results with its own findings and recommendations. Note that it is tuned for a single vertical, so by default the neutral categories are the comparable ones.
  4. Compare finding by finding, not verdict by verdict. Two tools reaching different overall scores is expected and uninteresting. Two tools disagreeing about whether a specific canonical is correct is the thing worth resolving.
  5. Resolve disagreements by looking at the page, not at the tools. Fetch the HTML and read the tag in question. Both audits are inferences from the same document; the document settles it.
  6. [manual] Report the conclusion with both sources attached. When a client’s own SEO tool disagrees with ours, the useful answer names the specific claim, shows the markup, and says which tool was wrong about what. “Our tool says otherwise” resolves nothing.

Disagreement is the output

This is not a tie-breaker procedure — no third opinion decides it. The value is that a disputed finding becomes a specific, checkable claim about a specific line of HTML, which is a conversation that ends.

What this does not cover

Deciding which opinion is right. Two audits disagreeing is information, not a verdict — a remote engine tuned for one vertical will flag things that do not apply and miss things that do. It is also an optional integration: without its endpoint and key configured it is inert, so this procedure has no second half on an install that has not been set up for it.

← All scenarios