White-Label GEO Diagnostic Reports for Agencies

1 — Purpose and core principles

A technical diagnostic report differs fundamentally from a marketing dashboard or speculative forecast. It serves as a timestamped, verifiable audit artifact designed for client review and engineering handoff:

• Falsifiable crawl observations: Every technical finding maps directly to an observable HTTP status, rendered HTML hash, robots.txt rule, schema validation check, or extraction probe with exact timestamps and URLs.
• Explicitly labeled model cohorts: Sample matrices record the exact prompt, raw model response, timestamp, locale, execution mode (API · Model knowledge, API · Web-grounded retrieval, or Manual · Product surface), model checkpoint ID, and deterministic matching rules. Unlabeled screenshots are excluded.
• Actionable engineering tickets: Findings requiring technical remediation are formatted as scoped tickets with assigned severity, target files, code diffs, and reproducible acceptance criteria.

Delivery readiness tracks three distinct phases: diagnosis (site crawl completed), visibility (prompt cohort sampled), and implementation (remediation code generated and reviewed). A delivery pack can be finalized for diagnostic review while generated code assets remain in draft status.

Sources

• Schema.org Report — Structured diagnostic reporting specifications.
• Schema.org TechArticle — Actionable technical ticket schemas with code diffs and acceptance criteria.
• W3C Guidance on Presenting Findings — Leading technical deliverables with actionable remediation steps.
• OpenAI Crawler Documentation — Crawler user agents and robots evaluation rules.
• CiteAura Delivery Documentation — Architecture of multi-phase readiness states (diagnosis, visibility, implementation).

2 — Delivery pack structure: documents, evidence, and assets

CiteAura compiles client deliverables into a standardized archive from work/<tenant>/<slug>/delivery/. The compiler reads active audit.json, tasks.json, metrics/, and delivery/ states, bundling numbered HTML reports, implementation assets, raw evidence JSONL files, and comparative visibility deltas with cryptographic SHA-256 manifests.

Evidence attachments are organized systematically: 07-Evidence/raw-ai-answers.jsonl, 07-Evidence/raw-ai-answers.html, and 07-Evidence/citation-evidence.csv contain complete model completions and extracted source links. When comparing consecutive cycles under matching parameters, 08-Before-After/visibility-delta.md details relative cohort movement.

Archive root files:

• manifest.json — Build metadata including build_id, built_at, workspace parameters, prompt hashes, audit hashes, and individual file SHA-256 signatures.
• README.txt — Overview and suggested reading sequence for technical client stakeholders.
• raw/ — Optional raw export directory containing audit.json, tasks.json, and CSV tables for client data teams.

3 — White-label branding and styling

Branding parameters are configured under Delivery → White-Label Branding and applied during pack compilation:

Configuration parameters

• Agency name: Applied across covers, page headers, and footers.
• Logo asset: SVG or high-resolution PNG (recommended 140×32 px), automatically validated to ensure clean rendering.
• Contact metadata: Agency website and primary support email for the report masthead.
• Confidentiality notice: Customizable legal notice displayed in document footers.
• Accent palette: Hex color tokens applied to headers, data callouts, and table borders.
• Vendor attribution toggle: Completely suppresses underlying platform identifiers from client-facing documents.

Compilation pipeline

1. When an operator triggers Build Pack, the compiler captures the current branding profile into delivery/branding.json.
2. Templates inject agency metadata directly into the document layout before rendering static HTML pages.
3. The manifest stamps a branding_hash to verify visual configuration integrity across builds.
4. Raw data exports in raw/ remain unstyled JSON/CSV files.

4 — Technical ticket lifecycle

Audit findings requiring code or server adjustments are tracked as structured tickets in tasks.json and exported to the action matrix:

Each ticket includes:

