How to Diagnose an Organic Traffic Drop with Claude or ChatGPT

Organic traffic is down, and every explanation sounds plausible. A deployment happened last week. Someone changed page titles. A competitor published a new guide. Google announced an update. Rewriting pages immediately can make the original cause harder to identify.

The useful first deliverable is a diagnosis memo: which traffic fell, when the decline began, which explanation has evidence, and what observation would distinguish the remaining possibilities. Claude or ChatGPT can organize that investigation. RankParse can add current public-page evidence to the historical search and analytics data you supply.

Start with one affected section and a few comparison pages. A small investigation that identifies a broken template is more valuable than a sitewide list of unrelated warnings.

Establish whether the loss is real

“Organic traffic” can mean Search Console clicks, analytics sessions attributed to organic search, engaged sessions, or conversions from those sessions. These measures describe different stages of a visit and will not reconcile perfectly.

Check each separately. If analytics sessions collapse while Search Console clicks remain broadly stable, investigate measurement, consent changes, channel rules, and landing-page tracking before concluding that search visibility disappeared. If clicks and sessions both decline, a search-side explanation becomes more plausible. If conversions fall while visits hold steady, investigate the offer, forms, checkout, and visitor mix.

Avoid comparing an unfinished week with a complete week. Use completed reporting periods with the same number of weekdays and consistent search type, country, device, and property filters. Note reporting delays. For a seasonal business, add the equivalent period last year, adjusting your interpretation for holidays that move between dates.

Record the first observable change as a range rather than forcing an exact hour from daily data. A gradual decline over months calls for a different investigation from a sharp break after a release. The chart establishes timing; it does not establish causation.

Assemble a packet the assistant can reconcile

Connect the RankParse MCP server to Claude or ChatGPT. The secure OAuth connector provides read-only research tools, including current page and site checks. It does not directly retrieve Search Console reports. Supply those exports yourself for this workflow. The separate API-key endpoint has connected integration tools, but that is a different setup.

Prepare these inputs before asking for a cause:

Record export filters and missing dimensions. Search Console query rows can omit information, and their sums need not match an unfiltered chart total. Keep that gap visible. Do not have the assistant invent an “other queries” breakdown or allocate missing clicks across pages.

Use the inventory to label useful groups: documentation, product pages, editorial guides, country sections, or template families. Preserve original URLs before joining datasets. Removing parameters or merging hostname variants without checking their meaning can conceal the very migration problem you are investigating.

Stage 1: locate the decline before fetching pages

The first prompt should consume the files, not launch a broad technical audit.

Analyze the attached completed-period search and analytics exports.
Keep their metrics and filters separate. Identify the page groups that
explain the largest absolute loss in clicks, then compare sessions and
conversions where the supplied data supports it.

Return: affected group, onset range, lost clicks, device/country pattern,
comparison group, relevant release events, and missing evidence.
Separate observations from hypotheses. Select at most six affected URLs
and three unaffected comparison URLs for current-page verification.
Do not call tools yet or attribute the loss to an algorithm update.

Absolute loss helps locate the work. A small page can lose most of its traffic without explaining the business problem. Conversely, a moderate decline across many important pages can matter more than one dramatic percentage.

Choose comparison URLs deliberately. For a changed article template, use unaffected articles if any exist, plus a different template. For a mobile-only decline, compare desktop performance on the same page group. A comparison group is imperfect evidence, but it helps test whether the proposed cause should have affected more of the site.

Check whether the group definition survived the period. If URLs moved from /learn/ to /guides/, declining traffic to the old folder can coexist with stable combined traffic. Aggregate the mapped old and new URLs before announcing a loss.

Stage 2: collect current evidence with RankParse

For the selected URLs, get_page_seo accepts url and returns a structured view of the fetched HTML. Ask for fields you can interpret, rather than an assistant-generated health score.

Use RankParse get_page_seo for the nine approved URLs, reusing results
for duplicates. Retain status_code, final_url, canonical.url, robots.raw,
title.text, headings.h1, and headings.h2 with the retrieval time.
Compare each result with the supplied inventory and historical evidence.

Use get_site_health with our bare domain only if the pattern suggests a
shared access or robots problem. Flag contradictions and fetch failures.
Do not infer Google indexing, a full redirect chain, rendered body copy,
or actual internal-link destinations from these results.

The Page SEO documentation explains the important distinctions. status_code is the target response status; a successful tool response does not mean the page itself returned a successful status. final_url identifies where the fetch ended after redirects, without listing every hop. canonical.url is the page's declared canonical, not Google's selected canonical.

