The internet’s pulse in 2025: inside Cloudflare radar’s data engine

What Cloudflare radar is

Cloudflare Radar is a public Internet observability portal that visualizes trends Cloudflare can measure from its global edge network. Think of it as a living dashboard for how the Internet behaves at scale: traffic patterns, bot activity, security events, connectivity disruptions, DNS popularity shifts, protocol adoption, and email security signals.

For operators, Radar is most useful as a reality check. When your own logs show “something weird,” Radar helps you answer three fast questions:

• Is this anomaly local to my site, or is it happening everywhere?

• Is it a traffic shift, a crawl wave, a security event, or a connectivity problem?

• Is the change persistent (trend) or transient (spike)?

It’s not “the entire Internet,” but it’s one of the best large-vantage lenses available publicly, and it’s designed to be explored by time range, geography, and category.

How the 2025 year in review is structured

The 2025 Cloudflare Radar Year in Review is a curated deep-dive that stitches together the biggest visible patterns across:

• Traffic

• Ai

• Adoption & usage

• Connectivity

• Security

• Email security

The value of this structure is that it forces cross-domain context. A traffic spike might be a product launch, but it might also be crawler behavior, a mitigation wave, or a regional outage that reshapes routing and load. Seeing those “layers” side by side is exactly what makes Radar actionable rather than just interesting.

Traffic trends in 2025

The big picture for 2025 is growth, but the interesting part is the shape of that growth. Radar visualizations tend to smooth short-term noise, which makes them good at revealing:

• Seasonal behavior (weekday/weekend rhythms)

• Event-driven bursts (announcements, outages, major releases)

• Structural shifts (persistent lift beginning at a specific time)

When you interpret the traffic charts, treat them like a macro climate map rather than a local thermometer. Your site can behave very differently depending on niche, geography, and monetization model, but global shifts often show up in your metrics as “background drift” (CPM changes, crawl load changes, baseline latency changes).

Service popularity: dns as the internet’s intent signal

One of Radar’s most underrated angles is DNS-based service ranking. DNS queries are a proxy for intent: devices and apps asking “where is X?” before they fetch it. That makes it a strong complement to pageview-centric analytics, especially when ad blockers or script failures distort measurements.

In the Year in Review, the list is dominated by platform-scale ecosystems (search, social, major SaaS, big cloud providers). The key is not the obvious top two; it’s the movement in the middle and the newcomers that climb quickly. Those shifts hint at where user attention and automation are concentrating, which matters for everything from referral patterns to abuse volumes.

Generative ai services: a category defined by churn

The generative AI ranking is the opposite of traditional web categories. Social networks, email providers, and search engines move slowly. AI services can re-rank in a quarter because distribution changes overnight: a new default in a browser, a new mobile integration, a viral feature, a developer wave.

For publishers and tool sites, this section is important for one reason: it shows when AI is not just a “headline topic,” but a measurable behavior with infrastructure impact. If AI services spike, you’ll typically see correlated shifts in crawling intensity, content demand, and sometimes even ad competition in AI-adjacent content categories.

Satellite connectivity as a traffic multiplier

Radar highlights satellite Internet expansion as a real operational factor, not a curiosity. When satellite connectivity grows, it changes the “shape” of traffic from certain geographies: latency profiles differ, congestion patterns differ, and user experience can be more variable. For site owners, that can translate into:

• Higher variance in Core Web Vitals from specific regions

• Different caching effectiveness due to higher RTT

• More sensitivity to large assets and blocking scripts

In other words, “more people online” also means “more diversity in last-mile behavior,” and Radar’s connectivity lens helps you anticipate that.

Bots, crawling, and the ai scrape economy

If you run any content site in 2025, bot traffic isn’t an edge case. It’s an ambient layer of the Internet, and it can easily become a top contributor to bandwidth, CPU time, and log volume.

The key to reading Radar’s bot sections is separating three concepts that look similar in raw logs:

• Indexing crawls (search discovery and refresh)

• Extraction crawls (scraping, training, aggregation)

• Abuse automation (credential stuffing, exploit scans, volumetric nuisance)

Radar doesn’t replace your own bot classification, but it gives a macro baseline: how big automation is, where it concentrates, and which crawler families dominate.

Verified bots: the “legitimate automation” baseline

Verified bots are the easiest category operationally because they’re recognizable and usually predictable. The Year in Review emphasizes that mainstream crawlers remain a massive share of automated requests.

This matters because many site owners make the wrong early assumption: “Most bot traffic is bad.” In reality, a large fraction is “the web doing its job.” The operational goal isn’t “eliminate bots,” it’s “control the cost and protect the experience.”

Practical implication: your caching strategy should assume that crawlers exist and will request pages differently than humans. If your pages are expensive to generate and you don’t cache well, crawlers can amplify load even when human traffic is stable.

Regional crawler mix: why your logs look different from someone else’s

Crawler mix varies by region. That’s not only about user populations; it’s also about how different ecosystems prioritize indexing, discovery, and product integration. The upshot is that two sites with similar content can see different bot distributions depending on language and audience geography.

