This week's traffic report reads as growth. It isn't. Here's the real split, why it's not a new problem, and the two access decisions blocking a clean number.
Active users are up 37.6% week over week. Engagement is down at the same time. That combination doesn't happen on a site that's actually growing — it happens when the denominator gets diluted with traffic that isn't reading anything.
These five figures are as reported — no GA4 API access in this pass to reconcile them against the Sep audit's numbers directly. Treated as directionally reliable, not exact, until §5 is resolved.
Breaking sessions out by channel and country isolates it precisely — two rows account for essentially the entire week-over-week gain, and both look nothing like a visitor:
| Channel · Country | Sessions | Avg. duration | Pages / session | Engagement rate |
|---|---|---|---|---|
| flagged Direct — Singapore |
15,810 | 2.4s | 0.99 | — |
| flagged Direct — China |
2,110 | 0.68s | — | 1.7% |
| clean Organic — US / UK / CA / AU / IN / DE |
— | 150–225s | — | 60%+ |
This is the same signature the Sep 2026 audit already identified and named — not a new problem, a larger wave of an old one. That audit found a landing page in the raw data reading /horoscopes/synastry in houses/juno in 8th house — literal spaces where every real URL on the site has hyphens. No browser produces that. It means a script is building URLs directly from the Category/Component fields in the database, not crawling rendered links — Singapore and China share the identical pattern at different scale.
It also explains why GA4 never caught it on its own: it presents as an ordinary Chrome/Windows desktop user-agent, not a known spider signature, so GA4's built-in bot filter — which only matches the IAB/ABC spider list — is blind to it. Only edge-level blocking actually stops it.
The audit's daily trend shows this traffic ramping from ~7,683 sessions in March to a 61,560 peak in June/July, then stepping down to an ~800–2,300/day baseline starting Aug 2–4 — coinciding with Cloudflare throttling going live. That throttling is capping it, not eliminating it. Whether this week's pasted numbers are a real reacceleration above that baseline, or just noise within it, is the open question in §5 — not something to guess at.
Throttling is already live from the Sep audit — it capped this at an ~800–2,300/day baseline, it didn't eliminate it. The next moves are gated on two access decisions, not more Cloudflare tuning in the dark.
The service-account credential from the Sep audit was written to a session-scoped path and didn't persist — nothing currently has API access to this property. Every other item below depends on this being redone first.
GCP service account → ga-readonly, re-issued + stored durablyConfirms whether this week is a real reacceleration above the post-throttle baseline or just noise within it. That answer decides whether anything below is urgent.
GA4 — once access above existsThe traffic presents as an ordinary Chrome/Windows user-agent, so generic Bot Fight Mode heuristics are unlikely to be why the baseline is non-zero. Check Security Analytics for the actual ASN behind it — a targeted WAF rule won't catch real visitors from Singapore/China the way a geo-block would.
Cloudflare → Security → AnalyticsThe 20–50% growth target only means something if it's measured against a number that can't be padded by bot noise. That starts with the baseline, then a fixed cadence of reports that would have caught this week's swing on its own.
Set the target against this week's clean organic figure — the US/UK/CA/AU/IN/DE segment above — not the blended total. That's the only number in this report that wasn't touched by the bot wave.
Three decisions, none of them code — nothing further in this report should be acted on until these are resolved.
Without this, §1's numbers stay unreconciled, §2's reacceleration question stays unanswered, and the weekly cadence in §4 can't run at all. This is the one blocker everything else sits behind.
outbound_click and app_cta_click are written but sitting uncommitted in a working tree — nothing ships without a decision to commit, push, and mark app_cta_click as a GA4 key event.
Half of the weekly cadence in §4 depends on it, and it's the one piece of this plan that can't be checked from the codebase — it has to be confirmed directly in Search Console.