Nebula Components · Diagnostic Specification

Landing Page Diagnostic Specification v1

Version 1.0.0 · Effective 2026-08-22 · Canonical URL: https://nebulacomponents.com/spec/landing-page-diagnostic-v1

Scope

This document defines exactly what the Nebula landing page diagnostic checks. It is the machine-readable and human-readable contract behind every audit result Nebula produces.

The diagnostic inspects one landing page URL against nine conversion signals. For each failing condition it returns a finding containing the observed condition, the required condition, the measured gap, and a selector identifying where on the page the evidence comes from.

Boundaries: findings are observations against these rules. They identify repair candidates. They do not predict revenue, guarantee ranking or citations, or replace controlled experiments. A signal without a returned finding means the run observed no failure for that category; it is not a certification.

Procedure

  1. Fetch the submitted URL and confirm it resolves to a retrievable page.
  2. Inspect raw HTML and rendered output across desktop and mobile widths.
  3. Evaluate the nine signals defined below.
  4. Emit findings for failing conditions, each carrying the evidence record described below.
  5. Order findings by priority: highest impact first, lowest effort breaks ties, label alphabetical as final tiebreaker.

Severity Model

Every finding carries an impact score from 0 to 10 and an effort score. Severity bands are deterministic:

BandImpactMeaning
critical8 to 10Repair candidate with severe expected cost of inaction
warning5 to 7.9Material friction worth scheduling
advisorybelow 5Improvement opportunity, lower urgency

Evidence Record

Every finding attaches one evidence record with six fields. Confidence declares how directly the engine observed the condition:

FieldContents
measuredWhat was observed on the page
requiredWhat the signal rule demands instead
deltaThe gap between measured and required
selectorLocator tying the observation to page markup
confidenceOne of definitive, high, contextual, unavailable
timestampWhen the observation was captured

When direct measurement is impossible, confidence drops to contextual or unavailable and the finding says so rather than asserting a number the engine did not observe.

The Nine Signals

Each signal also has its own reference page at nebulacomponents.com/signals with manual checks and pass/fail examples.

01Message Match

signal id: message_match

Does the page promise match the expectation created by the ad or referring source?

The primary headline and first supporting line must restate the same offer, audience, and outcome as the ad or referral context that produced the visit. A run flags this signal when the rendered headline contradicts, generalizes away from, or omits the promised offer.

Inspected: H1 text · first subheadline · title tag · referring campaign parameters when present

Pass: Ad promises a free landing page audit. H1 reads "Get a free audit of your landing page" for the same audience. Match.

Fail: Ad promises a free audit. Page opens with generic agency branding and no mention of an audit anywhere above the fold. Flagged.

02Trust Signals

signal id: trust

Does the page support its claims before asking for commitment?

At least one verifiable proof element must appear near the conversion ask: named results, sourced review counts, case studies, or identifiable company and author information. A run flags pages that make strong claims with no adjacent, checkable support.

Inspected: testimonial and logo blocks · review widgets · case study links · author and company identity markup

Pass: A pricing claim sits next to a linked case study naming the customer and the measured result. Support is checkable. Clear.

Fail: "Trusted by hundreds" appears with no names, no sources, and no links. Flagged.

03Mobile CTA

signal id: mobile_cta

Is the primary action visible and usable on a small viewport?

The primary call-to-action must be fully visible inside the initial 390px-wide viewport without scrolling, and must meet minimum tap-target size. A run flags CTAs pushed below the fold, overlapped by other elements, or smaller than usable touch targets at mobile width.

Inspected: CTA bounding box position and size at 390px · overlap checks against header, banners, and sticky elements · tap target dimensions

Pass: Primary button renders entirely inside the first mobile viewport with a 48px tap height and nothing covering it. Clear.

Fail: At 390px the CTA sits underneath a fixed bottom banner, so the first tap hits the banner instead. Flagged.

04Load Speed

signal id: load_time

Does the page become useful quickly enough to keep paid visitors from bouncing?

Main content must reach usable state fast enough on a constrained connection. A run inspects render-blocking behavior, oversized hero media, and late-loading primary content, then reports measured values against the required threshold for the specific finding.

Inspected: render-blocking resource count · hero image weight and format · when primary content becomes visible

