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.

GeoLocation, And Our Use Of Blogger

Recently, we've seen signs of confusion, from people who have problems with their Internet service, which shows them moving around their geographic region.

I logged in to Blogger, with no problem, yesterday. Today, after logging in successfully, I am asked for more details, to prove my identity!!

This blog owner has a problem with location based security.

Not all Blogger blog owners or readers understand that Country Code Alias Redirection, and the ability to access one's Blogger / Google account (and prevent others from accessing it), both depend upon the ability to determine the geographical location of each blog reader.

Various Google features, like Country Code Alias Redirection, and Google login, use geolocation, to identify the location of each reader.

For people using the Internet, Geolocation uses the Internet connection, to determine physical location. Unfortunately, for many blog owners, the Internet Service Provider, the Internet connection, and the Internet customer (or Blogger blog reader) may each be in a different location.

My own location - even when I am at home - may, at times, appear to move in a 30 mile radius. My ISP routes my connection through any of half a dozen different connection points, in my region, depending upon current network activity.

Some smaller ISPs, located near a country border, may actually get service through a larger ISP in another country. Customers of the smaller ISP may appear, through geolocation, to reside in the other country.

This can be an unfortunate problem, with country code alias redirection, with language detection, with login authentication, and / or the Location option in Post Editor.

People located in one country, reading an unfamiliar language, or seeing their latest post show up in the wrong province / state - or even country - may not appreciate the confusion which is caused. And people who login, and appear to move from city to city in the region, grow tired of having to prove their identity - after successfully entering account name and password.

Thanks to domain based filtering, this may become a security issue for some blog owners, near country borders, who may not be able to maintain / publish their blogs.

Unfortunately, geolocation, using the Internet Address (aka "IP" address), will never return consistent and precise results. Any location based processes will always provide fuzzy results, thanks to Internet services which load balance their network connections.

The Google "One account" Login, And Cookie Filters

Thanks to the recently added Google "One account" login, all Blogger features are now vulnerable to "third party" cookie filters.

Long ago, many people who used Blogger would login to Blogger using a link in the navbar - or a similar Blogger login wizard.

http://www.blogger.com

Now, that login redirects to the Google "One account" login.

http://www.google.com

When referenced from a Blogger login, the latter URL becomes magnificently complex.

https://accounts.google.com/ServiceLogin?service=blogger&passive=1209600&continue=https://www.blogger.com/home&followup=https://www.blogger.com/home<mpl=start

Long ago, people who logged in to Blogger, using the Blogger login, had no need to worry about "third party" cookies and filters.

When blog owners logged in under Blogger, the dashboard worked transparently.

Everybody could use the Blogger dashboard and some Blogger features, such as full page and popup window comments, without any problems. A login cookie, created under "blogger.com", could be read under most Blogger features - such as a full page or popup window comment form, or the various Blogger dashboard components - without any thought to any "third party" cookie filters.

Not everybody understood the difference between the dashboard and blog features.

The lack of worry about "third party" cookie filters, with Blogger login, did cause some dissent. People able to use the Blogger dashboard in general, became rather skeptical, when told to allow "third party" cookies, to enable the Stats "Don't track ..." option, or maybe the embedded comment form - or various other Blogger features.

Some blog owners, when advised to change form placement, because of reader problems when publishing comments, might object because the full page or popup window form lacked features - but not all. A few objected, simply because they did not believe that cookie filters could be so capricious.

Some blog owners attributed the differences to poor design.

Occasionally, some owners would ask why the embedded comment form would be designed so negligently, to require third party cookies - as if Blogger intentionally designed their features, to make it difficult to use their service. At one time, the embedded form was re written, to use "blogger.com" content, embedded in an iframe - possibly to allow the CAPTCHA form, for embedded comments, to avoid the nefarious "third party" cookie filters.

With Google "One account", Blogger and Google, instantaneously, has made the entire Blogger service require enabling of "third party" cookies. If a login cookie is created under "google.com", it will need to be read under "blogger.com" (the Blogger dashboard utilities), "blogspot.com" (Blogger blogs, published natively), any country code aliases that might apply, and any Blogger blogs, published to custom domains.

There is no more confusion about "third party" cookie filtering, because some features may work, and other features, mysteriously, don't work. Now, all of Blogger (GMail, Picasa, YouTube, ...) will require "third party" cookies to be permitted, if a login cookie is to be consistently accessible - and all services are to work, reliably.

