Traffic dropped: read the indexing report before panicking

When organic traffic drops, the first instinct is to suspect an algorithm update or a penalty. In the vast majority of cases the cause is far more mechanical, and it is visible within three minutes in the Search Console page indexing report: pages have stopped being indexed, or never started.

So before rewriting anything, answer a binary question: are your pages still in the index? If they are not, no editorial work will help. This article explains how to read that report, which reasons are noise, which ones call for action, and the five causes that account for almost every drop we see in audits.

A ranking drop and an indexing drop are not the same problem

The distinction takes two minutes and it steers everything else. In the Search Console performance report, compare impressions with the number of pages generating them. If impressions fall while the number of pages stays stable, you have a ranking problem: your pages are still there, they just rank lower. If the number of pages receiving impressions collapses, you have an indexing problem.

The second case is more serious and easier to fix, which is good news. More serious because a deindexed page earns nothing at all, whatever its content. Easier because the cause is almost always technical, identifiable and reversible.

Reading the indexing report without panicking

The page indexing report shows two numbers and a list of reasons. The first figure not to over-read is the count of non-indexed pages. On a site with a few years of history, it is normal for it to far exceed the number of indexed pages. What matters is the breakdown by reason, and which way it is moving.

The reasons that are noise

Four reasons fill the list without anything needing to be done. “Page with redirect” groups all your old URLs now pointing elsewhere: that is the expected behaviour, and the volume grows with every rename. “Alternate page with proper canonical tag” covers duplicates you declared yourself. “Blocked by robots.txt” usually covers admin areas and API endpoints. “Not found” on old addresses is healthy if those pages really are gone.

For scale: on a multilingual site with a few years of history and several waves of renaming, it is not unusual for redirects alone to account for several hundred non-indexed URLs. That is not a problem, it is memory.

The reasons that call for action

Three reasons deserve to be opened one by one. “Excluded by noindex tag” should match exactly the pages you deliberately excluded. If the volume exceeds that list, something is applying a noindex you did not ask for. “Crawled, currently not indexed” means Google read the page and decided it did not merit a slot: that is a quality signal, not a configuration issue. “Not found” on recent URLs, or on URLs still linked from your own site, points at broken internal links.

The five causes of an indexing drop

In order of frequency in audits, here they are, with how to confirm each one.

1. A noindex shipped to production

By far the most common cause, and the fastest to check. A tag set on the staging environment that ships with everything else, a duplicated template carrying another one’s head, an automated guard excluding pages on a badly calibrated criterion. The check takes one command: view the page source and look for the meta robots tag, or read the X-Robots-Tag HTTP header, which Google documents on its page about valid page metadata.

Watch out for automated rules in particular. A mechanism that deindexes pages based on a quality test can disqualify far more than intended if the test is too strict. The characteristic symptom: a sharp, precisely dated drop, hitting a coherent subset of pages, with no editorial change to explain it.

2. A staging environment open to crawling

A staging subdomain reachable without authentication, with a permissive robots.txt and a working sitemap, is an invitation. Google crawls it, discovers hundreds of URLs, discards them from the index if a noindex protects them, and consumes the crawl budget that should have gone to your real pages along the way.

An example from a recent audit: out of 1,805 URLs known to Google, 1,183 were not indexed, and 614 of those came from a staging subdomain left open. More than half of the “not indexed” volume had nothing to do with the production site. The fix is not a noindex, which still lets the crawl happen, but authentication, or failing that a robots.txt specific to that environment and a sitemap that returns an error.

3. A redesign with no redirect plan

If addresses changed without every old URL being redirected with a 301 to its equivalent, the search visibility you earned leaves with them. The blanket redirect to the homepage, often chosen for convenience, amounts to starting over: Google treats it as a disguised not-found page.

Google documents this scenario precisely in its guide to a site move with URL changes: prepare the mapping table before going live, keep the redirects for at least a year, and watch the indexing report in the following weeks. We cover the full method in our article on website redesign.

4. A robots.txt that is too broad

A blocking rule added to exclude a technical directory can, through a misplaced wildcard, cover far more. The robots.txt file can be tested directly in Search Console, and that check belongs in the acceptance list of every production release.

