# 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.

Source: https://seofix.ai/help/traffic-from-fixes · Category: Fixes · Updated: 2026-10-08

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

1. You (or your agent) run [Verify fix](https://seofix.ai/help/verify-fix.md) on a task and the result is `fixed`.
2. 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.
3. 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` |

```bash
curl -s "https://api.seofix.ai/v1/sites/42/fix-impact?limit=5" \
  -H "Authorization: Bearer $SEOFIX_API_KEY"
```

```json
{
  "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

- [Verify a fix](https://seofix.ai/help/verify-fix.md)
- [Fix tasks and the Top 3](https://seofix.ai/help/fix-tasks-and-top-3.md)
- [Connect Google Search Console](https://seofix.ai/help/connect-google-search-console.md)