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.
This approach has a practical downside: if no one visits your site for an extended period, scheduled tasks simply do not run. For low-traffic sites, this means scheduled posts may publish late and update checks may be delayed. On high-traffic sites the opposite problem occurs — the script can be triggered dozens of times per minute, adding unnecessary load to your server. This is one reason many hosting providers and developers recommend disabling the built-in WP-Cron and setting up a proper system cron job instead. You can disable the default behavior by adding define(‘DISABLE_WP_CRON’, true); to your wp-config.php file, then scheduling a server-level cron to call wp-cron.php at a fixed interval, such as every five minutes. This gives you full control over when tasks run and removes the dependency on site traffic. For more details on configuring this, see the official WordPress developer documentation on WP-Cron.
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.
The Heartbeat API is useful for collaborative editing environments, but on sites where multiple admins are logged in simultaneously, the volume of AJAX calls can become noticeable. Each ping is a separate server request, and while individual requests are lightweight, they accumulate. The frequency of these requests can be adjusted or reduced using the heartbeat_settings filter in your theme’s functions file, or by using a dedicated plugin. Reducing the interval from the default 15 seconds to 60 seconds, for example, can noticeably lower admin-related server load with no practical impact on the user experience. For reference, see the WordPress Heartbeat API documentation.
If enabled, WordPress sends self-requests to:
While not as commonly used today, they still generate background traffic.
Pingbacks and trackbacks were designed to connect the early blogging ecosystem, but in practice they are now largely used as a vector for comment spam. Most sites disable them entirely through the WordPress discussion settings. Doing so removes a category of self-requests that provides little value for most modern websites.
Many plugins and themes trigger self-requests for purposes such as:
Plugin-triggered self-requests vary widely in quality and frequency. Some well-built plugins use WordPress’s own scheduling system, which hooks into the cron layer, while others implement their own background processing logic. When evaluating a plugin, it is worth checking whether it adds scheduled events and how often they fire. Plugins like WP Crontrol let you inspect and manage all scheduled tasks from the WordPress admin panel, giving you visibility into what is running in the background and how often.
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.
Feed-related requests are usually cached after the first fetch, so they do not repeat on every page load. However, if caching is misconfigured or a plugin bypasses the cache, repeated feed requests can add up. Checking your caching plugin’s settings to confirm feed responses are stored correctly is a simple step that prevents unnecessary traffic.
Self-requests are useful, but excessive or poorly optimized ones can:
Best practices include:
Server-level monitoring tools can help you identify which endpoints receive the most internal traffic. If you notice high volumes of requests to wp-cron.php or admin-ajax.php in your access logs, that is a clear signal to investigate further. Many managed WordPress hosting providers offer built-in dashboards for this, and tools like Query Monitor provide detailed insight into background processes at the application level.
Normally no, but vulnerabilities in plugins/themes handling these requests can be exploited.
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.
Not directly, but excessive load can slow down your site, which impacts user experience and indirectly affects SEO. Page speed is a confirmed ranking factor, and a site bogged down by unnecessary self-requests will score lower on Core Web Vitals. Keeping background processes lean and well-managed is part of a broader performance strategy that supports both user experience and search visibility. Google’s own Core Web Vitals documentation outlines how server response time contributes to ranking signals.
