Real Traffic Audit Example: Reading a Report Section by Section
This page walks through a Real Traffic Audit report for Hartley Garden Rooms, a fictional builder of garden offices whose website is at example.co.uk. It is an illustrative example, not a real site's data: the business, the figures and the log entries are invented to show the kinds of result each report section produces. Read it before your first run to know what to expect, or alongside your own report to compare. For every section you will see what the example shows, what it means for the business, and the action the owner would sensibly take next.
About this example and what went in
Hartley Garden Rooms is imagined as a small firm with one office, a website of about thirty pages, a quote request form and an online price calculator. Its site runs WordPress on a Plesk server. The owner, who we will call Sam, has always been puzzled that Google Analytics reports a couple of thousand users a month while enquiries stay in single figures per week.
Sam downloaded four weeks of access logs from Plesk, covering 1 to 28 September 2026: access_ssl_log,
access_log and three older compressed files. All five went into the drop area together.
The fields were filled in as follows:
| Field | Value entered in the example |
|---|---|
| Your domain | example.co.uk |
| Your server's IP | 203.0.113.10 (a documentation address standing in for the real one) |
| Your own IPs | 198.51.100.24, the office broadband |
| Analytics users, same period | 2,140, copied from GA4 for 1 to 28 September |
Sam also signed in with a free aiwebpageseo account and connected Google Analytics and Search Console, so the comparison section could fill itself in. Sam had already verified the domain with aiwebpageseo through its domain verification, which is required before any Google data appears.
Real People and the automated traffic
👥 Real People
The headline reads 612 likely real people, unique visitors in this log. Of those, 47 confirmed people also submitted a form or used a feature: here, the quote request form or the price calculator. That is the first eye-opener: roughly 600 browsers that behaved like humans over four weeks, against 2,140 users in analytics.
What it means for Sam: the site's real audience is modest but far from empty, and nearly one in thirteen likely people did something meaningful. That is a healthier conversion picture than the analytics figure implied. Some of the 612 will be the same person on two networks, and some offices will have shown up as one, so it is an estimate, not a head count.
🖥 Your Own Server & Automated Browsers
This section explains most of the gap. The example shows requests from 203.0.113.10,
the site's own server, loading full pages at regular intervals through the night. In this imagined case
the culprit is a WordPress plugin that renders each product page in a headless browser to build downloadable
PDF brochures. Every render runs the analytics tag, and every render looks like a new user.
Alongside it, a self-identifying uptime monitor loads the home page with a real browser engine every five minutes, and a speed-testing service visits the top pages once a day. Each identifies itself in its user agent, so the audit lists them here rather than among the people.
Action: exclude the server IP and office IP as internal traffic in GA4, switch the uptime monitor to a plain health-check URL without the tag, and ask the plugin developer whether brochures can be generated less often or only when a page changes.
Where people came from and what they read
🧭 Where People Came From
| Source (illustrative) | Likely people |
|---|---|
| Direct / none | 314 |
| Search engines | 238 |
| Social networks | 41 |
| AI assistants | 19 |
Direct / none is the largest group, as it is for most sites. Sam sends a monthly newsletter and prints the web address on vans and brochures, so many of those visits are probably people typing the address or tapping an email link. Search engines are the next biggest source and the one Sam can most directly influence. Nineteen people arrived from an AI assistant after the assistant linked to the site, which is small but worth tracking month on month.
Action: add UTM parameters to newsletter links so next month some of the Direct / none share becomes attributable.
📄 What People Read
The most-read pages by likely people are the price calculator, the gallery of finished projects, the insulated garden office page and the planning permission advice article. The company history page, which Sam had assumed was popular from analytics, barely features once automated visits are removed; in this example it was mainly being loaded by the brochure plugin.
Action: treat the planning permission article as a proven draw and link from it to the quote form, and stop spending time on the history page.
AI crawlers and search engines
🤖 AI Crawlers & AI Assistants
| Kind | Examples seen in this illustration | Reading |
|---|---|---|
| Training crawlers | GPTBot, ClaudeBot, CCBot | Collecting pages for future models; no effect on today's answers. |
| AI search crawlers | OAI-SearchBot, PerplexityBot | Building the indexes assistants cite from. A good sign for visibility. |
| Live fetches | ChatGPT-User, Perplexity-User | Someone asked an assistant about a specific page. |
One detail stands out. A Perplexity-User fetch of the pricing page appears at 07:00 on nineteen different mornings. The audit flags it as scheduled, because a real person would not ask at the same minute every day. It is probably a competitor or a price-tracking service with a recurring task, so Sam should not read it as nineteen customers asking about prices. The remaining live fetches are scattered through the day and look like genuine questions.
Action: Sam decides the business benefits from being cited, keeps AI search crawlers and live fetchers allowed, and makes a deliberate choice about training crawlers in robots.txt rather than leaving it to chance.
🔎 Search Engine Crawlers
Googlebot and Bingbot visit daily, with DuckDuckBot and Applebot less often. Googlebot requests concentrate on the gallery and service pages, which matches what Sam wants indexed. Had the section shown no Googlebot activity at all, the next step would have been checking robots.txt and Search Console for blocks.
Security events and visitor errors
🔐 Security Events
- Attack probes: several hundred requests for paths such as
/.env,/.git/configand old plugin files. Sam checked and all received 404 responses. Background noise. - Failed logins and a password-guessing burst: a few hundred attempts against
wp-login.phpover twenty minutes from one address on 12 September. None succeeded. - Admin areas reached: only from the office IP that Sam listed. Reassuring.
- New accounts: one new account created on 19 September. Sam did not create it, and the site has no reason to allow public registration.
- Bursts of server errors: none outside the errors listed below.
Action: delete the unknown account, switch off "Anyone can register" in WordPress settings, add two-factor sign-in for administrators and enable login rate limiting. Sam keeps the results file for the Security Audit and runs that audit next.
⚠ Errors Real Visitors Hit
| Path (illustrative) | Status | Sam's diagnosis (illustrative) |
|---|---|---|
/garden-offices/ | 404 | Old address printed on a flyer before the site was restructured. |
/quote/submit | 500 | Form handler failing when a photo over a size limit is attached. |
/gallery/2025/ | 404 | Gallery year archive removed; linked from a supplier's website. |
The 500 on the quote form matters most, because it hits people at the moment they try to buy. Sam would check the server error log for the same timestamps, raise the upload limit or add a clear size warning, and test the form with a large photo. The two 404s each need a single 301 redirect to the current pages.
Comparisons and the daily picture
📊 Who Your Server Works For
In this illustration, people account for under a fifth of all requests. Other bots and scanners take the biggest share, followed by search engines, Sam's own server and automated browsers, and AI crawlers, with Sam's own team a sliver at the end. For a small business site, it is common for people to be a minority of what the server handles, and this view makes that visible at a glance. It also shows Sam that the brochure plugin is costing server time as well as polluting analytics.
📈 Google Analytics & Search Console vs Your Server Log
Analytics claims 2,140 users; the log shows 612 likely people. The own-server and automated-browser sections account for most of that difference. Search Console, connected for the same dates, reports clicks from Google results broadly in line with the people the log saw arriving from search engines, which is a useful cross-check that the people count is sensible. Separately, looking in GA4 itself rather than in the audit, Sam notices that daily users fall noticeably on days the brochure plugin was paused for an update, which supports the diagnosis.
📅 Likely People Per Day
Daily likely people sit mostly between fifteen and thirty, with a clear rise on the day after the newsletter went out and lower figures at weekends. Two flat days mid-month line up with a hosting maintenance window. The chart gives Sam a realistic baseline for judging next month's advertising.
Reading this report, step by step
Step 1
Check what went in
Before reading any figure, confirm the inputs. In the example, four weeks of Plesk logs were used, the domain was entered, and both the server address and office address were supplied, along with the analytics user total for identical dates. If any of these had been missing, some self-requests or staff visits might have landed among the people, so the headline would have been less trustworthy than it appears.
Step 2
Anchor on the people figures
Write down the likely and confirmed counts together. The example's 612 and 47 give a realistic audience and a firm minimum. Dividing confirmed by likely gives a rough rate of meaningful action that is far more honest than one based on analytics users. Remember the counts are per internet address over the log's dates, so treat them as estimates rather than names in a visitor book.
Step 3
Account for the automated traffic
Open the section on your own server and automated browsers next, because it usually explains why analytics looks inflated. In the example, a PDF brochure plugin and an uptime monitor using a real browser engine were the main sources. Note each source and decide whether to exclude its address in analytics, point it at an untagged URL, or change how often it runs.
Step 4
Read the audience sections together
Look at where people came from beside what they read. In the example, search visitors favoured the planning article and the price calculator, while the history page turned out to be read mainly by software. Pairing the two sections shows which pages earn genuine attention and which channels deliver it, which is the information you need to decide where to put effort.
Step 5
Triage security and errors
Separate noise from events that need action. Probes that received 404 responses can be noted and left. An unknown new account, admin access from an unfamiliar address or a successful login after many failures needs attention the same day. Then sort the errors real visitors hit by their impact, putting anything on a form, basket or checkout path at the very top.
Step 6
Compare with Google and the daily chart
Use the comparison section to check that the gap between analytics and the log is explained by the automated traffic you have already identified. Search clicks from Search Console should roughly agree with search visitors in the log. Then scan the daily chart for spikes and dips, and match them to newsletters, campaigns, outages or changes you made to the site.
Step 7
Turn the findings into a short list
Finish with no more than five actions, ordered by risk and visitor impact. For the example business that list is: remove the unknown account and disable registration, fix the quote form error, add the two redirects, exclude internal traffic and adjust the monitor and plugin, and add UTM tags to the newsletter. Save the PDF report so next month's run can be compared fairly.
1. Are the numbers on this page from a real website?
No. Hartley Garden Rooms is a fictional business and example.co.uk is used here only as a placeholder address. Every figure, path, address and date in this walk-through was invented to show the kinds of result the Real Traffic Audit produces and how to interpret them. Your own report will have different numbers, and the balance between people, bots and crawlers varies a great deal from one website to another, so do not use these figures as a benchmark.
2. Is a gap like 2,140 analytics users against 612 people realistic?
Large gaps do happen, and the tool page itself describes one site where analytics reported 4,600 users while the log showed 16 people who actually used the site. The size of the gap depends on how much automated software runs your analytics tag, including your own server, monitoring tools and script-running bots, and on how many real visitors decline tracking. Some sites see a small difference; others see a very large one. Only your own audit can tell you.
3. Why was the same Perplexity-User fetch flagged as scheduled?
Live fetches normally happen when a person asks an AI assistant about a page, so they arrive at irregular times. When the same kind of fetch for the same page lands at the same minute on several different days, the audit flags it as scheduled, because people do not ask at an identical minute every morning. In the example, it was more likely a recurring task set up by someone monitoring prices than nineteen separate customer enquiries.
4. Should Sam have panicked about hundreds of attack probes?
No. Requests for paths such as /.env, /.git/config and old plugin files are automated scans that reach every public website. In the example they all received 404 responses, meaning there was nothing to find. The events that deserved action were different: an unknown new account and a burst of failed login attempts. The first suggested registration was left open; the second was a reminder to add rate limiting and two-factor sign-in for administrators.
5. Why does the example connect Google Analytics as well as typing a user count?
Either works for the basic comparison. Typing the analytics user total for the same dates gives the audit a single figure to compare with likely people. Connecting Google Analytics and Search Console, which needs a free account and read-only permission, places Google's figures beside the log automatically and adds Search Console's search data. Sam connected both to cross-check search clicks against search visitors seen in the log, and the typed figure remains useful when no account is used.
6. What would change if Hartley's site used a CDN?
Anything a content delivery network served from its own cache would never reach the server, so it would be missing from the access log. Many CDNs cache images, styles and scripts but pass page requests through, so page views would still show while some supporting files would not. That would make the figures describe what the server handled rather than every visit, and comparisons between months with different cache settings would be less reliable.
Real Traffic Audit Fixes covers every finding shown in this example, from your own server and automated browsers inflating analytics to AI crawler choices, errors real visitors hit, security events and log gaps.
Open Real Traffic Audit Fixes →