Troubleshooting Custom Domain Issues

If you are trying to make your custom domain published blog work, see my guide Troubleshooting Your Custom Domain Problems.

If you want to know how to setup a custom domain properly, from the beginning - and avoid the need for Troubleshooting - read Setting Up A Custom Domain. Avoid the most basic mistakes made - read The Simplicity Of A Custom Domain Setup.

If you just setup your custom domain - and want to minimise the effects of the URL change upon your search engine relationships - read Managing The Migration.

If you're just browsing, then read on - but get a good cup of coffee first. And welcome, to Nitecruzr Dot Net.

>> Top

Troubleshooting Your Custom Domain Problems

Of the many accessories and features in Blogger, Custom Domain Publishing is possibly the most problematic.

Looking at the Labels index in this blog, I see the Custom Domains label on 317 posts (as of 2013/11/21) - which makes it one of the most heavily labeled single topics here. There are several challenges with diagnosing and resolving a custom domain problem.

• It has various different causes.
• It leads to many different symptoms, which can easily be confused for other problems.
• Its symptoms can be chronic or intermittent- and may be immediate, or may take months to exhibit themselves.
• It may require resolution by any blog guest, by the blog owner, by Blogger Support, and / or by a third party such as the domain registrar.

---

As you read this article, click on some of the many links in the text, and read the linked articles. Please think of this article as the first chapter in a very large book - right now, a book with 317 chapters.

---

How To Use This Guide

• Always start properly, with righteous DNS addresses.
• Verify DNS addresses, using Dig. If any doubt about Dig results, compare logs from multiple Dig utilities, including a Dig against the authoritative domain server. Possibly 90% of all custom domain problems are caused, directly or indirectly, by spurious DNS addresses.
  
• If examination of multiple Dig logs shows righteous DNS addresses, look at HTTP traces against the BlogSpot and domain URLs.
  
• If neither Dig nor HTTP traces provide a definitive diagnosis, consider that you have internal database corruption.
• As you diagnose your DNS setup, only look at "A" and "CNAME" records.
• As you diagnose and / or fix the problem, do not delete the Google Apps administrative desktop account.

These are the known custom domain publishing diagnoses. Here's a brief, one line summary of the problems, which are discussed, in some detail, farther below. Click on any one, if it looks promising, to jump to the detail discussion.

• Domain Purchase Unsuccessful
• Only Name Registration Purchased, No DNS Hosting
• Domain Addresses Not Defined
• Domain Ownership Not Verified
• Non Google DNS server Part Of Configuration
• Domain Addresses Not Properly Chosen
• Domain Previously Registered, And Used In Blogger
• Domain Registration Expired
• Blog Published To Domain, Using Mixed Case URL
• Blog Published To Domain Root, With Asymmetrical DNS
• Domain Redirected To Google Ad Services, Sites, or Start Page URL
• Domain Published, Partially
• Internal Blogger Database Corruption
• The Blog And Domain Are In Transition
• All Issues May Not Be Discussed Here

Domain Purchase Unsuccessful

• The domain will not be setup. The blog may, or may not, be published to the domain.
• This will follow use of "Buy a domain".
• The primary symptoms will vary. We see both "404 Not Found", and "Another blog is already hosted at this address", fairly common for this problem.
• This will be an issue for newly purchased domains.
• It will be diagnosed by use of the WhoIs log showing "xxxxxxx.xxx appears to be available", and verified by examination of the Google Checkout logs, and bank account ledger entries.
• The blog owner generally has to correct a problem with his bank account, then repeat the purchase of the domain.

Only Name Registration Purchased, No DNS Hosting

• The domain will not be setup, nor the blog published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom will be the query "What are the DNS servers for Google?", "I need 2 IP addresses for my domain!", or "I can only change NameServer1, NameServer2 in my domain setup!".
• This will be an issue for newly purchased domains.
• It will be diagnosed by the stated symptom, with the blogger confirming the diagnosis by checking the registrar's invoice to see what services were paid for.
• The blogger will have to arrange for DNS hosting - free or paid - but choose the right DNS hosting service. A free third party DNS hosting service may be useful, in this case.

Domain Addresses Not Defined

• The blog will not be successfully published to the domain.
• This will follow domain registration using "Buy a domain".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• This will occur for new custom domains.
• It will be diagnosed using an excerpted Dig log, for both domain URLs.
• Here, the blogger will be advised to contact Google Apps Support, for any domain purchase issues.

Domain Ownership Not Verified

• The blog will not be successfully published to the domain.
• The primary symptom will be an "Error 12" or variant (we have observed "Error 12", "Error 13", "Error 14", and "Error 32", in reported various forum topics), when using the the Settings - Basic - Publishing wizard.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• This will occur for new custom domains - as well as for mature domain being re published.
• This will be diagnosed using an excerpted Dig log, for both domain URLs. Base DNS addresses should also be verified, to ensure a righteous setup.
• The blog owner will be advised to add or verify presence of the proper domain ownership verification "CNAME". This may involve adding an updated "CNAME", and / or carefully examining the format of the "CNAME", as entered in the "Zone Edit" registrar display. Some blog owners may need to use a free third party DNS hosting service, to allow for registrars who cannot support the necessary "CNAME".

Non Google DNS server Part Of Configuration

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog). The symptoms will be observed intermittently, when the non Google server is referenced.
• Possible secondary symptoms:
  • Blog feeds, intermittently not redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for the domain root.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

Domain Addresses Not Properly Chosen

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog).
• Possible secondary symptoms:
  • Blog feeds, unreliably redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for both domain URLs.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

Domain Previously Registered, And Used In Blogger

• A Blogger blog was successfully published to the domain, at one time - by a different person. It is now not successfully published.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog ...", when attempting to publish / re publish the blog to the domain.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
• It will be resolved using the Custom Domain Reset form - and much patience by the current domain owner.