All problems are not caused by cookie filtering - and this expands the confusion.

Yet, "third party" cookie filters alone, do not explain all Blogger feature problems, that do involve cookies, in some way. Both the recently explored comment wizard CAPTCHA form, the interstitial warning displays, and the Reading List disappearances - all have other, complementary, issues.

Cookie filtering is just one detail, in the Blogger infrastructure - though when problems are seen, one should check and correct the filters.

Hopefully, as the need for third party cookies becomes more uniform in Blogger, everybody using Blogger can become objective enough, and stop inappropriate filtering. With third party cookie filters less critical an issue, maybe Blogger Engineers can identify the problems that they can, and should, solve.

Interstitial Warnings And Cookie Filters

Along with problems with comments and unwanted CAPTCHA forms, we're seeing some reports about problems with persistent and unwanted interstitial displays, in Blogger Help Forum: Get Help with an Issue.

The interstitial display, and its use of cookies, is similar to the new mandatory anonymous comments CAPTCHA form. If your identity can't be determined, or your decision to view a blog can't be remembered, an interstitial warning is displayed - just as the CAPTCHA form is displayed, when your readers are preparing to comment.

Interstitial warnings require cookies, both to identify you, and to remember your decisions.

• In front of a "private" blog, where you have to be identified, to determine your relationship with the blog.
• In front of a blog that contains (or is reputed to contain) objectionable material (naughty pictures or such), to remember your desire to view the blog, and your decision to continue.
• In front of a blog that is (or appears to be) published off site, to remember your desire to view the blog, and your decision to continue.
• In front of a blog that has been blocked, for TOS violation, or maybe for hosting hacking content, where you have to be identified, to determine your relationship with the blog.

If the cookie can't be read, the interstitial code will try again.

If a preference cookie can't be read after being created, the blog display may force you to try again, and re display the interstitial warning. If a session cookie is not accessible to the blog display, the reader gets treated as someone not logged in.

In neither case, does the reader get to go to the next screen, and view the blog.

Both session cookies, and preference cookies, are vulnerable to "third party" cookie filters.

• A preference cookie is created under "blogger.com", where the interstitial runs.
• A session cookie is created under "google.com", where you login.

These are third party cookies, being read under the blog published URL.

Both types of cookies are read under "blogspot.com" - or under whatever custom domain, or whatever country code alias, is being used by the blog, as displayed.

Whether a cookie is needed, but non existent - or needed, but can't be read - the result is the same. The reader is unable to continue, and does not get to view the blog, when necessary.

If the computer has a cookie filter, the cookie won't be read.

If a reader is subject to a filter that blocks "third party" cookies, and a preference or session cookie is needed, the reader will be unable to continue. This is a condition that Blogger Engineers cannot program around, because it is part of the security code, in the browser.

Thanks to the Google "One account" login, as Blogger is made a way of life to more of a reader population who have no interest in maintaining security on their computer, these issues will become more problematic.

Comments And Cookie Filters - October 2014

The new, mandatory CAPTCHA form, for blog readers wishing to comment anonymously, has been in service for just under a week.

We're seeing a variety of problems, reported in Blogger Help Forum: Get Help with an Issue, by blog owners and readers alike.

Long ago, for blogs with readers who were not really comfortable with maintaining security on their computers, we would recommend changing comment form placement.

The full page (or the slightly less preferable popup window) comment form was more usable, with readers who do not know how to properly maintain cookie and script filters. With recent changes in Blogger and Google, all Blogger comment forms are now vulnerable to inappropriate filters.

• Use of the Google "One account" login creates login cookies under "google.com" - not "blogger.com".
• Publishing blogs to custom domains - not "blogspot.com" - makes cookie access "third party".
• Referencing blogs from countries subject to country code aliasing - not as "blogspot.com" - makes cookie access "third party".
• The new, mandatory commenting CAPTCHA form, part of all Blogger comment form placement options, makes cookie access very important.

All of these issues, considered together, makes proper third party cookie filtering even more critical, than it has been, in the past - and makes new Blogger features more problematic.

The Google "One account" login, at "google.com", is now used by many blog owners and readers - instead of the Blogger native login, at "blogger.com". When the "blogger.com" login was used, cookies created under "blogger.com" were not as vulnerable, to cookie filters.