Likewise, robots.raw describes the robots meta tag. A permissive value does not prove indexability: robots.txt, HTTP headers, access failures, and Google's indexing decisions require separate checks. The tool parses raw HTML and does not execute the browser application. A client-rendered heading missing from this response may require browser and rendering inspection rather than a content rewrite.

get_site_health takes a bare domain. Its robots_txt.disallow_all flag is a heuristic, not a complete robots rules parser. Read the actual file before concluding that the site blocks all crawling; the flag can trigger on a subpath rule. Failed optional probes can also leave null values. The Site Health docs describe those cases.

The scope in this prompt is a working instruction, not an enforced execution cap. Check the proposed calls and their results before authorizing a broader investigation.

Read the pattern as competing explanations

A diagnosis gets stronger when an explanation predicts something you can check.

None of these patterns is conclusive alone. Average position can change because the set of queries changed. A sitewide click-through rate can fall because low-position queries gained impressions. Inspect consistent query groups before treating aggregate ratios as a page-level problem.

Search results also change independently of your pages. Human inspection may reveal that a query now favors video, product listings, or a different interpretation. Save the query, location, device, date, and observation. One search is a current sample, not historical proof of what every user saw.

An announced Google update is context. It does not explain why one directory lost traffic while another gained. Check the timing and scope against your evidence, and use Google's traffic-drop guidance for the broader investigation. Do not label a decline a penalty without supporting information such as a relevant manual action in Search Console.

Illustrative example: a release becomes a testable suspect

The following packet and observations are illustrative, not a real RankParse run or a customer result.

A software company sees documentation clicks fall from 1,200 to 720 across two comparable completed periods. Product-page clicks remain similar. Analytics sessions to documentation also decline. The release log records a documentation layout change near the onset; the query export shows losses distributed across several established documentation topics.

The assistant selects four affected documentation pages and two product-page comparisons. In the hypothetical RankParse results, all four documentation URLs return status_code: 200, but their canonical.url points to the documentation homepage. The comparison pages declare their own URLs. Earlier saved HTML shows self-referencing canonicals on the documentation pages.

That transforms “traffic fell after a release” into a specific hypothesis: the layout change introduced incorrect canonical declarations across the affected template. It still does not prove Google consolidated those pages or that this accounts for every lost click.

The next decision is to inspect the template source, check representative URLs in Search Console, and confirm the intended canonical policy with the owner. If confirmed, create a template correction ticket before briefing writers to expand the articles. Preserve unaffected comparison pages and the original export for later evaluation.

If the historical HTML instead showed the same canonical pattern months earlier, the release explanation would weaken. The defect could still deserve attention, but the memo should no longer present it as a newly demonstrated cause of the drop.

Stage 3: produce a diagnosis memo with a stopping rule

Write a one-page diagnosis memo using only the supplied exports and
verified observations. State the affected metric and cohort, then rank
at most three hypotheses by evidence strength.

For each, give supporting evidence, contradictory evidence, missing
checks, owner, and the smallest reversible next action. Distinguish a
confirmed defect from a proven cause of the traffic change. Include a
stop condition: what finding would make us abandon this hypothesis?
Do not draft sitewide content changes or promise a recovery date.

Use this reusable deliverable:

A useful stop condition might be: “If the original deployment did not change canonical generation, and saved pre-release pages show the same declarations, investigate another cause before linking the decline to that deployment.” This prevents a plausible narrative from becoming unquestioned fact.

Handle gaps without turning them into findings

If RankParse fetches a bot challenge, inspect the response title and compare it with a normal browser visit. The tool may be describing the challenge page. Record that limitation, supply verified page evidence, and avoid repeated calls that reproduce the same block.

If no historical page evidence exists, label the condition “observed now, start date unknown.” You can still fix an unintended noindex; you cannot honestly claim when it began. If analytics was reconfigured during the comparison, pause session-based conclusions and use the search evidence separately until measurement is reconciled.

If the losses are spread across unrelated pages and no shared defect emerges, resist expanding into an endless list of audits. Select one high-value query group, inspect its intent and competing results, and test a narrower content explanation. The content refresh prioritization workflow is appropriate once you have evidence that content relevance is the likely problem.

Verify the fix separately from the recovery

After an owner ships a correction, repeat the relevant RankParse page checks on affected and comparison URLs. Confirm that the exact defect changed. A correct canonical declaration or restored response is an implementation result you can verify immediately.

Search recovery is a later observation. Set a review window appropriate to traffic volume and crawl behavior, preserve the original segments, and log other releases that could confound the comparison. Watch query coverage, clicks, and relevant business outcomes without declaring victory after one better day.

Begin with the export packet and the first classification prompt. Finish the session with one evidence-backed next action and its owner. That gives the team something concrete to resolve while preserving the information needed to learn what actually happened.