Domain Registration Expired

• The blog was successfully published to the domain, at one time.
• This may follow domain registration, long ago purchased from a third party registrar, or using "Buy a domain".
• The primary symptom may be unexpected content, displayed by the blog. The nature of the unexpected content will vary.
  1. In most cases, and when the blog owner is lucky, the domain will be dead, or maybe display a page of ads or an "Offsite Warning" interstitial display.
  2. In rare cases, and when the blog owner is not lucky, the blog will display contents of another blog, another website, or an "Offsite Warning" interstitial display.
• It will be diagnosed using a WhoIs log, which shows expiry and last update dates, for the domain.
• There are two possible resolutions (see two primary symptoms, above, for possible variants).
  1. With the blog owner being lucky, it is in the control of the registrar. After domain registration is renewed, the problem is resolved by the 4 step process. For best results, follow this procedure religiously.
     1. Publish the blog back to BlogSpot.
     2. If necessary (and possible), contact the registrar, and renew the registration. Then, correct the DNS addresses.
     3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
     4. Republish to the domain URL.
  2. If the blog owner was not lucky, the domain may now be in the hand of an unknown party. This will be a subject for another article.

Blog Published To Domain, Using Mixed Case URL

• The blog will be successfully published to the domain, but will not be visible from either BlogSpot or domain URLs.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs.
• This will, typically, occur for new custom domains, immediately after the end of the 3 Day Transition Period.
• It will be diagnosed using a RexSwain HTTP Trace set, starting from the BlogSpot URL.
• It is typically resolved by publishing the blog back to BlogSpot, then re publishing to the correct URL, using all lower case letters.

Blog Published To Domain Root, But Asymmetrical DNS Used

• The blog will not be successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain" - though "Buy a domain" will be far more commonly seen.
• The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs - or the warning "Blogs may not be hosted at naked domains." or "Another blog or Google Site is already using this address.", when trying to publish or re publish the blog to the domain.
• This will, typically, occur for new custom domains.
• It will be diagnosed using a RexSwain HTTP Trace set, starting from the BlogSpot URL, and confirmed with a screen print of the Publishing wizard display, taken as the blog owner sees the error message in question.
• It is typically resolved by publishing to the "www" alias.

Domain Redirected To Google Ad Services, Sites, or Start Page URL

• The blog will not be successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• This will typically occur for new custom domains.
• It will be diagnosed using a RexSwain HTTP Trace, starting from either domain URL.
• It is typically resolved by deactivating or resetting the Ad Services, Sites, or Start Page service, using Google Apps.

Blog Published Partially, To The Custom Domain URL

• The blog will appear successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "404 Not Found", when viewing the blog using one of the domain URLs - and the blog will still be published to the BlogSpot URL.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs. If each of the above diagnoses are eliminated, one by one, and "404 Not Found" is still observed, internal database corruption is the only remaining possibility.
• It is typically resolved by re publishing the blog to the domain. This symptom may mask a Service Redirect, or Internal Database Corruption.
• As you diagnose the problem, re publish the blog to the domain, and / or recycle the domain settings, please do not delete the Apps desktop account.

Internal Blogger Database Corruption

• The blog will not be successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog or Google Site is already using this address." (or a similar phrasing), in the Settings - Basic - Publishing display.
• It will be diagnosed using an excerpted Dig log, for both domain URLs. If the above diagnoses are all eliminated, one by one, and "Another blog ..." is still observed, database corruption is the only remaining possibility.
• It is typically resolved by recycling the domain settings in Google Apps, and / or use of the Custom Domain Reset form.
• As you diagnose the problem and / or recycle the domain settings, please do not delete the Apps desktop account.

The Blog And Domain Are In Transition

• The domain will be setup - but will not redirect. The blog will be published to the domain URL.
• This will follow use of "Buy a domain".
• The primary symptom will be seen only by the owner (when properly logged in to Blogger). When clicking on the "View Blog" dashboard button / link, the owner will see an "In Transition" display.
• This will be a temporary issue, for newly purchased domains, successful purchased.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
• It will go away, when Transition expires, 72 to 96 hours after successful domain purchase and registration. The blog, and the domain, will then redirect properly.
• While you wait for Transition to expire, spend time reading what you will want to do, when Transition is complete.

All Issues May Not Be Yet Discussed Here
You could, occasionally, have a problem which is not diagnosed in this Guide - and in that case, please ask for help, politely, in Blogger Help Forum: Something Is Broken.

Before asking for help, you can help the helpers if you have tried some affinity diagnostics or maybe some differential diagnostics - and if you are aware that not all problems may be exclusively caused by Blogger.

---

And if it's not too late, read Setting Up A Custom Domain, before you start.

---

>> Top

A Blog Published To A Custom Domain Has A New URL - And No More

We see occasional signs of naivete, in Blogger Help Forum: How Do I?, about custom domain publishing.

Can I publish to a custom domain - and still use the Blogger dashboard?

and

Can I publish to a custom domain - and keep my comments and posts?

and

Can I publish to a custom domain - and avoid TOS restrictions?

Some blog owners seem to see custom domain publishing as more than it actually is.

When you publish your blog to a non BlogSpot URL (aka custom domain), using a proper setup, your blog now has a new URL.

The BlogSpot URL continues to work - and to direct search engines bots, search query results, and visitors, to the blog.

If your blog uses Google+ Comments, you won't see the comments published to the BlogSpot URL - although the comments will still exist, and be visible, in Google+.

Some accessory gadgets will stop working, temporarily, shortly after the new URL starts working. This is an unavoidable result of the Internet address lookup infrastructure, aka DNS.

Other than those details, you'll have the same blog as before - just with an extra URL, that may be more valuable to the search engines.

