WordPress and CMS user agents
WordPress and other content systems generate server-side HTTP requests that carry their own user agents — notably WordPress pingback requests and loopback calls the site makes to itself. These can look like external bots in logs but are often your own CMS. This page explains the patterns so you read them correctly.
Pingbacks and loopback requests
WordPress makes server-side HTTP requests in normal operation. Pingbacks are notifications WordPress sends to another site when you link to it, carrying a WordPress user agent. Loopback requests are calls a WordPress site makes to itself — used by features like the built-in cron and the site health tool — which also carry a WordPress user agent.
Because loopback requests originate from the site to itself, they can appear in logs as a bot hitting your own URLs. That is expected behaviour, not an intrusion.
- Pingback: WordPress notifying another site of a link
- Loopback: the site making HTTP requests to itself
- Both carry a WordPress user agent and run server-side
Reading CMS traffic correctly
Mistaking a WordPress loopback for an external bot can lead you to block your own site's internal calls, breaking cron or site-health features. Recognising the WordPress user agent on these requests prevents that.
Note the pingback mechanism has historically been abused for reflection-style attacks, so the WordPress user agent also appears in unwanted pingback traffic. Identify it by the documented token, judge by behaviour, and consult WordPress's documentation for specifics, since other CMS platforms emit their own distinct user agents too.
How it appears in analytics and logs
A WordPress user agent on a pingback or loopback request is the CMS acting server-side — often your own site calling itself — not an external visitor. A pingback UA hitting other sites is WordPress notifying them of a link.
Diagnostic use case
Recognise WordPress pingback and loopback user agents so internal CMS requests are not mistaken for external bots or counted as human visits.
What WebmasterID can help detect
WebmasterID recognises common WordPress and CMS user agents server-side and classifies them as automation/system traffic, separate from human analytics, with unknown clients kept in an honest bucket.
Common mistakes
- Blocking WordPress loopback requests and breaking cron or site-health features.
- Mistaking your own site's loopback calls for an external bot.
- Counting CMS server-side requests as human page views.
Privacy and accuracy notes
CMS user agents describe software and server-side processes, not a person. WebmasterID records them as automation/system events, never as human profiles.
Related pages
- curl, wget and script user agents
Command-line and library HTTP clients send a default user agent that names the tool: curl/x.y, Wget, python-requests, Go-http-client, and similar. These are scripts, not browsers, and seeing them is normal. This page explains the patterns and how to treat them without over- or under-reacting.
- Bot vs browser user agents: how to tell them apart
A user-agent string is a self-reported label, not an identity. This page explains how declared bots name themselves, why almost every UA still starts with the legacy Mozilla token, and how to read the difference between an automated client and a real browser without over-trusting the string.
- Website observability
See system, automation, and human traffic in their proper categories.
Sources and verification notes
- WordPress — Loopback requests and site health documentation
- WordPress — Pingbacks support documentation
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.