5. Content missing from the mobile version

Google indexes the web from the mobile version of pages. Content hidden, truncated behind a button that only loads on click, or served only on desktop is content Google does not see. The symptom is a loss of rankings on long-tail queries with no visible deindexing: the page stays in the index, but with half its text missing.

The trap that prevents you from fixing it

One confusion is worth clearing up, because it produces the exact opposite of the intended effect. Robots.txt controls crawling, not indexing. A page disallowed from crawling can still appear in results if other pages link to it, shown without a description since the crawler was never able to read its content.

More importantly, Google states that a page blocked in robots.txt cannot be deindexed: the noindex instruction lives inside the page, and the crawler never reads it. To remove a page from the index you therefore have to do the opposite of the intuition: leave it crawlable and give it a noindex. Blocking it first guarantees it will stay indexed indefinitely.

Using URL inspection properly

The tool that answers fastest is URL inspection, available from the search bar at the top of Search Console. Paste an address and you get the verdict for that specific page: indexed or not, when it was last crawled, which canonical URL Google selected, and whether a noindex tag was detected. It is the most direct way to confirm a hypothesis on a particular case.

The “Test live URL” button deserves a separate mention, because it solves the waiting problem. The report reflects the state of the last crawl, which may be weeks old; the live test fetches the page now and shows what Google sees at this moment. So it is the tool to use right after a fix, to confirm the tag is really gone, without waiting for the crawler’s next visit.

Requesting indexing, on the other hand, is often misunderstood. It places the URL in a priority queue, with no guarantee and no announced delay, and the daily quota is small. It is useful for a handful of strategic pages after a correction. It is useless for recovering from mass deindexing: there, the sitemap and fixing the cause do the work.

Discovered or crawled, the nuance that changes the diagnosis

Two reasons look alike and point at opposite problems. “Discovered, currently not indexed” means Google knows the URL but has not come to read it yet: that is a crawl budget issue, often tied to a site too large for its authority, or to thousands of low-value URLs saturating the crawl. “Crawled, currently not indexed” means it came, it read, and it decided not to index: that is a quality or duplication issue.

The confusion is expensive, because the fixes are opposite. In the first case you need to cut the number of useless URLs and strengthen internal linking towards the important pages. In the second, rewrite or merge. Treating one with the other’s method produces no effect at all.

The diagnostic method, in six steps

• Separate ranking from indexing. Stable impressions with falling page counts, or the other way round? The answer determines everything else.
• Open the indexing report and sort by reason. Look for which one moved, and on what date. The curve per reason says more than the total.
• Date the break. A sharp drop with a precise date points at a deployment, not at an algorithm. Comparing it with your release history is often enough to find the culprit.
• Check noindex on three representative pages. Page source and HTTP headers. Three minutes, and it rules the most common cause in or out.
• Check the sitemap. The number of declared URLs should match what you want indexed. Google explains in its sitemaps documentation that it is a signal rather than a guarantee, but a large gap between declared and indexed is a reliable clue.
• Wait before concluding. Google takes several weeks to recrawl an entire site. A fix deployed today does not show up in the report tomorrow.

When it really is a quality problem

If none of the five points above explains the drop and the “Crawled, currently not indexed” reason dominates, then the subject becomes editorial. Google read those pages and judged that they did not bring enough to deserve a slot. That is common on three profiles: unreviewed machine translations, pages generated from a single template with no distinctive content, and short articles repeating what the rest of the web already says.

The useful reflex is then to consolidate rather than multiply. Two articles targeting the same search intent compete with each other: merging them and redirecting one to the other beats letting both dilute. And page performance is part of the equation too, a subject we cover in our article on Core Web Vitals.

What we take from it

A drop in organic traffic should be diagnosed before it is treated, and the diagnosis is almost always faster than people fear. In most cases we see, the answer comes down to a deployment date and a tag. Editorial work comes afterwards, once you are certain the pages are actually in the index.

If your traffic has dropped and the indexing report means nothing to you, we run this diagnosis in half a day: reading the reasons, dating the break, technical verification, and a list of fixes ranked by impact. Let’s talk.