How To Unmap Google Sites To Solve "Another blog or Google Site is already using this address."

The literal cause of the error "Another blog or Google Site is already using this address." is that the Google Sites service is mapped to the address in question, in the Google domain services mapping database.

Some help articles published on the Internet imply that Sites mappings are the only cause of this error. This misconception creates some of the confusion associated with the error. Sites is not the only service in the services mapping database - but it is the only service with web address mappings.

The Sites service contains both service address, and web address, mappings - and both mappings can cause this problem. This oddity creates complexity, and makes a linear check list impossible, when using Google Apps to clear the error - as well as diagnosing the error, in a typical dialogue in Blogger Help Forum: Something Is Broken.

When the Sites service is suspected as the cause of "Another blog or Google Site is already using this address.", one must check both the Service Address Mapping, and the Web Address Mappings, in the Sites service.

Note that the presence of the mappings is not directly affected by the presence of the service wizards, on the desktop of the Google Apps account which you are using. Neither deleting the Apps account, nor uninstalling a given service wizard from the desktop, will immediately reset the mappings for that service, from the database.

If not present on the desktop, the Sites service must be first installed and activated, using the dashboard "Get more apps and services" link.

The Sites service address mapping, like all other services, can be examined and reset using the CustomURL form in Google Apps, as well as "Change URL" in the "General" tab, in the Sites Settings menu. The web address mappings can only be examined and reset using the "Web Address Mapping" tab, in the Sites Settings menu.

1. Select the "Web Address Mapping" tab, in the Sites Settings menu.
2. Select all addresses mapped, and click on "Delete Mapping(s)".
3. Click on "Yes" in the "Are you sure" popup.

If a Sites mapping is not the cause of your problem, Sites won't have a mapped address, in "Web Address Mapping". You will then need to check other settings, in Control Panel / Google Apps.

A Sites service address mapping, like other service address mappings, can sometimes be diagnosed in a simple "302 Moved Temporarily" redirect, in a typical HTTP trace.

Sending request:

GET / HTTP/1.1
Host: www.letthykingdomcome.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:18.0)
 Gecko/20100101 Firefox/18.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 74.125.129.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Content-Type:·text/html;·charset=UTF-8(CR)(LF)
Location:·http://sites.google.com/a/letthykingdomcome.com/
 sites/system/app/pages/meta/domainWelcome(CR)(LF)

A Sites web address mapping is not always so easy to diagnose - and may be the reason behind the fact that some HTTP traces end with the blog owner reporting "Another blog or Google Site is already using this address.", and an HTTP trace simply showing the generic 404 Not Found.

Sending request:

GET / HTTP/1.1
Host: www.markhamdesign.co.uk
User-Agent: Mozilla/5.0
 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 216.239.32.21
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·404·Not·Found(CR)(LF)

A Sites "Web Address Mapping" can include an address which is mapped outside Google Apps. This creates a mapping which can't be managed using Google Apps.

If you own a domain and have access to change the CNAME record, you can map any site created in Google Sites outside of Google Apps (for example, sites.google.com/site) to a custom URL

Sending request:

GET / HTTP/1.1
Host: www.medtechpedia.com
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Referer: http://www.rexswain.com/httpview.html
Connection: close

• Finding host IP address...
• Host IP address = 74.125.129.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:
HTTP/1.1·200·OK(CR)(LF)

<body·xmlns="http://www.google.com/ns/jotspot"·id="body"·class="·en············">(LF)
<script·src="//www.gstatic.com/caja/5246m/caja.js">·</script>(LF)
<script·src="http://www.gstatic.com/sites/p/926884/system/js/jot_caja.js">·</script>(LF)
<div·id="sites-page-toolbar"·class="sites-header-divider">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-status"·class="sites-status"·style="display:none;"><div·id="sites-notice"·class="sites-notice"·role="status"·aria-live="assertive">·</div></div>(LF)
</div>(LF)
<div·id="sites-chrome-everything-scrollbar">(LF)
<div·id="sites-chrome-everything">(LF)
<div·id="sites-chrome-page-wrapper"·style="direction:·ltr">(LF)
<div·id="sites-chrome-page-wrapper-inside">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-chrome-header-wrapper"·style="">(LF)
<table·id="sites-chrome-header"·class="sites-layout-hbox"·cellspacing="0"·style="">(LF)
<tr·class="sites-header-primary-row"·id="sites-chrome-userheader">(LF)
<td·id="sites-header-title"·class=""><div·class="sites-header-cell-buffer-wrapper"><h2>
  <a·href="http://sites.google.com/site/medtechpedia/"·dir="ltr"·id="sites-chrome-userheader-title">MedTechPedia</a></h2></div></td><td·class="sites-layout-searchbox·"><div·class="sites-header-cell-buffer-wrapper"><form·id="sites-searchbox-form"·action="/system/app/pages/search"><input·type="hidden"·id="sites-searchbox-scope"·name="scope"·value="search-site"·/><input·type="text"·id="jot-ui-searchInput"·name="q"·size="20"·value=""·aria-label="Search·this·site"·autocomplete="off"·/><div·id="sites-searchbox-button-set"·class="goog-inline-block"><div·role="button"·id="sites-searchbox-search-button"·class="goog-inline-block·jfk-button·jfk-button-standard"·tabindex="0">Search·this·site</div></div></form></div></td>(LF)
