Move and Redirect Posts on Blogger to an External Domain

redirect blogger
 By now I think you're aware of the fact that Blogger doesn't support redirection to external sites, even if said sites are running on Blogger. Instead, Blogger only supports redirection within the domain, be it a hosted domain (BlogSpot) or a custom domain. The redirects can be set by going to Settings > Search Preferences > Custom Redirects and can be marked as either permanent (301-redirect) or as temporary otherwise known as a soft-redirect (302-redirect).

Blogger doesn't support redirection to external websites for good reasons. The major concern prompting that decision is that such redirection is merely going to be abused by spammers and attackers despite it being a useful resource for webmasters with legitimate needs for it.

That's the situation I got myself in two months ago after I started another blog. A couple of posts I had published on this blog looked rather misplaced with rest of the content I have here and so I thought it would be a good idea to move them to that blog where they would be more relevant to the audience I was targeting.

Now here's the problem: a couple of these posts were doing well traffic wise since they were ranking rather high in Google results. As per Google recommendations, a 301-redirection is the most ideal solution for these posts as it would retain the ranking not to mention take care of any internal or external links emanating from other websites.

But that was clearly unfeasible and isntead the only options that I had to consider as an alternative were as follows:
  • Delete the posts so that they return a 404 then use the Remove URL tool in  Search Console to remove them from Google Search Results. After a while I would then republish the content on my new blog and start the arduous task of getting them to rank as before.
  • Redirect the posts to a page containing links to their new location then hope against all odds that the readers are going to follow the links.
  • Use the meta-refresh tag to redirect.

Enter the Meta-Refresh Tag

Of the above, the meta-refresh redirect presents the closest thing to a 301-redirect. However it does come with some downsides:
  • It comes at the cost of user experience: looks spammy as the visitor will for a couple seconds view the site before being redirected.
  • Some old browsers may not work well with meta-refresh resulting with users not being able to use the back button or creating infinite loops.
  • Search engines may flag your site as spammy if you use a lot of meta-refreshes.
  • Guides online on the subject of implementing the meta-refresh on Blogger indicate that it has to be implemented in the template itself. This may not be practical when redirecting a lot of posts (will inflate the size of template). A site-wide redirection seems better suited for its use.
  • The redirecting page (original URL) has to be kept alive for the purpose of redirection. If the original URL was already indexed and ranking in the search results, then it's likely that both the destination and original URL may show up in the search results. This brings us to the next issue:
  • There is the risk of being flagged for duplicate content as the content in the two domains is similar. Google may fill in the blanks and assume you're trying to manipulate their ranking resulting in either the site dropping in rank or even being removed entirely from their index.

The bright side in all these is that fortunately Google does process the meta-refresh tag as a redirect. They however don't recommend it because of its poor user experience and processing time. Nevertheless it does work.

Resolving Issues with the Meta-Refresh Tag

The duplicate content issue presents the biggest challenge here and Google cautions against it. To avoid it one may use the no-index tag on the original URL (tells Googlebots not to index that page) but that would inadvertently make the redirection useless for the purpose of retaining the ranking.

Other than using the no-index tag Google suggests using Canonicalization if the duplicate content is unavoidable or is there for legitimate reasons. Canonicalization tells Google which of the pages that have duplicate content is the authoritative version, i.e. the canonical version. If not told explicitly, Googlebot decides and indexes the URL it deems to be the most ideal according to a number of factors such as the type of traffic and makes that URL the canonical version (e.g. mobile and desktop versions).

That's why in the case of Blogger you may sometimes notice that Google has chosen to index either the mobile (www.example/2018/07/post-url.html?=1) or desktop (www.example/2018/07/post-url.html?=0) URL of a post instead of the one published or in your sitemap (www.example/2018/07/post-url.html).

If a canonical URL is explicitly specified (e.g using the rel=canonical tag), Google may index it and exclude the other duplicate URLs from the results. We can therefore use canonicalization to indicate to Google that the new URL to which we're redirecting to using the meta-refresh is the canonical one. Eventually the original URL will be dropped from the index and the new URL will take its rank.

  • For canonicalization to work, ensure that both URLs still have similar or almost similar content. If you must edit the content in the new URL, let it be minimal but let it retain the original subject matter.

Meta-Refresh + Rel Canonical Tags

Our redirect will therefore have to use these two tags in tandem. The rel=canonical tag will specify that the URL being redirected by the meta-refresh tag is the canonical one.

To do that easily, we'll use Insider Zone's cross-browser client side URL redirection generator tool. I came across this tool after I had long given up on this whole redirection plan courtesy of this answer that that I stumbled on StackOverflow. I suggest you check the answers in that question for a more varied take on the meta-refresh redirect.

This tool generates a redirection code with the above tags and also has safeguards to ensure the code works properly on old browsers (retain uses of back button) and on browsers that don't support or have JavaScript disabled. The code ideally should be put immediately after the head tag, that is on the template, but that would defeat the purpose since we need to redirect individual posts and not the homepage. Fortunately as I found out, the code does work with posts too.


A. Redirection

1. Go to the insider zone site here, enter the URL you're redirecting to in the external domain and hit the generate code button.
generate code
Generate Redirect Code

2. Copy the code as it is then open the Blogger post you're redirecting (the original post) in HTML view. The code will look as follows:
<!-- Place this snippet right after opening the head tag to make it work properly -->

