Baselines and diffs
Signal Diff compares each crawl to a baseline—a prior run on the same sitemap—so you see what changed between deploys, not just a static issue list.
On this page
What is a baseline?
A baseline is the prior completed crawl Signal Diff uses as the “before” picture when diffing your current run. Baselines are always scoped to the same monitored site (the same normalized sitemap URL on your account).
- Your first run on a site has no baseline—there is nothing to compare yet.
- From the second run onward, the deploy diff card and trend views compare against a baseline automatically.
- The run detail header shows which baseline was used, for example Compare #abc123 → #def456 with the baseline start time.
Scheduled and manual dashboard runs share the same site history. CI runs use the same diff machinery but may pick a different automatic baseline (see CI baselines).
New regressions vs resolved issues vs raw counts
The deploy diff focuses on what crossed the line between two runs—not whether your site has more warnings in absolute terms.
| Signal | Meaning |
|---|---|
| New finding(s) | Regressions: checks that appear on this run but were not present on the baseline for that URL and check. These are what CI gates and triage usually care about first. |
| Resolved | Issues that cleared since the baseline—the same check on the same URL no longer fires. |
| URLs changed | Pages whose crawled fields differ between runs (status, title, meta description, visible word count, or finding fingerprints)—even when the finding set looks similar. |
| Errors / warnings / info totals | Raw counts for this run only. A run can show fewer total errors than the baseline while still reporting new regressions on specific URLs. Use the diff chips for deploy impact; use severity totals for overall site health. |
The headline and impact summary on the deploy diff card summarize severity from new and resolved findings and URL churn. Lists under New vs baseline and Resolved since baseline show concrete examples (up to eight each in the UI).
Reading the deploy diff card
On a completed run’s report, the deploy diff appears above the findings table when a baseline exists. Open any run from the dashboard job history to see it.
- Severity label — Overall tone (for example clean, mixed, or regression-heavy) from new vs resolved findings.
- Headline and impact — Plain-language summary of what changed.
- Diff chips — Counts for new findings, resolved findings, and URLs changed.
- Field diff strip — When useful, a before/after example for one URL (see Field-level diffs).
If you do not see a deploy diff, the run may be first on that site, still running, or missing stored page detail. Older runs may have been pruned (see Run history).
Automatic baseline vs manual override
By default Signal Diff picks the baseline when the run completes. You do not need to configure anything for the deploy diff to appear.
Automatic selection (manual and scheduled runs)
For dashboard and scheduled crawls, the automatic baseline is the most recent completed run on the same site that finished before this run started.
Compare dropdown (manual override)
On a signed-in run report, use the Compare control in the report header to pick a different baseline from your saved history. The first option is labeled (automatic) and matches the server’s default. Choosing another run rebuilds the diff client-side from stored page payloads.
Override when you intentionally want to compare against an older deploy (for example before a hotfix) or exclude a bad intermediate run from the story. Your selection applies to the current view; the stored automatic baseline on the job record is unchanged.
Field-level diffs
Below the finding lists, Signal Diff may show a Field diff for one representative URL:
- Title and meta description — Before (baseline) and after (this run) snippets, including HTTP status when relevant.
- Visible word count — When thin-content or word-count checks drive the diff, the example shows counts per run instead of meta tags.
This strip illustrates how the site changed on a real page. The chips and new/resolved lists remain the primary signal for deploy review and CI.
CI runs: commit context and baseline selection
Runs triggered from CI (GitHub Actions or the API with an API key) are labeled CI on the report. The run detail shows repository, commit, branch or tag, pull request, and a link to the workflow run when provided.
CI baseline selection is designed so pipeline diffs compare like with like:
- Prefer the previous CI run on the same GitHub repository and sitemap that completed before this run—even if you ran manual scans in between. Example: CI run A, then a manual spot-check, then CI run B → B’s baseline is A, not the manual run.
- First CI run on a repo/site — If there is no earlier CI run, the baseline falls back to the latest completed run on that site (which may be manual or scheduled).
- Manual dashboard runs — Always use chronological “previous completed run on this site,” including CI runs in the timeline.
That difference matters when you mix ad-hoc production scans with per-PR crawls: CI regressions stay tied to the last pipeline baseline, not an unrelated manual crawl the same afternoon.
Wire CI from Developers → API keys or the signal-diff-action GitHub Action. CI access requires a paid plan; see Pricing.
30-day run history
On all plans (free and paid), completed runs and their full report payloads are kept for 30 days from run completion (UTC). After that, runs are pruned from history—you can no longer open them or use them as a compare baseline.
Paid checkout does not extend this window—it unlocks CI, cross-environment compare, higher concurrency, and customer agents instead. See the Plans and limits feature matrix. If a baseline job ages out, the next run may behave like a fresh baseline until you have two retained runs again.
Anonymous try-a-scan flows show the latest result only; sign in to save sites, history, schedules, and diffs across runs.
Cross-environment compare (paid)
Deploy diffs compare runs on the same monitored site. When you need to diff different hosts—staging vs production, or Dev / Test / Prod sitemaps—use Cross-environment compare on the dashboard.
Path-aligned matching ignores host and query strings so equivalent pages line up across environments. Same-site deploy diffs remain on the free plan; cross-environment compare requires a paid subscription.
Next steps
- Getting started — First monitored run and dashboard overview.
- SEO checks reference — What each finding type means.
- CI and GitHub Actions — Trigger runs from pipelines.
- Cross-environment compare — Dev / Test / Prod path-aligned diffs (paid).
- Dashboard — Run a scan and open the deploy diff on your latest complete job.