</tr>(LF)
<tr·class="sites-header-secondary-row"·id="sites-chrome-horizontal-nav">(LF)
<td·colspan="2"·id="sites-chrome-header-horizontal-nav-container">(LF)
<div·class="sites-header-nav"><ul·class="sites-header-nav-container-tabs"><li·class="current"><a·class="sites-navigation-link·current"·href="/home">Home</a></li><li·class="unselected"><a·class="sites-navigation-link·unselected"·href="/introduction-to-medical-technology">Introduction·to·Medical·Technology</a></li></ul><div·style="clear:·both;"></div></div>(LF)
</td>(LF)
</tr>(LF)
</table>·(LF)
</div>·

A Sites mapping won't always be present - but when it is, it's not difficult to solve - as long as you can access Google Apps aka "Control Panel".

Browser Cache, And Blogs Locked After Hacking

The effects of browser cache, upon our Internet life, are not always understood.

Most of us know, by now, to clear cache and restart the browser, after updating a blog, for consistent testing. Some folks know that blog security changes don't always take complete and immediate effect.

Recently, we're seeing a new effect, reported by owners of Blogger accounts locked, after hacking activity is detected.

I got a message mentioning suspicious account activity, when I logged in to Blogger. I provided my phone number, and I received a code on my phone, that I had to enter before I could then log in. My blog was working fine just after I logged in. A short while later, though, it was gone. Why was my blog deleted, because I unlocked my account?

This blog owner is just slightly confused, about the cause and effect here.

Google robotic processes are constantly monitoring account login activity, and watching for signs of hacking activity, such as brute force password entry.

Hacking Cannot Be Detected, Immediately.

When hacking is detected, the detection may not be immediate - so Google protects us by considering the possibility that the hacking could have been successful, and deletes or locks blogs owned by the account under attack. The blogs in question are taken offline, immediately, when hacking is detected.

When a blog is taken offline, blog content may be found in cache.

If a blog owner has just been working on a blog, as is frequently the case, the blog contents will be cached somewhere between the owner and the Blogger servers. Blogger can take the blogs offline, on their servers - but any cache containing the blogs will remain. If the blog owner is working on a blog while the Blogger account is under attack, what's in cache will remain, visible to the owner, until cache expires.

If a Blogger account is attacked, and the attack is detected, shortly after the owner has viewed a blog, what's in cache will be used, until it expires. The owner won't see the effects of the blog being deleted until the cache expires, and the browser tries to retrieve a fresh copy from the Blogger servers.

As cache expires later, the blog owner sees the blog go offline.

The blog owner sees the blog go offline shortly after he verifies account ownership, and thinks that the verification process caused the blog to go offline. In reality, the blog was taken offline before the owner even knew of "suspicious" account activity.

The blog owner has to wait, while the blogs are examined for hacker changes.

Now, the blog owner can do nothing, except wait until the account and the blogs are examined for signs of tampering. In some cases, no notification of progress will be received - and the owner will see the blog(s) returned to service, sometime later.

How much later the blogs return to service will vary widely, depending upon several details - and this variation, added to the uncertainty caused by cache latency, leads to mystery. And less attentive owners may take the delay as revenge, by Blogger, for their lack of attention to their blog(s).

---

Browser Cache, And Confusion About Blogs Locked After Suspected Account Hacking
Browser Cache, And Blogs Locked After Hacking

If You Moderate Comments Using Email, Mark The Spam Properly

One evidence of confusion, in Blogger Help Forum: Something Is Broken, comes from blog owners who are moderating comments, to their blogs, using comment moderation email.

I am constantly assailed by spam comments, being published to my blog, delivered to my Inbox! Is there anything I can do, about the spam, except just keep deleting?

Comment moderation, using email, offers several choices for action - but only one action will have any actual effect upon the spam.

When you moderate comments using email, and you are using comment moderation email - not comment notification email, you'll have the same choices for comment moderation, as when you use the Blogger dashboard wizard.

• Publish
• Delete
• Mark as spam

You'll have an additional choice, too.

• Moderate comments for this blog.

The latter choice gives you - when you are properly logged in to Blogger - quick access to the dashboard Comments wizard, to moderate from there.

As with using the dashboard wizard, the choice here is crucial. You need to mark spam comments as Spam. If you delete, the comment goes away - and nothing is done to train the spam filters. Spam comments, deleted, will simply let the spammer continue to annoy you.

With email messages, there are two more actions which some people take - and neither will do anything, directly, about comment spam.

• Some people will delete the email message - and this simply removes the email message, and the emailed copy of the spam, from the Inbox.
• Other people will use the "Spam" email mark. This selection is used to train the email comment filters - but it will only indirectly train the comment spam filters.

Neither deleting the email message, nor marking the email message as spam, will do anything about comment spam.

If you're looking at the comment notification email message, you'll have no comment moderation choices. Here, your only choice will be to delete the email message - if you're concerned with Inbox capacity. You can't moderate, using comment notification email.

Marking an email message, containing a spam comment, as spam - whether you are viewing the comment moderation or comment notification email message - accomplishes nothing. When you mark an email message as spam, you're reporting the sender of the email message. With comment moderation or comment notification email, marking an email message as spam reports the Blogger comment forwarding wizard - and this does nothing about the originator of the spam comment.

Use email to moderate comments, if you like. It's a convenient way to quickly moderate comments - and for some, more convenient than the Blogger dashboard. But make the right choices, when moderating.

>> Top

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.

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.

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".

How To Solve "Another blog or Google Site is already using this address."

Of all of the problems that are typically reported, in Blogger Help Forum: Something Is Broken, surely the most frustrating has to be

