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 search 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 explains 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?m=1) or desktop (
www.example/2018/07/post-url.html?m=0) URL of a post instead of the one published/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.
NOTE:
- For canonicalization to work, both URLs should retain 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 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.
Redirect Posts to an External Domain
Step 1: 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 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 http://insider.zone/tools/client-side-url-redirect-generator/ -->
<!-- REDIRECTING STARTS -->
<link rel="canonical" href="https://www.kenyanfix.com/2018/07/upgrade-airtel-kenya-sim-card-to-4g.html"/>
<noscript>
<meta http-equiv="refresh" content="0;URL=https://www.kenyanfix.com/2018/07/upgrade-airtel-kenya-sim-card-to-4g.html">
</noscript>
<!--[if lt IE 9]><script type="text/javascript">var IE_fix=true;</script><![endif]-->
<script type="text/javascript">
var url = "https://www.kenyanfix.com/2018/07/upgrade-airtel-kenya-sim-card-to-4g.html";
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;
document.body.appendChild(referLink);
referLink.click();
}
else { window.location.replace(url); } // All other browsers
</script>
<!-- Credit goes to http://insider.zone/ -->
<!-- REDIRECTING ENDS -->
3. Paste that code at the very top of the post and save the post.
Step 2: 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. Posts receiving good traffic do seem though to get updated pretty quick to the new 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 may have to be signalled that they too redirect to the new canonical URL, though with time it will notice on its own and update them accordingly. (I had 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 presence.
- 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. To do this, use either of these methods:
- Go to the new search console and inspect
the post URL by searching for it in the bar at the top of the page.
Google will retun it's index status and some other data. Repeat this for
the mobile and desktop URL variants and note if they're indexed as
well.
- Go to Google and search some keywords that will bring up the post then observe the URL. You can also do a site only search as follows: site: www.yoursiteurl.com "post keywords"
2. In search console open the
redirecting site's property then go to
Crawl > 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 |
4. The fetch and render should return the status as
Redirected.
 |
| Page Redirected |
NOTE:
- 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 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. Now just click the
Request indexing button.
 |
| Redirect Result |
5. Doing that will launch a window for you to select the method of re-crawling. You get two options here: Googlebot can either recrawl the submitted
URL only or along with the
direct links in that post's URL. You'll have to complete the
Recaptcha challenge for every request before you can do the submission.
 |
| Submit URL for Indexing |
For the purpose of redirecting, the crawling the URL only option will suffice. However you may consider using the second option if for instance the post has
updated internal links for posts that you've since redirected.
NOTE:
- Google mentions that there's quota on how many individual URLs you can submit for indexing per day though they doesn't explicitly mention how many. However, on the Fetch as Google help page the daily quota for the number of fetches that can be done is listed as 10.
- I take it that means also the quota for individual URL submissions is also ten, though I can't confirm this and whether this also applies to the crawl direct links option. What I've noticed though is that the Recaptcha challenge appears on the Fetch page when I reached reach the 9th request. I presume that's a "warning".
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 (posts with good traffic seem to update much quicker). Meanwhile, you can monitor the progress by inspecting the original URL using the new search console as follows:
1. Go to the
New 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 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 Updated |
Just below this you'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 Coverage Summary |
Our destination URL which we declared as the canonical version will instead be selected as the canonical one by Google.
 |
| Destination URL now Canonical |
D. Ranking
The URL won’t get the ranking of the old URL, at least not immediately though again I can't confirm on this behaviour. I also noticed the old URL in some cases 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 a 1-2 weeks depending on the post in question.
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 re-indexing 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.
(
Update: ramped it up to about three posts per week then 3 per day; didn't seem to make a huge difference)
This way at any given period I probably had only two redirects
"working" since by this time the old URLs from previous redirects had completely been dropped from the index and thus no one was 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!
