How To Solve WP-Cron Job Errors Caused By WordPress Hosting

Want to know how to solve WP Cron Job errors caused by WordPress hosting? It’s actually easier to spot and fix than you might think. And just five minutes resolving the issue can make a big difference to the performance of your WordPress website, usability and search engine optimisation.

Whether you need to change your wp-cron.php settings will depend on your internet host. Some hosts will disable it from running due to resource usage and legitimate security concerns. For example, Heart Internet. Others I know that encourage manual cron jobs include InMotion, Hostgator and many more.


What Are WP-Cron Job Errors:

You can spot if you have any WP Cron Job errors fairly quickly. If you look at your website, or the list of pages visited in your analytics software, do you ever see urls with ?doing_wp_cron= followed by a string of numbers?

So for example

If so, that indicates that you currently have an issue. Especially as those urls will be duplicates of existing articles.


What is a WP-Cron Job And Why Does It Fail:

WordPress uses a file named wp-cron.php as the way to scheduled automated tasks. For instance checking for updates, sending emails and automated tasks like backing up. It’s a virtual cron job which is triggered whenever a scheduled task is due to run, which can be either due to someone visiting and generating an automatic email, or having your back-up set to run on a regular basis.

So when someone lands on any page on your WordPress site, the wp-cron.php file could fire up and check whether it needs to send anything

On many WordPress hosts, this will run as intended. But some disable this functionality from running because it means that large visitor numbers can fire the virtual cron jobs a lot of times, using up the resources on your server. It’s also a potential security vulnerability.

For example, this site is hosted by Heart Internet, and their default setting is to have wp-cron.php disabled.


What Problems Do WP-Cron Errors Cause?:

There are two issues which can be created by wp-cron.php not working as intended. The first is that plugins and functionality which relies on cron jobs may not work properly, or might generate errors. So that includes things like scheduled posts, but also a lot of plug-in functionality for tasks like automated back-ups, auto-generated emails etc.

The other issue is potentially worse, as you may not spot it until you go looking. By creating a duplicate of your article with the same url gaining ?doing_wp_cron on the end, essentially you end up with at least two versions of every WordPress post you create.

That obviously has big implications for SEO, as search engines definitely do not like large-scale duplicate content. Even more annoying is the fact that the redirects and canonicalisation it causes will point to the duplicate version, rather than the original. So you’ll generally find your pages will be dismissed from search engine listings, and you’ll have a large number of 404 and soft 404 errors listed in Google Search Console or Bing Webmaster Tools.

Essentially it makes your legitimate site look like an effort to spam search engines. As well as potentially causing people to link to your duplicate version, minimising the benefit of getting an external website link.

So basically, it’s not good. Fortunately the fix is relatively quick and painless.


How to Solve WP-Cron Job Errors Caused By WordPress Hosting

To fix the problem, you just need to follow 3 simple steps.

  1. Disable the wp-cron.php from firing when someone visits your website.
  2. Set up a manual cron job to run on a set schedule. If you run multiple sites on one server, then stagger the times to avoid firing everything at once.
  3. Redirect the incorrect urls so that they point to the article addresses you actually want to rank, and stop confusing search engines.


1. How To Disable wp-cron.php

So first we need to stop that pesky wp-cron.php from causing any more problems. This is relatively simple once you’ve accessed the wp-cron.php file which is part of your WordPress software.

You can get to the files in your WordPress install via your hosts CPanel controls, although I prefer to use an FTP client to log into the server. With most hosts, you’ll need to log into the CPanel to unlock ftp access before using the details they supply in whatever FTP software you prefer. Personally, I’ve used Filezilla for years with no issues as it’s free, open source and frequently updated.

When you connect with Filezilla, you’ll generally see a default WordPress install puts all your files into a folder named Public.html. Open that and within the list you should find your wp.config.php file. This controls specific functions of your website, including cron jobs.

Click to view and edit. And before you do anything else, save a copy in notepad or similar just in case anything goes wrong. If you forget, you’ll either need to find the example listed on or reinstall WordPress.

You should see some text relating to your specific installation, and then:

/** Database Charset to use in creating database tables. */ define(‘DB_CHARSET’, ‘utf8’);
/** The Database Collate type. Don’t change this if in doubt. */ define(‘DB_COLLATE’, ”);

Underneath that text, simple add the following line:

define( ‘DISABLE_WP_CRON’, true );

You may seem some advice suggesting using define( ‘ALTERNATE_WP_CRON’, true ); as a solution, but every describes it as ‘a bit iffy’, and I’ve never found it to work yet. And the extra time for replacing the disabled version is only a couple of minutes more…

2. Set Up Your Manual Cron Job

For this step, you need to set up a manual cron job to run via your hosting company cPanel rather than relying on WordPress. This may be located in different places depending on your host – for example, Heart Internet list Scheduled Tasks under Web Tools. Wheras for InMotion you can find it listed as Cron Jobs under Advanced.