Whether used under "blogspot.com", or whatever country code alias or custom domain is in use (for the embedded comment form) - or under "blogger.com" (for the full page and popup window comment forms) - login cookies created under "google.com" (by the Google "One account" login) are vulnerable to "third party" cookie filters.

Blogs published to custom domains are becoming more and more popular. All blogs published to custom domains, which use the embedded comment form, are vulnerable to "third party" cookie filters.

Blogs referenced under country code aliasing are becoming more normal. All blogs subject to country code alias redirection are vulnerable to "third party" cookie filters.

The new, mandatory commenting CAPTCHA form needs to access the Blogger / Google login cookie - so blog readers, who are logged in to Blogger / Google, will not be subject to the CAPTCHA. The embedded, full page, and popup window forms are equally vulnerable to "third party" cookie filters, given the above discussed issues.

Thanks to the Google "One account" login, as Blogger is made a way of life to more of a reader population who have no interest in maintaining security on their computer, these issues will become more problematic.

>> Top

The Mysterious Disappearing Reading List

One long known mystery, reported from time to time in Blogger Help Forum: Get Help with an Issue, involves the dashboard Reading List, and panic from disappearing entries.

Where are the blogs, in my Reading List?

Some Blogger blog owners and readers can spend days setting up their Reading List complement - and see their work vanish, in seconds.

One of the reasons why this problem has not been solved is that it is not reported in consistently high volume, and has no obvious pattern. Another is that many people who use the Reading List - as opposed to a third party NewsFeed Reader - are not of the highest in technological skill level, and do not have the patience to provide coherent and relevant details about the problem.

From my observation of forum problem reports, I suspect that there are at least 3 different problems, which cause this intermittent Reading List scenario.

It's likely that each problem is caused in part by the people, who depend upon the Reading List to follow blogs published by them, and by other people. Some people also publish their own blogs, while others only read blogs, using their own Reading List - and this can complicate both the diagnosis, and resolution, of the problems.

At least some of the reports of "My Reading List has disappeared!" involve three long known problems - each problem caused, in part, by the Blogger account owners who use the Reading List.

• Cookie / Script Filters, which prevent the Reading List code from identifying the reader, and displaying the personal Reading List.
• Multiple Blogger accounts, where an account owner sets up their personal Reading List while logged in to one account, and later uses a different Blogger account, with no personal Reading List setup for that account.
• Load Timeout is a problem with the Reading List assembly process, similar to timeout by the Dynamic Template assembly process.

The cookie / script filtering issue is similar to another long standing problem - Blogger Comments, particularly using the Embedded comment form. Third party cookies, which carry the identity of the person logged in to Blogger, being filtered and unavailable to the Reading List generation code, lead to the empty Reading List display. The Blogger Comments problem, like the Reading List problem, seems more common to people with lower tech skills set.

The cookie / script filters issue may also involve people who access the Internet through countries subject to country code alias redirection. People who live in the UK may not consistently update their security filters to permit cookies or scripts from "blogspot.co.uk", as they do for "blogspot.com". People who live close to international boundaries may not be aware of the vagaries of geolocation, and how their country code alias redirection may be affected, from day to day.

Another filter issue may involve recently updated filters. Thanks to ever changing security needs, and frequent unannounced updates by many security product vendors, a filter which worked yesterday may not work today. People unaware of the intrusive nature of security updates won't think to check the update log for any security product.

The empty Reading List problem can be caused by aggressive cookie / script filters, as is a similar problem - inability to remove specific blogs from the Reading List.

The multiple accounts issue is common to almost every Blogger feature. Ever since Blogger added the "Create an account" link to the Blogger / Google login screen, people have been setting up multiple Blogger accounts. Some people setup multiple accounts accidentally, and others do so on purpose.

If you combine the "Create an account" link with the ease of setting up a non GMail based Blogger account, you see that many people who don't use GMail can easily setup a new Blogger account without realising what they are doing. The owner of a new account, newly able to login, finds an empty dashboard. People who use the Reading List, purely to Follow other peoples blogs, will not be interested in the empty "My blogs" list, and will simply observe the lack of entries in the Reading List.

Other people setup additional Blogger accounts intentionally, to host different blogs under different accounts. People who intentionally segregate their blogs may not understand the similar personal nature of the Reading List.

Cookie / script filters can also block the contents of the Google "One Account" display from being properly generated - and may similarly contribute to creation of multiple accounts. The "reflexive action" design of the "One Account" display also contributes to use of the wrong account, in multiple account situations.

