I lost 82% of my traffic while building my product.
I lost 82% of my traffic while building my product.
4.84k monthly users → 846.
At first I assumed I had a traffic problem.
So my brain immediately suggested:
More SEO
More content
More distribution
More promotion
But after looking deeper, I realized something uncomfortable.
Traffic wasn't the biggest problem.
It was easier to think about traffic than to think about execution.
While traffic was falling, I spent months rebuilding TruthLoop's investigation engine, debugging AI workflows, rewriting evidence collection systems, and constantly changing the product.
The visible problem was traffic.
The invisible problem was where my attention was going.
I think founders do this more often than we admit.
We focus on the metric that's easiest to measure while avoiding the question that's hardest to answer.
A question I keep coming back to:
Am I solving the problem that hurts the most?
Or the problem that's easiest to think about?
Curious if anyone else has discovered that the problem they were trying to solve wasn't actually the real problem.
The distinction between traffic and attention is useful. I’d split the 4.84k → 846 timeline by channel and compare returning-user retention for the 846 with Search Console impressions; that should separate an SEO/distribution cliff from a product-engagement shift. Then I’d restore one small maintenance loop for the channel that still brings retained users before adding more acquisition work. Which signal changed first: impressions, sessions, or repeat usage?
I like that distinction.
Founders often investigate the biggest number first, when the most useful clue is usually the first metric that changed.
An 82% drop is a big enough number that it is worth asking whether it was one identifiable cause or several things compounding at once. Did you trace it back to something specific, or is it still a bit of a mystery?
The attention trap you describe works even before you have traffic to lose. I have the opposite numbers (no users yet), and I catch myself doing the same thing: rebuilding features is comfortable because progress is visible in code, while distribution work feels like shouting into a void with no dashboard. "Am I solving the problem that hurts the most, or the one easiest to think about" is the right question. How are you splitting your week now between product work and winning the traffic back?
Everyone here is debating what caused the drop, but there's a prior question: is "4.84k → 846" measuring the same thing at both ends? Analytics tools change how they count during a rebuild too — new routing can break tracking scripts, a migrated domain can split sessions across two properties, a consent banner can silently start blocking the pixel on the new build. If the tool itself changed how it observes traffic, the 82% isn't a traffic story, it's a measurement story wearing a traffic costume.
The check: does a source outside GA4/Search Console agree with the drop — server logs, or a CDN's raw hit count? If they disagree, you didn't lose users, you lost your own ability to see them, which is a much less painful and much more boring fix.
A useful check is to track the first behavior that changed, not just the traffic line: which users return, what they tried to do, and where they stop. Talking to a few people who left often reveals whether the issue is acquisition, activation, or the product solving a low-priority problem. That keeps the response from becoming “do more SEO” by default.
The classic builder's trade — you mortgaged distribution for product. Painful but fixable, and the fix is boring: the same consistent output that built the traffic the first time.
One thing that helps me: separate "building time" from "distribution time" at the calendar level, not the motivation level. Two hours every morning for shipping content/answers before touching the product. When it's calendar-bound, it survives bad weeks.
And honestly — 82% down after a focused build is a better position than most: you proved you can earn attention once, and the product is actually ready for it this time. Second climb is faster because you know which slopes work.
That's an interesting distinction.
The hidden trap is that builders often sacrifice distribution for product, then later sacrifice product for distribution.
The real challenge is noticing which side of the loop you're stuck in.
having the same situation haha
An 82% drop is a big enough number that it is worth asking whether it was one identifiable cause or several things compounding at once. Did you trace it back to something specific, or is it still a bit of a mystery?
That's a valuable lens.
Sometimes the traffic drop isn't the problem. It's the event that finally exposes a dependency that was already there.
The pattern becomes visible only when the numbers stop hiding it.
The part I'd push back on is the denominator. 4.84k to 846 sounds catastrophic, but it only means something relative to what that traffic was doing - if you segment the old 4.84k by which pages actually produced a signup, most people find the loss is concentrated in low-intent pages that never converted, while the handful of URLs feeding the product held roughly flat. Before you accept the attention narrative, I'd redraw the chart as "sessions on the ten pages that generated a signup in the last year"; if that line is stable, you lost volume rather than business, and the real lesson is a different and less flattering one than the one you took. The flip side is that if those ten pages did collapse, it's strong support for the technical read others gave here, since your best-converting pages are usually your oldest and most-linked URLs - precisely the ones a rewrite orphans without throwing an error. Worth naming too that a build sprint doesn't only stop publishing, it stops maintenance: new internal links, refreshed pages, broken paths getting fixed. That decay never shows up on a content calendar because nothing was scheduled. So: did signups or revenue fall anywhere close to 82%, and what are you changing structurally so the next engine rebuild can't quietly take distribution with it?
That's a useful reframing.
Founders often optimize around the biggest loss, while the most valuable clue is usually hidden in the segment that stayed stable.
82% is brutal, especially when you're not sure which decision caused it. The worst part of traffic loss mid-build is the timescale mismatch - your product feels like it's moving forward while the SEO damage compounds quietly in the background and you don't see it until it's severe.
One thing worth adding to the checklist above: check your Google Search Console for the exact date the drop started. If it lines up with a Google core update rather than your rebuild dates, you're dealing with a completely different problem. Conflating algorithm changes with technical debt is a common trap and it changes the entire fix.
What's the breakdown? Organic only, or are other channels affected too?
The timescale mismatch is interesting.
The hardest problems are often the ones creating damage quietly while everything else appears to be moving forward.
There is a fourth option missing from that list, and it is the one that fits your timeline best: the rebuild was the decline.
Publishing stopping and rankings slipping are slow. A rewrite is fast, and it takes the URLs with it. Four things break quietly during one, and none of them surface as an error anywhere you would normally look:
The check that separates this from an attention problem takes about ten minutes. Pull your top 20 URLs from before the drop and request each one now, following redirects. If a meaningful share 404 or land somewhere unexpected, you did not lose attention, you lost addresses. Search Console will also split it for you: "crawled, currently not indexed" and "not found (404)" are two completely different stories and only one of them is about focus.
Worth ruling out before the psychological read, because if it is technical it is recoverable in a weekend, and if it is not, you have bought certainty about the harder question.
If you would rather not do the on-page half by hand, nexusbro.com/audit runs 125+ QA and SEO checks on a single URL in about 30 seconds, no signup and no card, and hands back a prioritised fix list. The redirect trace above you will still want to run yourself with curl, since that one is about URLs that are already gone.
The uncomfortable possibility is that both explanations can be true.
A technical issue may cause the drop, but the reaction to it still reveals the decision pattern.
Before treating it as attention allocation, I’d compare the timing of the loss against product or site changes: index coverage, redirect or noindex changes, content updates, and a simple channel split in Search Console. An 82% change may include an execution issue even if the bigger lesson is right. Then I’d ask the 846 retained users what task they still come back to complete. That answer is likely a better basis for the next product and acquisition decision than total sessions.
I like the idea of treating retained users as the control group.
The people who stayed often explain the product better than the people who left.
This feels very familiar — sometimes you try to improve what stands out first, while the real problem is somewhere else. I’ve noticed the same thing when creating crosswords in SuperColoring: sometimes I wanted to change the design right away, when I really needed to rethink the words and clues first. A good reminder to figure out what actually needs fixing before making changes.
That's a common trap.
We often change the visible thing first because the invisible thing is harder to investigate.
Neither 4.84k nor 846 tells you much, because monthly users is not a business metric, and trading one vanity number for a different vanity question feels like insight without being one. The honest test is how many of the 4,840 were paying versus how many of the 846 are paying, and if that number barely moved, you didn't lose traffic, you lost noise. I've watched founders rebuild engines for months against a traffic chart when 20 customer calls would have settled what to build in a week.
You didn't lose traffic, you lost noise.
The hidden question is whether the users who mattered changed their behaviour at all.
The uncomfortable part of this post is the right part, but I would push on one thing: check whether the traffic loss was actually caused by something you did, before you file it under execution.
We lost 98% of impressions on a single day. Same reflex as you, we assumed it was a content-quality problem and started rewriting. It was not. We had published 94 posts in 23 days the month before, and the collapse landed on the first day of the next month. That publishing rate is named in Google's scaled-content policy. Nothing about the individual posts was wrong. The shape of the corpus was.
What that changed for us: we stopped measuring by traffic and started measuring by whether the one thing the product promises is getting harder to fake. Traffic came back into scope only once that was true.
Two things worth checking on your own numbers before you accept the execution story: did the drop happen on one day or over weeks, and does Search Console show a manual action or nothing. A single-day cliff with no manual action is algorithmic, and no amount of rebuilding the engine moves it.
I build AI Applyd - https://aiapplyd.com?ref=indiehackers - auto-apply that proves your application arrived.
That's an important distinction.
A story can feel true long before enough evidence exists to support it.
I’ve fallen into the same trap; writing the customer problem down before opening analytics helps me keep the metric in context.
That's the interesting part.
Writing the problem down can create the feeling of clarity before enough evidence exists to support it.
That’s exactly where I’d look next.
The people who stayed are probably the closest thing you have to a control group: what job are they still hiring the product for, what would make them leave, and what would they genuinely miss if it disappeared?
I’d probably talk to 5–10 of them before changing the product. Sometimes retention tells you more about the real product than churn does.
The hidden signal may be who stayed, not who left.
Churn tells you what disappeared. Retention often tells you what the product actually is.
I'd rule out the boring explanation first: compare GA4 against something you don't control, like backend signups or server logs, for the same window. Consent changes and removed tags drop traffic for every cohort at once, which looks exactly like a content problem. If both numbers agree, then it's the harder problem you're describing.
Agreed.
The trap isn't choosing the wrong explanation. It's becoming emotionally attached to one before the investigation starts.
The lesson is probably true, and I would still spend ten minutes ruling out the boring explanation, because the two are not mutually exclusive.
Sites do not usually lose 82% to neglect. Neglect produces a slow slide. Going from 4.84k to 846 during the months you were rebuilding the product is much more often the shape of something you shipped: URLs changed without redirects, a noindex left on from staging, a robots.txt edit, or a framework migration that changed how the pages render.
Search Console settles it quickly. Look at whether the fall was a cliff on one date or a gradual slope, and whether impressions dropped alongside clicks or only clicks did. A cliff means you caused it, which also means it is recoverable. A slope means it is genuine competition and your reflective read is the right one.
Worth checking, because those two conclusions lead to completely different next months, and the more comfortable one is the one that does not ask you to go and look.
Agreed, and the only way out of that trap is to make the check cheaper than the deliberation.
Five minutes, in this order. Search Console, Performance, last 16 months, clicks and impressions both switched on. If there is a vertical drop on a single date, note the date, then open the Pages tab and compare the top URLs either side of it. Pages that vanish entirely are redirect or indexing casualties. Pages that survive with lower impressions are ranking losses. Then Indexing, Pages, and see what moved into Excluded by noindex tag or Crawled currently not indexed around that same date.
If the date lines up with a deploy, it is yours, and that is the good outcome because it is fixable.
That's the uncomfortable possibility.
Sometimes what looks like a psychological pattern is actually a systems problem.
The hidden trap is deciding which explanation feels true before investigating which one is.
An 82% drop is brutal, but at least it exposed the tradeoff clearly. I’d give the channel that used to work a fixed weekly maintenance floor, then allow only one build bet at a time. What caused most of the decline—publishing stopped, rankings slipped, or the product changed?
That's a useful distinction.
I spent a lot of time studying the decline. There may be more signal in the people who stayed than the people who left.
The 82% drop makes the remaining 846 users more interesting than the traffic loss itself. Do you see any meaningful difference in what the users who stayed are doing with TruthLoop versus the users who stopped coming back?
That's a great observation. I focused on the people who disappeared. The people who stayed may reveal a much more useful pattern. I haven't analyzed that group deeply yet, but I suspect there's a lesson there.
That retained-user segment could be more informative than the traffic loss itself. If you’re open to it, what’s the best email to reach you on?
That question changed how I'm looking at it.
I assumed the missing users held the answer. The retained users may be revealing a completely different pattern.
That retained-user angle is worth following. If you’re open to it, what’s the best email to reach you on?
truthloop.in@gmail.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.