domains / marketing / seo-drift-monitoring / seo-drift

seo-drift

Skill card

combined

The first copy is a thin pointer that delegates to a WORKFLOW.md file not included in the prompt, so it contains no executable steps. The second copy is a self-contained, detailed procedure. Because the first copy's actual procedure is missing and the second copy adds substantial steps, constraints, and severity rules not present in the first, crowning one would hide the real alternative. The second copy is the only one with actionable content, but the first copy's delegation pattern is a distinct structural choice that should be noted.

Repositories

Other copies

Combined skill

# SEO Drift Monitoring

## Overview
Capture a known-good SEO baseline and compare later snapshots against it so regressions become visible. The skill combines search-performance data with live on-page checks to surface ranking drops, deindexation, overwritten metadata, directive changes, and missing schema before they quietly cost traffic.

## When to Use
Use this skill when the user asks to:
- baseline or monitor a site's SEO over time;
- check whether a migration, redesign, CMS change, or redeploy damaged SEO;
- compare current search performance and page metadata with a prior snapshot;
- investigate titles, descriptions, canonicals, robots directives, or schema that changed unexpectedly;
- identify rankings or indexed pages that disappeared.

For a one-time comprehensive SEO audit with no historical comparison, use a general SEO audit skill instead.

## Prerequisites
Before capturing data:
1. Confirm the site and the key URLs in scope. Prefer top organic landing pages, commercial pages, and any URLs affected by a recent release.
2. Confirm baseline or compare mode. If no prior snapshot exists, use baseline mode and explain that there is nothing to compare yet.
3. Ask where the snapshot should be stored. Use a local `seo-drift/` directory alongside the user's other audit reports only after confirming the intended project or reports location.
4. Prefer a connected Google Search Console source for query, page, position, impression, click, and indexation signals.
5. Use a browser or web-fetch capability for current on-page values. Respect robots directives and avoid high-volume crawling.

If Search Console is unavailable, continue only with the on-page comparison and state that ranking and indexation drift could not be measured. Never infer missing Search Console values from a live crawl.

## How It Works

### 1. Choose the comparison boundary
Record:
- the site property and snapshot date supplied by the user or runtime;
- whether the snapshot is a baseline or comparison;
- the prior snapshot used for comparison, when applicable;
- the exact URL set and search-data window;
- any known migration, release, or CMS event that may explain expected changes.

Do not invent dates or silently compare mismatched date windows.

### 2. Capture the current snapshot
For the agreed URL set, collect:
- **Search performance:** query and page clicks, impressions, click-through rate, and average position for a stable window;
- **Indexation:** indexed status or coverage evidence for each key URL when the connected source exposes it;
- **Metadata:** title, meta description, and H1;
- **Directives:** canonical URL, robots header, and meta-robots value;
- **Structured data:** schema types present;
- **Content shape:** word count and another stable content fingerprint or summary useful for detecting large changes.

Persist both the values and their source. Keep unavailable fields as `unknown`; do not coerce them to zero or absent.

### 3. Diff against the previous baseline
Surface changes in five groups:
1. **Rankings:** queries that dropped by the agreed threshold or disappeared from the observed window.
2. **Indexation:** key pages that lost indexed status or a material drop in indexed-page count.
3. **Metadata:** titles, descriptions, or H1s that changed, became blank, or fell back to a generic template.
4. **Directives:** canonicals that changed or disappeared, and newly introduced `noindex` directives.
5. **Schema:** structured-data types that disappeared from pages where they previously existed.

Separate expected content changes from unexplained regressions. A changed value is evidence of drift, not proof of causation.

### 4. Rank severity
Use these default levels:
- **Critical:** an important page is newly `noindex`, deindexed, or canonicalized to an unintended URL.
- **Warning:** a material ranking decline, lost query visibility, blank or generic metadata, or missing schema.
- **Info:** an expected content or metadata change with no observed search-performance harm.

Put directive and indexation failures first because they can suppress the entire page regardless of content quality.

### 5. Report and preserve evidence
For every reported change, include:
- URL and field or metric;
- before and after values;
- comparison dates and data window;
- severity and likely cause, clearly labeled as an inference;
- the next verification or repair action.

End by offering to create a new baseline only after the user confirms that intended changes and critical repairs are complete.

## Best Practices
- Keep the key URL set stable so comparisons remain interpretable.
- Compare equivalent Search Console windows and call out incomplete or delayed data.
- Preserve raw snapshot evidence separately from the narrative report.
- Treat missing data as unknown, not zero.