Website Traffic Generator: What It Sends to Your Site

Requests. One generated visit is a burst of them: one for the page, then, if a real browser made it, one for each stylesheet, script and image the page needs, and, if that browser runs your analytics tag, one more that goes to your analytics provider instead of your server. Every request carries some values the tool chose and some it couldn't choose, and the useful skill is telling those apart.

Read the second column before the fourth. A value the tool chose proves only that it chose it, and the rows where the answer is no are the ones that tell you something. Which settings on a generator's form it really controls, and which report outcomes it can only guess at, is covered in what an online traffic generator controls. This post stays one layer down, at the requests themselves.

One thing is missing from the table: a search engine. Every request in it goes to your server or to your analytics provider, so none of it tells a search engine anything. Google has said it doesn't use click data as a direct ranking factor, and Bing says it considers how users interact with search results. Neither statement involves requests that never touched a results page, and click data as a ranking signal has the full record.

Every web traffic generator is built one of two ways, and a single visit in your log tells you which.

Request senders ask for the page and stop. A website hit generator, or any tool built on a plain HTTP library, doesn't parse the HTML it gets back, so it never asks for the stylesheet, the scripts or the images, and it never runs JavaScript. In our lab, curl 8.15.0 left exactly one line: the page request, with the user agent curl/8.15.0 and no Accept-Language, Referer or Sec-Fetch headers at all. A request sender can write a browser's user agent into that line, but the requests a browser makes next never arrive, and since nothing on your page runs, your analytics tag never fires.

Browser runners drive a real browser engine, usually Chromium, through an automation library. Our lab used Playwright. Because it's a real browser, it does what browsers do once the HTML arrives: it fetches the page's files, runs its scripts and, if your analytics tag is among them, sends the tag's data. That's what "real browsers" on a generator's page can honestly mean. It isn't the same thing as a real visitor.

The difference matters before you pay. A request sender can't run your analytics tag, however its pricing page is worded. A browser runner's footprint depends on what the vendor lets it do after the page opens, and that's what the rest of this post takes apart.

The first request of a browser visit carries a dozen or more headers, and a default access log keeps two of them. nginx's predefined combined format ends with "$http_referer" "$http_user_agent", and the other headers arrive, get read and disappear. Four of the missing ones are worth logging while you test a generator.

User-Agent. A string the client writes about itself, so it only proves what the tool chose to say. It's most useful when nobody touched it. In our lab, Google Chrome 152 run from the command line in headless mode and Playwright at its defaults both sent a user agent containing HeadlessChrome where a desktop browser says Chrome. Plenty of tools replace it, and our Website Traffic sends one drawn for the device type you pick, so an ordinary-looking user agent proves nothing either way.

Sec-CH-UA. Chromium browsers also send client hints, a separate header that lists the browser's brands. When we gave Playwright a desktop Chrome user agent, the User-Agent header changed and Sec-CH-UA kept listing "HeadlessChrome";v="151" on every request. One setting, two headers describing the same browser, and only one of them changed.

Accept-Language. Browsers send the languages their user prefers. Playwright at its defaults sent no Accept-Language header at all. With a German locale set, it sent de-DE, and the page's own JavaScript reported German too. That second reading matters because GA4 never sees your server's headers. Its tag runs in the browser and collects there: Google lists language, page_location, page_referrer, page_title and screen_resolution among the parameters "collected by default with every event" on a web stream.

Sec-Fetch-Site. The browser sets this one itself, and it records how a navigation started. MDN gives none for "a user-originated operation" such as typing a URL or opening a bookmark, cross-site when the request was started from a different site, and same-origin when your own page started it. Keep it in mind for the next two sections, because it's where a written referrer and the browser's own account of the visit can disagree.

The IP address isn't a header. It's the address at the other end of the connection, so a generator can't type a different one into the request. What it controls is where the connection starts: which data center, which country, which network. That makes the address the one field in your log that describes the vendor's infrastructure rather than its settings. If a CDN or load balancer sits in front of your server, make sure your origin logs the visitor's address and not the CDN's.

Each public address belongs to a block that some network announces under its autonomous system number, or ASN, and the name the network is registered under usually tells you what kind it is: a hosting or cloud company, a home broadband provider or a mobile carrier. You can look it up for free with RIPEstat. One call "returns the containing prefix and announcing ASN of a given IP address", and a second returns the network's holder name:

https://stat.ripe.net/data/network-info/data.json?resource=8.8.8.8
https://stat.ripe.net/data/as-overview/data.json?resource=15169

For 8.8.8.8, the first call returned AS15169 and the second returned the holder GOOGLE - Google LLC when we ran them on September 11, 2026. Swap in an address from your log and read the holder name.