• The Blogger blog will still be hosted by Blogger / Google, and will use the Blogger dashboard for maintenance and publishing.
• The blog will be served subject to Auto Pagination.
• The blog will be subject to the same content restrictions - both porn labeling, and malware / spam deletion, will be consequences of any infractions.
• The blog will be subject to the same deletion recovery restrictions.

Just as any time you change the URL of your blog, you'll face changes in external relationships, such as with your readers, and with search engines and other services. Don't do this without careful planning, and methodical execution!

For the few times when your domain fails, see my troubleshooting check list - but prevent problems best, by first setting it up properly, and by observing your own limitations.

>> Top

Is A Sitemap Useful, For A Blogger Blog?

Occasionally in Blogger Help Forum: How Do I?, we see evidence of confusion and doubt.

Do I really need a sitemap, for my blog?

This question, when asked, may help us to design our blogs better.

WikiPedia defines a sitemap as

a list of pages of a web site accessible to crawlers or users

Classically, a sitemap is a visual index, to help the people viewing a static website, to easily identify and access a specific article in the website.

A sitemap provides an alternate index, to a non Blogger website. Most websites are static, with a hierarchically accessed, single structure. A well designed sitemap allows people and crawlers to more efficiently locate specific articles (pages or posts), in a static website.

Most Blogger blogs provide much more than a hierarchical, single, static structure. By default, a Blogger blog links its pages and posts dynamically, using several alternate indexes.

• Archives (posts listed hierarchically, by date).
• Labels (posts listed hierarchically, by topic).
• Extended main page (posts listed sequentially, by "Newer Posts" / "Older Posts").

Any blog, which provides one or more of these features, is effectively its own sitemap - for viewer access.

For crawler access, the options are simpler.

• Archives (posts listed hierarchically, by date).
• Extended main page (posts listed sequentially, by "Newer Posts" / "Older Posts").

Label searches, which use a different URL structure from the base blog design, are not used for indexing a Blogger blog.

If you look at the main page of a typical blog, you can follow the "Newer Posts" / "Older Posts" links from page to page, repeatedly - and eventually, see every post in the blog. With a new blog, with few posts, and predominantly "first visit" viewer traffic, the main page makes a passible sitemap. For an older blog, with many posts, and more "repeat" viewer traffic, the main page makes a less efficient sitemap.

For crawlers, which will generally follow a limited number of links within any single blog or website, the main page makes a still less efficient sitemap. Most blogs with any appreciable search engine reputation, however, only need new posts indexed by the crawlers - as older posts are already indexed, and remain in search engine cache.

Blogger provides a good, default gadget which serves as a sitemap, on most blogs - the Archives index. Look in the sidebar of this blog, about halfway down, for the "Contents" gadget. This is an HTML based gadget, which produces a set of hierarchical, date structured links, exhaustively enumerating each post in the blog. It's an ideal structure, for search engine bots (crawlers) to follow. If your blog includes this accessory, that's probably sufficient for indexing.

Blogs which contain one or more features can provide search engine access, organically.

• Well written, regularly published posts.
• The standard Archives gadget.
• The standard "Newer Posts" / "Older Posts" links.

Such blogs may not need a sitemap, to provide good access to both people and crawlers.

Both the Archives, Labels, and "Newer Posts" / "Older Posts" links are subject, on some blogs, to customisation. A blog with Javascript driven Archives, Labels, and / or custom pagination ("Newer Posts" / "Older Posts") gadgets may not provide easy crawler access. This also affects blogs which use dynamic templates. If you tweak your blog extensively, you may want to consider these issues.

There is one special case where a sitemap is always needed. Any time the URL of your blog is changed - whether to a new BlogSpot URL, or to a non BlogSpot custom domain - prompt re indexing, under the new URL, is a necessity to regain search engine reputation. A robust sitemap set, which directly references all posts in the blog, helps the crawlers to re index each post, under the new URL, much faster.

Other than that special case, a blog with standard, well designed, features may not actually need a sitemap.

A sitemap, setup through Google Webmaster Tools - and using the blog posts newsfeed, defined through "robots.txt" - is a simple accessory to add, and requires no ongoing maintenance. Given this reasoning, most blog owners simply setup a sitemap, and don't worry about the above issues and questions.

>> Top

Your Google Apps Account, And The New Administrative Google Login

In some cases, the earlier provided procedure, for accessing the limited access domain administrator account, may not work, for your Google Apps domain.

For some Google Apps domains, you will need to reset the password using the Google administrative reset. Instead of the wizard at "accounts.google.com", you may need the administrative reset wizard, at "https://admin.google.com".

A Google Apps administrative account reset uses the same set of displays, as the previously discussed limited access account reset.

When you request administrative account reset, you first try the using default account name.

For my domain, if it had been purchased after November 2012, the default account name would be "bloggeradmin@nitecruzr.net". Yours will be "bloggeradmin@yourdomainURL" - whatever "yourdomainURL" actually is.

Domains purchased before December 2012 will apparently still use a Google Apps token sent in email or linked from Google Wallet.

As previously advised, always use one browser for Blogger and other Google activity like GMail, and the second for the Google Apps session. For best results, first clear cache, cookies and sessions (yes, all 3!), and restart the second browser.

Use the same account name, as advised - just substitute the administrative reset sequence.

https://admin.google.com/

Click on "Need help?".

Select "I don't know my password".

Enter your limited access Google Apps account name.
In most cases, you will go into the expected administrative account reset sequence.

With a mature account, where you have previously setup a custom administrative account, "bloggeradmin@yourdomainURL" may not be accepted. Now, you must try an extended administrative account reset.


If the limited access account, for your domain, is not operational, don't panic.

Return to the previous screen, and select "I don't know my username".