You then need to enter the script to run. For Heart Internet use:
/usr/bin/php5 /home/sites/yourdomainnamehere/public_html/wp-cron.php

And the space between php5 and /home is intentional! You’ll need to use the version of PHP your site is running on for it to run. For example, if you’re using php7, then you’ll need:

/usr/bin/php7 /home/sites/yourdomainnamehere/public_html/wp-cron.php

You should then be able to test it and if it’s correct, you’ll see the following pop up:

Solve WP-Cron Job Errors Caused By WordPress Hosting

‘The page at says
Your script returned the following:
X-Powered-By: PHP/5.2.17
Content-type: text/html’

InMotion, for example, recommend using the following, and replacing userna5 with your cPanel user name.

cd /home/userna5/public_html; php -q wp-cron.php

If there’s a problem, the first thing to check is the PHP version you’re using.

The only other thing to set is how often you want the manual cron job to run. Generally, you could run it every 6 hours for a low traffic site, or every hour if you have a more popular site. Either way, it’s going to actually work, and you can adjust the frequency if your hosting company alerts you to increased server usage (or you can check the server logs to preempt any warnings…)

So now we have the cron job issue fixed, as per existing advice and guides online.

But actually there’s still a big problem. We still have potentially thousands of duplicate pages floating around, and the confusion for search engines trying to find the right ones to list in search results.

For one site I left to test, the number of incorrect pages being visited had jumped over the last couple of months to be almost 50% of the total pages viewed on the site! Definitely not good.

Fixing WordPress Cron Usability and SEO Issues:

So to reconcile the right urls for users and search engines, we need to direct them to the right pages.

We could do that manually by individually redirecting each error. For instance, you could use a plugin like Redirection and go through everything listed in Google Analytics (or at least anything getting a reasonable amount of traffic).

That’s not the best use of your time though, and there’s a far better way.

Fire up your FTP client again, and this time you’re looking for your .htaccess file in your public.html folder.

When you select view and edit, you should see something like:

# Switch rewrite engine off in case this was installed under HostPay.
RewriteEngine Off


DirectoryIndex index.php

 BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

All we need to do to redirect every example of ?wp_doing _cron is add a rewrite for it. I’m no expert in creating rewrite conditions, so cheers to Rob Hughes from for his assistance with this…

You just need to add:

RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

For example:

# Switch rewrite engine off in case this was installed under HostPay.
RewriteEngine Off


DirectoryIndex index.php

#Rewrite Wp Cron Errors:
RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
RewriteRule ^ %{REQUEST_URI}? [R=301,L]

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

The # indicates something which is there for your notes, rather than something which is part of any condition. So #Rewrite Wp Cron Errors: is a useful reminder of what that bit was added to do, particularly if I want to go back and remove it after switching WordPress hosting, or need to find it to copy across for another site if this post and my notes all mysteriously vanish.

Now you should see that when you visit one of the old urls with ?wp_doing_cron, it should automatically 301 Redirect you to the correct url. You may find that analytics/search console add your website name again after the first / in a url, so just remove that before testing as it’s a slight glitch in logging the data, rather than yet another alternate.

Not only does this mean that your users will now end up at the right place should they visit the old duplicate url. It also makes it clear to every search engine which one is the correct url, and which one is a load of old rubbish they should ignore. And by using a 301 redirect, if someone has linked to the duplicate url from their website, you pass approximately 70% or so of the value of that link to the right place, rather than losing it all.

OK, so that quick and simple solution has now resulted in 1,700 words. So here’s the quick version:

Troubleshooting WP Cron Errors:

When this hasn’t worked, there are generally a few reasons I’ve discovered:

  • Using the wrong PHP version in the code for the manual cron job
  • Reinstalling or using a .htaccess file which has ( ‘ALTERNATE_WP_CRON’, true ); in it. This has to be removed from your .htaccess file. Otherwise it can mean the final redirect doesn’t work, and you geta  500 server error every time you try and visit your website.


The TL:DR WP Cron Fix Summary:

  1. Turn off any existing wp-cron.php tasks by adding define(‘DISABLE_WP_CRON’, ‘true’); to your wp.config.php.
  2. Set up a manual cron job via the cPanel control for your host. E.G /usr/bin/php5 /home/sites/yourdomainname/public_html/wp-cron.php in Heart Internet’s Scheduled Tasks section.
  3. Redirect all the duplicate rubbish urls to the right ones by adding
    #Rewrite Wp Cron Errors:
    RewriteCond %{QUERY_STRING} (^|&)doing_wp_cron=[0-9]+.[0-9]+(&|$) [NC]
    RewriteRule ^ %{REQUEST_URI}? [R=301,L]
    into your .htaccess file.
  4. Use one of the old duplicate ?wp_doing_cron urls to check it is now redirecting correctly.
  5. Repeat for all WordPress installs that might be affected on that host.
  6. Feel smug you can now solve WP-Cron Job Errors Caused By WordPress Hosting