Cron is a standard utility in Unix and Linux systems, it is used to schedule commands for automatic execution at specific intervals. For instance, you might have a script that produces web stats and you want it to run once a day at a specific hour. Or imagine you need to run a PHP script on weekdays, every 2 hours.
You can’t do these tasks manually and here is where Cron becomes useful. These commands involving Cron are referred to as ” cron jobs.“
WP-Cron vs “real” Cron jobs
WordPress has a feature called WP-Cron. WP Cron is a built-in function for automation which allows to schedule automated tasks, like publishing posts, maintenance tasks, update checks and by many plugins like WP Rocket which need to automate features.
WP-Cron is not actually a real cron job, you can think it is more like a “fake cron job”. These tasks are triggered when someone visits your site: during PHP page loads, WP Cron checks the database to see if there are any scheduled tasks to execute.
The way WP Cron works has some drawbacks:
When you are using a caching plugin like WP Rocket, no PHP is executed in the frontend, so if there is no activity on WP Admin for some time, WP Cron processes would stop being triggered.
It is also a potential issue on high traffic sites, since every page request might spawn a process that uses server resources
This file can be used as the target of a DOS attack
Tip: To check if WP-Cron can run on your WordPress site: WP-Cron Status Checker After activation, visit your Dashboard and look for the WP-Cron Status Checker widget.
Setting up a real Cron Job
Due to WP Cron drawbacks, is always recommended to set up a real Cron job on your server instead of relying on WP Cron.
If you want to create a real Cron job, first you need to disable WP Cron, so is not executed every time someone loads one of your pages. To disable it, open the wp-config.php file in your main WordPress folder and add the following line before the “/* That’s all, stop editing! Happy blogging. */” line:
define('DISABLE_WP_CRON', true);
Add a Cron job entry through your web hosting control panel. You can set the job to run every 5 or 10 minutes. Please remember to replace yourdomain.com with your actual domain:
Each server has different ways of adding a Cron job, so if you are not sure how to do it you can ask your hosting provider to help you. You can check this short video if you are using cPanel: https://recordit.co/A4Jj1Kg7x9
Common issues related to Cron
If for any reason, scheduled processes are not properly working, you may notice issues with some of the following WP Rocket features:
Cache Preloading
Scheduled Cache Clearing
Database optimization
Critical Path CSS generation
Google, Facebook and Cloudflare add-ons
Did you know? You can extend WP Rocket functionality using Cron to launch custom functions. For example:
WordPress includes a job scheduling system called wp-cron. The default method for scheduled jobs is for wp-cron to be checked on each page load, which has the potential to slow down your website while background jobs are run. Check out these other options that help maintain the user experience on your WordPress site while still running important tasks in the background.
Using ALTERNATE_WP_CRON
The ALTERNATE_WP_CRON method uses a quick, nearly invisible redirect to direct an incoming user to a new request while the old one continues running, executing background jobs. This is an easy, effective method and it works really well if you don’t have access to crontab on your hosting site. Even though this method adds some elements to the page URL, it’s only triggered when background jobs need to be run. To enable it, follow these instructions:
Open your site’s wp-config.php in your text editor.
After the lines containing your database credentials, add the following lines:
1
2
/** Use alternate WP_CRON method with redirects. */define('ALTERNATE_WP_CRON',true);
/** Use alternate WP_CRON method with redirects. */
define(‘ALTERNATE_WP_CRON’, true);
If you have access to a shell on your web host and can run cron jobs, this method might be the best. It ensures that background jobs will get run, even when your website isn’t getting any visitors. It also runs background jobs without requiring a redirect or any additional delays that will be noticed by users. Here’s how you do it.
Add a Crontab Entry
Run crontab -e
Add the following lines to the end of your crontab file:
Make sure you replace “www.example.com” with your website’s hostname. The */15 specifies that wp-cron.php will be called every 15 minutes. If you would like to change this, replace the 15 with a different number.
Disable Built-in wp-cron
The next step is to disable the built-in call to wp-cron in WordPress.
Open your site’s wp-config.php in your text editor.
After the lines containing your database credentials, add the following lines:
1
2
/** Disable built-in cron in favor of system crontab */define('DISABLE_WP_CRON',true);
/** Disable built-in cron in favor of system crontab */
define(‘DISABLE_WP_CRON’, true);
How To Solve WP-Cron Job Errors Caused By WordPress Hosting
By
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 http://www.thewayoftheweb.net/how-to-solve-wp-cron-job-errors-caused-by-wordpress-hosting?doing_wp_cron=128337.128371298731298371923
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.
Disable the wp-cron.php from firing when someone visits your website.
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.
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 WordPress.org 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 WordPress.org 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:
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 https://hosting.heartinternet.uk 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
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 https://whitemousedigital.com for his assistance with this…
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:
Turn off any existing wp-cron.php tasks by adding define(‘DISABLE_WP_CRON’, ‘true’); to your wp.config.php.
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.
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.
Use one of the old duplicate ?wp_doing_cron urls to check it is now redirecting correctly.
Repeat for all WordPress installs that might be affected on that host.
Feel smug you can now solve WP-Cron Job Errors Caused By WordPress Hosting