Now, you have other details to provide.


Whether you use the standard administrative reset - or the extended administrative reset - Google will send a password reset email message, to the backup email account associated with the domain. The email account should be the one used by the Blogger account, under which you purchased the domain.

Other than the previously enumerated cases where you can't use the recovery email address, this should be a reasonably straightforward process.

1. Access the new Google Administrator Login screen.
2. Click on "Need help?".
3. Request password reset.
4. Access the right email account.
5. Open, and execute the password reset email.
6. Hopefully, you're done.
7. If necessary, return to the previous screen.
8. Select "I don't know my username".
9. Provide additional details.
10. Go to Step 3.

Once you're in the Admin Console, you can check / set the auto renewal option setting, or you can retrieve the login instructions to access the registrar's zone editor - or do whatever else you need to do.

The next time you need to access the Admin Console, try to remember the previously set account name and password. And, if you feel up to it, add recovery options to your administrator account.

>> Top

Your Google Apps Account, And The New Google Login

In the not so distant past, explaining how to login to Google Apps was a painfully tedious process.

If I wanted to login to the Google Apps account for this domain, "nitecruzr.net", I would construct a URL in the browser address window (or use a bookmark)

https://www.google.com/a/nitecruzr.net/ServiceLogin

The URL for your domain would be different - and explaining the difference was frequently a nuisance, in the login sequence instructions.

When explaining how to login to a recently created limited access Apps account, I would focus on the account reset process.

For this domain, "nitecruzr.net", I would access the account reset wizard as

http://google.com/a/cpanel/nitecruzr.net/ResetAdminPassword

or possibly

http://google.com/a/nitecruzr.net/ResetAdminPassword

Again, your URLs would differ. Maintaining separate bookmarks, for each different domain, was a time sink.

With the new Google Apps integrated account login, all of that has changed.

Any time you start a process which involves Google accounts, first clear cache, cookies and sessions (yes, all 3!), and restart the browser.

Since the Google Apps login uses a different Google account, you'll need to use two browsers - as you do when transferring control of your blog.

Use one browser for Blogger and other Google activity like GMail, and the second for the Google Apps session. For best results, first clear cache, cookies and sessions (yes, all 3!), and restart the second browser.

Next, to login to the limited access Google Apps account for this domain, you simply go to the standard Google login screen, using the second browser.

https://accounts.google.com/ServiceLogin

You then click on "Need help?". On the next screen, select "I don't know my password", and enter the limited access Google Apps account name, for your domain.

For my domain, if it had been purchased after November 2012, the default account name would be the limited access "bloggeradmin@nitecruzr.net". Yours will be "bloggeradmin@yourdomainURL" - whatever "yourdomainURL" actually is.

Domains purchased before December 2012 will apparently still use a Google Apps token sent in email or linked from Google Wallet.

Enter the appropriate account name, click "Continue", and follow instructions.


Click on "Need help?".

Select "I don't know my password".

Enter your limited access Google Apps account name.
After you submit the password reset request, Google will send a password reset email message, to the backup email account associated with the domain. The email account, for a new Apps account, should be the email account used by the Blogger account, under which you purchased the domain.

The only problem which you can have is if the necessary email account can't be accessed.

• Being overly secretive, and basing the Blogger account on a bogus or inactive email address.
• Having the Blogger / Google account deleted for abusive practice.
• Never bothering to remember the email account and password.

In either case, without access to the right email account, you won't be able to reset the Google Apps account password - and you won't be able to gain / regain access to your Google Apps domain administrator account, aka the "Admin Console", for the domain in question.

Other than that one possible problem, it should be a straightforward process.

1. Access the new Google Login screen.
2. Click on "Need help?".
3. Request password reset.
4. Access the right email account.
5. Open, and execute the password reset email.

Once you're in the Admin Console, you can check / set the auto renewal option setting, or you can retrieve the login instructions to access the registrar's zone editor - or do whatever else you need to do.

If you're logging into Apps for a second time, and you remember the account name and password, it's simpler still. Access the new Google Login screen, enter the domain administrator account name and password, and login. Now, Google Apps is just one more Google application - but with its own unique account name.


If you remember the domain admin account name and password from last time, just login - and you're there.

Again, always open Google Apps in a second browser.

Other than the need to use a second browser, logging into Google Apps is now a series of bookmarks and simple scripts.

---

In some cases, you may not be able to use the limited account reset sequence. Don't panic! Google also provides an administrative account reset process, for these situations!

---

>> Top

Custom Redirects, And The Mobile Template Redirect, Are Not Compatible

We've recently seen a few reports about problems with custom redirects, in Blogger Help Forum: Something Is Broken.

I want to redirect my blog URL to a static home page. With a redirect in place, mobile computer users can't access my blog. Mobile browsers display an error, mentioning too many redirects.

This problem is being reported by owners of blogs both published to BlogSpot, and to non BlogSpot domains. When published to a non BlogSpot domain, the problem is present even for domains properly setup.

Some advice, given in the forum, suggests use of forwarding, instead of referral, as a solution. This advice is a problem, for 2 reasons.

• Forwarding cannot be used with blogs published to BlogSpot.
• Forwarding is not a good solution for custom domain publishing.

Right now, there is no solution for this problem - though there is a workaround. Blogger Support is aware of the problem - but it's not certain that a solution will be immediate.

For blogs published to BlogSpot, there are just two choices.

1. Disable the redirected home page, and do without the custom home page.
2. Enable the custom redirected main page, and do without mobile access to the blog.

For blogs published to a custom domain, there are, supposedly, three choices.

1. Disable the redirected home page, and do without the custom home page.
2. Enable the custom redirected main page, and do without mobile access to the blog.
3. Use forwarding, instead of referral, to redirect the domain to the blog.