Both aggressive cookie / script filtering, and use of multiple Blogger accounts, can lead to lack of proper identification of the Blogger account owner - and to an empty Reading List.

The load timeout issue is similar to Dynamic Template load timeout. If you have any interesting assortment of feeds, in your Reading List, clear cache, cookies, and sessions, restart the browser, and login to Blogger. Immediately, scroll to the bottom of the screen, and watch the Reading List on your dashboard.

The list will, initially, be completely empty - then suddenly, it will fill with some number of posts, instantaneously. This is the same way a blog displays, in a dynamic view.

The various feeds in the Reading List have to be merged, so the individual posts can be displayed in proper sequence - in the same way that the components of a dynamic template display are assembled. This will make the Reading List display vulnerable to intermittent local and network problems, as the dynamic templates are vulnerable.

Different client computers will be differently vulnerable to load timeout, because of details like differing reading list content, individual network problems, and individual local computer problems. Reading List load timeout will have the same effect as Dynamic View load timeout - no display. This will be a truly intermittent problem.

Besides the inconsistent and intermittent load timeout, we'll see consistent errors, like the empty Reading List - and the mysterious lack of ability to remove Reading List entries.

All of the above issues are caused, in part, by the Blogger account owners. Blogger Engineering has worked for many years to solve the problem of cookie filtering and commenting, in vain. I suspect that they have also worked on the Reading List display problem, with similar result.

As long as people use their own computers, with security components of their own choosing - and neglect to consistently use the same Blogger account - Blogger is never going to solve the problem of the empty Reading List. The panic will never go away.

Thanks to the Google "One account" login, as Blogger is made a way of life to more of a reader population who have no interest in maintaining security on their computer, these issues will become more problematic.

FaceBook Is Aggregating BlogSpot CC Aliases

We're seeing a few questions recently, in Blogger Help Forum: Something Is Broken, about FaceBook, and their treatment of Blogger URLs that are subject to local country domain redirection.

When I share a post on FaceBook, the URL used for my blog ends with "blogspot.in" instead of "blogspot.com".

Some people in Europe observe a variation.

When I share a post on FaceBook, the URL used for my blog ends with "blogspot.nl" instead of "blogspot.com".

We've been observing, for a long time, that FaceBook and other Internet services should start using the canonical tag - and aggregate BlogSpot URLs, that are subject to local country domain redirection.

With aggregation done properly, all BlogSpot URLs would be listed as "blogspot.com" - and all Likes, and similar references to a given Blogger blog, would be later counted under the proper "blogspot.com" URL - regardless where a given blog reader gets Internet access.

Apparently, FaceBook is now aggregating BlogSpot URLs - but they are not successfully using the canonical URL, as provided by the tag in the blog header. FaceBook now uses "blogspot.in" - or maybe "blogspot.nl" or "blogspot.pe" - as the final URL for some Blogger blogs, when shared.

If you share your blog to FaceBook and observe this problem, try using the FaceBook Sharing Debugger. Select "Scrape Again", when you see "blogspot.pe", or another alias, in the debugger log.

Selecting "Scrape Again", enough times, may lead to the Debugger displaying "blogspot.com" - and your actual canonical blog URL will be cached. This will provide a work around until FaceBook corrects their sharing feature.

When Blogger first started using local country domain redirection, only Google services such as Google Search would reliably aggregate all local country domain references, to "blogspot.com".

Many non Google services did not use canonical aggregation, immediately. Like every other newly developed Internet feature, it takes time for every web service to update their code.

With only Google using canonical aggregation, every Blogger URL subject to country code alias redirection would be shared using the country domain, as seen by the person doing the sharing. People in France might share a Blogger URL as "blogspot.fr", people in India as "blogspot.in", and so on.

People in the USA, of course, would share a Blogger URL as "blogspot.com". The USA, and various other countries, is not subject to country code alias redirection.

FaceBook is now aggregating BlogSpot URLs - but they are not using the canonical tag, in the blog header. They are aggregating to "blogspot.in", "blogspot.nl", or "blogspot.pe" for some or all BlogSpot URLs, shared to their service.

Maybe, FaceBook is resolving "blogspot.com" from various countries that are subject to local country domain redirection - and generates the redirection themselves?