Pass: Primary content paints early; hero image is sized and compressed for mobile. Within threshold. Clear.

Fail: A multi-megabyte autoplay video delays first meaningful content well past the threshold recorded in the finding. Flagged.

05CTA Clarity

signal id: cta_clarity

Is the next step obvious and proportionate to visitor intent?

One primary action must dominate. A run flags pages offering several competing equal-weight actions, vague action labels, or asks disproportionate to intent (for example demanding account creation before delivering any value).

Inspected: button label text · count and relative weight of distinct actions · ask placement relative to value shown

Pass: Single high-contrast "Run my free audit" button; secondary links are visually subordinate. Clear.

Fail: Four equal-weight buttons ("Book a call", "Sign up", "Learn more", "Follow us") compete in the first viewport. Flagged.

06Above-Fold Clarity

signal id: above_fold

Can a visitor understand the offer and next action in the first viewport?

Within the initial viewport a first-time visitor must be able to answer three questions: what is offered, who it is for, and what to do next. A run flags pages where any of these answers requires scrolling or inference.

Inspected: viewport-height slice of rendered DOM · headline, subhead, CTA presence in that slice

Pass: Offer, audience, and CTA all legible in the first desktop and mobile viewport. Clear.

Fail: First viewport contains only a full-screen illustration and a logo; offer and action require scrolling. Flagged.

07Ad Signal Continuity

signal id: ad_signals

Can paid clicks be connected to outcomes without guessing?

Paid traffic infrastructure must preserve click identity through to conversion events. A run checks for broken or missing tracking continuity between entry and conversion surfaces and flags gaps that would force attribution guesses.

Inspected: tracking parameter handling across navigation · conversion event wiring · attribution break points

Pass: Click identifiers survive the redirect into checkout and fire the purchase event with source intact. Clear.

Fail: The main CTA links to a separate domain without carrying parameters, severing attribution for every paid click. Flagged.

08SEO Foundations

signal id: seo_foundations

Can search systems retrieve and interpret the page foundations?

Core retrieval elements must be present, unique, and consistent: crawlable status, canonical URL, title, meta description, heading hierarchy, and indexability directives. A run flags missing, duplicated, or contradictory foundations.

Inspected: HTTP status and robots directives · canonical tag · title and meta description · heading structure

Pass: Self-referencing canonical, unique title and description, single H1, indexable. Clear.

Fail: Canonical points to a different URL while an internal link targets this one as the destination. Contradiction flagged.

09AI Readiness

signal id: ai_readiness

Can answer engines identify, verify, and cite the page accurately?

Machine-facing surfaces must let AI systems resolve who you are, what you offer, and what claims are supportable: structured data matching visible content, explicit factual statements, stable entity references, and crawler policy that permits answer engines you want citing you.

Inspected: JSON-LD presence and accuracy · entity consistency · claim specificity · crawler access rules for AI agents

Pass: Product schema matches visible pricing; company identity is stated once, consistently, with same-as links. Clear.

Fail: Schema asserts guarantees the visible page never makes, and robots.txt blocks every AI crawler indiscriminately. Flagged.

How to Cite This Spec

Short form

(Nebula Diagnostic Spec v1.0)

Full form

Nebula Landing Page Diagnostic Specification v1.0.0 (2026-08-22). Nebula Components. https://nebulacomponents.com/spec/landing-page-diagnostic-v1

  • Quoting with attribution and a link to the canonical URL is welcome for internal docs, client reports, playbooks, and publications.
  • Pin citations to a version: later versions never silently reinterpret audits run under an earlier one.
  • A machine-readable version of this spec is published at https://nebulacomponents.com/spec/landing-page-diagnostic-v1.json and linked from this page via link rel="alternate".
  • Retrieval and summarization by search and answer engines is permitted and encouraged with attribution; GPTBot, ClaudeBot, and PerplexityBot are allowed in robots.txt.

Versioning

This specification is versioned. Signal definitions, severity bands, and the evidence record are contractual within a major version. Additions ship as minor versions; changes to a signal's meaning ship as a new major version and never silently reinterpret prior audits.

v1.0.0 · 2026-08-22 · Initial publication. Nine signals, severity bands, evidence record.

Every Nebula audit runs against this exact specification. Run one against your landing page to see your findings with measured evidence.