# SEO Incident Response Playbook

Use this document to prepare for and coordinate unintended technical search incidents. Adapt the roles, severity definitions, approval authority, and response expectations to each client before an incident occurs.

This playbook is not a ranking-recovery promise. It separates observable public-page evidence from analytics interpretation and search-system behavior outside the team’s control.

## Quick-start incident card

- Incident ID:
- Short title:
- Opened at (UTC):
- First observed at (UTC):
- Incident lead:
- Technical owner:
- Communications owner:
- Client decision owner:
- Provisional severity:
- Affected hostname:
- Confirmed affected URLs or templates:
- Current customer or search impact:
- Last known approved state:
- Next update at (UTC):
- Current status: Investigating / Identified / Monitoring / Resolved / Closed

## Operating rules

1. Use UTC for every timestamp.
2. Keep confirmed facts separate from hypotheses.
3. Preserve the observed state before changing production.
4. Assign one incident lead with coordination authority.
5. Freeze unrelated production changes during a critical incident.
6. Prefer the smallest reversible remediation.
7. Verify the final public response, not only a CMS field or deployment status.
8. Do not promise a recrawl, ranking, traffic, lead, or revenue recovery date.
9. Do not store credentials, personal data, or private customer records in this document.
10. Close only after verification, ownership, communication, and prevention work are recorded.

## 00 — Prepare before an incident

Complete this section during normal operations.

### People and authority

- Primary incident lead:
- Backup incident lead:
- Technical owner:
- Communications owner:
- Client decision owner:
- Person authorized to freeze releases:
- Person authorized to approve rollback:
- Person authorized to publish client updates:
- After-hours contact path:

### Evidence and systems

- Public-page monitoring:
- Search Console property:
- Analytics property:
- Deployment history:
- CMS audit history:
- CDN or edge history:
- Server or application logs:
- Status page or client communication channel:
- Change log:
- Approved baseline location:
- Tested rollback procedure:

### Review cadence

- Review this playbook:
- Test contacts and access:
- Exercise one example scenario:
- Review after every material incident:

## 01 — Confirm the signal

Do not begin with a preferred cause. Reproduce what can be observed.

### Initial observation

- Reporting source:
- Exact message or alert:
- Exact public URL:
- Observation time (UTC):
- Observer:
- Reproduced from a clean request: Yes / No / Unknown
- Initial response status:
- Final response status:
- Redirect chain:
- Robots meta:
- X-Robots-Tag:
- Applicable robots.txt result:
- Canonical:
- Page title:
- Primary H1:
- Other affected protected fields:
- Screenshot, response capture, or evidence link:

### Measurement confirmation

If the signal is a traffic or visibility change:

- Compare equivalent date ranges and search types.
- Confirm analytics or Search Console collection is healthy.
- Identify whether the movement is site-wide, page-group, page, country, device, or query specific.
- Record when the movement begins; do not round the timeline to the latest release.
- Look for security notifications, manual actions, indexing problems, and data-reporting changes.
- Record seasonality, demand, search-feature, and algorithm explanations as hypotheses until supported.

Decision: Is there a reproducible public technical condition?

- Yes — preserve it and continue through declaration and scoping.
- No — keep investigating measurement, demand, security, and search-system branches. Do not make an unsupported website change.
- Unknown — name the next evidence needed, owner, and deadline.

## 02 — Declare and control

### Declaration

- Incident declared at (UTC):
- Incident lead:
- Provisional severity:
- Reason for severity:
- Release freeze started: Yes / No / Not required
- Incident record location:
- Technical work channel:
- Stakeholder update channel:
- Next update at (UTC):

### Provisional severity

SEV-1 / Critical

- Site-wide or business-critical access, response, redirect, or indexability failure.
- Examples: production homepage gains noindex; wildcard robots.txt blocks the site; critical hostname fails; migration redirects are broadly wrong.
- Initial control: declare, preserve evidence, freeze unrelated releases, assign leads, establish immediate authority and stakeholder path.

SEV-2 / High

- Important page group or template has unintended canonical, robots, content, structured-data, redirect, or response drift.
- Initial control: confirm scope, stop propagation, prepare a reversible remediation, and assign an owner in the same working period.

SEV-3 / Review

- Isolated noncritical page or ambiguous performance signal without a confirmed technical failure.
- Initial control: log, investigate, and schedule a controlled correction if warranted.

Severity is based on the current observable scope. Raise or lower it when stronger evidence changes that scope.

## 03 — Scope the impact

### Scope register

- Hostnames affected:
- Templates affected:
- Confirmed URLs:
- Representative URLs checked:
- Estimated URL group size:
- Business-critical journeys affected:
- Crawl access affected:
- Indexability affected:
- Preferred URL or redirect behavior affected:
- Search snippet fields affected:
- Structured data affected:
- Content or heading integrity affected:
- Social preview affected:
- Analytics collection affected:
- Security concern present:
- Scope confidence: Confirmed / Likely / Unknown

