📘 This use case demonstrates investigating whether a change made on your pages explains differences observed in traffic or ranking.
Best for: Search teams investigating a shift in rankings or traffic · Uses: project annotations and Search Console data, via your AI assistant
Overview
When traffic or rankings move, the explanation is often already recorded on the project as an annotation: a migration, a template change, a campaign, an incident. Botify MCP can pull the annotations for a period and the Search Console performance either side of one of them, so the two can be read together.
Prerequisites
Botify MCP connected to your AI assistant, such as Claude or ChatGPT. See Connecting to the Botify MCP for setup steps.
Google Search Console connected to the project.
Annotations logged on the project for the period in question. This check is only as good as what the team recorded.
Description of the problem
A drop is usually noticed weeks after the change that caused it, by which point several things have changed. The annotations sit in Botify, the performance data sits in Search Console, and lining them up by hand means exporting both and matching dates.
Application
Ask what was logged around the shift:
Clicks on /hiking-boots/ dropped in August for acme-outdoors.com. What annotations are logged between 15 July and 15 September?
Why this prompt works:Naming an explicit period returns everything logged in the window, not only the change you already suspect.
Asking what was logged, rather than what caused the drop, keeps the answer to recorded events. The assistant cannot know the cause, and a prompt that asks for one invites a guess.
Review the annotations in the window. More than one will usually fall inside it.
Ask for performance either side of the annotation date:
Show clicks, impressions, and average position for /hiking-boots/ for the 30 days before and the 30 days after 12 August.
Why this prompt works:
Naming both windows explicitly is what produces a before-and-after comparison. Search Console lookups through MCP default to fixed trailing windows of 7, 30, or 90 days, which cannot straddle a date you choose, so the comparison has to be asked for by date.
Asking for impressions and average position alongside clicks is what separates a demand change from a performance change. Clicks falling while impressions hold is a different problem from both falling together.
Read the two together, and account for anything else in the window before attributing the change. Two events in the same 30 days cannot be separated by this comparison alone.
Follow-up prompts
"Which queries lost the most clicks between those two windows?" — narrows a page-level drop to specific terms.
"Run the same comparison for the rest of the category template." — checks whether the change hit one page or the template.
"What was annotated on this project in the same window last year?" — separates a site change from a seasonal pattern.
Make it repeatable
Annotate changes as they ship. This check works only when someone recorded the change; an unannotated release is invisible here.
Use the same window length on both sides of the date. Comparing 30 days after against 90 days before produces a difference that is an artifact of the windows.
Result
The recorded changes and the performance either side of them in one answer, which is enough to say whether a shift lines up with a change in time. It is a correlation, not a cause.
Read next
Related topics