Forwarding comes in two versions, with differing effects from the two versions. Neither version of forwarding is beneficial, to Blogger blogs.

• DNS forwarding results in the blog being indexed under the BlogSpot URL, by the search engines. The blog's readers will be able to use the (forwarded) domain URL, to access the blog - but all search engine references will mention the BlogSpot URL.
  
  With some access to the blog through the BlogSpot URL, and other access through the domain URL, blog reputation will drop, similar to blogs newly published to a new URL. Both reputation and traffic will do the same.
• Frame forwarding results in the blog being visible within an IFrame. No indexing of the blog, by the search engines, will take place, with blog contents visible inside an iframe. Search engine reputation will drop even worse with DNS forwarding.

Not all registrars offer both versions of forwarding, so you may have to take what they offer - and accept the resulting loss to the blog.

As a workaround, until the problem is fixed, you can return to the previous technique for making a static home page.

Basically, blog owners may have to choose between having a custom home page (for desktop access), and having the blog accessible through mobile browsers (for mobile access) - or using the workaround. And everybody has to wait, patiently, until Blogger Engineering can come up with a better solution - to make custom redirects, and the mobile browser redirect, work together.

>> Top

Is A Custom Domain URL More Valuable Than A BlogSpot URL?

We see the question, about relative value of a custom domain, periodically in Blogger Help Forum: How Do I?.

Does a custom URL actually have value, over a normal BlogSpot URL?

Some people wonder if a custom URL isn't similar to a custom ("vanity") license plate, for your car.

Personally, I can think of 3 reasons why a custom domain might be more valuable, for your Blogger blog.

• Some people believe that having your own domain makes your blog more individual and interesting - and they may be more likely to visit your blog when presented to them, in a search list.
• Since domains are not free, there are less dormant domains than dormant BlogSpot subdomains. It may be easier for you to get the relevant domain of your choice, than the relevant BlogSpot subdomain.
• A properly chosen domain URL may be easier for people to remember, than a BlogSpot URL.

Some people believe that their car is more fun, if it has a license plate that properly reflects their personality.

We know that Blogger blogs, published to a custom domain, have no special qualities. Is the address so special?

Maybe the belief makes the value. People who buy non BlogSpot URLs are not doing so to waste time or money, they do so because they believe that they will benefit. Many people, who read the advice / content of the people who buy non BlogSpot URLs, will also believe that non BlogSpot URLs have value.

Those people will pay more attention to a non BlogSpot URL, than to a BlogSpot URL, when they see a SERP entry that references a non BlogSpot URL - simply because they believe that a non BlogSpot URL has more value than a BlogSpot URL.

Why did Blogger provide the custom domain publishing feature, originally? They did so because:

1. Non BlogSpot URLs are more valuable than BlogSpot URLs.
2. People believe that Non BlogSpot URLs are more valuable than BlogSpot URLs.
3. People who buy Non BlogSpot URLs believe that Non BlogSpot URLs are more valuable than BlogSpot URLs.

Possibly, #3 makes the whole issue self fulfilling.

People believe - therefore, it is true.

That said, a custom URL will have more value if you set it up properly, and if you manage the new URL, aggressively.

>> Top

New Custom Domains Purchased From A Registrar, And Lacking The Transition Period For New Domains

We've known about the Transition period, which has applied to domains purchased through Blogger, for a few years.

Under Transition, domains purchased using "Buy a Domain" were only partially published, immediately after the domain purchase - with the publishing process completed, several days later. The Transition period allowed for the domain, newly setup by "Buy a Domain", to become fully visible on the Internet, before blogs subject to Transition were re published.

The Transition period was originally applied to blogs re published using "Buy a Domain", to delay redirection of the BlogSpot URL to the domain URL, until after a new domain was fully visible, to all Internet DNS servers.

Transition was designed to apply to new domains, purchased using "Buy a Domain", with the hope that domains purchased outside "Buy a Domain" would not need Transition.

When "Buy a Domain" was active, most blogs being published to domains not just purchased using "Buy a Domain" did not require Transition.

• Blogs published to domains, purchased directly from a registrar, would be owned by people with experience setting up domains. People with experience would be able to cope better with the DNS Latency, and inherent instability, involved with new domains.
• Some blogs would be published to mature domains, which would not need Transition at all.

With the ending of the "Buy a Domain" feature, we now have every new domain owner, experienced and not, purchasing domains directly from registrars.

In many cases, Transition is not needed for newly purchased domains, when the owner is not experienced. Inexperienced domain owners make mistakes, when setting up their domains. The domain setup process creates its own limited length "Transition" period, for inexperienced domain owners.

Recently, some domain owners have reported a new symptom, when using the Publishing wizard, to publish their blogs to their newly purchased domains.

This operation failed. Try again later. If the problem persist, please file a post on the help forum.

This new symptom may be replacing the long dreaded "Another blog or Google Site is already using this address.".

Most domain owners, seeing "This operation failed.", have domains with bad DNS addresses. They are generally instructed

You need to correct your DNS addresses.

Those not instructed to correct their DNS addresses should probably be advised

Your DNS addresses are righteous. You now need to wait 24 to 48 hours, for the newly purchased domain to be visible, everywhere on the Internet.

The latter advice will be necessary, simply because the domain was properly setup, immediately - even with the domain not fully visible across the entire Internet.

What happens with gadgets, which need updating, is yet to be observed.

>> Top

Blog Owners Reporting Custom Domain Setup Showing "This operation failed."

This week, we're seeing a few reports, in Blogger Help Forum: Something Is Broken from blog owners, trying to publish their blogs to custom domains.

I'm trying to use the Publishing wizard - and I'm seeing a new error.

This operation failed. Try again later. If the problem persist, please file a post on the help forum.

What has Blogger changed, recently?

