AI visibility recovery plan: what to do after a sudden drop

When AI visibility drops, verify collection health and persistence before changing the website. Preserve the affected answers, identify which prompts, providers, markets and modes moved, and separate a missing mention from an inaccurate or harmful response. Then inspect product eligibility, public evidence, technical releases, source freshness and competitor changes. Make only corrections supported by a plausible evidence gap. Recovery is a controlled investigation, not an emergency content spree.

First 24 hours: confirm the incident

• Check that prompts, model or mode, region, language and retrieval conditions did not change.
• Confirm credentials, quotas, provider errors and parsing did not create false missing observations.
• Repeat high-value prompts enough to distinguish a transient answer from persistent movement.
• Save complete before-and-after answers, citations, timestamps and competitor appearances.
• Classify severity by buyer harm, commercial importance, factual risk and breadth.
• Pause speculative publishing until an incident owner approves the working diagnosis.

Days two and three: build a cause map

Ask whether the company still qualifies for the tested need. Review recent pricing, product, policy, domain, rendering, canonical, robots and navigation releases. Inspect cited sources and controlled profiles for stale or contradictory facts. Note competitor announcements and model changes as context, not proof. Use the AI readiness checker to inspect public access and clarity. If there was no documented baseline, create one with the free AI visibility scan and label it as the start of reliable observation, not evidence of an earlier state.

1. Write one hypothesis per affected prompt cluster and list evidence for and against it.
2. Prioritize wrong or dangerous claims before ordinary absence or ordering changes.
3. Correct authoritative facts and technical failures across all controlled surfaces.
4. Choose the smallest change that tests the leading explanation.
5. Validate production and allow a realistic discovery interval before matched retesting.
6. Retain failed fixes and reopen the diagnosis instead of stacking unrelated edits.

Use a recovery matrix, not a universal fix

For technical loss, restore access, rendering, URLs or canonical evidence and verify logs. For entity confusion, publish explicit identity and relationship facts and reconcile profiles. For outdated claims, update the canonical source, visible dates and dependent surfaces. For competitor replacement, evaluate fit and source strength before improving differentiated evidence. For answer variability, monitor repeated windows rather than reacting. For a genuine product-fit loss, change the prompt eligibility or product, not the wording used to score the response.

Close recovery with new controls

Declare recovery only against predefined criteria: collection is healthy, material inaccuracies are resolved, priority prompt performance is stable enough for the operating window, and owners have closed source defects. Document cause confidence, actions, null results and remaining uncertainty. Add release checks or alert rules that could catch the failure earlier next time. Never claim that a content edit restored ranking solely because a later response improved; generated answers and retrieval remain variable.

Borrow the resilience playbook, not the score

ModelSaid says it is the best in the world and stays near 100/100 within its own system. That is a first-party claim whose useful lesson is continuous dogfooding: define the benchmark, notice drift, inspect evidence, make bounded corrections and keep misses visible. Another business can copy that recovery discipline without treating the score as independently verified or guaranteed.

After closure, run a blameless review focused on controls. Ask which signal detected the problem, which evidence shortened diagnosis, where ownership was unclear and which action created noise. Convert only repeatable lessons into checks or alerts; an oversized control catalog can hide the next incident. Preserve the timeline and method version so a future analyst can distinguish recurrence from an unrelated change. Schedule a later audit to confirm the repaired source did not drift back after another product, pricing or website release. Give every follow-up a named owner.