Another blog or Google Site is already using this address.

or possibly

Key already exists for domain ...

One of the reasons for the frustration is that this is not a descriptive error - it's more of a symptom - and this symptom has a number of causes. Since many Blogger blog owners don't understand the principles of problem solving, the solutions for this error may not be obvious.

The monolithic message "Another blog or Google Site is already using this address." is actually a symptom of a number of possible problems.

Some time ago, I identified three categories of problems, which cause the message to be displayed.

1. The URL in question is actually in use, with another blog already published to that domain URL.
2. The DNS addresses are improperly setup, and not pointing to the correct Google servers.
3. There are broken / duplicate pointers, which affect the domain, in the Google internal database.

Check For A Blog Already Published To The Address

If there is a blog already published to the URL, and you control both blogs, make a simple decision - which blog to publish, to the URL in question. If necessary, a second blog can be published to a different host in the domain, and setup a domain cluster. In some cases, a previous domain owner may have published a blog, which you won't control, to the domain.

Check The DNS Address Setup

Having eliminated or solved the possibility of multiple blogs, check and - if necessary - correct the DNS addresses setup for the domain. There are three DNS address models - with one, asymmetrical, being involved with over 99% of the blogs reported with this problem. There is simply no alternative to "CNAME" forwarding, when publishing a blog to a custom domain.

Check For Service Redirections

With the DNS addresses corrected - and DNS propagation latency allowed for - diagnose the problem using a series of HTTP traces. Here, we'll generally see a number of possible redirections.

1. Calendar.
2. Drive and Docs.
3. Email.
4. Sites.
5. Start Page.

If the HTTP traces do not indicate a specific service, you may have an indeterminate case of database corruption.

When dealing with service redirections, start by establishing access to the Google Apps domain administrator desktop. If the domain was purchased in 2013 or later, you'll have use of a basic function Apps account. You'll use two Apps desktop wizards - "Organization & users" and "Settings".

1. Use "Organization & users", to install and activate any service.
2. Use "Settings" to disable mappings, and to uninstall any service.

Named Service Redirection

For a named service redirection:

1. If necessary, install and activate the service.
2. Delete the mappings for the service.
3. Uninstall the service.

Database Corruption Or Unknown Service Redirection

If a specific service is not identified in the HTTP traces, check the "Change URLs for multiple services" display, which is accessible from any "Change URL" service wizard.

1. Select any service, in the "Settings" wizard, and the "Change URL" link for that service.
2. Click on "Change URLs for all domain services".
3. Examine the "Change URLs for multiple services" display, and select the custom mapping, for any service with the default mapping (top) address selected. If any service entry is changed, click "Continue".
4. For each service with mapping which was just changed:
   • If necessary, install and activate the service.
   • Uninstall the service.

Just read about the details, take it one step at a time - and allow time to complete the entire task, carefully.

>> Top

How To Use Google Apps To Solve "Another blog or Google Site is already using this address."

The Google domain services database lets one or more Blogger blogs, and / or various Google services, be packaged as part of a domain - giving your organisation its own virtual web server.

Google Apps is used to manage this virtual web server, as you install and un install various domain services. Sometimes a domain, newly setup in Google after the domain has been purchased from a registrar, will have one or more addresses unexpectedly mapped to various Google services. This will be inconvenient to the blog owner, who may wish to use a given URL for a Blogger blog.

The most common cause of the error "Another blog or Google Site is already using this address." involves unexpected mappings, in the Google domain database.

When your domain has unwanted mappings, you'll need to use the Google Apps domain administrator desktop, and various utilities there, to remove the mappings and reset the services. To start, you'll need access to the Google Apps desktop for the domain administrator. For domains recently purchased using Blogger or Google wizards, you'll have a limited function domain administrator desktop.

You'll use two Apps desktop wizards - "Organization & users" and "Settings".

• Use "Organization & users", to install and activate a service.
• Use "Settings" to disable / remove mappings, and to disable / uninstall a service.

Install And Activate Services

Use "Organization & users" - "Services", to activate the various services.

• To install a service, click on "Dashboard", find "Common tasks" at the bottom left, and click on "Get more apps and services". Click on "Add it now", for the needed service.
• To activate a service, go to "Organization & users" - "Services", and look under "Core Google Services" or "Additional Services", for the service in question - and click on the coloured toggle switch as necessary. Then click on "Save changes".

Remove Mappings

Use the Settings wizard, for the service in question - to add and remove address mappings, and to deactivate services. Each different service, listed in Settings, has a different set of menus, and different options.

We currently know of 5 services which can be mapped to a domain, which may interfere with publication of a Blogger blog to a domain address. Any problem service, currently mapped to the default (top) address, will need to be changed to map to the custom (bottom) address.

1. Calendar.
2. Drive and Docs.
3. Email.
4. Sites.
5. Start Page.

To remove address mappings for Calendar:

1. Click on "Calendar", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Calender mapping, remember to uninstall Calender.

To remove address mappings for Drive and Docs:

1. Click on "Drive and Docs", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Drive and Docs mapping, remember to uninstall Drive and Docs.

To remove address mappings for Email:

1. Click on "Email", then the "General Settings" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Email mapping, remember to uninstall Email.

To remove address mappings for Sites, some extra effort may be required:

1. Click on "Sites", then the "General" tab, then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. Select the "Web Address Mapping" tab.
4. Select all addresses mapped, and click on "Delete Mapping(s)".
5. Some Sites mappings can only be diagnosed, and reset, outside Google Apps.
6. If you change any Sites mapping, remember to uninstall Sites.

