Synthetic traffic is web or API traffic produced by software instead of real people: load test virtual users, scheduled monitoring probes, post-deploy smoke checks and cache warmers. It is useful because you control the volume and the script, and risky for the same reason, since your analytics, firewall, billing and third-party services cannot tell it apart from real use unless you label it.
Key Takeaways
- Synthetic traffic has four legitimate uses: load tests, synthetic monitoring, canary or smoke checks after a deploy, and cache warming. Each has a different volume and frequency, so each carries different risks.
- The recurring risks are polluted analytics, WAF or bot rules blocking the test, calls to third-party services you do not control, and test data left in production.
- Label every synthetic request: a dedicated header, a recognisable user agent, source IPs you know, and a marker in any data it creates.
- GA4 can exclude internal or developer traffic with data filters, but an active filter is permanent and works from the moment it applies, not on past data.
- Only generate synthetic traffic against systems you own or are authorised to test.
What is synthetic traffic?
Synthetic traffic is any request generated by a script or tool on purpose, as opposed to organic traffic from real users and from search engine crawlers you did not schedule. The word describes the origin of the traffic, not its protocol or purpose, which is why it covers a 5,000 user load test and a one-request uptime check equally.
That also explains why people search it under several names. “Synthetic load testing” usually means load test traffic, “synthetic monitoring” means scheduled probes, and the comparison with real-user data is covered in the synthetic monitoring vs real user monitoring guide. This post is about the traffic itself and how to run it without side effects.
When is synthetic traffic the right tool?
Use it whenever you need a result that does not depend on who happens to visit: before launch, outside peak hours, from a place with no users yet, or at a volume you have not seen. The table compares the four uses.
| Use | Typical volume | When it runs | Main thing to protect |
|---|---|---|---|
| Load test (synthetic load testing) | High, ramped on purpose | Before releases and peaks, on demand or on a schedule | Capacity, rate limits, test data, third-party services |
| Synthetic monitoring | One request or one journey per run, from a few locations | Around the clock, on a fixed interval | Analytics, alert noise, login accounts |
| Canary or smoke check | A handful of requests | Right after a deploy | Test accounts, side effects such as emails |
| Cache warming | A list of known URLs | After a deploy or cache purge | Origin load, accuracy of any test that follows |
For a load test, the synthetic traffic is the experiment: see load testing vs stress testing for the types, and realistic load testing scenarios for e-commerce for how to make virtual users behave like customers. For monitoring, see improving user experience with synthetic monitoring.
How do you tell synthetic traffic apart from real users?
Add a label that your own systems can read, and keep the list of what you send. Four labels work together:
- A custom request header, for example
X-Synthetic-Traffic: loadtest-2026-10, set on every request from the test or monitor. Log it at the proxy so you can filter log queries and dashboards. - A recognisable User-Agent suffix, which analytics and WAF tools can match without custom configuration.
- Known source IP ranges. Cloud load generators and monitors run from published or stable addresses; record them. GA4 internal traffic rules can match on an IP address by equals, begins with, ends with, contains, CIDR range or regular expression.
- A marker in created data, such as an email on a reserved test domain or a prefix on order names, so cleanup scripts and reports can find test records.
A header is a label, not a pass. Do not let a request skip authentication, rate limits or fraud checks just because it carries a header, since anyone can copy it. If a bypass is needed for a test, make it verifiable, for example a secret value checked by the firewall, and rotate it after the test.
How do you keep synthetic traffic out of Google Analytics?
Tell GA4 which traffic is internal and filter it out. Google’s documentation says that once you define internal traffic rules, Analytics adds a traffic_type parameter to incoming events, with the default value internal, and that you create a data filter to act on it. A data filter can be in testing, active or inactive state (Google’s internal traffic page, read 2026-10-23).
Steps that follow from the documentation:
- Define an internal traffic rule with the IP addresses of your load generators and monitors.
- Create the Internal Traffic data filter and leave it in testing state first, so matching events are flagged without being removed. Check the reports.
- Switch the filter to active only when the test result looks right. Google states that an active filter makes permanent changes, excluded data is never processed and cannot be recovered, and a filter can take 24 to 36 hours to apply.
- For test scripts that run in a browser, set the
traffic_typeparameter yourself or use a debug mode developer-traffic filter, because their source IP may not be on your list.
Two points keep this realistic. A load test that requests HTML and JSON over HTTP does not run the analytics tag, so it never reaches GA4. A browser-based check or a real-browser test does run it. GA4 also excludes traffic from known bots and spiders, using Google research and the IAB list, and you cannot turn that off, but your own test tools are not on that list.
Worked example with illustrative numbers
These figures are assumptions. A site has 2,000 real sessions a day. A browser check runs every 5 minutes from 5 locations, and each run loads the analytics tag.
- Runs per location per day: 24 x 60 / 5 = 288.
- Across 5 locations: 288 x 5 = 1,440 synthetic sessions.
- Share of the total: 1,440 / (2,000 + 1,440) = about 42 percent.
Without a filter, conversion rate would fall by the same share for no real reason. The same arithmetic shows why a monitor that checks only an API endpoint, with no browser, adds nothing to the analytics counts.
What can go wrong with firewalls, third parties and data?
Most synthetic traffic incidents come from the systems around the application, not the application itself.
- WAF and bot rules. A rate-based rule counts requests over an evaluation window and limits them when they arrive too fast, aggregated by your chosen key such as the source IP (AWS WAF documentation, read 2026-10-23). A load generator is exactly that traffic. Agree an allow rule for the test source IPs and window with whoever runs the firewall, and expect partial results if you do not. Blocked requests in a test report are a signal about the firewall, not about performance.
- Third-party services. Payment gateways, SMS and email providers, maps and metered APIs get real calls, and may bill them or throttle your account. Use the provider’s sandbox, a stub, or a mock for those hops, and never send synthetic load to a service you are not authorised to test.
- Test data in production. Synthetic signups, orders and emails persist. Create them in a test tenant or with a clear marker, make downstream jobs skip marked records, and schedule cleanup.
- Caches. A cache warmer or a repeated URL list inflates the hit ratio and flatters response times. If the test should reflect real use, vary the URLs and read the cache invalidation post before trusting the numbers.
- Alert noise and cost. A monitor that runs every minute from many regions multiplies requests, log lines and alerts. Match the frequency to how fast you could act on a failure.
Rate limits on your own API can also look like failures during a test; the API rate limiting causes post helps tell them apart.
How does LoadFocus generate synthetic traffic?
LoadFocus covers two of the four uses. Its load testing runs JMeter and k6 scripts from 25+ cloud regions, and its synthetic monitoring runs API checks, multi-step API checks and Playwright browser checks on a schedule from cloud locations. For a definition, see the synthetic monitoring glossary entry. Whichever tool you use, set a distinctive header and user agent in the script, as described above, and check with the people who run your WAF and analytics before the first run. See the product pages for current limits and plans.
Frequently Asked Questions
What is synthetic traffic?
It is traffic generated by software on purpose: load test virtual users, monitoring probes, deploy smoke checks and cache warmers. It differs from organic traffic in origin, not protocol, and it needs labelling so analytics, firewalls and billing can treat it correctly.
Is synthetic traffic the same as bot traffic?
Not exactly. Bot traffic usually means automated requests you did not choose, such as crawlers or scrapers. Synthetic traffic is automated traffic you generate deliberately against your own or authorised systems. To a firewall they can look alike, which is why test traffic should be announced and allow-listed.
How do I exclude synthetic traffic from Google Analytics?
Define an internal traffic rule for your test source IPs in GA4, create the Internal Traffic data filter in testing state, verify the reports, then activate it. Google notes that an active filter permanently removes matching data and can take 24 to 36 hours to apply. Requests that never run the analytics tag, such as HTTP-only load tests, do not need a filter.
Can synthetic traffic hurt SEO or rankings?
Load tests and monitoring do not directly affect rankings. The indirect risks are real: a stress test can slow or crash the site while crawlers and users arrive, and polluted analytics can mislead decisions. Run heavy tests outside peak hours, on a staging copy where possible, and keep the load below what production can take.
Is it legal to send synthetic traffic to a site?
Only to systems you own or have written permission to test. Generating load against someone else’s site, or against a third-party API you depend on, can breach terms of service and the law. Use sandboxes for external dependencies.
Should I run synthetic tests in production?
Light, read-only checks, such as an uptime or login probe with a test account, are normal in production. Heavy load tests belong in a production-like environment, or in production only with a plan, a limit and the people who run the platform informed.
Sources
- Google, Analytics Help, Set up data filters and internal traffic, https://support.google.com/analytics/answer/10104470 and https://support.google.com/analytics/answer/10108813 (read 2026-10-23)
- Google, Analytics Help, Known bot-traffic exclusion, https://support.google.com/analytics/answer/9888366 (read 2026-10-23)
- AWS, Using rate-based rule statements in AWS WAF, https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html (read 2026-10-23)
- LoadFocus, loadfocus.com/index.md and https://loadfocus.com/synthetic-monitoring (read 2026-10-23)
