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.

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>·

>> Top

What Is This New "CNAME", Anyway?

Ever since Blogger finally restored the custom domain publishing feature, blog owners have been asking about the addition to the domain setup process - the new "CNAME".

Do I really need this? My old blogs don't have it, and they are fine.

and

My registrar won't let me add a second "CNAME" - they allow one "CNAME" / domain (my "www").

and

My registrar won't allow long addresses, such as what you have for "Destination" / "Target" / "Points To".

And we are learning that this requirement is going to be a problem for blog owners using some registrars, who can't provide this "CNAME" in their customers domains.

When we started out 3 days ago, all that we had to reference was an example setup document. As the problems were diagnosed and resolved, some blog owners were able to contribute what they had learned. Those insights I added to my FAQ, Why is my domain still in "12" / "404" State? Blogger Support later contributed a simple Guide, Custom Domain and CNAME setup.

In technical terms, the new "CNAME" is an ownership certificate, provided in a one way encryption. If you have WiFi in your home (likely) - and are using encryption (hopefully), you have a similar one way encrypted certificate - the WPA / WPA2 key / passphrase. For an allegorical (easy to read) discussion about certificate encryption, see Designing an Authentication System.

Only you, the blog owner (and anybody who you trust, on your behalf), are able to install the certificate for your domain, into your domain DNS addresses. This helps Blogger help you keep your domain under your control - as long as you pay the yearly registration fee for your domain.

The domain ownership certificate has 3 keys.

1. A private key, which Blogger appears to change regularly (some say daily) - and one which they control.
2. The BlogSpot URL.
3. The domain URL (entered in "Advanced settings").

It has two significant values.

1. "Name" / "Label" / "Host". This is now known as the "short token".
2. "Destination" / "Target" / "Points To". This is now known as the "long token".

Note the three labels used to identify each "value" - which reflect the diversity of the registrars which may provide DNS hosting for our domains (when they are able to fulfill our specific needs). When you look at the Domain Manager wizard for your domain, you may see any of the three (possibly, others) used - as there is no authoritative label for these two DNS address components.

Let's look at the two "CNAME"s, together, so you can compare the similar structure.

This is the first "CNAME" - the "www" alias DNS address. This "CNAME" is identical for all Blogger blogs, using the asymmetrical DNS address convention.

1. "Name" / "Label" / "Host". www
2. "Destination" / "Target" / "Points To". ghs.google.com

This is the second "CNAME" - the domain ownership certificate. This "CNAME" will vary, for each different domain. Here we see the original example (which has since changed).

1. The "short token". vptre6sub6jm
2. The "long token". gv-g47p6dir6kfenzufifywsqjjpdyfzk4sqmuuiuflylcqd4oigdfa.domainverify.googlehosted.com

See the final period, at the end of the "Destination" / "Target" / "Points To" address, below? It's not in the example, above. Be very careful here, some registrar's will automatically insert the "." for you - and if you insert it also, you'll have a problem. Other registrars will need you to add it - and if omitted, you'll have a problem. Regardless, its presence, in the final product, is essential.

gv-g47p6dir6kfenzufifywsqjjpdyfzk4sqmuuiuflylcqd4oigdfa.domainverify.googlehosted.com.

If you know the value for the short token, you can Dig and extract the long token - when the second "CNAME" is properly setup.

Once you provide the above examples to the Domain Manager, the following two DNS addresses are generated and added to the domain server. The "3600" represents the TTL, a setting provided by the registrar. The "IN" is part of the Dig log extract syntax.

www.mydomain.com. 3600 IN CNAME ghs.google.com.

and

vptre6sub6jm.mydomain.com. 3600 IN CNAME gv-g47p6dir6kfenzufifywsqjjpdyfzk4sqmuuiuflylcqd4oigdfa.domainverify.googlehosted.com.

Both "CNAME"s point to specific Google servers. The second "CNAME" is only slightly obscure. Both "CNAME"s are essential.

1. The first lets you, and your readers, view your blog.
2. The second lets Google verify that you own the domain, and you should be allowed to publish your blog to the domain URL.