To remove address mappings for Start Page:

1. Click on "Start Page", then "Change URL" for "Web address".
2. If necessary, select the custom mapping (bottom) address, and click "Continue".
3. If you change the Start Page mapping, remember to uninstall Start Page.

The CustomURL Wizard

Besides the multiple Sites mappings (in "Web Address Mapping"), it may be possible to use the "CustomURL" wizard, which will list all active services and current mappings. The CustomURL wizard is accessed from any "Change URL" wizard.

1. Click on "Change URLs for all domain services".
2. Examine the "Change URLs for multiple services" display, and disable any references to the default mapping. Select the custom mapping (bottom) address, for any service with the default mapping (top) address selected. If any service entry was changed, click "Continue".
3. For each service with mapping which was changed:
   • If necessary, install and activate the service.
   • Uninstall the service.

Disable / Uninstall Services After Changing Mapping

If you did change or delete any mappings, whether using CustomURL ("Change URLs for multiple services") or an individual service wizard ("Change URL" / "Web Address Mapping"), the final step is to disable or uninstall each service for which you changed or deleted mappings. If you do intend to use any named service, re install it later - after you get your custom domain working.

To uninstall Calendar, click on "Calendar", then the "General" tab. Click on "Uninstall Calendar", next to "Uninstall service".

To uninstall Drive and Docs, click on "Drive and Docs", then the "General" tab. Click on "Uninstall Drive and Docs", next to "Uninstall service".

To uninstall Email, click on "Email", then the "General Settings" tab. Click on "Uninstall Email", next to "Uninstall service".

To uninstall Sites, click on "Sites", then the "General" tab. Click on "Uninstall Sites", next to "Uninstall service".

To disable Start Page, click on "Start Page", then on "Disable Start Page", next to "Disable service".

Control The Email Settings, Relevant To Your Blog

Some blog owners don't always think about the various email settings, which are part of their Blogger blogs, and the possible effects to their email - or somebody else's email.

There are several settings, where a blog owner may enter an email address.

• Email posts to
• Comment Moderation.
• Comment Notification Email.

These settings don't require acceptance by the recipient, making for some interesting possibilities for causing problems in other people's email, as well as one's own email.

There are several Blogger dashboard settings - related to post publication and to various commenting activities - with differing effect to one's own, or somebody else's, email.

• Settings - "Mobile and email" - "Email posts to" - aka "BlogSend" - generates a minimally formatted text copy of each post, when published, to up to 10 email addresses.
• Settings - "Posts and comments" - "Comment Moderation" generates a minimally formatted copy of each incoming comment, before the comment is published - and allows moderation of the comment, while reading the email message - when the recipient has the proper authority.
• Settings - "Mobile and email" - "Comment Notification Email" generates a minimally formatted copy of each incoming comment, before the comment is published or rejected.

Since none of these settings require acceptance by the recipient, there are various possibilities for causing interesting email delivery.

Unlike various subscription services which use email, such as a FeedBurner Email Subscription service, an email address added to any of these three settings requires no formal acceptance. If a blog administrator should add an email address, whether their own (primary or additional personal email address), a willing friend or relative, or an unknown victim's address, there is no initial email sent to the recipient

You (or somebody else) has added this email address as a recipient of "Email posts to" / "Comment Moderation" / "Comment Notification Email". Do you approve of this additional traffic source to your email service?

or a similarly worded notification / approval. Given a clueless or malicious blog owner, it's possible that one (or all) of these settings could be used to harass an unwitting third party, or to (unwittingly) confuse oneself.

The "Email posts to" feature, also known as "BlogSend", generates a minimally formatted text copy of each post, when published, to up to 10 email addresses. This setting has been used, in the past, to provide distribution of newly published posts for private blogs, as well as a simple distribution for posts from public blogs.

Since it's limited to 10 entries, BlogSend does not provide a suitable service for any blog with a reader population of any appreciable size. For a blog owner with any technical experience, FeedBurner Email Distribution is a much better solution for post distribution - when the blog in question is publicly accessible.

For distribution of a private blog to more than 10 readers, one may use Google+.

The "Comment Moderation" and "Comment Notification Email" settings, used together, can generate interesting duplication of email to one's own (or somebody else's) email service. If these settings are made without thinking, some interesting confusion can result. Email addresses can be added to each of these settings without consideration of the relationship or level of authority enjoyed by the owner of the email address, relative to the blog in question.

Comment Moderation Email is presumed to generally be a function performed by blog administrators - but email resulting from this setting will be sent to anybody addressed. A blog administrator / member - or other non administrator of the blog or an unwitting stranger - will receive email suggesting several options,

Publish
Delete
Mark as spam
Moderate comments for this blog.

If the recipient is not an actual blog administrator, the links in the email provide confusion, and no result.

Comment Notification Email might be generally addressed to blog members - but is not necessarily limited. Since notification of comments is sent separately from moderation, recipients of a notification can become confused when they fail to find the comment, mentioned in the notification, present on the blog.

A blog administrator, using either an email moderation message - or using the blog Comments wizard, may or may not decide to Publish - or to designate a comment as Spam - regardless of a notification message having been delivered to each designated recipient.

Comment notification email may look similar to comment moderation email, less the comment processing options - possibly causing more confusion. A blog owner, adding his own email address to both comment moderation and comment notification, may see the combination as unknown duplication. And blog owners may confuse the proper use of comment moderation and comment notification email.

