In WordPress, self-requests are HTTP requests that your site sends to itself — typically to wp-cron.php, admin-ajax.php, or other endpoints — to perform scheduled tasks, process background jobs, and update content without direct user interaction. While they are an integral part of WordPress’s architecture, they can affect performance if misconfigured.
WordPress implements a pseudo-cron system called WP-Cron.
It relies on self-requests to trigger scheduled events, including:
Instead of a true system cron, WP-Cron is triggered when someone visits your site — a visit prompts WordPress to send a request to itself (wp-cron.php) to run pending tasks.
Introduced in WordPress 3.6, the Heartbeat API uses AJAX-based self-requests between the browser and the server.
It enables:
These requests typically hit admin-ajax.php every few seconds when you are in the admin panel.
If enabled, WordPress sends self-requests to:
While not as commonly used today, they still generate background traffic.
Many plugins and themes trigger self-requests for purposes such as:
If your site consumes RSS feeds (e.g., via widgets or plugins), WordPress may use self-requests to fetch and process feed data for display.
Self-requests are useful, but excessive or poorly optimized ones can:
Best practices include:
Are self-requests a security risk?
Normally no, but vulnerabilities in plugins/themes handling these requests can be exploited.
Can I disable them?
Some self-requests like WP-Cron can be replaced with system crons; others, like Heartbeat API, can be limited or disabled via plugins or filters.
Do they affect SEO?
Not directly, but excessive load can slow down your site, which impacts user experience and indirectly affects SEO.