### Boundary questions

- Is the issue visible in the server response or only after browser rendering?
- Is it site-wide, template-wide, or isolated?
- Does staging show the same condition?
- Does the problem cross a hostname, protocol, or domain migration?
- Is the current state definitely unintended?
- Is the reported traffic or ranking movement proven to be caused by this state?
- What important systems remain unverified?

## 04 — Diagnose with a timeline

Build the timeline before choosing a fix.

| UTC time | Confirmed event or observation | Source | Owner | Fact or hypothesis |
|---|---|---|---|---|
|  |  |  |  |  |

Review:

- deployments and release flags;
- CMS edits and publishing history;
- template, theme, plugin, or dependency changes;
- redirect and routing configuration;
- CDN, cache, firewall, or edge rules;
- domain, DNS, TLS, and hostname changes;
- sitemap and robots.txt releases;
- structured-data generation changes;
- analytics or tag-manager changes;
- security alerts and unauthorized modifications;
- the last known approved public state.

### Working hypotheses

For each hypothesis record:

- hypothesis;
- evidence supporting it;
- evidence contradicting it;
- safe test;
- owner;
- result;
- confidence.

Do not label a root cause merely because a change and an incident occurred close together.

## 05 — Contain and remediate

### Change gate

- Confirmed unintended state:
- Intended approved state:
- Proposed containment or fix:
- Why this is the smallest safe action:
- Affected systems and URLs:
- Change owner:
- Approver:
- Validation check:
- Rollback value or procedure:
- Rollback trigger:
- Planned release time (UTC):
- Customer impact during change:

### Release record

- Released at (UTC):
- Released by:
- Deployment or change reference:
- Cache or CDN action:
- Errors during release:
- Rollback used: Yes / No
- Additional changes deliberately deferred:

Avoid broad cleanup during the incident. Separate unrelated improvements into later controlled work.

## 06 — Verify the full path

Verification should cover the final public response after redirects and caches.

- Original failing URL:
- Final URL:
- Response status:
- Redirect chain:
- Robots meta:
- X-Robots-Tag:
- Applicable robots.txt result:
- Canonical:
- Title:
- H1:
- Structured data:
- Representative template URLs:
- Mobile or rendered check if relevant:
- Sitemap state:
- Analytics collection:
- Search Console inspection requested if appropriate:
- Monitoring resumed:
- Recurrence window:
- Verified by:
- Verified at (UTC):
- Evidence link:

Remember: restoring the intended technical state does not guarantee when or whether a search engine will recrawl, reprocess, or restore previous visibility.

## 07 — Communicate, close, and learn

### Initial update

We are investigating [observable condition] affecting [confirmed scope]. It was first observed at [UTC time]. [Confirmed customer/search impact or “Impact is still being verified.”] We have [control already taken]. The next update will be provided by [UTC time].

### Progress update

Confirmed facts: [facts]. Working hypothesis: [hypothesis, clearly labeled]. Completed actions: [actions]. Current scope: [scope]. Awaiting: [evidence or approval]. Next update: [UTC time].

### Resolution update

The unintended state was [condition]. We restored [approved state] at [UTC time] and verified [checks and representative URLs]. [Known remaining uncertainty, including recrawl or reporting delay.] Monitoring continues through [time or condition]. Prevention work is owned by [owner].

### Closure gate

- Intended public state verified.
- Representative scope verified.
- Monitoring window completed or explicitly handed over.
- Customer update sent.
- Root cause recorded only if supported.
- Contributing factors recorded.
- Detection gap recorded.
- Prevention work has an owner and date.
- Incident record contains no secrets or unnecessary personal data.
- Playbook improvement recorded.
- Closed by:
- Closed at (UTC):

### Post-incident review

- What happened?
- What was the confirmed impact?
- What was the root cause?
- Which contributing conditions increased impact or response time?
- What detected the incident?
- What should have detected it sooner?
- Which response actions helped?
- Which response actions added risk or delay?
- What evidence was missing?
- What communication was unclear?
- What will prevent recurrence?
- What will shorten detection?
- What will make remediation safer?
- Who owns each action and by when?

## Supporting RankLatch resources

- Free SEO change checker: https://ranklatch.com/seo-change-checker
- SEO change log template: https://ranklatch.com/seo-change-log-template
- SEO monitoring template: https://ranklatch.com/seo-monitoring-template
- Sample monitoring evidence: https://ranklatch.com/demo
- Start with an approved baseline: https://ranklatch.com/login?src=seo-incident-response-playbook

Primary references:

- Google Search Central — Debugging drops in Google Search traffic: https://developers.google.com/search/docs/monitor-debug/debugging-search-traffic-drops
- Google SRE — Incident Management Guide: https://sre.google/resources/practices-and-processes/incident-management-guide/

RankLatch is read-only monitoring software. It does not edit production websites, replace security incident response, or guarantee search outcomes.