libwww-perl

What libwww-perl does

LWP is Perl's classic web library, fetching pages for scripts since the 1990s. Its default UA marks the tool, not the operator: ancient cron jobs, sysadmin utilities, and - notoriously - old exploit scripts all announce themselves the same way. The base library ships with no robots.txt handling (a separate LWP module adds it, if the author bothers) and no JavaScript.

Why it visits your site

A Perl script fetched your page. In 2026 that's most often legacy automation or a recycled scanner script, since new tooling rarely gets written in Perl.

The bigger picture: utility & developer tools

This category is the honest miscellany of a server log: monitoring services, platform callbacks, and the default user agents of HTTP libraries. The unifying rule is that the string identifies software, not intent. A curl request might be your host's health check or a vulnerability probe; a python-requests hit might be a researcher or a scraper; a WordPress UA is one site talking to another. Reading these names as a threat list misses what they actually are - a census of the scripted web touching your site, most of it mundane, some of it yours.

robots.txt barely applies here, and not out of rudeness: monitors fetch the exact URL a customer configured, feed fetchers act on a user's subscription, and bare libraries simply ship with no robots logic at all. Blocking a default library UA filters the honest and the lazy while the malicious change one line and continue, so the effective levers are different - rate limiting by IP, watching which paths get requested, and reserving blocks for named services you can verify and have decided you don't want.

Should you block it?

libwww-perl is one of the oldest entries on shared-hosting UA blacklists because early exploit kits never changed the default - and precisely because everyone blocks it, modern attackers don't use it. Blocking it today mostly inconveniences someone's crusty-but-legitimate maintenance script. Low stakes either way; base decisions on what the requests actually target.

Block via robots.txt

Add these lines to the robots.txt at your site root to ask libwww-perl to stay away:

User-agent: libwww-perl
Disallow: /

Remember that robots.txt is a request, not a lock - compliance is voluntary, and enforcement happens at the server. Viz's AI Control pairs robots.txt rules with server-level 403 responses and then probes your site to verify the block is actually holding.

How to see libwww-perl traffic on your site

You have three windows onto it, each with a catch. Raw hosting access logs contain every libwww-perl request, but many managed WordPress hosts don't expose them, and when they do you are grepping text files by hand. A CDN dashboard sees the traffic at the edge, but it lives outside WordPress and speaks in totals, not in your site's terms. And JavaScript analytics - GA4 and friends - will never show it at all, because libwww-perl doesn't run scripts.

Viz's answer is the request log: filter to libwww-perl and read exactly which URLs it fetched and when, right inside wp-admin - then watch the same filter after any blocking decision to see whether the visits stopped, slowed, or kept coming.