Only your own logs can do this. Google says that in Google Analytics 4 "IP addresses are not logged or stored", so the address, and the network behind it, survive only in your server and CDN logs. A CDN can act on the network as well as record it: Cloudflare's rules language has a field for "the Autonomous System (AS) number associated with the client IP address", which a site can use in its rules to treat a whole network differently before a request ever reaches the server.

Ours, stated plainly: our delivery policy says Website Traffic and Realistic Traffic are "delivered using Data Centre IPs only." Look up any of those visits and you'll get a hosting network's name, not a household's broadband provider. A vendor who says its visits come from homes should be able to show you the same lookup coming back with consumer providers.

A generator's referrer setting writes one value into two places. Your server gets it as the Referer header on the page request, and your analytics tag reads it in the browser as document.referrer, which GA4 collects with every event as page_referrer. In our lab, when Playwright opened the test page with https://www.google.com/ as its referrer, the header in the log and the value the page's script read were identical. The setting works, and it's still only a string. What a genuine Referer can contain, and how GA4 turns it into a channel, is in referrer control explained.

Three other things in the log say more than the referrer does.

• The browser's own account of the navigation. The Google referrer arrived with Sec-Fetch-Site: none, the value for a navigation no page started. A click on a real results page is started by the search engine's page, so it arrives marked cross-site. A search engine referrer beside none is a pairing an ordinary click doesn't produce.
• The second page. A script that never clicks has to open each next page directly. In our lab that second page arrived with no Referer and Sec-Fetch-Site: none, and the tag read an empty referrer, because the tool supplied none. When the tool clicked the link instead, the second page arrived with the first page as its referrer and same-origin, exactly as a reader's click does.
• The files. Every stylesheet, script and image request carries your own page as its referrer, whatever the page request claimed. That's normal, and it's how you tie a burst of file requests back to the page view that caused them.

Once the HTML arrives, a browser runner's visit stops being one request. In every browser run in our lab, the stylesheet, the first image and, where JavaScript was on, the script were requested within 60 milliseconds of the page, each with the same user agent. That cluster is the plainest sign in a log that a browser, not a script, loaded the page. A CDN changes where you see it, not what was sent: files it serves from cache never reach your origin, so read the CDN's logs too.

The request that matters most for your reports is one your server never sees. Google's guide to running its tags under a content security policy lists what the Google Analytics tag needs: scripts from https://www.googletagmanager.com, and connections to https://.google-analytics.com and https://.analytics.google.com. The tag loads from Google, runs in the visitor's browser and sends its data to Google, so the request that puts a visit into GA4 never appears in your access log. A setup that relays analytics through your own domain is the exception.

Your log can still tell you whether GA4 had a chance. A browser that runs scripts requests the script files your page loads from your own domain. In our lab, the run with JavaScript switched off never requested the page's script at all, and the stand-in tag never ran. No script requests, no tag, whatever the vendor's page says. Some tools make this a setting: Sparky Traffic Bot, our scripted browser tool, lets you switch off images, CSS, fonts, JavaScript, video and audio to save bandwidth, and a session with JavaScript off can't run your tag.

Running your scripts also means answering their questions. The standard property navigator.webdriver "indicates whether the user agent is controlled by automation", in MDN's words. It read true in every Playwright run in our lab where scripts ran, and false in Chrome started from the command line, so it's a clue for bot-detection scripts rather than a verdict, and it never reaches your access log.

Your page also asks other servers for things: fonts, embeds and, on many sites, ads. Those requests go from the visiting browser to those servers, so they never appear in your log either, and whether they're sent at all is up to the tool. Our Website Traffic and Realistic Traffic FAQs say "Our ad filter blocks ad requests before they resolve, so the ads on your pages are never fetched". That's a claim about requests, which is the right kind to hold a vendor to. The ad network's rules still bind you: automated traffic counted as ad impressions is invalid traffic, and the penalty lands on your account, not ours. Keep generated visits off pages that carry ads.

Some of the most useful lines in a log are the ones that never appear. An image marked loading="lazy" is fetched only when the reader gets close to it. In web.dev's account of Chrome's behavior, "Images far below the device viewport are only fetched when the user scrolls near them." Put one lazy image near the bottom of a long page and your server log records, for every visit, whether the browser came near it.

The HTML standard treats this as a known tracking channel. It switches lazy loading off when scripting is disabled as "an anti-tracking measure", because otherwise a site could track "a user's approximate scroll position throughout a session, by strategically placing images in a page's markup such that a server can track how many images are requested and when." That's exactly the check a buyer wants: a record of scrolling that doesn't depend on any analytics tag.

In our lab it behaved as described. Playwright's runs that loaded the page and waited never requested the image 6,000 pixels down the page, and the run that scrolled requested it 2.5 seconds after the page request, once scrolling had started. Two caveats keep the test honest:

