Seeing how many people are browsing your site right this very moment sounds like a premium dashboard feature, but you can put it together with pieces you already have. The interesting part isn’t the counter: it’s interpreting the signal without fooling yourself. Let’s get to the actual setup.
Step 1: choose the data source before touching anything
There are three routes and they are not interchangeable:
- Analytics provider tag (GA4, Matomo, Plausible). Zero development, but aggregation latency means GA4’s “real time” isn’t instantaneous: according to Google’s official documentation, real-time reports reflect activity from the last 30 minutes and data can take time to consolidate.
- Server logs. This is the most faithful data; it includes bots and downloads that JavaScript never sees. It requires access to the log and a parser.
- Streaming from the site itself (WebSocket or Server-Sent Events). Full control, but you’re the one bearing the infrastructure cost.
For a small business with WordPress, route 1 is enough. To audit bot crawling or anomalous traffic spikes, route 2 is mandatory.
Step 2: enable the real-time view in GA4 and verify it
- Go to Admin → Data streams and confirm the tag is firing (browser extension or the DebugView report).
- Open Reports → Realtime and browse a URL with the parameter ?utm_source=test yourself.
- Verify that you show up with that source. If you don’t appear, the problem is almost always a consent condition blocking the tag, not the tag itself.
The mistake almost everyone makes the first time
A typical case: you install the snippet in the header, the active users counter shows 0, and you panic. In reality, the cookie blocker rejected the script or a caching plugin is serving HTML with the tag duplicated and disabled. Before reinstalling anything, open the browser console and look for the request to collect or to your tool’s endpoint. If it doesn’t appear, the problem is loading; if it appears with a 204, measurement is working and the failure is in internal filtering.
Step 3: build your own dashboard from the logs (optional but revealing)
If you want to see requests per second without depending on third parties, a terminal command is enough to get started:
tail -f /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -rn | head
This gives you the IPs with the most requests in the window you leave open. It’s useful for spotting an aggressive scraper in seconds, but it doesn’t distinguish users from bots or sessions: for that you need aggregation by time windows and a Grafana-style dashboard reading the log.
What real time won’t tell you
Here it’s worth being honest: live traffic is not useful for measuring conversions or attribution. A user who buys may have arrived three days ago through another channel. Nor does it reliably distinguish between a human visit and a bot with a spoofed user-agent. And if your site gets a lot of traffic, refreshing every second consumes resources and shows you noise, not trend.
According to industry studies on web analytics, a significant portion of traffic classified as “direct” in live dashboards corresponds to internal traffic, monitoring tools, and mislabeled links. Filter out your own IP and your team’s before drawing conclusions.
Minimum configuration checklist
- Tag loading on all templates, including the thank-you page.
- Internal IP filter active.
- Custom event for CTA clicks, also visible in the real-time report.
- Alert (email or Slack) when the data stream stops for more than 30 minutes: a tag outage is more frequent than a server outage.
- Weekly log review to compare with the tool: if they diverge a lot, there are bots or script blocking.
With this you have functional live monitoring and, above all, you know when to distrust what you see.