Trust, but Verify: How yeet Proves Your SEO Fixes Actually Worked
The five-stage card lifecycle, why waiting periods exist per fix type, regression detection, and the ledger that makes yeet's confidence smarter over time.
A tool that ships a fix and calls it done is making a promise it can't back up — SEO changes take time to show up, and plenty of fixes don't do what anyone predicted. yeet's answer is a card lifecycle with an explicit verification stage, and a ledger that records the outcome of every fix, whether it worked or not.
The five stages
| Stage | What triggers it |
|---|---|
| active | A card exists — a finding turned into a scoped, predicted fix |
| in_progress | yeet detects the fix actually happened — a matching commit, or content drift on the live page consistent with the fix |
| under_review | yeet re-scrapes the live page and confirms the specific fix is present, per rules for that fix type |
| verified | The metrics tied to the prediction moved at least 50% of the predicted distance |
| applied | Final state — the fix is confirmed live and its effect is confirmed real |
active to in_progress: did the fix actually happen
A card starts as active the moment an investigation turns a finding into a specific, predicted fix. It moves to in_progress once yeet has evidence the fix was actually applied — either it sees a matching commit (from an auto-applied PR, or one you merged from a copy-ready prompt), or it detects content drift on the live page consistent with what the card proposed. This stage exists so a card sitting untouched in your queue never quietly gets counted as done.
in_progress to under_review: is the fix actually there
Once yeet thinks the fix happened, it re-scrapes the live page — not the PR diff, the actual deployed page — and checks that the specific fix is present, per rules specific to that fix type. A meta_tags fix gets checked against the live title and description; a schema_markup fix gets checked for valid structured data in the page source; a technical_seo fix (removing a wrong noindex) gets checked against the live robots meta or header. This catches the fairly common failure mode where a PR merges but never actually deploys, or deploys somewhere other than where the card assumed.
under_review to verified: did it move the number
This is the stage that actually matters, and the one most tools skip. A card only reaches verified when the metrics tied to its original prediction — CTR, clicks, position, or impressions from Search Console, or new AI citations for AI-visibility fixes — have moved at least 50% of the predicted distance. Predict a 10-point CTR lift and land at 3 points, and the card doesn't verify; land at 6, and it does. It's a deliberately conservative bar: "real movement in the right direction," not "hit the exact number."
Why there's a wait, and why it differs by fix type
None of this happens instantly, on purpose. Google has to recrawl and reprocess a page before any of these metrics can reflect a change, and different fix types get different waiting windows because they behave differently in the wild: a meta tag change can show up in CTR data within a couple of weeks once Google recrawls and the SERP snippet updates, while a content change — new sections, rewritten copy, expanded coverage — realistically takes months to fully show up in rankings and traffic, because it depends on Google re-evaluating the whole page's relevance, not just re-reading one tag. Reporting "verified" before that window has run its course wouldn't be honest, so yeet holds cards in under_review until the fix-type-appropriate window has passed and the check runs again.
A verifier sweep runs every 30 minutes checking every card currently sitting in under_review, so as soon as a card is eligible to be re-checked, it gets re-checked promptly. The wait is about giving Google time to recrawl, not about yeet being slow to look.
Regression detection
Verification isn't a one-time pass or fail either. yeet keeps watching verified fixes for regressions — if a metric that moved in the right direction starts sliding back (a title tag got reverted in a later deploy, a noindex crept back in, a competitor change ate the CTR gain), that gets caught by the same watcher cycle covered in the weekly SEO workflow, and can reopen a card rather than leave a stale "verified" label sitting on something that no longer holds.
The fix_outcomes ledger
Every card that reaches a terminal state — verified or not — gets recorded in yeet's fix_outcomes ledger: the fix type, the prediction, the actual metric movement, and whether it cleared the 50% bar. This isn't just a record for your own history. It's the input that makes yeet's confidence scoring smarter over time — the same confidence score that gates auto_apply_safe, auto_apply_aggressive, and auto-merge. A fix type that verifies reliably across many sites earns a higher baseline confidence; one that verifies inconsistently doesn't, regardless of how convincing any individual card's prediction sounds. In practice, the autonomy thresholds aren't fixed forever — they're backed by an actual track record that keeps updating.
What this means day to day
If you're on propose_only, the lifecycle runs the same way whether you clicked apply yourself or yeet opened the PR — verification doesn't care how the fix got there, only whether it's live and whether it worked. And "applied" doesn't mean "we're done thinking about this page" — a page that regresses later gets caught by the same machinery. For what a hands-off, fully verified fix costs versus a fix you apply yourself, see the credits guide; for what a card actually contains before any of this starts, see optimization cards explained.
Quick FAQ
What if a fix never gets applied at all? The card just stays active — it never enters the verification pipeline, since there's nothing yet to check.
Does a verified card ever get un-verified? Yes — regression detection can catch a later revert or a metric sliding back and reopen the card rather than leave an inaccurate label on it.
Why 50% of the predicted distance instead of 100%? Predictions are estimates, not guarantees, made in a system with a lot of external noise — Google's own algorithm changes, seasonality, competitor moves. Requiring the full predicted number would reject fixes that clearly worked but landed short of an inherently uncertain estimate.