Social Sharing Popularity, And URL Changes

As both custom domain publishing, and social sharing networks, become normal with many blogs, we see anguish when blog owners change the URLs of their blogs, without planning for the effects of the change.

What happened to my Likes?

This blog owner - and many others - do not realise that FaceBook counts Likes, based on the URL, not the blog.

FaceBook Likes, and Google+ +1s, are counted by URL - and are not controlled by DNS redirection, or simple name changes. If you rename your blog, you get a new URL with a new popularity counter, in FaceBook and Google+.

Some social sharing services allow for URL changes.

BlogLovin lets you transfer Followers from one URL to another.

BlogLovin, for instance, provides for transfer of Followers, to a new URL - as long as the blog owner owns both the old and new URL.

First, make sure that you've claimed both of your blogs.

Once both blogs are claimed, navigate to "My blog" and select the "Edit Blog Info" option next to your original blog.

From the "Move Followers" dropdown menu, select the blog you'd like to move your followers to and click "Move". This will remove your original blog and move your followers to your new blog of choice.

Start from any BlogLovin page.

Select "Blog analytics" from the drop down menu.

Click "Edit blog info".

Select a blog, from the drop down blog menu, in the "Edit blog info" wizard - and click on "Move Followers".



Whether you have a blog with a new URL, or a blog with multiple feeds and groups of Followers, BlogLovin lets you consolidate / move Followers so you can address your Followers, conveniently.

Blogger Followers stay with the blog, automatically.

With a Blogger blog, and Blogger Following / Google Friend Connect, your Followers Follow the blog - not the URL. You can rename the blog, and change the URL - but as long as you don't change the BlogID, your Followers remain with your blog.

FaceBook and Google+ give you a new counter, for each URL.

Neither FaceBook or Google+ provide a similar option. To both FaceBook and Google+, if you change the URL of the blog, you have a new blog. Google+ Followers - unlike Blogger Followers - Follow the URL.

With custom domain publishing, and the BlogSpot to domain redirect, the attention of your Followers may end up on your redirected blog - but the +1 counter that was based on the BlogSpot URL stays with the BlogSpot URL. With the blog published to the domain, your blog gets a counter for the domain URL - and starts over.

With a BlogSpot to BlogSpot URL change, and a domain to BlogSpot URL change, everything starts over.

FaceBook Likes are counted, within FaceBook - and Google+ +1s are counted, within Google+. Both are based on the URL of the blog which accrues the Likes and +1s. If you change the URL of the blog, you get a new counter.

A URL change is effective for different changes, to a Blogger blog.

• BlogSpot to BlogSpot name change.
• BlogSpot to custom domain republishing.
• Custom domain to custom domain change.
• Custom domain to BlogSpot republishing.

All of these are URL changes - and are treated as a different blog, for most social sharing services.

BlogLovin supports URL changes. Neither FaceBook, Google+, or LinkedIn provides this ability. You change the URL, you start over with +1 / Like count, and sharing reputation.

---

With most social sharing services, if you change the URL of a #Blogger blog, you start over accumulating +1s, Followers, and Likes. BlogLovin appears to be alone, in letting you transfer Followers from one blog to another - if you create a new blog, or change the URL of an existing blog.

https://productforums.google.com/forum/#!category-topic/blogger/ZiozKZOS07Q

https://productforums.google.com/forum/#!category-topic/blogger/gkmBV6s03Ck

Read More

Changing Your Custom Domain - The Next Chapter

We see some blog owners deciding to change their custom domain URLs - and discovering an unexpected limitation, in re indexing the blog, under the new URL

I received email from Google, advising that my previous domain is pulling up a number of 404 errors. I've noticed that these are for individual blog posts.

When you change one custom domain to another, you may not see the domain re indexed, transparently.

Changing a Blogger blog, from one custom domain to another, is a reasonably simple project - if you're able to plan the change.

A domain change should involve simply re indexing the blog.

A simple custom domain name change involves republishing the blog, under a new domain. Retaining readers, and search engine access, requires slightly more work.

Renaming a custom domain - if it involves a BlogSpot rename - becomes significantly more complicated.

Renaming a custom domain - and having the individual post URLs in the old domain working, after the change - will require slightly more effort, than any of the above requirements.

With GoDaddy, using specific settings, you may be able to forward post URLs.

In one forum topic, a domain owner was able to forward a domain, using instructions provided by GoDaddy - so individual post URLs redirect properly.

In the GoDaddy domain settings for the old (original) custom domain, activate Domain Forwarding.

1. Set the "Forward to:" address to the new custom domain.
2. Choose the Redirect Type as "301 Permanent".
3. Choose the Forward Settings as "Forward only".

This may not be the effect seen, by all blog owners. Not all registrars will provide this ability.

This is the GoDaddy DNS wizard, as of 2016.

If your domain was not registered by GoDaddy, you will have a different wizard - and most likely, ""Forward only" will be a different option. Maybe, "Forward without masking" will be a useful description.



Blogger does not support redirection, from blog URL to blog URL.

Blogger does not support redirection, between BlogSpot or custom domain URLs - as transparent redirection would simply encourage spam activity. Any redirection, from the old custom domain, has to be provided by the domain registrar.

Most registrars provide simple DNS forwarding, from one domain to another - if you are able to pay for both domains, simultaneously. Generally, most registrars will setup forwarding, from the old domain to the new published blog URL.

Not all blog owners may get the redirection, for their domain, correct.

With a domain forwarded to the published URL - using most registrar provided instructions - readers who click on the URL to a specific post, using the old domain URL, will find themselves unexpectedly viewing the blog home page, under the new domain. This will cause some confusion.

Search engine bots won't find a specific blog post, under the new domain.

A search engine bot, indexing a specific post, using the old domain URL, will be redirected to the blog home page, under the new domain URL. This will not enhance indexing of the blog.

Some search engine bots may report this as a "404 Not Found" - and blog reputation will suffer.

Here's an example of the problem.

The specific post URL ("www.chloellio.co.uk/2016/05/ fashion-river-island-plus.html") redirects to the main page ("www.chloeincurve.com").



For most obvious benefit, "www.chloellio.co.uk/2016/05/fashion-river-island-plus.html" should redirect to "www.chloeincurve.com/2016/05/fashion-river-island-plus.html" - not to the blog main page "www.chloeincurve.com".

Let's look at an HTTP trace. This shows an individual post in the blog, with forwarding provided by GoDaddy.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://www.chloellio.co.uk/2016/05/fashion-river-island-plus.html&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Sending request:

