Disable wp-cron properly

To disable wp-cron properly, define DISABLE_WP_CRON as true in wp-config.php and add one server cron that runs every five minutes. The constant stops WordPress from firing jobs on page views, and the crontab actually runs those jobs on a steady schedule. Using only one of the two leaves scheduled posts stuck or lets jobs pile up on busy traffic.

Why the built-in cron is unreliable

By default, WordPress checks for due events whenever someone loads a page. A quiet site may go hours without a visit, so scheduled posts and plugin tasks never fire. A busy site can trigger the same work on several requests at once, which wastes CPU and can race WooCommerce or backup jobs. Moving the work to a real cron gives you a predictable interval without tying it to visitors.

Turn off the visit-based runner

Open wp-config.php for the live site and add this line above the comment that says stop editing:

define(‘DISABLE_WP_CRON’, true);

Save the file and confirm you edited the document root that actually serves the site. If the constant is missing or sits in an old copy of the config, WordPress keeps spawning cron on traffic and your server job will not be the only runner.

Add one five-minute cron job

In cPanel, open Cron Jobs and create a single entry that runs every five minutes. Prefer WP-CLI when it is available on the account:

cd /home/USER/public_html && wp cron event run –due-now >/dev/null 2>&1

Replace USER and the path with your real home directory and WordPress root. If WP-CLI is not available, call the endpoint with wget or curl instead:

wget -q -O – https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Use your live domain in that URL. Keep exactly one cron line for this site. Two crontabs plus the old visit-based runner still on will overlap and race the same events. Five minutes is enough for scheduled posts and most store tasks; running every minute with a long job invites overlap unless you add a lock.

Verify scheduled work still runs

Confirm the cPanel cron list shows one wp-cron entry and that wp-config.php contains the constant. Schedule a test post a few minutes ahead and wait for it to publish. If nothing happens, the crontab may point at an old or parked document root, or a cache may be serving HTML for wp-cron.php instead of PHP. Exclude wp-cron.php from LSCache, fix the path or URL so it hits the live WordPress install, and test again. WooCommerce Action Scheduler has its own queue, but a real server cron still gives it a regular chance to run.