Right now, for some blog owners who share a BlogSpot URL to FaceBook, the URL will be modified, to "blogspot.in", "blogspot.nl", or "blogspot.pe". Every Like, and similar activity against that URL, will then be counted under the "blogspot.in", "blogspot.nl", or "blogspot.pe" alias. This is probably slightly better than having every different URL shared by country code alias - but only slightly better.

Blogger blogs published to custom domains are not subject to URL modification, because custom domain URLs are not subject to local country domain redirection.

Some Blogger blogs will continue to appear to have at 3 URLs - "blogspot.com", "blogspot.in", "blogspot.nl", or "blogspot.pe", and any others under which FaceBook was sharing, originally. The search engines may index blog content, accessed from FaceBook shares, as "blogspot.com", "blogspot.in", "blogspot.nl", or "blogspot.pe".

If this is not acceptable, you may need to report this to FaceBook Support. Please, resist the temptation to install malicious code on your blog, that will later leave you asking for advice on having the blog unlocked, cleaned and reviewed.

---

https://productforums.google.com/d/topic/blogger/2UXBv3Q21YY/discussion

The Blogger Country Code Aliases, And Search Engine Reputation

Many blog owners take great pride in publishing a blog that's read by many readers, and that is held in high esteem by the search engines.

Some owners have even installed various badges on their blogs, which automatically retrieve the Page Rank achieved by the blog, as distributed at the most recent Page Rank calculation. Recently, we've been seeing cries of anguish, in Blogger Help Forum: Something Is Broken.

I lost my Page Rank! My blog, as a ".com", had PR of 2 - but as ".in", it has 0! Woe is me!!

These owners do not understand that search engine reputation is still calculated and indexed using the ".com" alias.

If you are in Australia, and you're now viewing your blog as "myblog.blogspot.com.au" (with PR of 0), use the "no country redirect" URL modifier, and view the blog as "myblog.blogspot.com/ncr".

Your Page Rank badge should pop back up with the correct PR number, once again. Unfortunately, this won't do anything for your readers, who are now viewing the blog as "myblog.blogspot.co.nz", "myblog.blogspot.in", or what ever alias is relevant to their location.

If your PR badge uses the displayed URL (and is affected by the country code aliasing) - and if you're worried that your readers will be unduly influenced by seeing that they are now viewing a blog with PR of 0 - you're going to need a different PR badge, to decorate your blog.

Try and find a Page Rank badge / calculator that either

• Observes the "canonical" tag in the blog header.
• Lets you hard code the blog URL (so you can continue to specify "myblog.blogspot.com").

Blog accessories, and search engines, which blindly use the viewed URL - and ignore the "canonical" tag" - will be a problem, under the Blogger country code based redirects.

Search Engines, Visitor Logs, And Country Domains

Some blog owners are seeing the recently added Country Code Top Level Domain Aliases in their visitor logs / meters, and various non Google search engines.

Possibly unaware of the aliases, they are afraid that their blog has been hacked.

My SiteMeter logs show that I've had incoming traffic from "mybloggerblog.blogspot.in". Clicking on one of the links in SiteMeter, I see my blog, "mybloggerblog.blogspot.com". Has somebody cloned my blog?

In reality, the scenario is not so ominous.

Those of us aware of the CC aliases, and how they are being used by Blogger, will understand that simply seeing a non canonical alias in our referer lists, in any search engine or visitor log / meter, is not an indication of malicious activity.

People unfamiliar with the country code aliases may be confused.

People long used to seeing only "blogspot.com" and "google.com", and not yet experienced with the CC aliases, may become confused, however. Blogger blogs owners with long established blogs that have audiences outside the USA are probably used to seeing all references to their blogs based on the canonical URL, such as "mybloggerblog.blogspot.com".

Now that BlogSpot published blogs are being served using the CC aliases, in many countries outside the USA, the readers of BlogSpot published blogs are seeing each blog under non "blogspot.com" URLs in some search engines, and in many visitor logs and meters.

Many search engines will aggregate search references, to the canonical URL.

Most major search engines, which reference the "canonical" tag in the blog header, are aggregating all SERP entries to use the "blogspot.com" URLs. Our important search reputation is not being fragmented, such that readers in Australia provide reputation to "blogspot.com.au", readers in India provide reputation to "blogspot.in", readers in New Zealand provide reputation to "blogspot.co.nz", and so on.

Every hit, from every reader in every country, still provides reputation to the canonical alias, "blogspot.com".

