Audit First, Then Diagnosis, Then a Blueprint

Definition

The path runs from Audit to Diagnosis to Blueprint, and a deep audit treats the site as a system rather than a single score. It walks pages, structure, topics, entities, questions, and evidence before anyone writes the blueprint. Findings are grouped by rule with sample URLs, so diagnosis can explain the pattern and the blueprint can name the next actions.

Short answer

Diagnosis sits between the audit and the blueprint because a pile of URLs is not yet a plan. When rendering exists, review health, answerability, and accessibility as separate columns, prioritize template-level defects, sample JavaScript against no JavaScript, and attach why the issue matters, how to address it, and what happens if it is ignored.

What to check

• Walk pages before the blueprint
• Group findings under one rule
• Keep sample URLs with each rule
• Write the blueprint after diagnosis

What this does not claim

A finished blueprint does not guarantee that the optimize step will produce rankings or citations. Stating why a finding matters, how to address it, and what happens if it is ignored still does not guarantee a commercial outcome.

A practical example

If many product templates omit a direct answer, the audit groups those URLs under one rule instead of treating each URL as a separate mystery. Diagnosis explains the shared defect, and the blueprint targets the template, with the sample URLs kept attached so a later check can confirm the work.