A blog owner, transferring ownership of a given blog, may overlook updating of the email settings. A new blog owner, receiving a blog being transferred, may likewise overlook these settings, and may lack the associated email, until the omission is corrected.

Either the previous owner, or the new owner, may be confused temporarily - and may wonder why they are still getting email / not getting email, until they examine and correct the setting in question. Alternately, if someone's email address was added maliciously, by a blog owner intending to harass somebody, one can see interesting possibility for conflict.

Blog Owners, Logging In To Blogger, Receiving Malware Warnings

We've been seeing a few problem reports, in Blogger Help Forum: Something Is Broken, from blog owners seeing malware warnings for unknown blogs or websites.

I get a warning from Google Chrome, when I login to Blogger.

Content from www.unknownblog.com, a known malware distributor, has been inserted into this web page. Visiting this page now is very likely to infect your computer with malware.

We know that our blogs are subject to malware and spam classification - but now we see that we can also get warnings for other blogs and websites, that we don't own.

A blog owner, seeing this warning when logging in, will probably find the source of the problem in the Reading List, where content from other people's blogs is routinely found. In some cases, the problem will be in blogs that are intentionally Followed, and blatantly contain malware - and in other cases, blogs that are intentionally Followed may be redirecting the post feed, in a vain attempt to extend their reader base.

In either case, the only solution is to identify the problem blog or website, by examining each individual Reading List entry, one by one, until the noted blog or website is found - then discontinue Following the problem blog or website.

One mysterious scenario can involve blogs using favicons which are detected as malicious, by image scanning malware protection - or which are hosted from a domain which is known for malicious activity. Favicons, tiny icons which represent a blog or website, are used to decorate blog headers and feed gadgets, and are sometimes served by third party services. A "malicious" favicon may be found on entries in the Reading List, or on entries in a bloglist, which will then affect our readers ability to view our blogs.

The bottom line here is that we are responsible for the content of the blogs and websites which we link to from our blogs - and which we Follow - as well as the content on our own blogs.

>> Top

When You Publish Your Blog To A Custom Domain, Almost Always Publish To The "www" Alias

Of all of the known problems with Blogger, in general - and of the known problems with Blogger / Google Custom Domain Publishing, specifically - surely the most frustrating single problem starts with the well known monolithic error

Another blog or Google Site is already using this address.

The most frequently seen solution to this problem, contrary to the opinions expressed in some blogs and websites, starts with correction of the domain DNS addresses. But even after careful DNS address correction, some blog owners still report the well known "Another blog ..." error.

Maybe 99.99% of the custom domain published blogs use what I call an asymmetrical DNS address configuration.

mydomain.com. 3600 IN A 216.239.32.21
mydomain.com. 3600 IN A 216.239.34.21
mydomain.com. 3600 IN A 216.239.36.21
mydomain.com. 3600 IN A 216.239.38.21
www.mydomain.com. 3600 IN CNAME ghs.google.com.

Note the restriction with the asymmetrical configuration, sometimes overlooked.

With an asymmetrical configuration, you may not publish to the domain root. Your only valid choice is to publish to "www.mydomain.com", and select "Redirect mydomain.com to www.mydomain.com". If you publish to "mydomain.com", you will eventually see

Blogs may not be hosted at naked domains.

or maybe a well known monolithic error

Another blog or Google Site is already using this address.

The conclusion is simple. Unless you intentionally created a symmetrical or non root virtual host address configuration, always publish to the "www" host. And, even though you do publish to the "www" host, understand that righteous addressing of the domain root is a necessity - not an option.

>> Top

When You Create A Blog, Only Type The Blog Name!

Too many would be blog owners are unable to create a blog, because they don't understand how to check for availability.

I can't seem to type in a URL, without it saying it's not available.

Some people don't understand that you do not type a URL - you just type a blog name, when checking for availability.

This is the (BlogSpot) URL of this blog.

http://bloggerstatusforreal.blogspot.com

This is the (BlogSpot) name of this blog.

bloggerstatusforreal

If I was going to use the "Create a blog" wizard, and create this blog, I would type the name - "bloggerstatusforreal".

If I typed the entire URL "http://bloggerstatusforreal.blogspot.com" - even if "bloggerstatusforreal" was available (and no, it is not ever going to be available), I should expect to see

Sorry, this blog address is not available.

or

This blog address is invalid or not supported.

It's that simple - only type the name, to create a blog. And - only create a blog once - then spend your time creating "New Posts".

Deleted / Locked Blogs Have Several Causes

Many blog owners are occasionally confused, by the effects of various Blogger / Google security processes.

We see the agony, daily, in Blogger Help Forum: Something Is Broken, from those who only want to login to Blogger and work on their blogs.

The side effects of the security processes are similar - and depending upon various owner specific details, can be easily confused for each other. The possibility of confusion requires careful initial analysis, when we are faced with an angry blog owner.

My blog was deleted, by Blogger. How could they do this? I do not publish spam!

This is a typical problem report, which can reflect any one of the processes, each requiring different action in the forums.

There are multiple Blogger / Google security / TOS enforcement processes, which encourage observance of various Blogger / Google requirements.

Each process may cause a Blogger account and / or blog to be unavailable for public access, at any time.