It appears that we are now seeing a new phrasing of the well known error

Another blog is already hosted at this address

The majority of the domains showing this error, when checked, have bogus or missing DNS addresses. We see the usual demurrals.

I just got off the phone with the registrar. They say everything is fine on their end.

This is simply more of the same - registrars that still do not understand the importance of using referral, as opposed to forwarding, for custom domain publishing.

Once again, I cannot over emphasise the importance of righteous DNS addresses, when setting up a custom domain. It appears that, contrary to current instructions from Blogger Help, there is still just one working DNS address model, for custom domain publishing.

If you try to publish your blog to a custom domain, and the domain has any DNS addresses defined, the addresses must be righteous. If the defined addresses do not match the one known DNS model, expect now to see a new monolithic error.

This operation failed.

In some cases, it's possible that newly purchased domains, not subject to the Transition period earlier provided by "Buy a Domain", may display this error because of DNS propagation latency. New domain owners, even when they are able to setup a domain properly, may see this error because the new domain is simply not visible to all Internet DNS servers.

>> Top

Why Do We Need Four DNS Servers?

Occasionally, we see a perplexed blog owner asking a popular question about custom domain setup.

Does my domain really need four servers?

Some even seem to think that newer domains, with less readers, can get by with less - even one - servers.

Won't one server do - at least, for newer blogs? Theoretically, yes. But not one server is going to be 100% reliable, or last forever. Every computer ever made, like every human born, will die, one day.

Your blog (and your domain) depends upon DNS, to resolve its address. Address resolution is an essential part of helping your computer connect with the computer where your blog is stored.

If you specify just one server for your domain, and that one server goes down, your domain will be out of service - to the people depending upon that one server.

The named DNS server "ghs.google.com" is a redundant server array.

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

We use a "CNAME" to reference "ghs.google.com" - and we can't always use a "CNAME". Most registrars will not let you use a "CNAME" to resolve the domain root.

Google provides the 4 x "A" addressed server set, to resolve the domain root - when you wish to simply redirect the domain root to one of the aliases. Most domain owners will redirect the root to the "www" alias - though you are allowed to redirect to any one alias, at your discretion.

Google provides four mutually redundant individual servers, each responding to a specific IP address, for custom domain clients to access in a round robin sequence.

If any one server in the array of four becomes overloaded or goes out of service, and doesn't respond to a DNS query, the DNS resolver, on any client computer, will try the next server defined - if there is another server provided. If your domain provides just one server to resolve its address, and that one server goes down, your domain goes out of service. Your readers will see, yet again

404 Server Not Found

But wait - - there's more. Since Google provides four servers, and only one is out of service, they won't regard that as a major emergency. They still have three servers online - and nobody is losing sleep. Except, of course, you.

Google will repair or replace their one down server, when it is convenient to them. Maybe that will be next week, when their DNS server technician gets back from vacation.

Is that not convenient to you? Sorry.

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

Another blog is already hosted at this address.

or

Blogs may not be hosted at naked domains.

If you want to publish your blog to a custom domain using an ASymmetrical configuration, always publish to "www.mydomain.com", not to "mydomain.com". If you want to publish to "mydomain.com", you'll have to use a Symmetrical DNS configuration, and risk losing services hosted by your registrar. If you go with the first option, you will need all 4 servers - if you want a reliable and supported custom domain.

If your registrar or hosting service does not support 4 x "A" DNS addresses setup, you may want to use a (free) third party DNS host. Now, here's hoping that your registrar allows easy configuration of third party DNS service.

>> Top

Click On The "X" (If You Can Find It - And If You Mean To Do It)

The custom domain publishing form, in the dashboard Publishing wizard, causes confusion.

Occasionally, we see evidence of the confusion, in Blogger Help Forum: Something Is Broken.

I need to cancel my domain - but Blogger won't let me!

or

I clicked on my dashboard, and now my blog isn't published to my domain!

These blog owners, and more, are perplexed by the Publishing overlay form, displayed for a blog published to a custom domain.

The custom domain overlay, in the dashboard Basic - Publishing wizard, is very elegant. The overlay design is similar to forms used by Blogger and Google+, to display photos.

The "overlay" form is appropriately designed, for its use. The form follows the function - and reflects the status of the blog. For all that, it's diabolically subtle.

The normal display, for a blog published to BlogSpot, is a simple box, containing the current BlogSpot URL - and an "Edit" link, used to change the published BlogSpot URL. If this blog were still published as "bloggerstatusforreal.blogspot.com", for instance, I would see

bloggerstatusforreal.blogspot.com Edit

Clicking on the "Edit" link, I would get the wizard, to re publish the blog under a different BlogSpot URL.

The display for a custom domain published blog overlays the normal BlogSpot URL box. With this blog published as "blogging.nitecruzr.net" (but still retaining the BlogSpot URL "bloggerstatusforreal.blogspot.com"), I see a simple box.

blogging.nitecruzr.net Edit X
bloggerstatusforreal.blogspot.com redirects

This simple box "overlays" the previous box.

bloggerstatusforreal.blogspot.com Edit

This justifies the use of the "overlay" design, I suspect.

If I want to return the blog to the "bloggerstatusforreal.blogspot.com" published URL, I have to simply click on the "X", to the right of "Edit". The "overlay" box closes - as the blog is re published, to the BlogSpot URL.

It's that simple.

• When I can see the "X".
• When I understand what the "X" is intended for.
• When I intend to return the blog to the BlogSpot URL.

At other times, not so simple - not so obvious to everybody - and not so appreciated.

If you were to request assistance, in the forum.

How do I publish the blog back to BlogSpot?

The answer should be very simple.

Click on the "X".

How elegant - and how non useful. In strict online etiquette, it's rude. Since you are requesting assistance, it's possible that you don't see the "X" or do not understand its function.