<!-- This code is licensed under GNU GPL v3 -->
<!-- You are allowed to freely copy, distribute and use this code, but removing author credit is strictly prohibited -->
<!-- Generated by -->

<link rel="canonical" href=""/>
    <meta http-equiv="refresh" content="0;URL=">
<!--[if lt IE 9]><script type="text/javascript">var IE_fix=true;</script><![endif]-->
<script type="text/javascript">
    var url = "";
    if(typeof IE_fix != "undefined") // IE8 and lower fix to pass the http referer
        document.write("redirecting..."); // Don't remove this line or appendChild() will fail because it is called before document.onload to make the redirect as fast as possible. Nobody will see this text, it is only a tech fix.
        var referLink = document.createElement("a");
        referLink.href = url;
    else { window.location.replace(url); } // All other browsers
<!-- Credit goes to -->
3. Paste that code at the very top of the post and save the post.

B. Indexing

Doing the above is enough, but it may take Google a while before it crawls your site to notice the redirection and the new canonical URL. Also since this is Blogger, Google may have indexed more than one version of your URL (the mobile and desktop variants) and therefore it has to be signalled that they too redirect to the new canonical URL (I ignored this initially only to later wonder why the redirected post was still showing in the results).

To fast-track this process, we can request Google to reindex the page using the Fetch as Google in Search Console. This step therefore assumes:

  • You use Search Console and have added properties for both sites. The site with original URL however is what we require, but it's good to have all you sites there if you want to monitor their search appearance.
  • That the original URL is already indexed by Google.

1. Start by finding out which URL variant of your post Google has selected as the canonical one. It's usually the published one but in some cases Google may have also indexed the mobile (?m=1) or desktop (?m=0) versions. You can do this by searching some key words that bring up that post in the results or you can do a site only search in Google search as follows:

site: "post keywords"

2. In search console open the redirecting site's property then go to Crawl > Fetch as Google
fetch as google
Fetch as Google

3. Enter the URL of the page you're redirecting and click the FETCH AND RENDER button.
fetch and render
Fetch and Render

4. The fetch and request should return the status as Redirected.
page redirected
Page Redirected

If you use FETCH, the redirection won't be detected and will return a Complete status instead of Redirected. This is because our redirect is not a HTTP one (301/302). For Googlebot to see the meta-refresh redirect it has to parse the page and that's why we're using the FETCH AND RENDER option instead.
fetch only
Fetch Only Status

4. To confirm that the page has redirected to the intended destination, click to open the result. You should find the external URL that you used to generate the redirect code as the destination.
redirect result
Redirect Result

5. Click the Request indexing button to finish.

6. Now repeat the above for the mobile or desktop URL variants if you established that one of them has been indexed too.

C. Monitoring

Now all that's left is to wait. It will take Google from a few days to a week to update their index as it was in my case. Meanwhile, you can monitor the progress by inspecting the original URL using the new search console as follows:

1. Go to the new Beta Search Console and select the property with the redirected URL.

2. In the search box at the top, enter the redirected URL and press the Enter key. If Google has not yet updated the index, you'll get the status that the URL is still in Google. In that case, just wait a few more days.
index status
Index Status of Original URL

If the index has been updated you'll get the status that the URL is no longer in Google, exactly what we want.
index status updated
Index Updated

Just below this yuo'll find the Index Coverage summary. You'll notice the reason given for this status is that the Submitted URL (our original URL still in the sitemap) is NOT selected as the Canonical URL.
index summary
Index Coverage Summary
Our destination URL which we declared as the canonical version will instead be selected as the canonical one by Google.
canonical url
Destination URL now Canonical

D. Ranking

The URL won’t get the ranking of the old URL immediately. I also noticed the old URL still showed up in search results along with the new URL for a couple days before disappearing completely. During this "transition period" the old URL ranked higher than the new URL. It's not until the old URL disappeared completely that the new URL started ranking higher. The whole process took about two weeks.

If you notice the old URL is still showing up in the search results long after search console has indicated it has selected your URL as the canonical one, then it's likely you had multiple URLs in the index. Open that result and verify the URL. It could be the mobile or desktop variant in which case you'll have to repeat the reindexing for it. I learnt this the hard way.

E. Schedule

Remember one of the downsides of using the meta-refresh is that the site comes across as spammy. This is inevitable but I suppose its impact can be reduced if things are done in a systematic way. My approach up until now has been to take the whole process slow. Instead of doing the redirects in one go for all the posts I intend to move, I’ve been redirecting on average one post per week. Quite low I know, but that’s only because I’m redirecting in total about 30 pages.

This way at any given period I probably have only two redirects "working" since by this time the old URLs from previous redirects will have completely been dropped from the index and no one is getting to them save for those coming from external or internal links, which brings me to.

F. Linking

Make sure to consolidate any internal or external links you had pointing to the old URL to now point to the new URL. This is very key for two reasons:
  • it will help Google discover the new URL relatively quicker
  • it passes the link juice helping the new URL rank better

To figure out the internal and external links to a given URL, go to Search Console > Search Traffic then choose Internal Links or Links to Your Site for external links. The latter has no URL search function but you can use the Ctrl+F option in your browser to manually search the URL.
Consolidate Links

Updating the internal links in your blog should be easy, it's the external links originating form external sites that pose the biggest challenge here. I suppose the only thing you can do here is contact the site owners and tell them to update to the new links.

Cheers and Good luck!

Leave your comment below. Spammers are advised to file a missing comment report in not less than a weeks time.