• DMCA Violation looks for copyright and similar violations.
• Hacking detection looks for automated attacks against our Blogger accounts and blogs.
• Malware detection looks for malicious code installed in our Blogger blogs.
• Porn classification looks for blogs with adult content, and with unacceptable advertisements (aka monetised porn).
• Spam blog classification looks for Blogger blogs which contain spammy material or use spammy techniques.
• Repeated offenses can have gradually increasing severity of action taken.
• Owner deletion or rename may be confused with spam classification.
• Team blog ownership will affect blogs owned in common, by that team.

Each different process has a different effect on the Blogger account and blogs owned - and requires different attention by the blog owners, by the forum helpers, and by Blogger Support and Google Security. Not all blogs will be listed in the "Deleted blogs" dashboard inventory.

DMCA Violation

Accounts and blogs can be deleted, for progressive DMCA violations. The DMCA violation process originated with complaints made by the major entertainment industry content enforcement organisations, citing theft of "intellectual property" which they control.

In the USA, this would involve the "MPAA" (Motion Picture Association of America), and the "RIAA" (Recording Industry Association of America). I have been told that similar content enforcement organisations exist in other countries.

In more recent events, private citizens have been known to use the DMCA Violation complaint process, for miscellaneous copyright violation reporting. DMCA Violations have a formal complaint and appeal process.

Hacking detection

Blogger / Google network monitors are constantly analysing account login activity, and looking for signs of brute force password hacking.

When hacking activity is discovered, the Blogger account - and all blogs owned by the account - are deleted and locked, pending account verification by the owner, and blog integrity checking by Google Security.

The blog owner, after changing the account password, solving a CAPTCHA, and / or verifying account ownership by providing various personal details, is left waiting for the blogs owned by the account to be examined for signs of abuse by the hacker.

Until the blog(s) are returned to online status, they appear in neither the "Deleted blogs" or "Locked blogs" dashboard lists. The owner, even when logged in to the right Blogger account, simply sees the dashboard advice

You are not an author on any blogs.

In this case, neither the blog owner nor the forum helpers can do anything useful, except wait, anxiously - possibly, with no notice provided. The blog being offline may not be immediately observed by the owner - and this may cause more confusion.

Malware detection

Blogger robotic processes are constantly checking the various blogs, looking for malicious blog accessories, components, and scripts. When a blog is subject to "Malware" classification, the blog will appear in one of two dashboard lists, in sequence.

1. Initially, the blog will appear in the "Deleted blogs" list. While the blog is in "Deleted" status, the blog owner will be able to do nothing, except request "Restore".
2. Once the owner has requested "Restore", the blog is undeleted, and placed into the "Locked blogs" list. While the blog is in "Locked" status, all authors can access the blog to remove malware - but the blog remains offline, to all viewers. Once all malware has been removed from the blog, the owner can "Request Unlock Review".

If the blog remains in "Locked" status for over 48 hours, the blog owner may report this in the forums, and may request a manual review. The forum helpers, and online viewers, will generally see the blog displayed as "TOS violation".

This blog is in violation of Blogger Terms of Service and is open to authors only

Adult Content / Porn Detection

Blogger will soon classify and delete blogs with "adult content", which host advertisements to commercial porn sites. Like spam classification, this will probably involve both false negatives and false positives.

Spam detection

Blogger robotic processes are constantly checking the various blogs, looking for signs of spam activity and content. When a blog is subject to "Spam" classification, the blog will be displayed in the "Deleted blogs" dashboard list.

The owner can do nothing, except request "Restore". If the blog remains in "Deleted" status for over 48 hours, the blog owner may report this in the forums, and may request a manual review. The forum helpers, and online viewers, will generally see the blog displayed as "Removed".

Blog has been removed Sorry, the blog at xxxxxxx.blogspot.com has been removed. This address is not available for new blogs.

Repeated Offenses

We have recently noted that repeated TOS Violations, involving DMCA, Malware, Porn, and Spam, are being dealt with in increasing severity.

Owner deletion or rename

Mistakes made by the owner can be confused with Spam detection. When a blog is deleted by the owner, it will appear in the dashboard "Deleted blogs" list for up to 90 days.

During the 90 days, the owner (or a team member, when applicable) may "Restore" the blog. After the 90 days expire, the blog will be removed from "Deleted blogs", and will be unrecoverable. Besides being unrecoverable, no other details have been determined.

If the blog is renamed (published under a different BlogSpot URL), the external symptom may be similar to deletion by the owner.

Blog has been removed Sorry, the blog at myblog.blogspot.com has been removed. This address is not available for new blogs.

In this case, the blog will be listed in the dashboard "My blogs" list, under the right Title. The owner needs to setup a stub blog, pointing the readers to the new URL.

Team Ownership

Any blogs owned by a deleted / locked Blogger account may simply disappear from the dashboards of other team members. If the Blogger account is not restored / unlocked, the blogs owned by that account - including any team owned blogs - may remain deleted - and inaccessible to everybody.

The Confusion Accumulates

Because of anonymous blog ownership, loss of account control, team blog ownership, and use of inactive or non existent email addresses, any account / blog which is deleted or locked for hacking (actively / as a victim), malware, and / or spam may not be easily discovered or recovered by the owner.

And, not all scenarios can be easily diagnosed. Besides the deleted blogs, there are blogs that remain online - but have still disappeared from the dashboard of the owner.

All of these issues cause further confusion and frustration.

These scenarios may appear, to the untrained eye, to be signs of fraudulent, malicious, and / or petty actions by Blogger - and are loudly claimed so by spammers with their own agenda. None of these accusations are true - the above processes simply represent Blogger and Google attempting, in the best possible way, to protect everybody against the various hacking, malware, porn, and spam attacks which are constantly in progress.