Some specialised search engines like Alexa, DMOZ, etc - and most visitor logs like SiteMeter, StatCounter, and Stats, may not be designed to reference the canonical tag. It's also possible that visitor logs, by their nature, should not aggregate CC aliases to the canonical URL - as the country code, relevant to the individual readers, may be important to some blog owners.

Until the canonical tag is used by every Internet service, there will be confusion.

Until the use of the canonical tag, and the CC aliases to our readers, becomes mature, it's possible that we will see various oddities like a perceived problem with Alexa, SiteMeter, or StatCounter. It's likely that not all Internet services will ever reference the canonical tag consistently, and aggregate all statistics and visitor demographics, canonically.

Given the latter probability, this may be yet one more reason why Blogger Help Forum: Something Is Broken may never go out of business.

---

Some Confusion Over Use Of The CC TLD Aliases, By Search Engines And Visitor Logs
http://blogging.nitecruzr.net/2012/02/some-confusion-over-use-of-cc-tld.html

Search Engines And Visitor Logs, And The Country Specific Domains
Search Engines, Visitor Logs, And Country Domains
http://blogging.nitecruzr.net/2012/02/search-engines-visitor-logs-and-country.html

Blogs Viewed, Using A CC TLD Alias, Will Continue To Be Indexed Using "BlogSpot.Com"

We're starting to see some evidence of confusion, in Blogger Help Forum: Something Is Broken, about the impact of the new CC TLD aliases, upon indexing and reputation.

There's no cache for my blog, after redirecting to a ccTLD!

This is an example of the confusion, from a concerned blog owner.

99% of all Blogger blogs will see no difference, in indexing or reputation, to their blog, in Blogger / Google services.

Properly constructed Blogger blogs always reference a "blogspot.com" URL.

Every BlogSpot published blog, which uses a standard blog header, has a "Canonical" tag, defining the "BlogSpot.Com" URL for that blog.

Search engines which recognise the Canonical tag will simply index all BlogSpot content, whether accessed as "blogspot.com.au", "blogspot.in", or whatever new CC TLD alias is deployed in the future, under the base URL, "blogspot.com". Blogs such as this one, published outside "blogspot.com", will continue to be indexed under the current non BlogSpot URL.

<link href='http://blogging.nitecruzr.net/' rel='canonical'/>

That's the Canonical tag for this blog, "blogging.nitecruzr.net".

Search engine metrics are always checked as "blogspot,com", if no custom domain.

When you check the Page Rank, you should continue to check the "blogspot.com" URL - if your blog is published to "blogspot.com".

Some non Google services such as Alexa - and some third party accessories such as commenting, provided by Disqus and Intense Debate - are known to require tweaking of their code, so they will recognise the Canonical tag for the host blog. Once the code is properly updated, they should simply reference the host blog under the "blogspot.com" alias - no matter where the blog viewer may be geographically located.

It also appears that the Stats "Traffic Sources" display is displaying the different CC aliases, rather than aggregate inlinks using the canonical URL. This is causing some confusion with people who are not yet aware of the CC aliases, and their purpose.

Some Blogger features only reference the Blogger blog name.

The "Forgot?" wizard, on the other hand, uses only the blog name. Whether you are seeing your blog as "xxxxxxx.blogspot.ca" (in Canada), as "xxxxxxx.blogspot.mx" (in Mexico), or "xxxxxxx.blogspot.com" / "xxxxxxx.blogspot.us" (in the USA), you'll always use only "xxxxxxx" when recovering access to your Blogger account.

If your blog uses no third party accessories or services, relax just a bit - then get back to work on your blog.

Country Code Based Aliases Will Interfere With Filters

As the Country Code TLD aliases, for blogs published to "blogspot.com", become more and more noticed, incidental problems are being reported.

For people who are security minded, as well as people who are conscientious about what is permitted on their personal computer, a few domain based filter related problems should be obvious.

Where are the pencil / tool icons on my blog?

and

Why can't my readers comment on my blog?

are just a couple examples of the various questions being seen in Blogger Help Forum: Something Is Broken, since the CC TLD aliases went into effect last week.

As with any layered security feature on our computers, local country domains affect our blogs in several ways.

• Content filtering.
• Cookie filtering.
• Script filtering.

These are all concerns, for both the blog owners, the blog readers, and of course Blogger Support.

