Website Rankings Drop Audit: Diagnose Click and Visibility Loss

A rankings drop audit separates measured changes in clicks, impressions, CTR and average position from possible causes. Start with the SEO audit hub and record the comparison before changing pages.

Google recommends comparing a drop period with a similar prior period and reviewing affected pages and queries. A date overlap with a ranking update is evidence to investigate rather than proof that the update caused the loss. This workflow follows Google's traffic-drop guidance.

Is the rankings drop real?

A real search loss appears in a controlled comparison of clicks, impressions, CTR and average position. Confirm the search type, property, date range and aggregation before diagnosing a cause.

1. Freeze the observation: write the property, search type, timezone, comparison dates and export date. Use a completed period where the most recent data is available.
2. Compare like with like: compare the same number of days with the previous period or the same dates year over year. Annotate launches, migrations, outages, pricing changes and seasonality.
3. Separate the metrics: clicks count clicks from Google Search results, impressions measure appearances, CTR is clicks divided by impressions, and average position is an aggregate rather than a fixed rank. A position change alone is not a traffic diagnosis.
4. Check the scope: aggregate by page and by query, then segment by device and country. Search Console supports these dimensions, but table rows are incomplete: anonymised queries are omitted and data can be truncated. Treat filtered totals as approximate where Google says filtering changes totals.

Keep the raw export private. Publish only redacted URLs, grouped counts or an explicitly labelled illustrative row. For a full evidence record, link the SEO audit report workflow rather than pasting a client's queries.

Could a Google update explain it?

A confirmed update can explain timing and broad movement, but it does not identify a page's cause or guarantee recovery. Compare the rollout window with the same page and query groups before assessing content and intent.

Use the Google Search Status Dashboard and the core update guidance to label a date as confirmed or unconfirmed. Google says core updates are broad changes that do not target specific sites or pages. Record “correlated with update” as a hypothesis and list other explanations still open.

When Google marks a core rollout complete, wait at least a full week. Then compare that week with a week before the core update started rolling out. Keep the same pages, queries and search type in the comparison.

For a sustained large position loss, review the affected pages against Google's core update self-assessment. Avoid a quick edit based on a rumour. Mark every change with its date and rationale so the next comparison can distinguish an implementation effect from normal movement.

Which technical checks come first?

Technical checks come first when the loss is sudden, site-wide or concentrated on a template. Verify access and indexability on representative URLs before rewriting content.

• Access: check response status, DNS, HTTPS, robots.txt rules and server errors. Compare the live crawl with a known-good deployment or crawl export.
• Indexability: check noindex directives, canonicals, redirects, sitemap membership and internal links. A crawl shows declared signals; Search Console shows Google's reported index state.
• Templates: sample a winning URL, a losing URL and one recently changed URL. Group the result by template so one fix does not get inferred from one page.
• Performance: review Core Web Vitals as user-experience evidence and inspect whether a regression coincided with the drop. Do not describe a threshold miss as the sole cause without supporting page and query data.

URL Inspection is useful for a specific URL's indexed and live views. It does not prove that a page will rank. Google's documentation says live testing does not check every indexing condition such as duplicate or canonical selection, quality, manual actions, removals or security issues. Record the crawl date and view used.

Is there a manual action?

A manual action is a Search Console report that names a spam-policy issue. A traffic drop without that report is not evidence of a manual penalty.

Check Search Console's Manual actions and Security issues reports. If a manual action exists, map the named issue to affected URL patterns, remove or correct the violating instances, document the work and follow Google's reconsideration process. Keep the notice and response in the private audit record.

What do page and query patterns show?

Page and query aggregation shows whether the loss is concentrated in a topic, intent, template or snippet. Use the pattern to choose a justified fix rather than labelling a page “low quality” from position alone.

On small screens, swipe or use arrow keys inside the table region to inspect every column.

Use Search Console's query-to-page view to see which URLs were shown for a query. Remember that performance data is generally credited to Google's selected canonical URL. Do not merge rows blindly when redirects or duplicates are involved.

Did demand or SERP composition change?

A competitor can displace a page, or a result page can change while your URL stays visible. Compare the affected query set on the dates in question and save the observation date with any SERP notes.

Check whether the query is seasonal, whether search type changed, and whether new result features or different page types now appear. A competitor's presence is an observation. It is not proof that a backlink, redesign or content change caused the movement unless dated evidence supports that link.

When do links matter?

Investigate links when a dated link event or Search Console manual action supports the hypothesis. Do not treat a third-party “toxic link” score as a Google diagnosis.

Review lost referring pages, anchor context and deliberate link activity. Google's disavow guidance describes a narrow tool for cases such as a manual action for unnatural links after reasonable removal efforts. Do not recommend automatic disavow files for ordinary unsolicited links.

How do you build a recovery queue?

A recovery queue connects one observed pattern to one owner, one justified change and one remeasurement window. It records uncertainty so a hypothesis does not become a promise.

1. Rank the work: give priority to blocking indexability, security and manual-action issues. Then use affected clicks or impressions, business importance, confidence and implementation effort to order the rest.
2. Write the evidence: include the URL or redacted group, metric change, comparison dates, source export, diagnosis, proposed change and what would falsify the diagnosis.
3. Apply one coherent change: preserve a dated changelog. Avoid bundling unrelated rewrites, redirects and template changes when the result needs to be interpreted.
4. Remeasure: annotate the implementation date and repeat the same page, query, device, country and search-type cuts after enough data accumulates. A request for indexing is not a ranking guarantee.

For content improvements assessed after a core update, Google says effects can take days or several months to show and there is no guarantee of a noticeable impact. Technical and manual-action corrections need their own retest condition. Report the next state as improved, unchanged or inconclusive with the date and evidence.

For a completed owned-site handoff, compare this queue with the website audit report example and record the next check in the implementation tracker.

What are the source and privacy limits?

Search data and crawl data are time-bound evidence with privacy and coverage limits. Findings need dates, scope and confidence labels.

This workflow uses Google's traffic-drop guide, Performance report dimensions, URL Inspection documentation and spam policies. Search Console omits some queries for privacy and limits displayed rows. Crawl data describes what was fetched at crawl time.