Without The PostID, A Deleted Post Is Not Easily Recovered

If you delete a post (page) in your blog, it's a simple matter to recover the post - as long as you know the PostID. Unfortunately, once the post is gone, finding the post (page) id is not a simple matter - especially for those who would typically delete a page or post without planning. Blogger does not provide the PostID in any list, that we might save, periodically, to reference later.

The task of retrieving a deleted page or post is particularly frustrating, for owners of private blogs. Private blogs probably won't be cached, nor do they publish a blog feed - and without either a cache entry, or a feed reference, the PostID for a deleted post is not easily obtained.

Right now, once you delete a page or post, in a private blog, you're out of luck - unless you have cached the blog on your own computer. Retrieving from local cache is not an issue to be productively discussed in Blogger Support, as it is going to be as individual as your computer may be.

>> Top

"Nice Blog" Spam Is Recently Becoming More Obscure, In Content And Style

In 2009, we discovered an odd style of spam comments which, from all appearances, served no purpose.

I recently came across your blog, and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

When discovered, Google Search suggested that over 22,000,000 copies of these comments had been successfully installed, on various blogs and websites.

A couple years ago, I suggested a possible reason for the spam - and later showed how Google+, and various Blogger security measures, were making the spam less useful.

Last month, we began to see suggestions, from some blog owners, that this "nice blog" spam was morphing, into more obscurely phrased and structured styles.

A lot of spam comments are being published on my blog. This problem started a few weeks ago - though previously, Google almost always put them in my Spam Folder.

Upon examination of examples of the spam comments, we see the same spam style as observed in 2009 - yet more imaginatively phrased.

Today, I spent a couple hours, and scanned through the comments queues on this blog. Both the Awaiting, and Spam, folders yielded some interesting specimens.

This topic is very educational and it took my interest. Hope it will always be alive! And provide productive information to many others.

and

Nice post. I learn something new and challenging on websites I stumble upon every day. It's always interesting to read articles from other writers and practice a little something from other sites.

These were the comment bodies of just two examples which I located - and these resemble others identified by various other blog owners.

The bodies of the comments examined, this week, will sometimes contain embedded links, while other examples will have external links - and some comments seem to contain no links at all, to any payload. The only thing consistent about the comments is their vague and apparently pointless nature.

The comments are both large in volume, and varied in content and structure. Both patience and persistence, from every blog owner moderating the spam, is required. The spam filters must be trained, to recognise the new content and structures - and this will require more effort, from everybody seeing the spam.

Since various reports about the spam have been seen recently, in Blogger Help Forum: Something Is Broken, we added a rollup discussion there, where we are requesting minimally organised details about the comments being observed.

• Are you moderating before, or after publishing?
• What's the average amount of time the spam comment sits in "Awaiting" or "Published", before being moved to "Spam"?
• How often do you check "Awaiting" and "Published", looking for more spam comments?
• How often do you check "Spam", looking for non spam comments?
• How many spam comments do you typically dispatch, in each batch?
• Looking objectively in your personal "Awaiting", "Published", and "Spam" folders, what number of this style of comments do you typically see in each, without your intervention?
• When did you first observe this threat, in your comment folders?

As always, please help here by answering as carefully and completely as possible - and please only post relevant replies. Do not turn the rollup discussion into a chat room.

>> Top

A Blog Deleted, As A Suspected Spam Host, Is Not Subject To The 90 Day Limit For Restore

We see signs of panic, periodically, in Blogger Help Forum: Something Is Broken, about blogs deleted as suspected spam hosts.

My blog was deleted for spam 2 months ago. I need my blog restored, this month, as I don't want to lose it!

This is a common misconception, about spam deletions, and the mysterious 90 day limit.

There's no deadline for either the start, or the completion, of the review process, when a blog is classified as a suspected spam host. The owner may request review a year after the blog is deleted - if he's willing to wait for a year without concern. Alternately, he may ask for review the same day that he discovers the blog is offline. When the review is requested, Blogger Support may be immediately available, and may return a blog to service that same day - or they may be busy, and require a month to respond.

When the blog does get reviewed, the rules are simple.

• If the blog is judged to be righteously classified, the blog is deleted, with the URL locked to the deleted blog.
• If the blog is judged to be spuriously classified, the blog is restored, and control is returned to the owner.

In either case, the URL is not made available to the public.

This is either good news (if you are the owner), or bad news (if you wish that you were the owner).

You cannot gain control of the blog, or of the URL, by reporting the blog as a spam host - whether the blog has 1 post (one post published 10 years ago), or 3650 posts (one post published daily, for 10 years). If the blog appears to be inactive, your only option is to contact the owner, directly. If Blogger classifies an inactive blog, following your reporting the blog as a spam host, the blog will remain deleted or locked, until the owner requests review.

If the owner deletes the blog, the URL may - or may not - be made available.

Pick an available URL, and start your blog - and concentrate on the interests of your readers.

>> Top

Check Your Template, And Look For Unfamiliar JavaScript Code, Following Odd Blog Behaviour

Recently, we've been seeing some odd problem reports in Blogger Help Forum: Something Is Broken, suggesting deviously hijacked blogs.

My blog is requesting me to login, using a user name and password, when I view it.

Given the URL of the window requesting the login, it's a simple matter for us to use the right forensic Internet software, and to locate a relevant snippet of code, frequently installed as part of the blog template.

