WordPress

The Log Hero plugin records every request your WordPress site answers and sends it to Log Hero in batches. There is no tracking script, nothing changes on your pages, and you do not need access to the server.

Time: about 5 minutes · Access needed: WordPress administrator, Log Hero API key

Before you start

WordPress 6.0 or newer, PHP 7.4 or newer. Older versions cannot run the current plugin.
Your Log Hero API key. You get it in the signup flow at log-hero.com. If you do not have one yet, start with the Quickstart.
Somewhere to buffer. By default the plugin writes to its own logs folder inside the plugin directory, so that folder has to be writable by the web server. Hosts that keep the plugin directory read-only can use Redis instead, see Buffer options below.

1. Install the plugin

From within WordPress

Go to Plugins → Add New.
Search for Log Hero.
Choose Install Now, then Activate.

Manually

Download the plugin from wordpress.org/plugins/loghero.
Upload the loghero folder to /wp-content/plugins/.
Activate Log Hero on the Plugins page.

2. Enter your API key

Go to Settings → LogHero.
Paste your key into LogHero API Key (required).
Choose Save Changes.

Nothing is transmitted until a valid key is saved. While the field is empty, WordPress shows an admin notice on every page of the backend.

3. Confirm hits are arriving

Open Log Hero → Bot Activity in your Keyword Hero account. Within a few minutes you should see the banner Log Hero is receiving bot traffic for this domain and a non-zero Bot hits figure.

You do not need to generate traffic yourself. Bots arrive on their own, and on most sites the first bot request lands within the hour.

How the plugin works

Understanding the mechanism makes the two common failures obvious.

On every request, the plugin hooks WordPress’ shutdown action and appends one record to a buffer file at wp-content/plugins/loghero/logs/buffer.loghero.io.txt. The folder ships with an .htaccess that denies access to it.
When the buffer passes 100 KB, or when the last dump was more than 5 minutes ago, the plugin triggers a flush.
The flush is a non-blocking call to the REST route loghero/v1/flush on your own site, authenticated with your API key in a Token header. The visitor’s page is never held up by it.
That route posts the buffered records to https://in.app.log-hero.com/logs, in batches of at most 1000 records.

If your server blocks requests it makes to itself, step 3 fails and the plugin falls back to flushing synchronously, with a warning in the backend. See Asynchronous flush failed.

Settings reference

Everything except the API key lives under Advanced Setup and should stay at its default unless you have a reason.

Setting	Default	What it does
LogHero API Key	empty	Your key. Nothing is sent without it.
Disable Log Transport	off	Buffers records but never sends them. For manual submission only.
Disable Async Mode	off	Sends records synchronously, inside the visitor’s request. Use only if the asynchronous flush fails.
Redis URL	empty	Buffer in Redis instead of a file, for example `tcp://127.0.0.1:6379`.
Redis Key Prefix	`io.loghero:wp:<api-key>`	The key the buffered records are stored under.

Buffer options

The file buffer is the default and needs no configuration, but the plugin’s logs folder must be writable. If it is not, WordPress shows a permission denied notice and no data is collected. See Permission denied.

The Redis buffer replaces the file entirely. Enter a Redis URL and the plugin buffers there, flushing after 1000 records or 5 minutes. This is the option for read-only deployments and for sites spread over several application servers, where each server would otherwise keep its own file.

What the plugin cannot see

The plugin runs inside WordPress, so it only sees requests that boot WordPress.

Static files. Images, PDFs, CSS and JavaScript served straight off disk by the web server never reach PHP.
Cached pages. A full-page cache plugin, a reverse proxy or a CDN in front of WordPress answers without involving PHP. Those hits are invisible here.
Response times other than PHP’s. The recorded duration is how long WordPress took to build the page, not what the visitor experienced.
Server errors that never reached PHP. A 500 WordPress itself produced is recorded — the plugin logs on shutdown, which still runs after a fatal error. A 502 or 504 from your web server, because PHP-FPM was down or timed out, is not. See Status codes.

If your site sits behind a CDN and you need the requests it answers from cache, read Choose your integration.

What is sent

The plugin transmits one record per request, for every request, from bots and human visitors alike. Filtering happens on the Log Hero side, not in the plugin, which means visitor IP addresses are transmitted too.

Each record contains the hostname, the protocol, the requested path including its query string, the request method, the status code, the User-Agent, the Referer if present, the client IP address, the timestamp and the time WordPress needed to build the response. Anatomy of a log line explains what each of those fields tells you — and which two of them a client can forge.

If it doesn’t work

Work through No data arriving. The WordPress-specific causes, in the order they turn up:

The plugin is older than 0.3.0 and posts to a dead endpoint.
The logs folder is not writable, see Permission denied.
The server blocks loopback requests, so the flush trigger never arrives, see Asynchronous flush failed.
A page cache answers before WordPress runs, so there is nothing to record.