toolkit

Scenario · Content and search

Is this page good for search?

“Is this page good for search?” The default first check on any single URL.

This is the first, most basic question worth asking about any single page: are the technical fundamentals search engines actually read — the title, the description, the page's own address, the machine-readable details — present and correctly formed. This checks exactly that against a fixed standard, not against any other page, because passing it proves the page is well-built; it says nothing about whether the content is good or whether it's even targeting the right search term.

What to ask for

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.

See it work

A real run of On-page SEO:

FAIL — 1 page(s) on toolkit-tests.pages.dev
      [error] missing <title>
      [warn] missing meta description
      [error] no <h1> on the page
      [warn] no rel=canonical link
      [warn] no viewport meta (mobile rendering)
      [warn] no lang attribute on <html>
      [warn] no Open Graph tags — shared links get a guessed title/description and no image
      [info] no <link rel="icon"> declared (a root /favicon.ico may still resolve; declare one for a modern SVG/PNG icon)
      [info] no apple-touch-icon — iOS home-screen bookmarks fall back to a page screenshot
      [info] no web app manifest (<link rel="manifest">) — needed for an installable PWA / richer mobile metadata
      [info] no theme-color meta — mobile browsers use it to tint the address bar
      [info] no structured data (see structured-data-schema)

  playbook: local fallback

  report: ./out/on-page-seo-on-page-seo.html
  text:   ./out/on-page-seo-on-page-seo.txt

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

Seen in the wild

Where a PASS or a FAIL actually comes from.

A tool that grades a page and will not say what it graded it against is just an opinion with a colour on it. So every report behind this series ends the same way: with a link to the team’s own written standard, pulled live from our wiki at the moment the report is built.

What three reports attached this morning, unasked

On-page SEO standardsteam wiki
Web performance standardsteam wiki
SEO change QAteam wiki
Fetchedlive, then cached
If the wiki is downbundled copy
Who edits the rulewe do

The wiki pages are ours and editable by the people who own the standard. Change the page and the next report grades against the new one — nobody has to touch a tool.

60tools installed
232known-answer tests
39proven against a live page

The middle number is the one that matters. A known-answer test is a page whose defects are already known, served to the tool to check it returns the right verdict — not that it ran, that it was right. Twenty-one tools have no such fixture and are labelled partial in our own report rather than quietly counted as proven.

This is the on-page fundamentals check — title, meta description, canonical, a single H1, viewport, html lang, Open Graph, structured data — graded against zero rather than against any other page. A page can pass every one of these and still not rank, because none of them is the content or the keyword strategy; they’re the baseline a page needs before either of those has a chance to matter.

  1. Run the on-page check for the exact public URL.
  2. Read the title, description, heading, canonical, social and structured-data findings alongside their source evidence — each one names the actual tag or attribute it’s grading.
  3. [manual] Decide the content and keyword intent with the page owner. Passing technical signals proves the page is well-formed; it does not establish that the target keyword is the right one, or that the content backs it up.
  4. Make the approved on-page changes, verify the rendered public page, and rerun the check to record the result.

Well-formed is the floor, not the ceiling

A clean run here is necessary and nowhere near sufficient. It clears the technical baseline every page needs; whether the page actually competes for its keyword is what-should-we-target and how-do-we-compare’s question, not this one’s.

What this does not cover

Whether the content deserves to rank. Read-only and external: it checks that the signals search engines actually read are present and well-formed in the delivered HTML, which is a different question from whether the page is any good, or whether it targets the right term at all.

← All scenarios