Which metric actually dropped? Confirm that first.

“Rankings dropped” first needs to become a description you can verify. Did the position of one query change, or did the average position in Search Console change? Did organic clicks fall, or did GA4 simply record fewer of them? If you haven’t even pinned down the metric, the discussion that follows easily mixes different problems together.

I suggest fixing the comparison conditions first: the same property, comparable dates, search type, region, and device. Check whether a filter was left on, and also account for weekdays, holidays, and seasonality. The point isn’t that every period must be identical, but that known differences stay explicitly in the record.

Don’t replace the whole period’s performance with one position from an ad-hoc search of your own. A single result can be shaped by the conditions you observed it under, and Search Console’s average position also shifts as the mix of queries and pages changes. Go back and keep checking against the same queries, pages, and conditions; for the relevant method, see the different ways to check Google rankings.

If overall clicks fell but your site analytics setup was also changed around the same time, check the measurement records as well. One tool losing data isn’t enough to prove that search impressions really fell; conversely, normal analytics can’t rule out a change on the search side either. Google’s official documentation on debugging search traffic drops likewise reminds you to check for data anomalies and different causes.

Is it the whole site, one kind of page, or one query?

Locate the scope first, then pick the most informative samples to check. I group affected pages by directory, template, language, and task, and check whether they cluster in a certain kind of product page, article page, or language version. At the same time, keep a comparison page with similar conditions that did not drop, so you don’t declare the whole site broken from looking only at the failing pages.

Totals and composition have to be kept separate. Search Console’s breakdowns by query or page tell you where the change is concentrated; you can’t just add the detail rows together and call it the total. The overall chart, or an appropriate dimension-free query, is what verifies the total, while the detail rows find the composition; your own exports also need to state their dates and filter conditions.

The table is a set of triage leads, not a formula for inferring cause from a curve. Once you’ve located things, look at Search Console page and query diagnostics and add the actual evidence next to each judgment. State the sampling scope too; you can’t present a check of a few samples as the whole site passing.

How should I check the site changes made before the drop?

The earlier you record the timeline, the fewer misjudgments you’ll make. I’d suggest listing the actual changes: URL adjustments, migrations, theme or template edits, body-copy rewrites, language configuration, caching, and analytics deployment. Record the actions that happened, not a memory-picked action that looks most like the cause.

Then compare the scope the change affected with the scope of the drop. If you only edited one article but claim it explains a site-wide decline, you need more evidence; if pages under the same template misbehave together, that template is worth checking first. Sequence in time is only a lead; it cannot prove causation on its own.

Pages changed recently should be compared against backups. Do the titles, body copy, internal links, canonical URLs, and redirects still match the original task? After a redesign, “looks about the same” doesn’t replace a content check. Especially with bulk rewrites, verify that correct specifications, conditions, or buyer questions weren’t accidentally deleted.

If logs or backups can’t be found, state honestly that the timeline is incomplete; don’t fill in a precise date. Write the gaps down clearly, and revise your judgment later if records turn up. For how to read diagnostic evidence, see the evidence and priorities in an SEO diagnostic report.

If crawling or indexing breaks, where do I look first?

First confirm that the target URL opens correctly, lands on the expected page, and that the important body content is really there. Check not just the homepage in a browser but also the affected directories, key detail pages, and the corresponding language versions. Server errors, wrong redirects, or empty template content all need specific URLs and response evidence.

Then check the crawling and indexing directives. robots.txt, noindex, and canonical are not the same signal; seeing one isn’t grounds to draw a conclusion about the other two. Google’s official guidance on blocking indexing notes that a crawler has to be able to access the page before it can read the noindex directive on it.

A page check should look at both the current version and the crawled version. The live page being fine doesn’t mean the search system has read the latest edit; an indexed record likewise doesn’t guarantee that the template is healthy right now. You can use the official documentation for the URL Inspection tool to understand the different inspection states, then go back to the actual evidence.

One of our own canary records left a reminder: that batch of pages was later indexed 7 out of 7, but only 2 out of 7 had impressions. Indexing and earning search impressions really do need to be recorded separately, and this observation doesn’t support promising when rankings will follow after indexing. For the related steps, see the difference between discovery, crawling, indexing, and ranking.

