Traffic from fixes
How SEOFix measures the Search Console clicks of the pages you fixed - the 28-day baseline, the 7, 14 and 28 day measurements, "no data", and the caveats.
Every time Verify fix marks a task fixed, SEOFix records a fix event: the 28-day Search Console clicks of the task's affected pages at that moment (the baseline). It then measures the same pages 7, 14 and 28 days later. The result is shown as "+X clicks/28 days vs before the fix (estimated, not seasonally adjusted)". Without Search Console data the result is "no data", never 0.
Where to see it
- Dashboard: the "Traffic from fixes" card, across all your team's sites.
- Site page: the same card for one site, shown when the site is verified or already has fix events.
The card's headline is the measured total. While fixes wait for their 28-day measurement it shows "Measuring." and roughly when the first result lands. If none of the fixes had Search Console data it shows "No Search Console data for these pages." with a prompt to connect Search Console. Each fix lists its "7 days", "14 days" and "28 days" change against its baseline, or "measuring" or "no data".
How a fix event is recorded
- You (or your agent) run Verify fix on a task and the result is
fixed. - SEOFix stores a fix event with the task, its check code and template, the recheck id and the affected pages: up to 5,000 pages, counted once per
www/scheme/trailing-slash variant. If the recheck was sampled (tasks over 200 pages), the event still covers all affected pages up to 5,000. - If the site has fresh Search Console data, the baseline is the sum of the 28-day clicks (and impressions) of those pages.
Fresh Search Console data means all of these are true:
- the site's ownership is verified;
- its Search Console connection is active;
- it synced within the last 8 days;
- page-level stats exist for the site.
If any is false, the baseline is null, the event's status is no_data, and it is never measured. Connecting Search Console later does not backfill it; the next fixes you verify are measured.
One task gets at most one fix event per recheck, and a task verified again within 28 days of an existing event does not get a second, overlapping one.
How it is measured
Measurements happen during the Search Console sync, right after new page stats arrive. Each slot is filled once, when its offset from the verification has passed:
| Slot | Filled once this many days after verification | Field |
|---|---|---|
| d7 | 7 | d7, measured at d7_at |
| d14 | 14 | d14, measured at d14_at |
| d28 | 28 | d28 (and d28_impressions), measured at d28_at |
Each value is again the 28-day clicks of exactly the same pages as the baseline. The sync runs daily or weekly depending on your plan, so a slot can be filled a few days after its due date; the _at timestamp says when.
delta_28d = d28 - baseline_clicks_28d for one fix. It is null until d28 is measured.
Reading the numbers
| Status | Meaning |
|---|---|
no_data |
No Search Console data at verification. All numbers are null. |
measuring |
Has a baseline; d28 not measured yet. d7 and d14 may be filled. |
measured |
d28 is in; delta_28d is set. |
null always means "no data" or "not measured yet". It is never the same as 0 clicks.
The total (total_delta_28d) adds up the measured fixes, counting each page once. When several fixes share a page, the page belongs to the earliest fix with a baseline and counts only once that fix is measured. measured_events is how many fixes have their d28. The total is null until at least one fix is measured.
Caveats
- Estimated, not seasonally adjusted. The comparison is before and after on the same pages. Seasonality, other site changes, algorithm updates and demand changes all show up in it.
- d7 and d14 are a trend. Search Console's 28-day window is rolling and ends about 3 days before each sync, so d7 and d14 still overlap the baseline window. d28 is nearly non-overlapping.
- Indexing takes time. Google has to re-crawl the fixed pages before rankings can move.
- Only fixes verified with Verify fix count. Tasks that need a full audit to confirm (
recheckable: false) do not create fix events.
Report the result as "+X clicks/28 days vs before the fix (estimated, not seasonally adjusted)".
For agents
| Action | REST API | MCP tool |
|---|---|---|
| Team total and latest fix events | GET /v1/fix-impact?limit=10 (1–50, default 10) |
get_fix_impact without site_id |
| One site's fix events and total | GET /v1/sites/{id}/fix-impact?limit=50 (1–200, default 50) |
get_fix_impact with site_id |
curl -s "https://api.seofix.ai/v1/sites/42/fix-impact?limit=5" \
-H "Authorization: Bearer $SEOFIX_API_KEY"
{
"site_id": 42,
"total_delta_28d": 2310,
"measured_events": 3,
"events": [
{
"task_key": "3f9c2a71b0d4e8a6",
"code": "TITLE_TOO_LONG",
"template": "/jobs/[slug]",
"recheck_id": 9188,
"urls_count": 1840,
"sampled": true,
"verified_at": "2026-09-01T10:12:00.000000Z",
"baseline_clicks_28d": 5210,
"d7": 5390,
"d14": 5820,
"d28": 6640,
"delta_28d": 1430,
"status": "measured"
}
],
"note": "estimated, not seasonally adjusted",
"methodology": "Clicks are Search Console 28-day clicks summed over the fixed task's affected pages ..."
}
The team endpoint adds site_id and site_host to each event. Events also carry id, baseline_impressions_28d, d7_at, d14_at, d28_at, d28_impressions and measured_at.
Related
More in Fixes
Still stuck? Email [email protected] with your site and what you expected to see.