The log · Service & process guides · 03 Sept 2026 · By Sherif Awad, Founder, GeoMarineHub
The noindex Tag That Erased Our Search Traffic
Our clicks went from about 100 a day to zero in under two weeks — six weeks before we even moved platforms. Here is the forensic trail: what broke, how we found it, and the alarm we built so it cannot happen silently again.
The collapse, in numbers
1,070 clicks / 84,100 impressions — 12 months33,928 pages excluded by a noindex tagCollapse began six weeks before our migrationNow: an alarm on every deploy, not a habit
Read directly from Search Console, 2026-09-03
The chart that did not add up
We went looking at our search performance for an unrelated reason and found a cliff: clicks that had been running close to a hundred a day fell to zero within about two weeks, and stayed there. Not a slow decline — a wall.
The date on that wall was six weeks before we moved to this platform. Whatever happened, the migration did not cause it. Something on the site we were still running at the time did.
What the evidence actually shows
Search Console keeps a separate report for exactly this kind of question: page indexing. It broke our pages down by why each one was or was not indexed, and one reason accounted for 33,928 of them — excluded by a noindex tag. That is a page telling search engines, in so many words, do not show this.
We are being precise here rather than tidy about it: our own internal history flags a same-day infrastructure change around the same period as a plausible trigger for a ranking drop, distinct from the noindex tag itself. We have not proven a single root cause connects every number in this post, and pretending otherwise would be the opposite of the diligence this whole post is about.
Why it stayed invisible for weeks
A noindex tag does not throw an error. The site keeps serving 200 OK on every page. Nothing in a normal uptime check, a normal page load, or a casual look at the homepage would ever show it. The only place it shows up is a report that someone has to open and read on purpose.
Nobody was reading it on purpose, on a fixed schedule, until we went looking for something else entirely.
What we built so this cannot happen quietly again
The fix for the immediate problem was straightforward once found. The fix for the real problem — that a change like this can sit unnoticed for weeks — was not a fix, it was a habit, and habits skip. So we built an alarm instead: a snapshot of every public page’s indexing signals, taken after every deploy, compared automatically against the last known-good state.
—A URL leaving the sitemap
—A page becoming noindexed
—A canonical tag moving to a different page
—Structured data disappearing from a page that had it
—robots.txt changing at all, for any reason, including a change we did not make ourselves
Any one of those now fails a check the same day, not six weeks later when someone happens to look.
The takeaway, if you run search traffic for anything
The specific bug will not repeat itself — we have alarms on it now. The general failure will, for anyone: the things most worth monitoring are exactly the things that produce no visible symptom and no error message. If a check depends on a person remembering to run it, it will eventually not run.
We would rather have found this in a day than in a quarter. The alarm exists so that next time, we do.