Operational implication: don’t copy someone else’s allowlist/denylist blindly. You want rules based on your site’s real crawl patterns, not global folklore.

Ai crawlers as a share of html: meaningful, not dominant, but persistent

One of Radar’s core messages is that AI crawling is large enough to be measurable as a slice of HTML traffic. It’s not “everything,” but it’s persistent and growing.

The practical takeaway is subtle:

• If you optimize only for humans, you might still end up paying for AI crawling.

• If you block too aggressively, you might inadvertently block valuable discovery and indexing.

• If you do nothing, you might absorb an ongoing infrastructure tax that scales with your success.

That means you need policy, not panic: decide which automation you accept, under what constraints, and at what cost.

Crawl-to-refer: the economics problem publishers can’t ignore

Crawl-to-refer is the uncomfortable metric that explains why 2025 felt different. Crawling used to be “cost paid for benefit received” (search sends traffic back). In the AI ecosystem, that reciprocity is often weaker, and the incentive misalignment shows up in operational decisions:

• More sites rate-limit crawlers

• More sites separate bot-facing and human-facing delivery

• More sites enforce stricter robots and tokenized feeds

• More sites require authentication for high-value content

Even if you don’t take a hard stance, the crawl-to-refer framing is useful internally: it helps you justify infrastructure decisions and set expectations for “why bandwidth costs rose without more pageviews.”

Industry targeting: why some sites get hammered

Radar shows that AI crawler intensity isn’t evenly distributed. Certain industries attract disproportionate automation because the content is economically valuable (commerce), structurally useful (software docs), or highly “summarizable” (how-to and reference).

Operational implication: if you publish in high-interest categories, you should treat bot management as a first-class feature, not a security afterthought.

A simple operational heuristic:

• If you publish reference-like content (definitions, calculators, specs, comparisons), expect more extraction crawls.

• If you publish time-sensitive news, expect spikes aligned to news cycles.

• If you publish product-driven content, expect both affiliate scrapers and aggregation crawls.

Adoption and usage: devices, protocols, browsers

This section matters for performance and monetization. Ad delivery, caching efficiency, and rendering behavior depend heavily on device mix and protocol adoption.

Mobile os mix: the monetization and UX multiplier

iOS vs Android isn’t just a brand war; it’s a behavioral split. In many markets, iOS users correlate with higher purchasing power and different browsing patterns, which can influence RPM, bounce rate, and session depth. Meanwhile, Android dominates globally, meaning “average performance” decisions still need to work on a huge variety of devices.

Operational implication: if you only test on a modern flagship phone, you’re optimizing for a minority of the real device landscape.

Http versions: why protocol adoption changes your real costs

Radar’s distribution of HTTP versions is a reminder that protocol adoption is not uniform. HTTP/2 dominates, HTTP/3 is significant, and HTTP/1.x still persists.

This matters because protocol behavior impacts:

• Connection concurrency and head-of-line blocking risk

• Request multiplexing efficiency

• CDN cache performance patterns

• The “shape” of bot traffic (older stacks often stick to HTTP/1.x)

Operational implication: if you see a sudden rise in HTTP/1.x share, it can signal a surge in automation or legacy clients. That’s not automatically bad, but it often correlates with lower cache efficiency and higher origin load.

Browsers: baseline expectations for debugging anomalies

Browser mix gives you a baseline for debugging. If your stats show a weird browser distribution, you might be seeing:

• Script-blocked analytics (invisible humans)

• In-app browsers misclassified

• Automation faking UA strings

• Regional platform defaults shifting

Operational implication: use browser mix as a consistency check. Your “normal” distribution should be stable over time, with slow drift. Fast jumps usually indicate a measurement change or an automation event.

Web tech footprint: wordpress reality at scale

Radar’s web-tech lens is useful for one reason: it reflects what the Internet actually runs on, not what developers talk about on social media. WordPress remains enormous, while modern frameworks coexist with older libraries at surprising scale.

Operational implication for WordPress site owners: you’re in the largest target class. That means better ecosystem maturity, but also more automated scanning and more commodity abuse. Security hardening and caching aren’t optional at scale.

Automated api clients: why go and python matter

The rise of Go and Python in automated clients mirrors what many operators see: more tooling written in performant languages, more “bot-like” requests that look clean and consistent, and more traffic that is not a browser at all.

Operational implication: build bot rules around behavior, not language fingerprints. The ecosystem changes too quickly for simplistic “block X stack” thinking.

Post-quantum encryption: the quiet mainstreaming of pq tls

Post-quantum (PQ) support in TLS moved from “pilot” to “mainstream trajectory” in 2025. That sounds academic until you realize what it changes operationally:

• Client handshake characteristics shift

• TLS negotiation becomes more complex

• Network middleboxes that assume old patterns can behave badly

• Fingerprint-based detection needs updating

For most site owners, the key takeaway is positive: modern security upgrades are reaching users automatically through OS/browser updates. But it also means that performance debugging needs to consider changing handshake behavior as part of the baseline.

Connectivity and outages: why the internet goes dark

Radar’s connectivity story is the part many SEOs and publishers underestimate. Outages aren’t only “a hosting problem.” They can be:

• Government-directed shutdowns

• ISP routing incidents

• Submarine cable faults

• Power failures

• Natural disasters

• Infrastructure fires and construction damage

Policy-driven shutdowns: the invisible hand on traffic charts

When shutdowns happen, your analytics can collapse in a region without any change on your end. If you do international publishing, this affects:

• Session geography distribution

• Ad auctions (demand shifts with geography)

• Crawl behavior (retries and burst recrawls after recovery)

• Conversion rates (traffic becomes “less representative”)

Operational implication: when you see a regional drop, check connectivity context before you assume ranking loss or technical regression.

Physical infrastructure failures: cables, power, and timing

Cables and power failures create a different signature from policy shutdowns. You often see:

• Latency rising before traffic falling

• Throughput degrading

• Timeouts increasing

• Routing changes altering CDN PoP selection

Operational implication: if you have a multi-region audience, a single infrastructure event can change your global performance distribution. This is why RUM (real user monitoring) and CDN analytics are so valuable alongside SEO tools.

IPv6 adoption: uneven progress, real operational impact

IPv6 adoption remains uneven globally. For operators, the key point is not ideology; it’s compatibility and routing behavior. You want:

• Correct dual-stack configuration

• No broken AAAA records

• No IPv6 path MTU weirdness

• Proper firewall/WAF parity across stacks

Even if IPv6 isn’t the majority everywhere, poor IPv6 behavior can create “mysterious” regional performance issues that look like SEO problems.

Internet quality: speed and latency shape expectations

Radar’s speed-test lens is a reminder that “fast” is relative. Some regions have extremely high baseline throughput; others have constraints where heavy scripts or large images are more punishing.

Operational implication: performance budgets should be designed for the slow end of your audience distribution, not the peak.

Security: what “bad traffic” looks like at internet scale

Radar’s security sections are the macro backdrop for what you see locally: mitigation rates, DDoS evolution, and broad threat trends.

Mitigated traffic: the baseline noise floor

Cloud-scale networks routinely mitigate a measurable slice of traffic. That slice includes both clearly malicious activity and “unwanted” automation defined by customers. Practically, it means:

• The Internet always has background attack noise

• Scanning is continuous, not episodic

• “Quiet days” can still include probing

• Good security posture is about steady-state resilience

Operational implication: measure your mitigation as a percentage and track it over time. Sudden shifts are more actionable than absolute numbers.

Ddos escalation: why peaks keep breaking records

The DDoS story in 2025 is about two accelerations:

• Peak size rising (bigger volumetric floods)

• Frequency rising (more events, more often)

For site owners, the takeaway isn’t fear; it’s architecture:

• CDN in front of origin

• Aggressive caching for static and cacheable HTML where feasible

• Rate limiting on sensitive endpoints

• Separate admin surfaces and protected paths

• Origin hardening (timeouts, connection caps, request validation)

If your site is monetized, stability is revenue. Security isn’t just “prevent hacks,” it’s “prevent downtime and protect performance.”

Email security: the overlooked layer

Radar includes email security because phishing and spoofing remain core threat vectors. For site operators, email security trends connect directly to:

• Brand impersonation risk

• Deliverability issues

• Support load from scam reports

• Ad account and analytics account takeover attempts

Operational implication: enforce SPF, DKIM, and DMARC; monitor failures; keep your domain reputation clean. This is often the cheapest security win.

How to turn radar insights into practical actions

Monitoring playbook

1. Track baseline distributions
   Record your normal ranges for:

• Bot vs human ratio (as best you can estimate)

• Cache hit ratio

• HTTP version share

• Browser share

• Top requested paths

• Origin response times

2. Detect anomalies by shape, not by feeling
   When something changes, classify it:

• Spike (short, sharp) vs drift (slow, persistent)

• Regional vs global

• Human-facing vs bot-facing (UA + path + rate)

3. Confirm with external context
   If your traffic or performance changes regionally, validate connectivity context. If your origin load spikes without human traffic growth, validate crawling and automation.

Bot management blueprint

• Allow predictable indexing where it benefits you

• Rate-limit expensive endpoints

• Cache HTML where safe (especially for content pages)

• Protect admin, login, xmlrpc-like surfaces

• Use behavior-based rules: request rate, path patterns, abnormal header mixes

Performance blueprint

• Reduce render-blocking scripts

• Defer non-critical JS

• Optimize images aggressively (next-gen formats, responsive sizing)

• Use long TTL for static assets

• Make the “first view” cheap for both humans and crawlers

Seo and monetization alignment

• Treat crawl load as part of your “cost of traffic”

• Track RPM shifts alongside geography shifts

• Don’t assume ranking loss when you see regional drops

• Keep pages stable: fast, cacheable, and resilient during spikes

Cloudflare Radar’s 2025 view shows an Internet shaped by sustained growth, structurally significant automation, rapidly evolving AI usage, mainstream adoption of modern protocols and stronger encryption, outage patterns driven by both policy and physical infrastructure, and escalating security threats that make resilience and caching-first architecture essential for any serious content or tool site.

Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.

This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you. This helps support our independent testing and content creation.