Prepare before an incident
Name the incident lead, technical owner, communications owner, backups, evidence locations, approval authority, monitoring sources, and safe rollback path before urgency removes time to decide.
Agency playbook · Markdown and CSV
SEO incident response playbook.
Confirm the signal, preserve the evidence, control production changes, verify recovery, communicate what is known, and leave a record the team can learn from.
✓ Public evidence first✓ Reversible actions✓ Client-ready record✓ Commercial use allowed
The first rule
Do not turn a scary graph into an unverified website change.
Search incidents become expensive when the response begins with a preferred theory instead of an observed state. A traffic drop can reflect a technical release, reporting failure, security problem, changed demand, seasonality, search-system update, or ordinary volatility. The job is to narrow those branches without destroying evidence or introducing new variables.
This playbook keeps the public-page investigation separate from performance interpretation. It gives one person coordination authority, puts every timestamp in UTC, records facts apart from hypotheses, and requires a verification step before closure.
Eight phases from preparation to prevention.
Use the phases in order, but let the incident lead run safe checks in parallel when the scope is large. The downloadable Markdown version includes prompts, owners, decision gates, and update templates.
Confirm the signal
Reproduce the issue from a clean public request. Record the exact URL, UTC time, response, redirect destination, robots directives, canonical, title, and source that first reported the problem.
Declare and control
Assign one incident lead, open a dated record, classify provisional severity, freeze unrelated releases, and establish who may approve containment or rollback actions.
Scope the impact
Determine whether the issue affects one field, one page, a template group, a hostname, or the whole site. Separate observed public-page impact from analytics movement that may have another cause.
Diagnose with a timeline
Compare the last known approved state with the current response and the deployment, CMS, plugin, CDN, redirect, and configuration history. Treat correlation as a lead—not proof.
Contain and remediate
Choose the smallest reversible action that restores the intended public state. Preserve the current evidence and proposed rollback value before changing production.
Verify the full path
Check the live response after caches and redirects, validate affected templates and representative URLs, confirm the intended directive or value, and watch for a recurrence.
Close and learn
Record the root cause only when supported, the exact fix, verification evidence, remaining uncertainty, customer communication, owner, and prevention work. Update the playbook after the review.
Prioritize observable scope—not anxiety.
These are starting definitions, not universal service levels. Customize the approval path and response target before using them with a client.
LevelObservable conditionInitial controlEscalation
SEV-1CriticalSite-wide or business-critical access, response, redirect, or indexability failureDeclare, preserve evidence, freeze unrelated releases, assign leadsImmediate authority and stakeholder path
SEV-2HighImportant page group or template has unintended canonical, robots, content, or response driftConfirm scope, stop propagation, prepare reversible remediationSame working period under an assigned owner
SEV-3ReviewIsolated noncritical page or ambiguous performance signal without confirmed technical failureLog, investigate, schedule correction if warrantedNormal change-control process
A severity label describes the current observed impact. Raise or lower it as stronger evidence changes the scope.
Collect enough to make the next decision reversible.
Do not paste credentials, personal data, or private customer records into the incident record. Link to restricted systems when access control is required.
Observed public state
Exact URL, UTC observation time, response and redirect chain, indexability directives, canonical, title, headings, affected template, and reproducible request evidence.
Approved comparison
The last reviewed value or release, where it was approved, when it was last verified, and whether the current state is definitely unintended or still awaiting an owner decision.
Change timeline
Deployments, CMS edits, plugins, CDN rules, migrations, domain or certificate events, and monitoring alerts around the first known change. Record facts separately from suspected causes.
Verification evidence
The exact remediation, approver, post-change public response, representative pages checked, cache state, remaining uncertainty, monitoring window, and owner of prevention work.
Communication discipline
Say what changed, what is affected, and what happens next.
A useful update separates confirmed facts, working hypotheses, actions completed, actions awaiting approval, known customer impact, and the next update time. Avoid promising recovery dates controlled by search engines or attributing a traffic change before the evidence supports it.
The downloadable playbook includes short initial, progress, resolution, and post-incident update structures so technical work and client communication use the same timeline.
The remediation gate
Prefer the smallest change that restores the approved state.
Before production is changed, capture the current value, intended value, owner, approval, validation check, rollback condition, and representative URLs. After release, verify the final public response—not only a CMS field or deployment status.
Protect an approved baseline ↗INCIDENT / CONFIRMED DRIFTProduction homepage gained noindex
APPROVED index, followOBSERVED noindex, follow↳ Preserve the response and timeline. Confirm intent, owner, scope, and a reversible restoration before release.
Primary references and tools
Use the playbook with authoritative evidence.
RankLatch can preserve public-page drift, but a complete investigation may also need Search Console, analytics, server or CDN logs, deployment history, security review, and rendered-page testing.
Google: debugging traffic dropsSeparate technical, algorithmic, seasonal, reporting, and security branches ↗Google SRE incident management guidePreparation, coordination, mitigation, communication, and learning ↗Free SEO change checkerCompare a live page with a browser-local prior snapshot ↗SEO change log templateRecord intentional work before it becomes incident evidence ↗SEO monitoring templateDefine protected pages, signals, owners, and escalation rules ↗Sample RankLatch evidenceSee exact before-and-after field changes in a workspace ↗
Response questions
Control the incident without inventing certainty.
Fast response matters. So do evidence, scope, reversibility, and honest communication.
01What counts as an SEO incident?+
An SEO incident is an unintended condition with credible search risk that requires coordinated response. Examples include a production noindex directive, site-wide robots block, broken redirect migration, invalid canonical rollout, important pages returning errors, or widespread removal of titles or structured data. A normal ranking fluctuation is not automatically an incident.
02What should I do first when organic traffic drops?+
Confirm the measurement before changing the website. Compare equivalent dates and search types, inspect affected pages and queries, check analytics collection, and look for a reproducible public technical change. Google’s debugging guidance separates site-level technical issues, page-level issues, algorithmic changes, seasonality, reporting problems, and security concerns because they require different responses.
03Should we immediately roll back the latest deployment?+
Not automatically. First preserve the current evidence, establish a timeline, and verify that the deployment changed the affected public signal. Rollback can be the safest containment when the connection is clear and the path is tested, but an unsupported rollback can add a second incident and destroy useful evidence.
04How should severity be assigned?+
Base severity on observable scope, business-critical URLs, indexability or access impact, reversibility, and time sensitivity—not on who reports the issue most loudly. The included severity matrix is a starting point; each agency should adapt authority and response expectations to its clients and staffing.
05Does a noindex tag always require a critical incident?+
Context matters. A new noindex on the production homepage or a large group of intended search landing pages is usually urgent. A noindex on a confirmation, account, search-results, or staging page may be intentional. Confirm the approved purpose before changing it.
06How does RankLatch help during an incident?+
RankLatch preserves approved public-page fields and exact before-and-after drift evidence for responses, redirects, titles, canonicals, robots directives, headings, copy, social metadata, structured data, and homepage favicon declarations. That can shorten the first question—what changed—but it does not replace Search Console, analytics, server logs, rendered testing, or human approval.
07Are the downloads free for client work?+
Yes. The Markdown playbook and CSV incident record are ungated and may be adapted for commercial client work. They contain no real client names, domains, incidents, or performance claims.
08Can this playbook guarantee rankings recover?+
No. Restoring an unintended technical state does not guarantee when or whether search systems will recrawl, reprocess, or restore previous visibility. The playbook helps teams make controlled, evidence-backed decisions and document what remains outside their control.