GET /2016/05/fashion-river-island-plus.html HTTP/1.1
Host: www.chloellio.co.uk
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 79.170.40.4
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·302·Found
Date:·Sun,·15·May·2016·17:17:57·GMT
Server:·Apache/2.2.24·(Red·Hat)
Location:·http://chloellio.co.uk/2016/05/fashion-river-island-plus.html

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://chloellio.co.uk/2016/05/fashion-river-island-plus.html&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=TXT

Sending request:

GET /2016/05/fashion-river-island-plus.html HTTP/1.1
Host: chloellio.co.uk
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 79.170.40.4
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·302·Found
Date:·Sun,·15·May·2016·17:17:58·GMT
Server:·Apache/2.2.24·(Red·Hat)
Location:·http://www.ChloeInCurve.com

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://www.ChloeInCurve.com&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=TXT

Sending request:

GET / HTTP/1.1
Host: www.ChloeInCurve.com
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 74.125.28.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·200·OK(CR)

<meta·content='blogger'·name='generator'/>
<link·href='http://www.chloeincurve.com/favicon.ico'·rel='icon'·type='image/x-icon'/>
<link·href='http://www.chloeincurve.com/'·rel='canonical'/>
<link·rel="alternate"·type="application/atom+xml"·title="ChloeInCurve·-·Atom"·href="http://www.chloeincurve.com/feeds/posts/default"·/>
<link·rel="alternate"·type="application/rss+xml"·title="ChloeInCurve·-·RSS"·href="http://www.chloeincurve.com/feeds/posts/default?alt=rss"·/>
<link·rel="service.post"·type="application/atom+xml"·title="ChloeInCurve·-·Atom"·href="https://www.blogger.com/feeds/5573572064729110417/posts/default"·/>
<link·rel="me"·href="https://www.blogger.com/profile/03895481660022671513"·/>
<link·rel="openid.server"·href="https://www.blogger.com/openid-server.g"·/>
<link·rel="openid.delegate"·href="http://www.chloeincurve.com/"·/>

Even if the domain, redirected to the new domain home page, does not generate a "404", blog reputation will not benefit. An individual post, will not be indexed immediately, when hidden behind the home page.

Not all registrars will help you change domain URLs - and retain post URLs.

If you are going to change custom domain names - and transparently redirect readers and search engines, you will need the extra effort, as described above.

Alternately, simply forward the domain, to the published Blogger URL (generally, the "www" domain host) - then concentrate on getting the blog re indexed, under the new URL. Once the blog is completely indexed under the new domain URL, people won't bookmark the old domain - and the new domain URL will be the reference, for the blog. That's what you want, at the end of the day.

Your readers will see the home page of the blog, when clicking on individual posts, indexed under the old domain URL. Then add a Featured Post, mentioning the domain change - and maybe setup one or both blog searches, for reader convenience.

---

It's possible to redirect a #Blogger blog, as published under a custom domain, to a new domain. It's not always possible to transparently redirect an individual post URL, to the new domain, however.

If you change your custom domain, you may have to expect some problems from readers and search engines.

https://productforums.google.com/d/topic/blogger/ZiozKZOS07Q/discussion

https://productforums.google.com/d/topic/blogger/9rTL7U2ZMvU/discussion

https://productforums.google.com/d/topic/blogger/Yd5qUg77wUw/discussion

Read More

Blogger Magic - Supporting A BlogSpot URL Change

Blog owners are always changing the URLs of their blogs - then asking why Blogger does not provide automatic redirection, to the new URL.

We see the occasional query, in Blogger Help Forum: Learn More About Blogger.

How do I redirect my readers, to my new URL?

And this is a need that will likely go unfulfilled.

If Blogger provided automated redirection, spammers would abuse it, as part of a spam publishing strategy.

Blogger wants to keep the Blogger infrastructure as free from spam, as possible.

Changing the URL is simple enough.

Just use the Publishing wizard, in the Settings - Basic page, and Edit the "Blog Address". Subject to availability, your blog will have a new URL - as you watch.


The change is not difficult. Just Edit "Blog Address".


But with a new URL, unplanned, you'll lose traffic.

Blogger does not support automated blog to blog redirection.

Trying to keep the Blogger ecosystem clean from spam, Blogger actively discourages automated redirection. Neither JavaScript or meta refresh redirection is recommended.

You can use passive redirection, though - and give your readers the choice, to read the blog using the new URL.

• Setup a blog cluster.
• Setup a stub blog, at the old URL.

Setup a blog cluster.

Publish a blog at the old URL - and pair the old and new blogs, actively. There are a number of possible techniques to use, to combine two blogs as equals.

You will need informative, interesting, and unique content, for both blogs, to get the most from this approach.

Setup a stub blog, at the old URL.

Publish a blog at the old URL - and add a single post, advising your readers about the change - with a link, taking them to the new blog. You can use a custom 404 display, to collect all existing links to posts in the blog, which will take your readers to the single post.

A Featured Post is perfect, as the single post in the stub blog.

You can redirect the blog posts feed, even though you can't redirect the posts themselves. Just redirect the old blog feed, to the new blog posts feed URL.

Combine the two approaches, if you like.

There's no need to consider the two approaches as mutually exclusive. You can use techniques from each, if you like. Simply pick an approach that suits your readers.

Just don't look for automated redirection. That's not likely to happen.

---

Some #Blogger blog owners decide to change the URL of their blog - then ask how to setup automated redirection, from the old URL to the new. That is, however not likely to be an option provided, or even allowed, by Blogger.

Read More

CloudFlare, Custom Domain Publishing, And HTTPS

A few blog owners, who publish blogs published to custom domains, are becoming impatient, waiting for Blogger Engineering to finish the Blogger upgrade to support HTTPS / SSL.

If I get a domain through Google Domains, will I be able to get HTTPS?

Unfortunately, no. HTTPS / SSL is simply not available, to blogs published to custom domains.

HTTPS is not available, for non BlogSpot published blogs.

Whether registered by eNom, GoDaddy, or Google Domains, it simply is not possible to publish a non BlogSpot URL as a supported custom domain, and make HTTPS / SSL available. CloudFlare, a supposed alternative, does not produce a supported custom domain.

A proxied CloudFlare domain looks like malicious redirection.

In some cases, a CloudFlare DNS "solution" tried by some blog owners, will look like dangerous / malicious redirection. Some blogs will show up as "Deceptive sites", aka "phishing".

Some blogs using CloudFlare, for custom domain publishing, will be classified as "Deceptive" sites.



Others will produce alarming warnings about malware.

"This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware."

Click on "Details".



Look at the warning.