Sometimes, when we reply to the blog owner with advice to remove a bit of dodgy code, we get a response suggesting disbelief. Our advice

Use the Template Editor, and remove the highlighted code snippet.

may receive a confused or skeptical response.

Where did that bit of code come from? I never installed that!

How did the code in question get installed? Discussion of one possible scenario may require thinking outside the box. Not every unrecognised blog change is being caused by memory loss by the blog owner, after an intentional accessory install or template tweak.

Looking at the subject / theme of some blogs involved in recent problem reports, we're seeing a beginning of a trend, which may indicate a new - and very subtle - blog hijacking technique. We know that Blogger blogs are subjected to brute force password guessing attacks, and we know that Blogger / Google has to consider the possibility that a brute force attack detection is made after the attack was successful.

Current blog security, and defense against blog hijacks, involves detection of hijack attempts, by Google Security. It's possible that some blogs, with some owning Blogger accounts and passwords, are more vulnerable to sophisticated password guess hacking.

When you login to Blogger or Google, you hopefully know the right account name and password, and are generally able to get logged in - after maybe one or two mistakes. You learn, soon enough, that if you have to guess your account name or current password - and you require more than a couple tries - you may have to solve yet another CAPTCHA, or request account unlock, to continue.

The ever unpopular CAPTCHA / locked account comes from Google, detecting a possible brute force attack in progress, and protecting your account and your blogs. A Blogger blog, with its content providing enough clues, combined with a simple account password that is easily guessed, may allow an experienced hacker to login to your account in one or two tries, without being detected by Google attack monitors.

It's alternately possible that some attacks are being conducted by very patient hackers, who are able to use days, and / or thousands of different computers, to conduct a throttled brute force password attack. Again, just attack without providing a detectable pattern.

This may help to explain the mysterious spam blog setups, of last year.

A hacker, able to login to a Blogger account without being detected, could install small changes in a blog template without ever being discovered. The blog owner would never discover subtle template changes, made by an easily satisfied hacker.

Finally, install latent code that does not activate immediately, as we observed during Winter 2009 / 2010, so no blogs show symptoms until the hack is installed on thousands of blogs. If one or two blog owners discover the odd code in their blogs, who would ever suspect their blog being part of a massive cloud of victims?

If you report odd behaviour by your blog, you write to Blogger Help requesting advice, and you are advised to remove a bit of dodgy code from the template - and you do not remember having installed the noted dodgy code - you may want to review your Blogger / Google password, and make the password harder to guess. Better still, start using 2-step verification for logging in to your Blogger / Google account.

>> Top

How You Should Backup Your Blog Will Depend Upon How You Plan To Restore It

We see signs of naivete, in Blogger Help Forum: How Do I?, from blog owners concerned with malware / spam deletions, and with other unexplained disasters in Blogger.

How do I backup my blog, to protect the contents against unfair spam deletions?

Not many concerned blog owners realise the first principle of backups, known by any experienced network administrator.

• Never plan a backup, without first planning the restore.

How you backup your blog depends upon several details.

• What problem do you expect, to require a backup?
• How do you plan to recover, from a problem?

One of the simplest solutions for a backup, which some Blogger experts will suggest, is to use the Export / Import wizard, in Settings - Other.

• Before disaster strikes, Export your posts and comments.
• After disaster strikes, simply Import your posts and comments, from a convenient backup.

Besides backing up comments and posts, backup the template.

Similarly, some experts may suggest backing up the template.

• Before disaster strikes, use the dashboard Template "Backup / Restore" wizard, to backup the template.
• After disaster strikes, use the wizard to restore the template.

But consider other components, too.

There are many components of a Blogger blog - not just the comments, posts, and template.

• Accessories.
• Comments.
• Decorations.
• Gadgets.
• Posts.
• Layout.
• URL.

Before you plan how to backup your blog, you need to decide which of these features is most important to you, and what problem from which you wish to recover.

Backing up accessories right now is not so easily done.

The accessories (decorations, gadgets) is one component of the blog which is most frequently missed, after a deleted blog is recreated / restored using a "comments / posts / template backup" restore strategy. Both graphic decorations, and XML based gadgets, may not be easily backed up, and may present a challenge when the blog is restored, or recreated.

XML gadgets, such as bloglists and linklists, may contain a lot of detail, which is installed into the blog one entry at a time - and there is no known way to automate a backup or restore of these gadgets.

The URL cannot be recovered, by creating or restoring.

Recovering the URL is one of the most subtle details, that may not always be considered by many blog owners. The URL is relevant in two ways. Most blogs which are important enough, for the owner to want to backup, have acquired reputation - both with people (readers, subscribers, and viewers), and with search engines.

Some blogs will link the various posts to each other - as I do with this blog. In either case, the recovered blog is not as useful, unless the URL is also recovered.

If the blog is deleted, the URL may not be recoverable.

If the blog is deleted by Blogger - or by the owner - the URL may not be available, for blog recovery. When Blogger deletes a blog as a suspected abusive content host, the URL is locked to the blog. The only way to recover the URL is to have the blog reviewed, and restored to availability.

When a blog is deleted by the owner, the blog must be restored by the owner - within 90 days after deletion. In either case, a backup is useless.

If you have a personal blog, containing just posts (and maybe comments from known family or friends), backing up the comments and posts makes sense. For a publicly known blog, containing various accessories, and having a known URL, you'll want to plan your backup / restore strategy using a bit more effort.