• id — Unique identifier (e.g. GEO-017), preserved across rebuilds.
• severity — P0 (blocks crawler access), P1 (hinders content extraction), or P2 (schema optimization).
• target — Target URL or file path (e.g. /robots.txt, /pricing).
• finding — Concise technical observation with raw evidence pointers.
• requested_change — Exact code diff or server directive to apply.
• acceptance_check — Automated test command used to verify resolution (e.g. verifying an Allow directive under GPTBot with curl).

5 — Verification and acceptance testing

Verification provides empirical proof that deployed adjustments resolved the underlying audit defect:

• Target re-crawling: Re-fetches URLs to confirm status codes, header values, rendered HTML extractability, and JSON-LD schema validity.
• Root file inspection: Evaluates live robots.txt and llms.txt directives on the canonical host, detecting stale CDN cache states.
• Follow-up sampling: Executes a new cohort under matching prompt and sampling parameters to record post-deployment baseline shifts.

The automated Verify & Deliver pipeline executes acceptance probes, stores response snapshots under delivery/evidence/<ticket_id>/, and updates ticket statuses upon successful validation.

6 — End-to-end agency workflow

1. Project setup & site audit: Configure client domain parameters, locale, and target markets. Run automated crawling and review P0 blockers.
2. Cohort sampling: Establish the prompt bank, select sampling modes (e.g. api_param), and collect baseline responses.
3. Ticket triage: Convert technical findings into scoped tickets with assigned developers and acceptance checks.
4. Branding review: Verify agency visual assets and confidentiality notices in the white-label settings.
5. Compile initial pack: Build the delivery package containing diagnostic summaries, visibility matrices, and draft remediation assets.
6. Deploy & verify: Once client developers deploy fixes, run verification probes to confirm resolution and transition tickets to VERIFIED.
7. Deliver final package: Rebuild the delivery ZIP and provide technical stakeholders with verified diffs and updated cohort measurements.

7 — Common engagement models

8 — Client handoff checklist

Review these quality gates before transmitting reports to clients:

• Branding verified: All document headers, footers, and covers display agency branding with zero platform vendor marks.
• Build recency: manifest.json:built_at reflects the latest deployment and verification runs.
• Asset readiness: Only reviewed and tested code patches are marked ready for production deployment.
• Explicit acceptance checks: Every remediation ticket specifies a testable verification command.
• Evidence attached: All verified tickets link directly to supporting crawl headers or response logs in 07-Evidence/.
• Accurate cohort labeling: Prompt hashes, sampling modes, timestamps, and model checkpoint versions are fully documented.
• Realistic positioning: The executive summary clearly positions findings as an empirical audit rather than an absolute ranking guarantee.

9 — Case walkthrough: B2B SaaS platform

Profile: Mid-market B2B SaaS platform with ~180 marketing URLs, subdomain documentation, and client-rendered pricing calculators. Evaluated across US/en-US buyer prompts.

Initial diagnostic baseline: An initial crawl identified that documentation was blocked in robots.txt and pricing tables were rendered entirely via client-side JavaScript. A 20-prompt baseline cohort (API · Model knowledge) recorded a 10% mention rate (2/20). The agency delivered an initial diagnostic pack with P0 tickets for robots.txt and server-side rendering.

Remediation and verification: The client engineering team updated robots.txt rules, migrated key product descriptions to server-side HTML, and added structured SoftwareApplication JSON-LD schemas. Automated verification confirmed crawler access and HTML extractability across target pages.

Follow-up sampling: Running an identical 20-prompt cohort 7 days post-deployment recorded an 8/20 mention rate (40%). The delivery pack documented the two cohorts side-by-side with identical prompt hashes, detailing the structural improvements without asserting speculative universal visibility claims.

10 — Professional reporting boundaries

• Avoid ungrounded single-session screenshots; present verified prompt cohorts with sample depths.
• Do not include untested draft assets in production deployment guides.
• Avoid speculative ranking claims; report measured visibility proportions within defined testing cohorts.
• Keep disparate sampling environments clearly segmented rather than averaging API and consumer app data.
• Report unmeasured model platforms as unmeasured rather than 0%.