Phishing sites pretend to be other websites to trick you.

And there is what you get, with a redirecting proxy service, like CloudFlare.

kireisubs.id. 300 IN A 104.27.133.198
www.kireisubs.id. 300 IN A 104.27.133.198

or

topmovies21.biz. 300 IN A 104.28.0.106
www.topmovies21.biz. 300 IN A 104.28.0.106

This is the basis for malware / phishing classification.

This is most likely a false positive - most custom domain published blogs do not contain malware. Even so, it's not likely that the "Deceptive site" classification will be easily corrected, or the malware warning interstitial removed.

And this is one more blog owner, who must next be provided instruction to correct the DNS addresses.

Having corrected as instructed, DNS addresses are now asymmetrical, and righteous.

kireisubs.id. 86400 IN A 216.239.32.21
kireisubs.id. 86400 IN A 216.239.34.21
kireisubs.id. 86400 IN A 216.239.36.21
kireisubs.id. 86400 IN A 216.239.38.21
www.kireisubs.id. 86400 IN CNAME ghs.google.com.

With DNS corrected, Google shows "Not dangerous" - but the warning still displays.

"Not dangerous".

Note "CloudFlare" is still seen as the host.

You can report an error, to SafeBrowsing.



False classification now requires time consuming site review.

Use "Report Incorrect Phishing Warning", if you believe the site is safe.

Finally, get the site reviewed, from the Security Issues page in Security Console (Webmaster Tools) - Security Issues.

And while the blog remains offline, search reputation - and the owner - will suffer.

---

Some #Blogger blog owners want to provide blogs published to custom domains - and offer HTTPS connectivity. Since Blogger cannot provide custom domains with HTTPS right now, the blog owners are using CloudFlare, which provides an HTTPS proxy.

Unfortunately, a CloudFlare proxy looks like malicious redirection - and blogs using CloudFlare are being labeled as "Deceptive" sites.

https://productforums.google.com/forum/#!category-topic/blogger/ApuJ58a4-kg

https://productforums.google.com/forum/#!category-topic/blogger/-LoJCeX6DEA

https://productforums.google.com/forum/#!category-topic/blogger/DhAFOtJFoCw

Read More

Custom Domain Publishing, And Alias Blocking

Some blog owners setup their new custom domain, check all settings carefully (and correctly) - then find that it does not work.

We see the confusion, in Blogger Help Forum: Get Help with an Issue.

The addresses were right - and all the DNS servers updated correctly. But when I open the website, it does not open. It continuously reloads for 5 minutes and after 5 minutes it shows an error.

It's frustrating, when everything is setup properly - but still no results.

It's also frustrating, when you forget about unsupported tweaks that you made, to the blog - then have to ask for help.

Whenever changing the URL, check for - and remove - any redirecting scripts.

Before you publish a blog to a new URL, you need to check the template, for any redirecting scripts, that you may have previously installed.

