When a suspicious referrer suddenly appears to be generating a large amount of traffic to a WordPress site, the first instinct may be to block it at the firewall. But before creating Cloudflare rules or changing server configuration, it is important to determine whether the traffic is actually reaching the website or simply appearing in analytics as referral spam.
In this case, a suspicious domain appeared to be generating significant traffic. The initial request was to block the source at the firewall, but the investigation showed that the correct next step was first to confirm whether the activity existed only in Google Analytics 4 (GA4) reporting or represented genuine requests reaching the website. That distinction determines whether the solution belongs in analytics, Cloudflare, or another security layer.
Issue background
A WordPress site was showing what appeared to be a large volume of traffic from an unwanted external source. The request was to determine whether that source could be blocked at the firewall level.
The site was already using Cloudflare, but only for DNS management. Stricter Cloudflare bot-blocking or Web Application Firewall protections had not been configured for the site.
Because the reported traffic was associated with a referring domain, there were two very different possibilities:
- The source was sending real automated requests to the website and consuming site resources.
- The source was appearing only in analytics as referral spam without meaningfully hitting the WordPress application.
Those two scenarios require different fixes, so blocking traffic before verifying the source could lead to unnecessary configuration changes.
Diagnosis
The first technical conclusion was that firewall-level blocking would be the most effective response if the traffic represented real requests reaching the site. However, the hosting configuration did not provide direct firewall-level traffic controls, so any upstream blocking would need to be handled through a service such as Cloudflare.
The team then confirmed that the site was using Cloudflare. At that point, a more important diagnostic question emerged: was the suspicious source visible in GA4 referral reporting, or was there evidence that it was generating actual HTTP requests against the site?
This distinction matters because referral spam can pollute analytics data without behaving like conventional bot traffic against WordPress. In that situation, a firewall rule may not address the underlying reporting problem. Instead, the appropriate action may be to filter or exclude the unwanted referral in GA4.
By contrast, if server logs, Cloudflare analytics, or other traffic data confirm that a bot is actually requesting pages or endpoints, Cloudflare can be used as the upstream control point for blocking or challenging that traffic.
Resolution steps
A practical workflow for investigating suspicious referral or bot traffic is:
- Identify where the traffic is being observed. Confirm whether the suspicious source appears in GA4, another analytics platform, server logs, Cloudflare analytics, or multiple places.
- Do not assume referral traffic equals real site traffic. A suspicious referrer in analytics can be referral spam rather than evidence of a bot actively loading WordPress pages.
- Check the current Cloudflare configuration. Determine whether Cloudflare is being used only for DNS or whether traffic is actually proxied through Cloudflare. DNS-only use does not provide the same WAF and bot-management opportunities as proxied traffic.
- If the problem is analytics spam, address it in analytics. For unwanted referral data in GA4, use the appropriate referral exclusion or filtering configuration so the source no longer pollutes reporting.
- If real bot requests are confirmed, move protection upstream. When Cloudflare is proxying site traffic, its firewall and security controls can be used to block or challenge unwanted requests before they reach WordPress.
- Review the available Cloudflare plan and existing rules. The exact controls available can depend on the account plan and the site’s current Cloudflare configuration, so rule creation should be based on what the account actually supports.
- Monitor after changes. Recheck analytics and traffic data to verify that unwanted activity has stopped or that the reporting data is clean.
The task also highlighted an important operational point: when Cloudflare was initially being used only for DNS, enabling stricter bot or WAF protections would have required changing how traffic was routed through Cloudflare rather than simply adding a WordPress-level setting.
Final outcome
The investigation established the correct diagnostic path but did not document a completed Cloudflare firewall-rule implementation. The team confirmed Cloudflare access, determined that the suspicious activity might be referral or analytics spam rather than confirmed malicious traffic, and requested confirmation of where the traffic was being observed before applying a specific fix.
The broader lesson is that suspicious referral traffic should be classified before it is blocked. If the issue exists only in GA4, solve the reporting problem in analytics. If the requests are genuinely reaching the site, Cloudflare can provide an upstream layer for bot filtering, WAF rules, and other protections.
If you are seeing suspicious bot traffic, referral spam, or unusual GA4 traffic on a WordPress site and need help determining where to block it, contact Freshy. Our WordPress team can help review Cloudflare, GA4, DNS configuration, bot traffic, and website security controls.