Any filter, which permits cookies and / or scripts from "blogspot.com", needs to be checked - and to permit cookies and to permit scripts from the country local domain, that's relevant to the location of the computer being used. Note that with computers located near international borders, the owners may need to consider the country local domain for the countries on either side of the border.

• "blogspot.com.au" - if the computer receives service in Australia.
• "blogspot.in" - if the computer receives service in India.
• "blogspot.ca" / "blogspot.mx" - if the computer is located in northern / southern USA (or Canada / Mexico).
• Any future added CC TLD alias - if the computer receives service in the relevant country.

The blog owner, and the computer owner, must accept responsibility for filters.

As always, I will ask you to remember that Blogger Support cannot support the filters affecting your personal computer. Both blog owners, and blog readers, have to check all filters in their browsers, their computers and their networks.

Any local filters are the responsibility of the "owner" of the computer in use - whether the "owner" is the blog owner, the blog reader, or someone supporting the blog owner or reader. There are several problems, reported periodically.

• Commenting, on blogs which use the embedded comment form.
• Editing the blog template, using the Template Designer "Live Preview" window.
• Editing a post, and using the "pencil" or "screwdriver / spanner / wrench" icon.
• Editing a post, and using the "Preview" button in Post Editor. The "Preview" button, like the Template Designer "Live Preview" window, will require third party scripts to display a "blogspot.com" / "blogspot.com.au" / "blogspot.in" / whatever alias follows next, page from a "blogger.com" script.

All of these issues are related, in some way, to domain based cookie and / or script filters. And all of these issues, when reported, involve personal use of a computer - and can't be exclusively resolved by contacting Blogger / Google Support.

Some of the above problems, like a similar issue with custom domain publishing, may be seen on any computer used by the blog owner - or by any blog reader.

There may be workarounds, depending upon the actual problem.

If you are a blog owner, and the redirection is causing you problems, it's possible that you could work around the problem, by using the "No Country Redirect" modifier - if use of the "/ncr" modifier does not cause secondary problems, like language used.

If I had a problem with my blog, published as "bloggerstatusforreal.blogspot.com", I could access it as "bloggerstatusforreal.blogspot.com" in any country subject to the CC based redirect, by using the URL "bloggerstatusforreal.blogspot.com/ncr". This is, unfortunately, not likely to help our readers with their problems.

Please, don't be misled by advice to use clever JavaScript based redirection of blog traffic, to the "/ncr" alias, as an alternative to Country Code alias redirection. Clever solutions will not work well for you, in the long run.

What's The Canonical URL Of My Blog?

This blog is (for those of you not familiar with it) "The Real Blogger Status".

The URL of this blog is currently "http://blogging.nitecruzr.net". As long as I publish the blog properly (as "blogging.nitecruzr.net"), I am allowed to advertise the blog using any combination of lower case and upper case letters, that I like. This blog can be accessed as "blogging.nitecruzr.net", "Blogging.Nitecruzr.Net", or even "BlOgGiNg.nitecruzr.net". We say that Blogger URLs are case insensitive.

Even with my readers allowed to use any combination of lower and uppercase letters, to access this blog, I don't want the search engines to index (and determine page rank) my blog using the exact URLs, as typed by each different reader. Even with this blog being addressed as "blogging.nitecruzr.net", "Blogging.Nitecruzr.Net", or even "BlOgGiNg.nitecruzr.net", the search engines index this blog as "blogging.nitecruzr.net".

To help this happen, Blogger uses the "canonical" tag, in the blog header.

The "canonical" tag is not unique to Google.

The "canonical" tag is a cooperative standard.

It was developed as a standard in 2009, jointly, by Google, Microsoft, and Yahoo.

Every Blogger blog, which has a standard and up to date header, contains a "canonical" tag.

A Blogger "canonical" tag is used to convert the blog URL to lowercase characters.

The "canonical" tag provides the base URL of the blog, in all lower case letters, so the search engines know how to ignore various syntax variations.

• Case variations.
• CC TLD aliases.
• Any other reader generated variations.

All links are indexed under one unified URL, providing better SERP positioning, and more search engine generated traffic.

Look at the source for this blog home page, in the header. Note that you have to look at the online "source code" - not at the raw HTML, using the Template Editor!

Here's an excerpt of the header for this blog, with a few line breaks added - and some lines removed - to make it more readable.