• With JavaScript off, the browser fetched the lower image at once, as the standard requires. The check only means something for visits that also fetched your scripts.
• Chrome started from the command line to dump the page fetched it without scrolling too. A request for the lower image suggests scrolling. Its absence, from a browser that ran your scripts, is the stronger evidence.

Clicks leave their own trace, the second-page request carrying your first page as its referrer that the referrer section describes, and a form nobody submits sends nothing at all. GA4's scroll event is the analytics-side version of the lazy-image check, covered in what a visitor bot can't fake in your engagement data.

On September 11, 2026 we built a one-page test site on a local machine and pointed six clients at it. The page had a stylesheet, one image at the top, one lazy-loaded image 6,000 pixels down, a link to a second page, and a small script standing in for an analytics tag. The script reported what the browser's JavaScript could see back to the same server, where a real GA4 tag would report to Google. The server recorded every request and its headers. This is a lab test of general-purpose tools, not a measurement of any vendor's product, ours included.

The six clients:

• A. curl 8.15.0, a plain HTTP client.
• B. Google Chrome 152, run from the command line in headless mode.
• C. Playwright 1.62.1 driving Chromium 151 at its defaults, loading the page and waiting.
• D. The same, with a generator-style profile: a desktop Chrome user agent, a German locale and https://www.google.com/ as the referrer, then the second page opened directly.
• E. The same profile, scrolling down the page and then clicking the link.
• F. Playwright with JavaScript switched off.

Reading it against the sections above:

• The count separates the two kinds of tool. A left one line. Every browser run left a cluster.
• Every oddity came from a default or a single setting. The HeadlessChrome tokens, the missing Accept-Language, the Google referrer beside Sec-Fetch-Site: none and the second page with no referrer were each produced, or left alone, by one line of configuration.
• The requests a visit has to earn are the ones that went missing. Apart from the two clients that skip lazy loading, only the run that scrolled fetched the lower image, and the run without JavaScript never fetched the script.

What the lab can't show: every address was local, so there was no network to look up, and nothing here says how any commercial generator configures its browser. That's what your own log is for.

You can run the same lab on your own site with one test page and a small batch of visits.

1. Build the page. Publish a page nobody links to, with your analytics tag, one image near the top and one image with loading="lazy" near the bottom of a long page. Ours sat 6,000 pixels down. Keep ads off it.
2. Log the headers your default format drops. On nginx, add a second log with an extended format for the test, and remove it afterwards:

log_format gentest '$remote_addr [$time_local] "$request" $status '
                   '"$http_referer" "$http_user_agent" "$http_accept_language" '
                   '"$http_sec_fetch_site" "$http_sec_ch_ua"';
access_log /var/log/nginx/gentest.log gentest;

nginx exposes any request header as $http_ plus the header name "converted to lower case with dashes replaced by underscores". On Apache, %{Accept-Language}i and its siblings log "header line(s) in the request sent to the server."

1. Send a small batch and group the lines. Filter the log to the test page and its files, then group requests into visits by IP address, user agent and time.
2. Look up the busiest addresses with the two RIPEstat calls above and note each holder.
3. Hold each claim against its evidence:

A claim with no line to match is a question for the vendor. To run the comparison across a week and hold your log against GA4 day by day, use the seven-day trial plan. Before the first visit lands, check what the extra requests do to your hosting and analytics allowances in what a free traffic bot does to your logs, bills and reports.

We sell four products that put visits on a site, and each leaves a different shape in a log. Every cell below comes from our published product pages and policies.

Three of those rows turn into log lines you can check. Website Traffic doesn't scroll, so a lazy image near the bottom of a long page gives its visits no reason to fetch it. Realistic Traffic's scrolling can show up as that lazy-image request, and its internal click as a second page carrying the first as its referrer, while the mouse movement and highlighting happen inside the browser and send nothing to your server. SERP Clicks is the only product here where a real search happens, which is why it's also the only one that can appear in Search Console. It's desktop only, has no free tier and starts at LITE, $47 a month for 120 clicks (60 if geo-targeted, at 2 credits a click).

Two candid notes before you buy from us. Nobody's automated visits are undetectable, ours included: data center networks and pages that load but never scroll are there for anyone who reads a log, and a vendor who promises otherwise is promising something it can't check. And "delivered visits show in your Analytics" is a commitment about your reports with conditions attached in our delivery policy. It covers sites with Google Analytics installed, some third-party analytics platforms may need whitelisting through support, and sites behind Cloudflare's proxy with bot detection switched on are asked to switch them off, because we don't support bypassing them. That last condition is a real cost, since that layer is what would otherwise answer a generator's first request with a challenge instead of your page.

Website Traffic's free NANO tier needs no card, so you can run the checks above on our visits before you pay for any.