<script·type='text/javascript'>
var·blog·=·document.location.href.toLowerCase();
if·(!blog.match(/\.blogspot\.com/))·{
  blog·=·blog.replace(/\.blogspot\..*?\//,·".blogspot.com/ncr/");
  window.location.replace(blog);
  }
</script>

Scripts which redirect - or block redirecting, when the blog is published to BlogSpot - will not work for you, when you publish to a non BlogSpot URL.

You will need to connect URLs, when possible - without scripts interfering.

Any time you change the URL of the blog, you're going to need some ability to link from the old URL to the new URL. Before you change the URL - either BlogSpot to BlogSpot, or BlogSpot to custom domain - check the template, for redirecting scripts.

Any redirecting scripts, that might have helped you with the blog originally published, will be a problem, when you change the URL. Remove any scripts, before changing the URL.

Better yet, don't add redirecting scripts. If you got this far, without having the blog classified as a malware host, consider yourself lucky.

---

Some blog owners install mysterious scripts, to "protect" against unwanted Blogger features - and forget about their unwise tweaks. When they change the URL of the blog - and the blog, under the new URL reacts to the previously installed tweaks - they are clueless.

If you make unsupported tweaks to your blog, only you can correct problems that arise, later.

Read More

BlogLovin Has Problems With Some Blog Feeds

We see occasional reports, in Blogger Help Forum: Get Help with an Issue, from Blogger blog owners who want to share their blogs using BlogLovin.

Why can't I claim my blog?

BlogLovin is somewhat monolithic. They use the blog feed, and a BlogLovin URL with embedded token, to process / validate blog claims - and their diagnostics, when a claim is a problem, are not always effective.

Some blog feeds can be validated, yet not be found by BlogLovin. And other feeds won't validate.

Blog owners have reported several common problems, when trying to claim their blog with BlogLovin.

• Start with the published blog URL.
• Empty / very short feeds.
• Redirected feeds, generally involving FeedBurner.
• Feeds containing GeoRSS datapoints.
• Feeds with content formatted in Microsoft Office.
• Positioning the claim verification link / token.

Start with the published blog URL.

Even though BlogLovin uses the blog posts newsfeed for content source, when you claim your blog, you need to use the published URL. You do not specify the feed URL. BlogLovin finds the feed URL from the blog header - after you give it the published URL of the blog.

Feeds can be validated, using either the W3C Feed Validator, or the FeedValidator.org Feed Validator. You have to use the right W3C validator, though.

If the blog is published to a custom domain, the published URL - and the feed - will be most consistently accessible to BlogLovin when the domain is properly setup. Bogus DNS addressing, or poorly setup domains, will cause feed access issues - and BlogLovin won't process your claim.

Empty / very short feeds.

An empty or very short feed just does not contain enough material, for BlogLovin to reliably claim a blog.

It's best to let your blog mature slightly, before trying to use it with BlogLovin. Half a dozen good posts are better than just one or two, when claiming a blog.

Redirected feeds, generally involving FeedBurner.

A FeedBurner redirected feed looks completely different from a native Blogger feed. If you're going to use a Blogger blog in BlogLovin, it's best to use a non redirected version of the feed for your blog.

Feeds containing GeoRSS datapoints.

A feed from a blog that includes a GeoRSS datapoint will fail validation.

GeoRSS will disrupt BlogLovin, and cause problems with FeedBurner. If you want to use either service, you have to edit any post using GeoRSS, and remove the GeoLocation element.

Feeds with content formatted in Microsoft Office.

A Microsoft Office formatted blog will produce a validated feed - yet BlogLovin and FeedBurner will both have problems, when using the feed.

We've been dealing with Microsoft Office generated problems, in various Blogger features, for years. BlogLovin is one more service where Microsoft Office formatted posts just don't work.

Both the W3C and FeedValidator.org feed validators are generally used, to diagnose non claimable blogs.

But neither is 100% useful, when there's a problem. Some blogs with valid feeds still can't be claimed.





Use the right validator.

You do need to use the right W3C validator, when checking the feed for your blog. Some BlogLovin diagnostic instructions may mention the wrong validator.

W3C provides 2 validator services.

This is for HTML / XML Markup Validation:

http://validator.w3.org/

This is for Feed Validation:

https://validator.w3.org/feed/

If you use the Markup Validator, with a blog feed, you're going to see a lot of irrelevant errors. You have to use the Feed Validator.

Use a properly coded template.

Some blogs cannot be claimed, because BlogLovin cannot detect a feed. If your blog lacks the necessary header records in the template, your blog cannot be claimed.

This problem is not caused by BlogLovin. This is a problem caused by you, using a custom template that lacks the necessary template content.

BlogLovin does have a good Help contact page, though.



Positioning the claim verification link / token.

BlogLovin suggests publishing a new post, with the claim link / token at the top of the post - or alone. I found that the link, added to an HTML gadget, and positioned in the sidebar, works - and makes more sense than cluttering the blog posts newsfeed with a gratuitous post containing a claim link.

Proper positioning of the claim link - whether in a post or the sidebar - is also essential to the success of the claim process.

As last resort, contact BlogLovin Support for help.

If you just can't get your blog claimed, you can contact BlogLovin Support - or you can read the BlogLovin Help database.

---

Some #Blogger blog owners use BlogLovin as a social sharing platform. Unfortunately, not every blog owner can successfully claim their blog, in BlogLovin, immediately.

BlogLovin has several possible problems with Blogger blogs - and not all problems are well known.

Read More

Blogger Blogs Cannot Be Used As Gateways

We see evidence of confusion, from time to time, in Blogger Help Forum: How Do I?.

How do I move an established blog to WordPress (or any other platform), while retaining the history, reader interest, search engine reputation?

Some blog owners think blog readers are cattle (to be herded from blog to blog) - or monkeys (to be attracted by shiny things).

We've known for some time, that Blogger blogs cannot be used as gateways, with traffic automatically redirected from one blog to another - or from a blog to a non Google website. Use of traffic redirection scripts is a known cause of blogs classified as malware hosts.

If you wish to relocate a Blogger blog in another hosting service, you can always publish your Blogger blog, and a non Google blog / website, as dual hosts, in a non BlogSpot domain.

With your Blogger blog and non Blogger website published to the same domain, you can then combine the two, dynamically. Just remember to add unique content to each, periodically, to retain search engine reputation.

1. Publish your Blogger blog to a host in your custom domain.
2. Publish your WordPress (or any other platform) blog to a host in your custom domain.
3. Combine the two blogs.
4. Let your readers access either blog, as their choice.
5. Update both blogs, to retain search engine reputation, regularly.
6. When the WordPress (or any other platform) blog receives enough reputation and traffic, make the Blogger blog into a stub blog.

Just don't build a maze of blogs and web sites - and don't waste time or money artificially developing traffic. Blogger blog readers are attracted by interesting, unique, and useful content - and are retained by new content, added periodically.

And don't try adding clever code, to shuffle your readers from one blog to another. That could make your blog look like one member in a well planned spam blog farm - and leave you reporting

Help! Blogger just deleted my blog!!

.

Read More

Forwarding A Domain Requires Experience

I constantly advise Blogger blog owners to avoid forwarding, when setting up custom domain publishing.

In the rare cases where forwarding is actually required, not every blog owner reports success.

My blog now displays a non Google search page!

or worse

My blog now displays

404 Not Found

What did I do wrong??

Depending upon what setup work was done by the blog / domain owner, and what effort is required by the registrar, one may expect to see, quite predictably, either of the above errors.

When you just publish your blog to the primary domain, you're using the Blogger Publishing wizard.

Many domains will require two settings, to forward a domain.

When you forward a secondary domain to the primary domain, you're using the DNS Manager wizard provided by the registrar, for that secondary domain. Frequently, this is a 2 step process.

1. You use the DNS Manager for the secondary domain, and designate the primary domain as the forwarding target for this domain.
2. You setup a DNS address for the secondary domain URL, and target the redirection server - as provided by the DNS host.

Some domains may make one setting, for you, automatically.

Some wizards will handle one step for you automatically, while others will require that you do both steps separately. I have had both experiences, when forwarding different domains using the GoDaddy DNS manager. You may need to experiment, here - or ask an experienced technician at the registrar, for advice.

If both settings are not made, the domain will not forward properly.

If your zone editor requires that you perform both steps separately, and you only do the first, your domain gets redirected to the redirection server. If you don't define a redirection target, you have a parked domain, similar to an expired domain - and your domain will serve the ads display page provided by the registrar.

If your zone editor requires that you perform both steps separately, and you only do the second, your domain will be properly redirected from the redirection server - but the redirection server will not be defined, for your domain. If the redirection server isn't defined, the domain will be "404".

You may need to contact your registrar, for detailed instructions.

If your registrar does not provide explicit instructions - or if you use the domain manager wizard and get either of the above results, it may be time to contact a registrar customer service representative - and possibly, insist on support from a senior technician. Using a third party registrar, or a third party DNS hosting service, you may have to improvise.

Forwarding a domain - when you must serve two domains (or more) from one blog - is simply not a task for the inexperienced.

Read More

The Task Of Forwarding A Domain Requires Experience, Persistence, And Research

I constantly advise Blogger blog owners to avoid forwarding, when setting up custom domain publishing.

In the rare cases where forwarding is actually required, not every blog owner reports success.

My blog now displays a non Google search page!

or worse

My blog now displays

404 Not Found

What did I do wrong??

Depending upon what setup work was done by the blog / domain owner, and what effort is required by the registrar, one may expect to see, quite predictably, either of the above errors.

When you just publish your blog to the primary domain, you're using the Blogger Publishing wizard.

Domain forwarding frequently requires two steps.

When you forward a secondary domain to the primary domain, you're using the DNS Manager wizard provided by the registrar, for that secondary domain. Frequently, this is a 2 step process.

1. You use the DNS Manager for the secondary domain, and designate the primary domain as the forwarding target for this domain.
2. You setup a DNS address for the secondary domain URL, and target the redirection server - as provided by the DNS host.

Some wizards will handle both steps for you automatically, while others will require that you do both steps separately. I have had both experiences, when forwarding different domains using the GoDaddy DNS manager. You may need to experiment, here - or ask an experienced technician at the registrar, for advice.

The registrar may require both steps, done by you separately.

If your registrar requires that you perform both steps separately, and you only do the first, your domain gets redirected to the redirection server. If you don't define a redirection target, you have a parked domain, similar to an expired domain - and your domain will serve the ads display page provided by the registrar.

If your registrar requires that you perform both steps separately, and you only do the second, your domain will be properly redirected from the redirection server - but the redirection server will not be defined, for your domain. If the redirection server isn't defined, the domain will be "404".

With no instructions provided, contact the registrar customer care group.

If your registrar does not provide explicit instructions - or if you use the domain manager wizard and get either of the above results, it may be time to contact a customer service representative. Using a third party registrar, or a third party DNS hosting service, you may have to improvise.

Forwarding a domain - when you must serve two domains (or more) from one blog - is simply not a task for the inexperienced.

Read More

Recovering A Deleted Page Or Post, Chapter 2

Blog owners have been deleting their pages and posts, then changing their minds later, since Blogger started providing the ability to delete pages and posts.

We've been advising anxious blog owners, for some time, how to recover deleted pages and posts. The easiest solution, in the long run, is to recover the PageID / PostID, and re publish the deleted page / post.

When the deleted page or post cannot be re published, the next option is to re build the page / post, possibly using feed cache.

Using this technique, you'll have to reformat the post content, as feed content is formatted relatively simply. When you publish the post, it will publish as a new post, with a new URL - so any external references to the missing post URL will still be broken.

Thanks to the recently offered Custom Redirects option, though, we can make this latter choice slightly less undesirable.

When a deleted page or post has to be rebuilt from the beginning, the classic prognosis was not good.

1. The content is retrieved or rewritten, then re formatted.
2. The page / post is re published, but under a new URL.
3. The readers, and the search engines, adjust to the new URL being used.

For many blog owners, issue #3 is the cruelest blow - as the blog suffers reputation loss, from readers and search engines seeing

404 Not Found

for the deleted page / post.

Given enough determination and time, the blog owner can get through issues #1 and #2 - but issue #3 is the gift that just keeps on giving. Using Custom Redirects, though, that does not have to be the case.

It's a simple solution - and your readers and the search engines don't have to do anything unusual.

1. Rebuild the page / post, using a carefully chosen Title / URL.
2. Add a Custom Redirect.
   • From: The deleted (previously published) URL.
   • To: The new (re published) URL.
3. The readers, and the search engines can view the re built page / post contents using the old URL - and update their record of the URL, as convenient to them, to point to the new URL. And the page / post never goes offline.

And you, the blog owner, can get back to work on new pages and posts.

>> Top

Read More

Confusion About The Post Feed Redirect Feature

The world of Blogger blogs contains a lot of confusing terminology.

Some Blogger features don't even have names. Some names, which I use, are terms which I made up on my own, years ago - simply because Blogger did not provide a name, at that time. One term, which Blogger did give us, still causes confusion. The term "Post Feed Redirect" seems to describe an option, in Blogger, to redirect the post feed to a different URL.

The Post Feed Redirect feature is used by some confused blog owners, improperly.

There are several specific cases, all too common.

• Change the URL of the feed. Redirecting the blog feed, to simply change the URL, causes the feed to redirect to non existent content - or a dead feed.
• Publishing the blog to a non BlogSpot URL. Custom domain publishing provides automatic redirection of the blog URL - and by extension, the blog feed URL. Adding a feed redirect causes an infinite loop.
• Randomly expose the blog to new audiences. Redirecting the blog feed to a random redirector causes the blog readers to report a hijacked Reading List - and later, to simply remove the blog, using a redirected feed, from the Reading List.

This redirection, contrary to the term "Post Feed", also affects the comments feeds and the labels feeds, relevant to the blog where the setting is used.

Besides the fact that the option in question affects all feeds in the blog, the biggest confusion is that using the option does not actually redirect the feed - it redirects the references to the feed. People use this option in the expectation that it will change the URL of the feed. This option does not change the URL of the feed - it changes the URL used by references to the feed.

To change the feed references, successfully, you must have the URL mentioned by the setting already published, in a separate effort.

• If you renamed the blog to a different BlogSpot URL, you can redirect the feed reference, from a stub blog, to the feed published under the new URL.
• If you used a different service, like FeedBurner, to create a reformatted feed replica, you can redirect the feed reference to the FeedBurner feed URL.
• In either case, the URL has to exist, from a separate effort.

If you are reading this post, look down the page, after the "Newer Post Home Older Post" links.

Subscribe to: Post Comments (Atom)

There is an example of the original feed reference. The purpose of the post feed redirect feature, long ago, was to let the blog owners generate a different feed for the blog - maybe a FeedBurner republished post feed - and force that link to reference the FeedBurner republished feed.

If you use that link, and subscribe to the feed from this blog, you should get a subscription offer, using the FeedBurner feed for this blog.

The Post Feed Redirect simply lets people setup and use an alternate feed URL, without having to update the code for all links which reference the post feed - such as that link.

That's it - pure and simple.

If you have - even unintentionally - misused the post feed redirect in your blog, it's easy to correct the mistake. Just understand why you should correct the mistake.

Read More

Clear, Or Set, The Post Feed Redirect

One of the most mysterious settings, in our blogs, is the ability to redirect references to the blog feed.

Some people use the "Post Feed Redirect" setting improperly. When this is done, the problems created can be easily solved, by clearing the setting.

1. Go to the dashboard menu Settings - Other - Site feed.
2. Look at the entry for "Post Feed Redirect URL".
3. If that option is incorrectly set, click on "Remove".
4. Click on "Save settings".
5. You're done.

If you actually need the feed redirected, it's similarly simple to set it.

1. Go to the dashboard menu Settings - Other - Site feed.
2. Look at the entry for "Post Feed Redirect URL".
3. If that option needs to be set, click on "Add".
4. Paste or type the correct URL, into the box.
5. Click on "Save settings".
6. You're done.

The setting, for this blog, for instance, is:

http://feeds.feedburner.com/Nitecruzr-Blogging

Just understand what the setting does, how to clear, and how to add, the setting - and when you should use it, or not use it.

Read More

If You Are Not Planning To Renew Domain Registration, Give Your Readers Advance Notice

One of the saddest answers given in Blogger Help Forum: Something Is Broken starts with the naive query

My domain registration expired last month, and my blog is now offline. How do I redirect the domain back to the blog?

The answer here is simple, and does not provide a lot of promise, to the blog owner.

If possible, you may be able to publish the blog back to BlogSpot - but the blog will have to be re indexed from the beginning.

Once the domain registration expires, you cannot use the domain address for reputation or traffic source. Any search engine hit entries, to the domain URL, will be 404 - and there is nothing that you can do, if you no longer own the domain.

If your blog depends upon reputation, or search engine listings, for reader activity - and you are contemplating changing from a non BlogSpot domain address back to a BlogSpot address - you need to plan this change, before you start.

Successful publishing, back to BlogSpot, starts well before registration expiration.
A successful change, back to a BlogSpot URL, starts before the domain registration expires - while you can use the domain to provide reputation, and search engine hits, to the BlogSpot URL. I like to advise people to allow at least a month for any blog to be fully indexed by search engines, when a blog is new.

If the blog is mature, and is indexed under a non BlogSpot URL, the process of re indexing under the BlogSpot URL may be only slightly briefer. A mature blog will have one thing going for it, that a new blog won't - inherent reader reputation.

Reader reputation will help some blogs - not all - survive the transition.
Unfortunately, reader reputation will be good for one thing, when re indexing your blog under the BlogSpot URL - links on the readers blogs, to your blog. If your blog has readers who don't publish blogs, or their own reader list, publicly - or if you let the domain registration expire before starting the process of re indexing the blog - you won't gain a lot from reader reputation.

All of the links on your readers blogs, just like all of the links in the search engine result pages, will be

404 not found

This sight will not provide you with reader traffic, or with any reputation.

Start at least a month before registration expiration.
If you must move from a non BlogSpot URL back to a BlogSpot URL, the time to start is a month before the domain registration expires. This is one of the few times when I will tell you to use domain forwarding. Use the Domain Manager wizard, hopefully provided by the registrar, and setup a "301 Moved Permanently" redirect to the BlogSpot URL - if the domain host allows this.

You'll also want to add a notice on the blog, announcing the change - again, well before the domain registration expires. An HTML / Text notice, visible on all pages, would be best.

This blog will move back to a native BlogSpot URL on (date). Please update your bookmarks now!

Plan the migration, and keep your readers - and maybe your readers readers, who use the links on your readers blogs to find your blog.

If you wait until the last minute, you'll be starting over - completely.
If you wait until the domain registration expires, you'll have nothing to do but publish your blog with new content - and hope that the search engines will continue to pick up the new content under the new URL - the old BlogSpot address. And maybe your current readers will find your blog. Maybe.

Read More

Some Blogger Blogs Being Locked As Malware Hosts

For a long time, we've been dealing with various malware / spam mitigation issues, in Blogger Help Forum: Something Is Broken.

Recently, malware detections, long simply identified as "Malicious JavaScript" in the well known Spam Appeal Guidelines, was given its own identity, and a separate classification / appeal process. We're now seeing several common types of JavaScript, included in blogs which are typically mentioned in forum reports.

It may be helpful to describe some examples of JavaScript code being seen, so blog owners can avoid making the same mistakes, by not including these scripts in their blogs.

There are several common types of JavaScript applications, found in many blogs with the owners requesting review / unlock action.

1. CPA / Cost Per Action.
2. Multiple popups, such as a generic "Welcome!", followed by "Like my blog, before you read it!".
3. Password protection, on a page basis.
4. Security warning popups, suggesting that you need to install a recommended security software.
5. Social networking popups, demanding "Like my blog, before you read it!".
6. Traffic Redirection, targeting other blogs / websites.
7. Traffic redirection, targeting the canonical URL for the host blog.

CPA / CPALeads / Cost Per Action, and similar online marketing terminology, involves providing a reward for viewing a blog, or for subscribing to the blog feed. Some CPA scripts may be used to collect email addresses, also known as "email address mining", later used for hacking activity or spam distribution.

CPA scripts present another problem. Since Blogger blogs are intended to reward the readers by providing interesting and unique content, blogs which use CPA may be improperly designed or maintained. Blogger wants the blog owners to publish blogs which entertain or inform their readers - not blogs which require artificial or ingenious techniques to generate traffic, and visitor activity.

Multiple popups, such as an initial "Welcome to my blog!" greeting, followed by the well known FaceBook "Like my blog, to read my blog!" demand. If multiple popups should become an established practice, it's possible that malware producers could enjoy this technique, to conceal a malware installation.

Password protection, on a page basis, is an attempt to make a blog (or blog portion) private, by using a password. This protection is easily defeated, as the password is provided in the page (post / template) code, as plain text - and can easily be identified by anybody knowing how to view page source as text.

Besides the "protection" being easily bypassed, this is a problem because security scanning programs - such as the malicious scripting bot - can't pass through JavaScript code easily. When encountering this JavaScript application, your blog will be righteously classified, as a malicious script host.

Security warning popups, suggesting that your computer is infected - and offering, for immediate installation, the perfect tool to remove the claimed malware. Security experts know that this is similarly a favourite malware installation technique, where the computer owner would give permission to have the offered software installed - and the installed software would later install a botnet client or similar malicious trash.

Social networking popups are an arrogant way of wasting your readers time, and guaranteeing eventual malware classification of your blog. Popular among some WordPress blogs, the circular FaceBook "Like my blog, to read my blog!" demand is a good way to make genuine readers go elsewhere.

If you want genuine readers, who read a Blogger blog because of thoughtful, unique content, you will not get them by demanding that they boost your FaceBook popularity, before reading your blog. This is just another way of buying "Likes" - and it belongs in WordPress, not in Blogger.

Traffic Redirection, targeting other blogs / websites is a technique attempted by many hackers and spammers. The use of some blogs as gateways, leading to redistributors, which in turn lead to payload blogs or non Google websites, is part of many hacking / spam attacks. Google is trying to restrict the use of Blogger blogs as malware / spam hosts - and actively prevents scripts, which only shuffle readers from one blog to another, without choice.

Even though Blogger will not encourage you to move your blog, to Tumblr, Weebly, WordPress, or wherever, you are allowed to do this - if you feel the need.

Hello, faithful readers:

This blog is now hosted at my new blogging host. Please update your blog lists and bookmarks!

If you must do this, it's OK to post a notice, in your Blogger blog. You can even put a link, to the new blog, in the notice. You just can't use JavaScript, to automatically redirect the reader to the new blog.

Traffic redirection, targeting the canonical URL for the host blog, is a technique used by some blog owners who perceive Country Code Alias Redirection to present a problem. Some accessories installed on their blogs, and various non Google services which may be used to provide activity on their blogs, may not properly reference the canonical URL tag included in all Blogger blogs.

Since Blogger / Google wants all Blogger blog owners to benefit from improved world wide access to Blogger blogs, blogs which employ automatic canonical URL redirection may damage the effect of CC alias redirection. Blogs which host scripts which immediately redirect readers to the canonical URL, and are considered undesirable by any host government, may force an offended host government to block the entire Blogger service, in their country.

To prevent malicious misuse of Blogger by hackers and spammers, and to encourage effective long term use of Blogger by legitimate blog owners, Blogger / Google may detect any blogs which use these types of scripts as part of their general malware / spam classification strategy. Given the ability and willingness of the blog owner, to remove the JavaScript code in question, most blogs can be returned to service - but each blog will remain offline, until the removal is verified.

It's to everybody's benefit to identify, and to avoid use of, these scripts in our blogs, before it's too late. If your blog contains one of these scripts, why not remove the problem now, instead of waiting until you too have to post your problem report, in the forum

Help me! My blog was just locked for

MALICIOUS JAVASCRIPT

What do I do, now?

Read More

Malware Classification, And Country Code Redirection

We're seeing a few complaints, in Blogger Help Forum: Something Is Broken, about overly aggressive malware classification.

Many of the complaints are from blog owners who only want to publish their blogs without fear of side effects from the latest controversial feature, Country Code Alias Redirection.

Spurious malware / spam detection is a painful topic to discuss - and it's even more so when the question of country code alias redirection is discussed. Like auto pagination long ago, country code alias redirection appears to be another case of Google manipulating its customers, maliciously. If you consider this issue from the viewpoint of Blogger blogs in general, though, you may see the full picture.

Blogger blogs, like the Internet, need to be available to all countries in the world, without fear of censorship.

Redirection allows specific blogs to be blocked in specific countries.

Country Code Alias Redirection allows Blogger to selectively disable any single blog, in any single country. This selective disabling will, eventually, eliminate the need of any country government to block the entire Blogger service, in their country, because of a few culturally or politically insensitive blogs.

Country Code Alias Redirection is a righteous feature in Blogger blogs. Like many new Google features, it was added before every Internet service was made able to support it. Country Code Alias Redirection uses an Internet standard - not a Google proprietary feature - the canonical URL tag.

If you look at the header in this blog, you can see an example of a canonical URL tag.

<link href='http://blogging.nitecruzr.net/2013/02/malware-classification-and-cc-alias.html' rel='canonical'/>

That's the tag for this article, for instance.

Some non Google features and services don't support Blogger Redirection.

Some Blogger blog owners find that Country Code Alias Redirection causes problems, with some accessories on their blog. Some owners have added anti redirection code to their blogs, so the accessories on their blogs continue to work.

Country Code Alias Redirection may not work with every third party provided blog accessory or Internet service - because all Internet services, and third party accessory providers, do not support canonical URL tags.

Just because some services are not up to date with all Internet features (like Country Code Alias Redirection), this does not mean that it should not be used. The delinquent services need to be encouraged to update their code, as necessary.

Blogs which block redirection are classified as malware hosts.

Some blogs, which block Country Code Alias Redirection, are being spuriously detected as malware hosts - and this is more controversy.

The anti redirection code looks like malware - because that same code is used by spammers, to abuse the Blogger service. To not classify blogs attempting to disable Country Code Alias Redirection, would require the malware classifier to identify the intent of the blog owner - and would make malware detection more complicated.

Since Country Code Alias Redirection is a righteous feature, it's possible that anti redirection code actually should be treated as malware - even though the blog owners, adding the code to their blogs, may not consider this to be the case.

We need to discourage blocking of redirection, for everybody's benefit.

Those of us who are concerned with detection and removal of malware and spam from the Internet, in general, know that malware and spam is like a cancer - if you don't remove what you see, it's only going to get worse.

To allow anti redirection code to be installed in some Blogger blogs, will encourage other blog owners to do the same - and will inhibit the effects of Country Code Aliasing. Also, it will allow some hackers and spammers to do likewise, without fear of detection. None of these possibilities is good for Blogger blogs, in general.

Your blog may now be locked, because of redirection blocking code,

If you installed anti redirection code in your blog some time ago, your blog was just locked as a suspected malware host. and you are now anxiously waiting for malware review while your blog remains offline, we're sorry for you. But you are not being abused by Blogger - nor is your malware classification unfair.

Remove the anti redirection code, on your blog - now, while you are able. Encourage the providers of third party accessories and Internet services to update their code. And don't allow or encourage hackers and spammers to abuse Blogger blogs, or the Internet in general. Please.

Read More

Custom Redirects, And Old FTP Published Blog URLs

Long ago, Blogger blog owners would publish a blog as part of an existing website.

With the website published as "www.mydomain.com", they would create a website subdirectory "www.mydomain.com/myblog", and publish the blog there.

The option to publish a blog as "www.mydomain.com/myblog" required an externally maintained domain / website - and the Blogger feature "FTP Publishing". In 2010, Blogger, with many man hours spent fixing a constant stream of problems, retired "FTP Publishing", in favour of "Custom Domain Publishing".

Custom Domain Publishing, like FTP Publishing, lets us publish our Blogger blogs to non BlogSpot URLs.

Unlike an FTP published blog, a custom domain published blog requires a separate subdomain for each different blog. If a non Blogger website is hosted as "www.mydomain.com", a Blogger blog can only be published to "blog.mydomain.com" - and "www.mydomain.com/blog" became an impossibility.

Last year, Blogger introduced Custom Redirects, as part of the "Search Preferences" feature. Now, once again, a Blogger blog can be addressed as "www.mydomain.com/myblog", when hosted as "www.mydomain.com" - though a non Blogger website (if one exists) cannot be directly hosted as "www.mydomain.com", simultaneously.

It may be possible, however, to host an externally published website as "site.mydomain.com", and a Blogger blog as "www.mydomain.com" - and use the Blogger "Missing Files Host" feature to locate website pages, dynamically, in "site.mydomain.com". There may be hope, for people who declined to migrate their FTP Published blogs, in 2009 - and who now have static "blogs" as frozen pages in their external websites.

Read More

Country Code Aliases Are Not In Use, In All Non USA Countries

One source of confusion, about the occasionally misunderstood country code aliasing of BlogSpot published blogs, comes from the way the aliasing is being installed, world wide.

Country Code Aliasing is a new feature - and it's still being tested. Since it's being tested, it's not being immediately installed in all countries, world wide - and this will cause confusion, until it is fully installed.

Google is installing Country Code Aliasing, one country at a time, as convenient to them.

Change notification will be provided, if at all, after change is made.

Google is providing no notice, before - or after - any given country is being added, as an alias to "blogspot.com". This is a standard technique used in Information Technology environments - it's not new or unique to the Blogger / Google Country Code Aliasing feature.

It's called by various names, in different companies. Some call it phased installation, others pilot testing, and others may have other names.

Each blog, with a different reader population, will have different results.

What it means - simply - is that not all blog owners will see the same effects, as the new feature is installed, in every country, as each new country is added. Every different blog will have a differing reader population, distributed over different countries.

Readers in some countries - where aliasing is active - will see different results than readers in other countries, where aliasing is not active.

Not any two blog owners will see the same problems.

Combining the different content in every different blog, which makes some blogs more or less susceptible than other blogs to the effects of aliasing, with the different reader population, not any two blog owners will see the same problems, or have the same opinions, about aliasing.

Until every blog owner realises several details about aliasing, we're going to keep hearing complaints.

• Country code aliasing is not optional.
• Country code aliasing has a real purpose.
• Country code aliasing is beneficial to all of us.

We'll deal with the problems, one blog, one country, and one owner at a time.

We'll all just have to deal with the problems, one country at a time. We'll need to ask our readers, one crucial question.

What exact URL is displayed, by your browser, when you observe the problem?

And, we'll have to observe the difference between "blogspot.com", "blogspot.co.uk", and "blogspot.fr".

Read More

Country Code Aliases Cannot Be Bypassed

Occasionally we see the innocent query in Blogger Help Forum: Something Is Broken, about the recently introduced Blogger feature - country code aliasing.

Is there any way I can opt out from this constantly changing of the .com termination, into .be, .bg, or .ro, depending on where I travel?

Not many Blogger blog owners realise the benefits of country code aliasing, which is, like auto pagination, a feature which is not optional. There are publicly available workarounds, which may bypass the effects of country code aliasing - and which may cause more trouble than simple URL confusion.

Many spammers would love to setup gateway blogs, and automatically redirect their unwitting victims.

Spammers would redirect traffic to dangerous blogs and websites.

The redirections would lead to other blogs (or non Blogger websites) which contain their actual hacking, porn, or spam payload. Blogger / Google, like some browsers and security programs, actively prevents automatic redirection of Blogger blog traffic.

Blogger malware classification is not understood by everybody.

Not all blog owners understand the effect of Blogger malware classification. Similar to spam classification, malware classification persistently scans through Blogger blogs, looking for signs of malware.

Anti-alias redirection code is very simple, and subtle.

Here's an example - a very simple code snippet, recently discovered in the header of the template, in a blog which has been repeatedly locked for "Malicious JavaScript" / "Spam".

var·blog·=·document.location.hostname;
var·slug·=·document.location.pathname;
var·ctld·=·blog.substr(blog.lastIndexOf("."));
if·(ctld·!=·".com")·{
var·ncr·=·"http://"·+·blog.substr(0,·blog.indexOf("."));
ncr·+=·".blogspot.com/ncr"·+·slug;
window.location.replace(ncr);
}

or maybe, a more compact snippet

if ((window.location.href.toString().indexOf('.com/'))=='-1') {
window.location.href =window.location.href.toString().replace('.blogspot.in/','.blogspot.com/ncr/').replace('.blogspot.com.au/','.blogspot.com/ncr/');
}

or maybe

//<![CDATA[(LF)
var·curl·=·window.location.href;if·(curl.indexOf('m=1')·!=·-1)·{curl·=·curl.replace('m=1',·'m=0');window.location.href·=·curl;}(LF)//]]>

To prevent malware detection from blocking this post, I'm omitting the essential opening and closing tags, which would normally encase the above code snippets.

<script·type='text/javascript'> ... </script>

You can try anti alias redirection code, if you like.

If your blog contains similar redirection code, to bypass country code aliasing, you may get a notice, one day, that your blog has been deleted for "Malicious Javascript". In order to get the blog restored, so your readers may view it, you may have to remove the Malicious JavaScript - then wait until the blog can be reviewed, to ensure that it is safe for public visibility.

When your blog is classified as a malware host, you will suffer.

While you wait for review, you will have to endure the loss of search engine and reader reputation - while every would be reader sees the interstitial notice, mentioning why your blog is deleted or locked.

Work on the problem, don't use (and encourage) dodgy workarounds.

You will accomplish more, and cause yourself (and your readers) less pain, by learning to live with country code aliasing - and concentrating on convincing the various search engines and other Internet services to accept Canonical URLs, so country code aliasing will work, seamlessly, with the Internet service which interests you. Alternately, use better designed gadgets and Internet services.

Read More

Blogger Magic - Redirecting A URL In Your Blog

In 2012, Blogger gave us a suite of useful utilities to control how the search engines see our blogs.

This feature suite includes the ability to redirect one URL in our blog to another URL in our blog. The "Custom Redirects" feature is easy to use - but like many Blogger features, not immediately so.

Neither its possibilities, nor its limitations, are obvious to everybody.

A Custom Redirect starts with the dashboard wizard, at Settings - Search preferences.


Click "New redirect", to start, if you have redirects already.


Add From and To values, as noted.


Remember to select "Permanent".

1. Go to Settings - Search preferences - Custom Redirects, and click on Edit.
2. If you have existing redirects, click on "New redirect".
3. Enter the correct "From" and "To" values.
4. Select "Permanent".
5. Click on "Save".
6. Click on "Save changes".

You can redirect any URL in the blog - to any other URL in that same blog.

The possibilities are almost endless, when you reference any valid URL in a given blog.

Thanks to the syntax of the "From" and "To" values in the wizard, Custom Redirects will only redirect within the blog itself, and is thus useless to spammers and others who would like to misuse it. Also, the custom redirects, which do not include the published URL, will work after the blog URL is changed - either BlogSpot to BlogSpot, or custom domain publishing.

The URL of this post:

http://blogging.nitecruzr.net/2013/01/blogger-magic-redirecting-url-in-your.html

The base URL, stripped:

/2013/01/blogger-magic-redirecting-url-in-your.html

Take any two URLs in your blog, strip the base URL, and add a custom redirect.

Just take any two specific URLs (no masking, or wild cards) within your blog, strip the base URL from each, and enter the results as the "From" and "To" values. Always start "From" and "To" with a "/" (no leading spaces, or non visible control characters!), signifying the root of the URL, follow the above procedure, and you're done.

Click here, for examples of what you can do. Then, use your imagination.

Just remember though to use specific URLs, no masking or "wild card" characters. Also - the actual URL - and what your readers see in the address window - will not change. The magic goes only so far.

Read More