How To Redirect a Blogspot Blog To Another Site

If you’ve been using blogger as your website, you might have decided it’s time to change your CMS. And that might also mean switching from the standard address to a custom domain. But how do you ensure that the search authority and visitors from your current site are transferred to your new one as effectively as possible? Well, here’s how to redirect a Blogspot blog to another site.

How To Redirect a Blogspot Blog To Another Site

Before we get into the exact instructions, it’s worth explaining a little about Blogger and how redirects work between different urls. Or if you want to remove pages from your current website, including after a redesign. One of our main services is assisting with this process for business clients ranging from small websites to massive enterprise solutions. We’ve migrated a large number of websites over the years, and ensured traffic and search rankings are kept as high as possible during the transition.

If you’re in a hurry, already know about website redirects, or find it boring, you can skip the next bit!


Blogger and Redirects:

Blogger was originally launched in 1999 as a blog-publishing service by Pyra Labs. The company was founded by Meg Hourihan and Evan Williams, who also went on to co-found Twitter and Medium. Blogger itself was acquired by Google back in 2003. And although new features have regularly been added, the service itself hasn’t radically changed for a long time now. So although it’s still a very popular way to start blogging and publishing content online, many people find they want to switch to an alternative like WordPress after a while.

By default, your Blogger site will have an address ending in If you’ve bought a custom domain for your site, e.g., then everything will work on your new site as long as the urls of your posts stay the same. But your old site will revert back to and display your old duplicate content unless you either delete or redirect it.

However, when urls are being changed or posts are being removed, that’s when redirects are useful. For any permanent changes or deletions, you would want to use what is called a ‘301 Redirect’. This indicates to search engines that the content has been permently moved to a new address. And redirects your users to the new page automatically. So unless you want to completely ditch your old content and let users see a 404 error page, you’d typically put a 301 Redirect into your .htaccess file for PHP websites and web.config for IIS sites.

But editing .htaccess and web.config require server access. And Blogger doesn’t allow that.

Meanwhile adding redirection plugins and services to your new website and domain won’t have any effect on your old address.

But there is a solution. It uses what’s called a Meta Refresh to perform a client-side redirect (rather than the server-side options described above).

How To Redirect a Blogspot Blog To Another Site – Detailed Steps:

Rather than putting an instruction directly onto your server, we’re going to add a Meta Refresh tag to the header of your old blogspot site. This will refresh the page content, and in the process, send visitors to your new website. It does have some downsides, which we’ll outline later. But the advantages will generally outweight the negatives.

And don’t be scared of the code in the steps below. It really is very simple.

Step 1:

Go to Blogger and log into your website. When you’re viewing the main dashboard, click on ‘Theme’ in the left hand menu. You’ll see a preview of your theme with the option to ‘Edit HTML’ under the ‘Live on Blog’ window.

Click Edit HTML and you’ll see the code for your site:

How To Redirect a Blogspot Blog Theme Editing

This can look intimidating, but adding the Meta Refresh code is very simple. You need to locate the <head> tag in the code, and then add the following code straight after it:

<meta http-equiv=”refresh” content=”0;URL=’'” />

Obviously you’ll replace with your new url!

I’ve highlighted the relevant code in the example below with a couple of red stars.

How To Redirect a Blogspot Blog Theme With Redirect Code

Now click on Save Theme, and you’re done!

Visit your address and check the redirect works.


Meta Fresh: Options and Downsides?

There’s not a huge amount of options available when you have a client-side redirect with a Meta Refresh Tag. The main one is how long it takes for your redirect to work. If you’ve put a message on your site explaining what’s happening, you may want to give your visitors time to see it before they’re sent to your new website.

Luckily, that’s simple. If you take another look at the code:

<meta http-equiv=”refresh” content=”0;URL=’'” />

You can see there’s a 0 value after content. Simple adjust that for the number of seconds you want to allow visitors to stay on your old site and see whatever is left there to explain the redirect.

See, easy!

Now for the Meta Refresh downsides.

Unfortunately, being an easy way to redirect visitors without accessing a server means Meta Refresh Tags have often been used by spammers and other people who might be less than honest.

So many SEO specialists will recommend that your refresh time is set to at least 5 seconds to avoid being seen as dubious and incurring a potential problem.

Also due to the spam problem, search engines will generally not pass all of the SEO value of the original site. You’ll still get some benefit, and obviously it’s better than nothing. But using a server-side redirect should generally be seamless for traffic and SEO authority.


The Best Solution for Redirecting Blogspot Sites?

Although using a Meta Refresh Tag won’t pass all of the SEO equity of your original blogspot site, it’s still going to pass more than if you didn’t put in any redirect at all. And as long as you keep an eye on your site to ensure you’re not accidentally seen as trying to trick users, then it has the major benefit of ensuring your existing traffic is carried across to your new website.


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