You can continue checking directives in the order given in robots, noindex, canonical, and sitemap: the order to check them. Performance also needs measuring: keep the device, network, and actual page conditions, rule out a local connection problem, and don’t turn one wait time into a claim of server degradation.

The pages still work; how do I check demand and results-page changes?

Once the technical checks pass, move on to checking the task the searcher wants to complete. Open the target query’s results in the same market and language, and see whether the dominant pages have shifted from an explainer article to product pages, comparison pages, or official technical documentation. Record the specific results; you can’t sum up every change with “competition is fiercer now.”

If impressions are similar but clicks fell, I’d suggest looking at how results are presented and whether the title and snippet still help readers decide, while also checking the query mix. Other answer formats appearing in the results are only a candidate explanation; you need corresponding observations, and you can’t attribute every click decline to AI summaries.

Demand shifts can also be checked against industry information and trend data. Fewer searches for one kind of query on our site doesn’t automatically mean demand across the industry has fallen; you need to look at the relevant external evidence. If you haven’t checked, write “not ruled out”; don’t make a confident claim to cover for missing data.

When working on content, prioritize filling in the facts the target task requires. If buyers want supply terms but the page piles up conceptual explanations, adjust the information; if readers need to verify specifications and the data isn’t confirmed, get the material first. For the specific method, see checking page content against search intent.

When is there grounds to suspect an algorithm change?

Check the official update records first, then compare the timing and the affected scope. Google’s traffic-drop guide lists algorithm, technical, security, demand, and migration among the possible factors, and cautions against drastic changes over minor fluctuations. An official update having happened doesn’t mean it explains your site’s problem.

Security issues and manual actions also require actually looking at the relevant reports. Google’s security issues report and manual actions report provide different evidence; if you haven’t looked, you can’t say neither exists just because no email arrived.

My approach is to ask: what other data could overturn the current explanation? If a single misconfigured setting would produce the same curve, you can’t rule it out on the curve alone. Check that potentially disconfirming data first, then decide whether content changes are needed. Explanations you can’t distinguish stay on the list as candidate causes.

How should fixes and retests be sequenced to keep the evidence intact?

Schedule fixes for confirmed problems. Save the original values and the affected pages, write down what you’re changing, why, and how to roll back, then make a change with a clearly defined scope. Don’t let one kind of page misbehaving lead you to rewrite the whole site’s content or wipe data that’s still correct.

After the change, read back the page and configuration first, confirm the problem is really gone, and then watch crawling and search performance. A technical fix passing, the search system reading it, clicks changing, and real inquiries improving are different stages. Report only the stage you have evidence for; don’t write a successful save as a recovered ranking.

Retests should keep the original dates, devices, and data definitions, and reopen the specific pages that had problems. Fix one sample and report that sample; to say a whole class of problems is cleared, you must state the full scan scope. For related reporting, compare with result boundaries in an SEO monthly report.

I keep unverified items in the triage record until evidence arrives or they’re explicitly dropped. A foreign-trade business owner needs to know which uncertainty the next check can resolve, rather than hearing “algorithms are hard to judge” and stopping there. The test materials and their limitations can be found at the research records entry point.

What other common questions come up in ranking triage?

Does a drop in clicks always mean a drop in rankings?

Not necessarily. Check impressions, position for the same queries, click-through rate, how results are presented, and the measurement conditions together; a single total can’t determine the cause directly.

If a page opens, can that rule out technical problems?

No. You still need to check the actual response, redirects, body copy, indexation directives, and the search system’s crawl records, and state the scope you checked.

When an algorithm update happens, should I rewrite all my articles right away?

You shouldn’t do that based on the update date alone. Check the affected scope, technical state, and other explanations first, then adjust for confirmed problems and keep backups.

I fixed the configuration, so why can’t I announce recovery right away?

Reading back the configuration, recrawling, search performance, and business results are different stages. Report according to each stage’s evidence, and don’t equate a successful edit with a recovered ranking.