Page scan vs whole-site scan

A page scan grades the URL you entered. A whole-site scan grades that URL the same way and then also grades up to 5 of the site's own pages, taken from its sitemap, and lists each one with its score. The overall score and grade at the top of the report come from the URL you entered in both modes; the extra pages are graded separately so you can see where the rest of the site falls short.

What does a page scan grade?

A page scan (Specific page on the scanner, mode=page or no mode in the API) fetches the URL you entered and runs every selected check against it. Checks about the page itself, such as JSON-LD, headings, the canonical link and the amount of server-rendered text, read that page's HTML. Checks about the site as a whole, such as robots.txt, llms.txt, the sitemap and the well-known discovery files, are read from the root of the same origin, whatever path you entered.

So scanning https://example.com/blog/post grades that blog post's HTML together with https://example.com/robots.txt and the other root files. That is useful when an agent is more likely to land on a deep page than on the homepage, for example a product page or a documentation article that search results point to.

What does a whole-site scan add?

A whole-site scan (Whole site on the scanner, --site in the CLI, mode=site in the API and the MCP tool) runs the page scan first, then:

1. Reads /sitemap.xml from the site's root, the file already fetched for the sitemap check.
2. Picks up to 5 page URLs from it, in the order they appear.
3. Fetches those pages together and grades each one with the same checks, reusing the site-wide results (robots.txt, llms.txt, DNS and discovery files) from the first fetch.
4. Adds a Pages graded table to the report, worst score first, with each page's score, grade and number of failing checks.

The API and the scanner page always ask for 5 pages. The scanner code caps the number at 10, but none of the ways to run a scan lets you change it today.

Which pages does it pick from the sitemap?

Only URLs that can stand for a page of the same site. A URL is skipped when any of these is true:

Skipped	Why
It is on another origin (different scheme, host or port)	A scan of one site must not turn into a fetch of another
It is the URL you entered	That page is already graded at the top of the report
Its path ends in .xml, .json, .txt, .pdf, an image extension, .css, .js, .zip or .gz	Not a page an agent reads as HTML
It appeared earlier in the sitemap	No page is graded twice

When /sitemap.xml is a sitemap index (a list of other sitemaps, as defined by the sitemaps.org protocol) rather than a list of pages, the scanner opens up to 2 of the child sitemaps it lists, on the same origin only, and takes pages from those.

Which pages are left out of the table?

A picked page is dropped without counting against the site when:

• it does not answer within 8 seconds,
• it answers with a status outside 200 to 299 (redirects are followed first),
• its Content-Type is not text/html or application/xhtml+xml.

Each page's HTML is read up to 1.5 MB. If nothing in the sitemap qualifies, or the site has no /sitemap.xml, the report looks like a page scan: the Pages graded table appears only when at least one page was graded.

A sitemap declared only in robots.txt with a Sitemap: line counts for the sitemap check, but the whole-site scan reads pages from /sitemap.xml only. If your sitemap lives at another path, serve a copy or an index at /sitemap.xml to get pages graded.

When should I use each mode?

Use	When
Page scan	Checking one template or one important page, re-checking a single fix, or running a quick check in CI
Whole-site scan	A first audit of a site, or when the homepage scores well but you suspect inner pages do not (thin content, missing JSON-LD or a stray noindex on a template)

Both modes count as one scan against your daily allowance. A whole-site scan takes longer, because it waits for the extra pages after the first fetch.

The pages table grades each page with the same weights described in Scores, grades and scan filters. To fix what it finds, run a page scan on the worst page and follow Fixing issues with fix prompts, since the fix prompts in the report belong to the URL you entered.