To avoid causing more frustration, I provide some detail.

Click on the "X", to the right of the "Edit" link".

To make sure that I am instructing you properly, I first must make sure that the blog is properly published to the domain. I request verification of what you are seeing.

Please provide a screen print, showing the Publishing wizard, in the dashboard Settings - Basic display.

Later seeing the properly produced screen print, which indicates the blog properly published to the domain, I can then reply, confidently.

Click on the "X".

Such is life, in the Blogger elegance.

And, if you "accidentally" happen to click on the "X" without meaning to do so, your domain promptly (within limits of cache expiration) goes offline, as the blog only responds to a BlogSpot URL.

Oh yes, the "Edit" link, visible when the blog is published to the domain, does lead to an essential function - the ability to select the option.

Redirect nitecruzr.net to blogging.nitecruzr.net

Again, not always a good idea.

>> Top

Maintaining Auto-Renew Settings For Your Domain - 2013

Recently, Google Apps redesigned their desktop GUI. Now, it's easier to maintain auto-renew settings for your custom domain.

Of course, "easier" may not be the same as "more initially obvious".

Along with the GUI redesign of Google Apps, Google changed payment procedures for domain registrations.

Google recently removed Google Wallet from custom domain registration.

Google Apps (now,"Google Admin") handles domain registration payment, along with domain registration renewal. When you access Google Admin, and the new GUI, you will be invited to verify payment information, and replace your Google Wallet registration.

Start by accessing the Google Apps desktop, for your domain. If you use GMail for your email, or other Google products, try to use a different browser for Google Apps. Alternately, use an "Incognito" window, in Chrome - or a "Private" window, in Firefox. Or, clear cache, cookies, and sessions - then restart the browser, when possible.

For this domain, "nitecruzr.net", I would access the desktop as

http://google.com/a/cpanel/nitecruzr.net/ServiceLogin

or possibly

http://google.com/a/nitecruzr.net/ServiceLogin

You simply change "nitecruzr.net", to your domain URL, to access the desktop for your domain.

If Google Admin sends you to Google Apps for Business, see Google Apps: Cancel Google Apps for Business 30-day free trial, for instructions on removing Apps For Business from your domain.

"Google Admin" provides the "Admin console". Relevant to domain registration, you'll find two key dashboard links.

• Billing. How you pay for domain registration.
• Domains. How you maintain domain registration.

When your domain is currently setup to use Google Wallet for registration payment, and you click on "Billing", you will be invited to "Verify billing information".

The billing information verification process is reasonably straight forward, involving basic identification of your payment account - and uses data already entered in Google Wallet. When complete, you'll have Google Apps verified billing information.

Having verified billing information, you return to the dashboard, and click on "Domains". Right there, you'll have the usual option to "Automatically renew my domain registration".

No mess, no fuss.

• If you want to automatically renew, you leave the option checked.
• If you decide to manually renew, you un check the option.

And, you're done.

>> Top

Confusion Over Custom Domain Expiration Dates, Caused By Google Apps Email

We're seeing some panic today, in Blogger Help Forum: Something Is Broken, from a few blog owners who have received email, which implies that their custom domain registrations are approaching expiration - and can't be renewed.

I registered my domain several months ago, through Google. I have the receipt for the payment in my email, my Google Wallet account, and my credit card statement.

Why am I getting this email now, some months after registering my domain - but well before my registration should be expiring?

Our records indicate that the payment for registering your domain mydomain.com was unsuccessful.

Payment failures happen for a variety of reasons (such as insufficient funds or an expired card). You can update your payment information to resolve the issue.

Please log in to your account and update your payment information. If you take no action, your domain will not be renewed on .

This confusion is especially unfortunate, given the recent discontinuation of the very popular Google Domain Registration option, which drives the Blogger "Buy a domain" wizard. It is reminiscent of a similar episode, almost a year ago.

When this confusion is reported in Blogger Help Forum: Something Is Broken, it's not difficult to dispel the panic. Several helpful websites provide registration look up services for the domains in question - and allow us to easily verify that there is no sudden flood of registration problems.

• DomainTools.com
• Name.com
• Network-Tools.com

Overview for mydomain.com
Registrar Info
Name  ENOM, INC.
Whois Server  whois.enom.com
Referral URL  http://www.enom.com
Status  clientTransferProhibited

Important Dates
Expires On  December 01, 2013
Registered On  December 01, 2012
Updated On  December 01, 2012

We have identified a popular topic in Google Apps Forum: General Discussion, where this issue is being discussed, and which has been forwarded to Google Apps Support.

Please watch the Google Apps discussion, or this blog post, for updates. And get back to work, on your blog.

>> Top

Custom Domain Instability Caused By Using Unacceptable Servers

A few blog owners become confused by the necessary configuration of the domain root, when setting up their custom domains.

Some blog owners, who do not have a good understanding of DNS principles, make mistakes when setting up the domain root (aka "naked" domain). From good intentions (trying to ensure that the domain performs better or differently), their naivete may actually make the domain perform worse - or not at all.

With more blog owners unable to buy a domain through Blogger, and forced to setup their own DNS addresses, this will become an increasingly critical issue.

Blogger designed the custom domain feature to use "A" / "CNAME" referral, instead of DNS / frame forwarding.

The most obvious referral configuration - dual "CNAME" aka "symmetrical" DNS - is not supported by all registrars. Some registrars refuse to allow "CNAME" definition of the domain root, by policy.

To make custom domain publishing more globally usable, Blogger provided an alternative to dual "CNAME" referral - a hybrid configuration which uses 4 x "A" referral, for the domain root. This configuration is also known as "asymmetrical" DNS.

Asymmetrical DNS uses 4 Google servers, accessed in a round robin sequence, to define the domain root.

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.

