Read delivery evidence, recognized crawler observations, and privacy controls correctly.

How it works

Analytics recording is opt-in. When enabled, Cybermaps records registered endpoint requests that execute WordPress/PHP plus crawler-signature and conservative crawler-candidate visits to ordinary content. Diagnostic probes sent by Cybermaps status pages are excluded.

When XML management is off, Sitemap Status reports that disabled state and offers the settings link instead of probing unowned URLs. Those paths are no longer classified or throttled as Cybermaps sitemap endpoints; ordinary crawler-content observation rules still apply.

Quick Setup’s activity-insights choice enables logging with IP anonymization for 30 days and selects dynamic delivery. Its lightweight choice disables logging and favors static delivery; existing log history is not cleared by that choice.

The classifier distinguishes:

a claimed registered crawler signature;
a conservative unregistered-crawler candidate;
another automated client;
a browser or manual client;
a missing User-Agent;
an unknown client; and
a logged-in WordPress user.

Crawler names are matches against a self-reported User-Agent product token, not verified provider network identities. Product-token matching avoids classifying a bot name that appears only inside a comment or documentation URL.

Logged-out observations can include time, path, endpoint, response status, method, accepted media family, identity class, normalized User-Agent, site-specific pseudonymous requester key, resolved-IP source, IP-storage mode, and the resolved address. IP anonymization is enabled by default and stores an IPv4 /24 or IPv6 /64 network. Administrators can instead retain full resolved addresses for future rows. Changing this choice does not rewrite existing history.

Logged-in observations store the numeric WordPress user ID and omit IP, requester key, and User-Agent. WordPress personal-data export and erasure tools cover these rows, and user deletion removes that user’s authenticated observations.

ClientIPResolver uses the immediate peer by default. It accepts CF-Connecting-IP only when that peer belongs to an official Cloudflare network. The general trusted-proxy settings trusted_proxy_header and trusted_proxy_cidrs are both off by default; when enabled, the selected forwarded-IP header is trusted only from the configured CIDR ranges. Cybermaps never trusts arbitrary forwarded headers and still exposes cybermaps_client_ip_resolution for integrations that validate another proxy boundary.

That filter receives a bounded, sanitized context rather than the full server environment. Its context can contain only valid values collected from REMOTE_ADDR, HTTP_CF_CONNECTING_IP, HTTP_FORWARDED, HTTP_X_FORWARDED_FOR, and HTTP_X_REAL_IP. An integration still has to authenticate its own proxy boundary before returning a client address. Each header is limited to 4,096 bytes and forwarding chains to 32 hops. Invalid addresses, control characters, and excessive chains are rejected rather than truncated into a trusted address.

Retention accepts 1–365 days and is enforced by a daily cleanup event. Discovery Analytics can export or clear the stored history. Physical files, CDNs, web-server rules, and full-page caches answer before PHP and therefore cannot appear in these statistics.

Local 60-second request limits protect discovery routes by matched crawler, installation-salted client identifier, cost tier, and minute. REST search uses an installation-salted one-way identifier derived from the resolved IP; neither the raw address nor query is stored in that rate-limit transient.