<head>
<meta content='IE=EmulateIE7' http-equiv='X-UA-Compatible'/>
<meta content='width=1100' name='viewport'/>

...

<link href='http://blogging.nitecruzr.net/favicon.ico'
rel='icon' type='image/x-icon'/>
<link href='http://blogging.nitecruzr.net/' rel='canonical'/>
<link rel="alternate" type="application/atom+xml"
title="The Real Blogger Status - Atom"
href="http://blogging.nitecruzr.net/feeds/posts/default" />
<link rel="alternate" type="application/rss+xml"
title="The Real Blogger Status - RSS"
href="http://blogging.nitecruzr.net/feeds/posts/default?alt=rss" />
<link rel="service.post" type="application/atom+xml"
title="The Real Blogger Status - Atom"
href="http://www.blogger.com/feeds/24069595/posts/default" />
<link rel="EditURI" type="application/rsd+xml"
title="RSD" href="http://www.blogger.com/rsd.g?blogID=24069595" />
<link rel="openid.server" href="http://www.blogger.com/openid-server.g" />

There it is.

<link href='http://blogging.nitecruzr.net/' rel='canonical'/>

My test blog, "Nitecruzr New Template Laboratory", is still published to "nitecruzrtestnew.blogspot.com".

<link href='http://nitecruzrtestnew.blogspot.com/' rel='canonical'/>

The "canonical" tag is essential for the country code domains.

These records are essential, for blogs published to "blogspot.com", now that Blogger is aliasing our blogs using country code TLD URLs.

My test blog, for instance, published to "nitecruzrtestnew.blogspot.com", will be accessed as "nitecruzrtestnew.blogspot.in" in India - but the search engines, which observe the Canonical tag, will still index any links as "nitecruzrtestnew.blogspot.com".

BlogSpot Published Blogs Being Accessed Using Country Code TLDs

Recently, some blog owners outside the USA have been asking about mysterious redirects which they (or their readers) are seeing, when accessing their blogs.

Why is "xxx.blogspot.com" now redirecting to "xxx.blogspot.com.au"?

and

Why was my blog address recently changed from ".com" to ".in"?

Blogger will host our blog content using country code relevant aliases, according to the unique laws of each different country.

The local country domain URL is determined using geolocation.

The relevant CC alias will be accessed automatically, according to the network location of the reader in question. These aliases are being added on a country by country basis, with Australia ("blogspot.com.au") and India ("blogspot.in") apparently recently deployed.

This will let Blogger remove content, that's illegal in one country, without having to remove that same content for all of your readers, worldwide. You benefit, because your blog won't go offline, for the entire world, when you publish something that's illegal in one single country.

A BlogSpot blog, with a standard header, will be indexed under "blogspot.com".

With any BlogSpot published blog containing a standard Blogger header, the blog will have a canonical reference to the "blogspot.com" alias. The search engines will index the blog, using the "blogspot.com" alias - even when following a country code specific link.

The search engine ranking of your blog won't be affected - except that a blog, left online in most countries, will get more traffic than one taken offline worldwide. When you check the Page Rank, you should continue to check the "blogspot.com" URL, because all search engine reputation will accumulate under the "blogspot.com" alias.

Owners of blogs with custom templates should check the template.

Owners of older or uniquely developed blogs, possibly using Classic or highly customised templates, may want to check the headers in their blogs, and make sure that they have a "canonical" tag referencing their "blogspot.com" alias.

Blogs published to non "blogspot.com" URLs, using properly setup and fully operational "custom domain" publishing, will not be affected - as the default "blogspot.com" URL is already redirected to the domain URL. While a newly purchased custom domain is "In Transition", the domain redirect will not be in effect - and the "blogspot.com" URL will be subject to CC alias redirect.

Any reader using a browser or computer that's affected by domain based filters will need to check all filters. Add "blogspot.com.au", "blogspot.in", "blogspot.jp", or any other relevant country, wherever "blogspot.com" is specified.

Note that geolocation will produce anomalies in odd cases.

Note that the redirect uses geolocation, to identify a relevant country code. Readers in small countries, or located near the border of other countries, may be using an ISP located in a different country, and may find their personal redirect reflecting the other country.

Any reader wishing to bypass the local alias can access a "no country redirect" alias using the URL of "blogspot.com/ncr". Similar to the "ncr" URL modifier used to bypass local language redirects of "blogger.com", this will give access to the U.S. English alias of the blog of your choice.