Nobody but you, the blog owner, will ever know the values of the tokens. Nobody but you, the domain owner, can install that "CNAME" into the domain DNS addresses. If DNS resolution of the short token address points back to the right Google server, then you, the owner of the blog, and the owner of the domain are verified as the same person. And the ownership certificate is "decrypted", using DNS name resolution.

• Short token. vptre6sub6jm
• Long token. gv-g47p6dir6kfenzufifywsqjjpdyfzk4sqmuuiuflylcqd4oigdfa.domainverify.googlehosted.com

Since the private Blogger key changes regularly, if anybody learns what tokens you used, in the short 3 step domain verification process, the values will have likely changed, and their time will have been wasted. Your blog and domain remain your blog and domain.

So, do the necessary. Blogger provides instructions, specific for 7 known registrars - and a general purpose instruction for others, in Google Help: Create a CNAME record for my custom domain. If their instructions conflict too much with your reality, try setting up third party DNS hosting.

1. Get the short token and long token values, for your unique blog / domain.
2. Add the new "CNAME" to your domain.
3. Publish the blog to the domain URL.

That's it (subject to observed timing issues). You are now done with the domain ownership verification process, and with these encrypted values. Start planning the migration - this will happen faster than you think. And it is your responsibility, to get this done.

>> Top

Custom Domain Publishing Is Back - And With A New Detail

After a very stressful week, Blogger Engineering has restored the custom domain publishing option.

Last week we encountered an issue that could affect Blogger users in the process of configuring a custom domain, during the verification of ownership of domains between the provider and Blogger. Blogs with previously configured custom domains were not affected.

With the reason for disabling custom domain publishing being security, Blogger Engineering has added a step in the publishing process, to add a random token as a "CNAME", and verify your right to publish to your domain, from Blogger. You get the random token from the "settings instructions" document, "How do I use a custom domain name for my blog?".

See the URL of this (hypothetical) settings instructions document?

http://www.blogger.com/custom-domain-instructions.g?cnameVerificationToken=VPTRE6SUB6JM+gv-G47P6DIR6KFENZUFIFYWSQJJPDYFZK4SQMUUIUFLYLCQD4OIGDFA.domainverify.googlehosted.com.&domain=www.hotspotshield.com

This is an example. If you're registering a domain other than "www.hotspotshield.com", you're going to have a different token - which should be a function of the BlogSpot and domain URLs. You'll also note another case sensitivity issue - "www.hotspotshield.com" and "www.HotSpotShield.com" will produce completely different tokens.
Now, it's an out of date example.

http://www.blogger.com/custom-domain-instructions.g?cnameVerificationToken=GKBPLXBRMT5M+gv-H5FFOYEKYNXE46EE4A3PLAK6HCDIELS27KQUR5OBKHFKXRKMCTDA.domainverify.googlehosted.com.&domain=www.hotspotshield.com

That's what you get, for "www.hotspotshield.com", today. We'll check again, tomorrow. Also, we need to know when "today" ends.

If you buy a domain using "Buy a domain" after today, Google Apps should setup the domain for you - including the second "CNAME". If you bought the domain directly from a registrar, you're going to have to click on "settings instructions", and get the token for your domain. Note that a "CNAME" is required - a "TXT" won't provide the same verification. Also note the various registrar entry conventions, which will affect your use of their domain manager forms.

We are learning a lot of details about the domain verification process, some of which were known in custom domain setup in general - and which are absolutely critical to the process. You will want to read the [FAQ] Why is my domain still in "12" / "404" State?, to get all of the details. The FAQ has been updated several times, so re read it often..

This will, hopefully, provide a solution for the Abandoned Domains problem, and allow everybody to publish to their domain, regardless of whether the domain was previously used for Blogger / Google custom domain publishing by another blog.

On the other hand, if you purchased your domain using "Buy a domain", and you ever need to recycle the publishing settings, you're probably going to have to add this new "CNAME" to your domain, before you can re publish. This will possibly include everybody who purchased their domain, before the Publishing option was disabled - if the domain is not operational right now - and possibly, blog owners who need to un delete a domain published blog.

>> Top