Round robin DNS is pretty simple. Each server in the set is queried by the DNS client on the readers computer, in sequence, until one server responds. The first responding server is required to provide a suitable answer. If the first responding server provides an unsuitable answer, the DNS client has no alternative but to display yet another version of

Server Not Found
Error 404

Google uses the 4 servers to provide quadruple redundancy. One server is designed to handle the entire workload, at any time - with 4 servers, and each server running at 25% of full load. If any one server has to be temporarily taken out of service, they still have 3 servers - with each server running at 33% of full load.

During scheduled maintenance - and with triple redundancy, even two simultaneous emergencies (with 2 servers out of service, unscheduled) will not cause an immediate, major problem. This allows Google Engineers to schedule routine network maintenance as mutually convenient for everybody in their group - even considering the global need for Blogger services, on a 3600 x 24 x 7 x 56 basis.

There is one weakness of round robin DNS. All servers, in the set, have to be equally capable of performing reliably. A naive blog owner, including any additional or different server, in the set, risks having one server, responding to the round robin access - but providing an unsuitable answer.

mydomain.com.  3600 IN A 50.63.202.39
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.

What is 50.63.202.39?

ip-50-63-202-39.ip.secureserver.net (50.63.202.39)

50.62.0.0 - 50.63.255.255
GoDaddy.com, LLC GO-DADDY-COM-LLC (NET-160-153-0-0-1) 160.153.0.0 - 160.153.255.255

GoDaddy uses forwarding - not referral - to direct traffic. Here, some (not all, and not always) prospective blog readers see

Server Not Found
Error 404

Some blog owners make a second mistake - which compounds the first mistake.

mydomain.com.  3600 IN A 50.63.202.39
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 mydomain.com.

Here we see the "www" alias - which is what 95% of your direct traffic accesses - using the domain root for obtaining the address. Add to that the bogus server (in this example, "50.63.202.39"), and you will get a lot of complaints about sporadic connectivity problems.

Server Not Found
Error 404

This is so simple - if you only believe.

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.

>> Top

Custom Domains Purchase - "Buy a domain" Lacks The "Check Availability" Option

We're seeing a few reports from confused blog owners, in Blogger Help Forum: Something Is Broken, who want a non BlogSpot URL for their blog.

I have tried to follow the guide, but my page does not say the same as the guide.

Several blog owners, in trying to use "Add a custom domain" to buy a domain, are observing that there is no "Check Availability" sequence.

Right now, the "Add a custom domain" link in the Publishing wizard simply goes straight to the "Advanced settings" option. This conflicts with Blogger supplied instructions.

In Blogger, locate the Publishing area under the Settings tab. Settings to Publishing.

Then, click the link to add a custom domain name, enter the domain name you'd like, and click Check Availability.

Clicking on "Add a custom domain", we are immediately presented with "Advanced settings".

Right now, we're getting very terse advice from Blogger Support.

Blogger still supports custom domain hosting, though no longer offer an option to purchase domains within the product. To purchase a custom domain, please visit a third party registrar such as GoDaddy or eNom.

Until we hear more, I'll suggest use of eNom or GoDaddy, as advised. If you choose GoDaddy, you may be able to use the Blogger / GoDaddy DNS Setup wizard, to approximate the convenience of "Buy a domain". If you can't use the GoDaddy wizard, please note that the normal rules remain in full effect.

>> Top

The Google Apps "bloggeradmin" Password Reset May Be Broken, For Some Domains

We've been seeing reports from some frustrated blog owners, about problems with the limited access Google Apps accounts.

I've reset my password numerous times and it still doesn't work.

Even given the recently provided "bloggeradmin" username, and the standard Google account reset process, some blog owners still cannot access Google Apps to manage their Blogger custom domain published blogs.

We do have one bit of hope. One such problem report, recently forwarded to Google Apps Support, was noted by a Google Apps Engineer with the advice

We identified a recent change which may have affected the password reset flow for some users. We expect it to either be fixed or rolled out shortly.

So, there is some hope for a few unhappy new domain owners. It's possible that this problem has been resolved, with Google Apps now using the new comprehensive Google login screen.

>> Top

The Google Apps "bloggeradmin" Password Reset Uses A Standard Google Account Reset

As Google Apps updates their limited function ("bloggeradmin") account setup process, we see reports from confused Blogger blog owners.

After I reset my password, I still get

The username or password you entered is incorrect

when I try to login, later!

and

I reset my password - and it changed my Blogger and GMail account - but I still can't login to Google Apps!!

The Google Apps password reset uses a standard Google account reset process - and is subject to normal account reset behaviour. If you don't reset the right account, you won't be able to login, later.

We've been warning people for years, about the need to use two browsers, to transfer a Blogger blog from one Google (GMail) account to another.

The Google Apps "bloggeradmin" account setup, like the Blogger blog transfer, works best using two browsers. The password reset, for "bloggeradmin@mydomain.com" (as an example, here) involves a Google account reset.

1. You start the password reset from a Google Apps login screen, for "mydomain.com".
2. After clicking on the "Can't access your account?" link, you use a standard Google account reset process.

When you attempt to login to Google Apps, click on "Can't access your account?". That takes you into the Google Account Reset process.


Provide the full account name of your Apps account.

bloggeradmin@mydomain.com

instead of

myemail@gmail.com

The Google Apps password reset, like blog account transfer, is one more process where you may need to use two different browsers. And, to be safe, clear cache, cookies, and sessions (yes, all 3!) - then restart the second browser, before opening the password reset email.

The password reset will be more likely to be successful, if your Blogger account is based on an active and real email address - this is not a good time to be anonymous.

---

(Update 2013/11/03): This process should be slightly simplified, with Google Apps now using the new Google comprehensive login screen.

---

>> Top