Subscribe: The Real Blogger Status
Added By: Feedage Forager Feedage Grade A rated
Language: English
addresses  blog  blogger  blogs  blogspot  custom domain  custom  dns  domain root  domain  domains  google  https  published 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: The Real Blogger Status

The Real Blogger Status

What Blogger won't tell you

Updated: 2018-04-22T09:59:07.038-07:00


HTTPS Availability For All Custom Domain Blogs


After years of waiting, this blog is now readable, using HTTPS.This blog, and others published using properly setup custom domains, now provides optional HTTPS connectivity.I looked at the Settings - Basic page of my Blogger dashboard, a couple hours ago.Previously, I might see the HTTPS options "Availability" and "Redirect" when accessing my Draft Blogger dashboard. Now, both are there, in Production Blogger.If you publish a blog, using a custom domain URL, you should see the new option too. It took 5 minutes, with my blog, to activate "HTTPS Availability".RBS is now secure!A couple hours ago, "HTTPS Availability" was offered, on my Blogger dashboard.There are two options - HTTPS Availability, and HTTPS Redirect.HTTPS Availability lets your readers access your blog, using HTTP or HTTPS, as they choose. HTTPS Availability is now an option, for all blogs.HTTPS Redirect automatically requires all readers use HTTPS, to access your blog. HTTPS Redirect is an option, with HTTPS Availability enabled.HTTPS Availability is now an option!"HTTPS Availability" lets your readers, who use only HTTPS, connect to your blog. It's the first step in upgrading the web.So, it's selected - and now we wait.Less than 5 minutes later, and I see the display updated."HTTPS Redirect" is now available, for this blog. "HTTPS Redirect" automatically requires all of your readers to use HTTPS, when reading your blog. It's the second step in upgrading the web.So "HTTPS Availability" is now a reality. Common sense - and Blogger advice - tells me to take things slowly. I'll still allow HTTP connectivity, for readers who can't use HTTPS.I next need to setup Search Console entries for this blog, using HTTPS.For best results, the domain needs to be properly setup. Both the BlogSpot to domain redirection, and the domain root ("naked domain") to published URL redirection, can be complicated, with HTTPS offered for an improperly setup domain.Also, remove any other custom installed redirecting code. Both code blocking local country redirection, and code blocking (or enabling) HTTPS redirection, will interfere with the HTTPS Redirect option.And check your non Blogger accessories and features carefully. Blogger is not the last Internet service to provide this upgrade - and your blog will provide the best experience, for your readers, if all accessories and features also support HTTPS.Test the blog and domain, in the many URLs.With the blog published to the domain, and offering HTTPS connectivity, you'll have 6 URLs - all pointing to the blog. Make sure that all 6 work properly.Right now, my test blog does provide HTTPS connectivity / redirect - though this blog does not, since I don't want broken links to third party services. Using my test blog, I have 6 URLs to check. Note that this blog is published as "" - not "", or "".http://myspaceandmore.blogspot.comhttp://nitecruzr.nethttp://techdict.nitecruzr.nethttps://myspaceandmore.blogspot.comhttps://nitecruzr.nethttps://techdict.nitecruzr.netYour readers will be happiest, if all 6 URLs work - and all redirect to your blog. Again, your domain will probably use "www", in place of "blogging" or "techdict", in #3 and #6.Be prepared to re publish the blog, for best results.If you were using "HTTPS Redirect" for the BlogSpot URL, #2 and / or #5 many be "404". You may need to re publish the blog, and remove the BlogSpot "HTTP" to "HTTPS" redirect. The domain root redirect, and "HTTPS Redirect" for the domain, may conflict.Activate "HTTPS Redirect" for the domain, with the BlogSpot URL having "HTTPS Redirect" enabled - and you may see this.You will have 3 redirects, with HTTPS Redirect added.The BlogSpot to domain redirect.The domain root to published URL redirect.The "HTTP" to "HTTPS" redirect.All 3 redirects need to be addd in proper sequence - if you want the BlogSpot URLs, the domain root, and the published domain URL to all redirect to the blog.With both the BlogSpot redirect, the domain root redirect, and the HTTPS redirect enabled, you may[...]

HTTPS Availability For Custom Domain Published Blogs


After many years of waiting, people who publish blogs using custom domains can provide HTTPS connectivity, to their readers.Right now, HTTPS Availability / Redirect can be enabled, for custom domain published blogs, using Draft Blogger.Since Draft Blogger is used by Blogger for beta testing new features and problem fixes, you will do best using it selectively.Use Draft Blogger only to enable HTTPS Availability / Redirect.In this case, you use draft Blogger only for enabling HTTPS for your custom domain URL. This is a good time to use a second browser - either a different browser on this computer, any preferred browser on another computer, or this browser with an Incognito / Private window.Start by logging into Draft Blogger - using a second browser.The Settings - Basic dashboard page, in Draft Blogger, now has a new option.Select "Yes" for "HTTPS Availabiity" - and wait while the domain is setup with SSL.With "HTTPS Availability" enabled, Blogger has to obtain an SSL Certificate for your domain. This is not a casual formality. With many domain registrations, you might pay extra for a certificate.Once "HTTPS Availability" is activated, you'll have the "HTTPS Redirect" option.Allow half an hour after enabling "HTTPS Availability", then refresh the display. You should have "HTTPS Redirect" available - and if you wish, you can enable it.Success!Blogger is not the last Internet service to provide "HTTPS" connectivity.If you enable "HTTPS Availability", and later "HTTPS Redirect", you'll probably have accessories and services that don't support HTTPS.Be selective when you use Page / Post / Template Editor, and see suggestions to "Fix" all links that continue to reference "HTTP" connectivity. If you routinely select "Fix" you will end up with broken links, for accessories and services that have not been upgraded.If you can deal with the details though, you'll have a secure domain - and you can now offer your readers SSL connectivity, to your custom domain published blog.If your #Blogger custom domain is setup properly, you can now offer HTTPS connectivity for your custom domain published blog.You should consider the redirects, and the different URLs involved, carefully.[...]

What Is The Mysterious Custom Domain "Error 12"?


Both the historically infamous "Another blog ..", and the currently infamous "Error 12", are part of the custom domain publishing process.Similar to the mysterious "bX" codes being an enhanced version of "We're sorry, but we were unable to complete your request.", "Error 12" (and variants) is an enhanced version of the monolithic "Another blog or Google Site is already using this address."."Another blog" (which was generally seen during use of the Blogger Publishing wizard) is complemented by the equally annoying "Not found" (which is generally seen after Publishing is used).The "Another blog ..." / "Not Found" condition is not desirable - for a working domain.The condition, in general, appears to be an unavoidable result of the flexible Blogger custom domain design. A Blogger custom domain published blog can be one host in a domain cluster, that can also include a Tumblr blog, a WordPress blog, any number of third party hosted websites - and even an odd feature like a forum.Blogger custom domain publishing is a powerful feature.Blogger custom domains can be purchased from (almost) any registrar - and can use DNS provided by (virtually) any DNS host. It's more powerful than competing Internet services. Use of "CNAME" referral, to connect the blog and domain, is innovative, and smart.Custom domain publishing does some of the domain processing from your computer - instead of solely from Google. Use of your computer, unfortunately, involves computers and networks uncontrolled by Google - and may lead to occasional database corruption, and to "Another blog". Custom domain publishing depends upon DNS - and DNS is an Internet service controlled by neither Google or any blog owner."Another blog" and "Not found" are two displays, caused by one problem.The mysterious "Server Not Found", seen occasionally, is similar to the classic "Another blog ..." error.In many cases, righteous DNS addressing is present - but broken links, in the Google database, leave the blog displayed as “Not found”. "Another blog" is seen by the blog owner, when publishing - and "Not found" is typically seen by would be blog readers, and search engines, after publishing.An experienced blog owner would generally prefer the former, to the latter. The owner, when seeing "Another blog", can fix the problems - so prospective readers and search engines can view the blog, without seeing "Not Found"."Error 12" is the best known, but not the only, "Error"."Error 12" is the best known "Error" - but not the only one. There appear to actually be several dozen different variants of "Error 12", which refer to problems with the Publishing dashboard wizard. We've seen "Error 32", at least.32 "Error" codes is nowhere as complex as 36^6 "bX" codes - but it's a start.An example of the infamous "Error 12", seen long ago.Earlier, "Error 12" was seen when domain ownership verification was needed, when publishing to newly setup domains. We have, during the past year, seen reports of Publishing problems labeled "Error 13", "Error 14", and "Error 32"."Error 12", in reality, is not an actual error condition - it is simply a domain, requiring normal ownership verification. Recently, the "Error 12" label was removed from the "domain ownership verification is needed" display - and now, we simply see the label "Third party domain settings"."Error 13", "Error 14", and "Error 32" appear to also involve domain ownership verification - but with slightly different circumstances. There may also be some "Error" numbers which involve features other than domain ownership verification. And some "bX" codes are caused by bogus DNS addressing, encountered during custom domain publishing - like various "Error" codes.The "Error 12" seen now, with verification instructions re written - and without the "Error 12" label.Ownership verification has become both more flexible - and less necessary.Domains purchased through Google Domains don't need ownership verification, when purchased under the Blogger / Google account as the blog owner[...]

When Correcting A DNS "CNAME", Maybe Delete Before Adding


Very few registrars allow multiple "CNAME" addresses, for a single DNS host.

When I diagnose DNS address problems, I generally recommend
Add the addresses highlighted in green.
Remove the addresses highlighted in red.
I find that it helps to have the old address visible, while the new address is being composed. This does not always produce the desired result, unfortunately.

Many registrars do not allow multiple "CNAME" addresses, for DNS hosts - and the zone editors reject new address attempts.

When DNS addresses for a Blogger custom domain need to be corrected, I recommend
Add the addresses highlighted in green.
Remove the addresses highlighted in red.
I recommend correction in this order, so the blog owner can view the current (incorrect) addresses, while adding new (correct) addresses. This compensates for various zone editor syntax oddities.

Making corrections in this order - adding correct addresses, then removing incorrect addresses - does not always produce the anticipated results. If the zone editor checks as each individual address change is made, we see the result.

"That name is reserved (already in use)."

Some zone editors check, immediately, when a second "CNAME" is entered, for a given "Host" address. When multiple "CNAME"s are forbidden, and the zone editor checks for multiple "CNAME"s immediately, we have a problem.

Other zone editors check for a correct address complement, when Saving multiple zone editor changes - after all additions and removals are successfully made and verified. These zone editors do not present a challenge - as long as the blog owner removes all incorrect addresses.

When the incorrect addresses are not removed properly, we see the result.

That name is reserved (already in use).

This leads the blog owner to cancel the recommended correction - and we wait, in vain, for the domain to come online.

In a worse case scenario, we can even end up with another case of "Another blog ...".

Right now, though, we can only diagnose the problem, one domain at a time.

Some registrars have zone editors which forbid multiple "CNAME"s for specific addresses - and check, one entry at a time, for mistakes. This may cause a problem, with a #Blogger blog owner making custom domain DNS address corrections, when instructed to "Add addresses highlighted in green.", then "Delete addresses highlighted in red."

Custom Domain Publishing, And DNS Latency


The Internet is diverse and large - and the Internet directory system, aka the DNS Infrastructure, supports the diversity and size.When we setup a new domain, the registrar frequently advises us to wait patiently, before continuing.Congrats on your new domain! Now, we suggest that you wait 24 - 48 hours for the new domain to propagate, before trying to publish to the domain.When we update a domain - and add or delete a single DNS address - we won't always get advice about waiting, from the registrar.Responsible helpers will occasionally provide advice to be patient, in Blogger Help Forum: Get Help with an Issue.After you correct the addresses, please wait 8 hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.This advice is generally given, for domains that use a 4 hour ("14400" second) or greater Time To Live or TTL.Many registrars use a 1 ("3600") or 2 ("7200") hour TTL, for individual domain DNS addresses. Domains with 2 hour or less TTL generally do not require latency advice, because most forum topics take more than 2 - 4 hours to complete.Adding a domain - and updating a domain - involve different latency.The difference between "new domain" and "domain update" advice - and irregular presence of either - causes confusion.Some advice about domain updates involves unnecessary waiting. In other cases, new domain owners jump right in, and try using their new domains, immediately - and regret later.Moving too quickly, with Blogger custom domain publishing, can lead to Google database corruption. Fear of the apocryphal "Another blog ..." error - and similar Blogger access disruptions - leads many technical helpers to routinely advise unnecessary waiting periods.People who make changes, and see their changes work immediately, cause similar confusion. Somebody who is advised to wait 2 to 4 hours, before publishing the blog to the domain - and who observe that the domain, perversely, is immediately operational - may misunderstand.Remember that everybody who wants to read a blog won't have the same DNS service. Differences between one reader (or search engine), and another, will cause various confusions.Waiting too long wastes time - but not waiting long enough can cause worse problems. For best results, there will be unnecessary waiting, sometimes.Just be aware of the different latency periods - and try to provide relevant advice.Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).Domain addition latency can be 24 to 48 hours ("86400" to "172800" seconds).Domain addition latency results from the different name servers - and server owners and update policies - all over the Internet. Any given name server updates their local domain master database periodically, by retrieving the zone file from the various master name servers.If the domain master database on a given server is updated daily - and if your domain was setup 1 minute after the daily update, your domain will not be added to that server until the next daily update.Now consider that there are thousands of name servers, owned by hundreds of registrars, ISPs, and other Internet services. All local name servers are updated on a schedule considered appropriate, by the owner of each service.For best results, your domain needs to be indexed on any name server that might be used by any one of your readers - or any one of the search engines that provide necessary search results, for any one of your would be readers. Do you see the possibilities for confusion, for any new domain?This justifies waiting "24 to 48 hours", so your new domain will be visible to everybody, at the same time. This strategy hopefully will prevent possible Google database corruption.Domain update latency can be 10 minutes, to 48 hours ("600" to "172800" seconds).Update of individual DNS addresses will generally [...]

Custom Domains And HTTPS Redirection Code


As most of us know, Blogger HTTPS support does not include custom domain publishing.The advantages offered by HTTPS access are widely advertised - and have led to envy between blog owners who publish to custom domains, and native BlogSpot blog owners proudly advertising their new HTTPS connectivity.Long ago, we saw possibly malicious code which helps our readers avoid using country code aliases, to read our blogs from an aliased country. Recently, there was dodgy code which blocked HTTPS mode, to read a customised blog.Now, we have custom code to force HTTPS access, for BlogSpot published blogs.Along with providing code to help blog owners avoid country local domain aliasing, some marginally helpful hackers are providing code to help blog owners force reader access to HTTPS.Some blog owners always wanted HTTPS to be used, to access their blog.Some blog owners wanted their readers always using HTTPS to access their blogs, before forced HTTPS access became an option. They Googled, and found, semi helpful hackers who provide clever code to force the "HTTP --> HTTPS" redirection. This is clever code - when only BlogSpot access is involved. When you add BlogSpot to custom domain redirection, it becomes another "404".Adding this clever code is an excellent solution - until the blog owner forgets about it, and later upgrades to a non BlogSpot custom domain.With a custom domain published blog, the redirection becomes a problem.The added code contains no exception to permit custom domain published blogs to remain in HTTP mode. When accessing an otherwise properly setup custom domain published blog, from a reader using the "" URL, this prevents the BlogSpot to domain redirect from operating.BlogSpot URLs, which should redirect to the HTTP published custom domain URL, instead redirect to a non existent HTTPS URL - and result in another "404". As the custom domain URL becomes more commonly used for a recently published blog, confusion increases when the rarer BlogSpot URL reference is encountered.My blog has been using the domain URL for months, why is this happening now?The problem involves dual redirection - to "https:" mode, and to the custom domain.After painful problem diagnosis, we find the clever redirection code buried in template HTML - and we see that the blog reader is starting from the BlogSpot URL, and using the BlogSpot to domain redirection, to access the blog.With blog access redirected to "https:" mode, then subsequently to the custom domain URL, the readers sees a "404" - because the custom domain URL is not available as "https:" content.This problem will become increasingly rarer - but not extinct.As self caused custom domain victims become rarer, this way of breaking ones own blog will become more obscure - and it's likely that some cases will go, unsolved. This will be similar to the problem of un migrated classic templates, which has increasingly less experienced support.If you must install unsupported template tweaks into your template - consider the long term effects. Learn to recognise a problem that you have caused, to your own blog.Not every helper will realise that you have added custom redirection code - and when looking at the pr[...]

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 DNS Addresses For Custom Domains. 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.

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 363 posts (as of 2015/06/15) - 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 363 chapters.How To Use This GuideAlways start properly, with properly setup 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 properly setup 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 UnsuccessfulOnly Name Registration Purchased, No DNS HostingDomain Addresses Not DefinedDomain Ownership Not VerifiedNon Google DNS server Part Of ConfigurationDomain Addresses Not Properly ChosenDomain Previously Registered, And Used In BloggerDomain Registration ExpiredBlog Published To Domain, Using Mixed Case URLBlog Published To Domain Root, With Asymmetrical DNSDomain Redirected To Google Ad Services, Sites, or Start Page URLDomain Published, PartiallyInternal Blogger Database CorruptionThe Blog And Domain Are In TransitionAll Issues May Not Be Discussed HereDomain Purchase UnsuccessfulThe 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 " 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 HostingThe 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 [...]

The Mysterious "Destination" / "Points To" Label


Some blog owners buy domains, for publishing a Blogger blog, and ask about how to address the domain.What address do I use for "Points to"?Other owners may ask a similar question, referencing "Destination" or maybe "Target".There is no real difference, between all 3 labels. "Destination", "Target", and "Points to" all refer to the same DNS address value.To compound the confusion, 4 different addresses are required, when addressing a Blogger custom domain root.Defining the DNS servers used by the domain root ("naked domain") requires 4 address records - and the labels used, in the zone editor, will vary from registrar to registrar.We know of 3 different labels, used by Blogger custom domain instructions.The referential Blogger document How do I use a custom domain name for my blog? uses 3 labels to identify the 4 name servers, which are provided by Google. Blogger uses the triplet label "Destination, Target, or Points to" as their example.Note that not all registrars use "Name, Label, or Host" and "Destination, Target, or Points to" - because not all registrar zone editors display addresses in a neat column based display.Google provides 4 name servers, to give us multiple redundancy.Google provides four mutually redundant individual servers, each responding to a specific IP address - for custom domain clients to address the domain root, in a round robin sequence.There are 4 name servers provided by Blogger, to address a custom domain root.Each domain root name server entry uses 2 important label values ("Name, Label, or Host" - and "Destination, Target, or Points to") - with a zone editor that displays addresses in columns.Each label may have 1 of 3 values, depending upon the zone editor provided by the registrar.Here is the Dig Log, for the domain root. Look at the 2, 4, 6, and 8, in the 4 address 3600 IN A 3600 IN A 3600 IN A 3600 IN A the GoDaddy zone editor, you'll see these entries depicted as  Host   Points to           TTL  @    1 Hour  @    1 Hour  @    1 Hour  @    1 HourThe GoDaddy zone editor uses the labels "Host" and "Points to".Similar labels ("Name", "Label" and "Destination", "Target") are used by various other registrars, in their own zone editor.A Zone Editor display, showing the base DNS addresses, for GoDaddy.Here is the display, used by GoDaddy, for "". Here is the zone editor display, as provided by GoDaddy.Do you see the 4 address records, beneath "Points to"?The labels in the address records differ, from registrar to registrar. The "Name, Label, or Host" address values (here, shown as "@") will differ, from registrar to registrar - but the "Destination, Target, or Points to" address values will not differ. A properly addressed domain will have the same 4 "Destination, Target, or Points to" address values, as every other properly addressed 3600 IN A 216.239.3n.21Each address will have one of four values for n: 2, 4, 6, or 8.Complementing "Destination, Target, or Points to", we have another label set.Complementing the 3 "Destination, Target, or Points to" label address values, for addressing the 4 name servers provided by Google, we have a similar set of 3 "Name, Label, or Host" label address values.Addressing "Name, Label, or Host" is somewhat simpler - as all 4 entries are identical to each other, for any domain root address entry.T[...]

Custom Domain Migration, And Redirection Blocking


We see occasional frustration, in Blogger Help Forum: Get Help with an Issue, involving broken or unreliable custom domains.
I setup the Custom Domain properly, following the Google directions.

For some of my readers, my custom domain is not opening. I can see it is going in an infinite loop in the browser - and after a long time, it's throwing errors. My domain is setup, properly. Why do I have to deal with this?
And we will investigate - and in many cases, we find the domain is setup properly.

Some custom domain published blogs have problems, which have nothing to do with the domain setup.

Some custom domain problems involve custom code, added to the template, long ago.

Not everybody is in favour of the ongoing Blogger efforts to convince blog owners to force their readers to use HTTPS / SSL, in blog access.

A number of hackers are making their websites popular, by providing code that lets blogs block forced HTTPS access - just as they provided code that blocked local country domain redirection. Some blog owners add this dodgy code, to their blogs.

This hacking lets blog owners publish their blogs, and use accessories and gadgets that only support HTTP access. Unfortunately, with third party code, you get what you get.

Some third party code, which blocks HTTPS blog access, works OK - for a while.

When a blog is published to a custom domain, redirection to "" causes a redirect loop - or a security check.

This is clever code, seen some time ago when used to block country local domain redirection. Then, as now, some blogs might be deleted or locked as malware hosts - or the blogs would become intermittently inaccessible.

Is the unreliability appropriate? You can add what code you like, to your blog. Eventually, what you add may cause you problems.

Some #Blogger blog owners add clever code, to block HTTPS Redirection, to their blogs. This is the same hacker provided code, used long ago to block local country domain redirection.

Like country domain redirection, the code added may work fine, for a while. Eventually, the blog will be deleted / locked for malware hosting - or will start throwing 404 errors and similar confusion.!category-topic/blogger/71k8xOXxByI

Custom Domain Publishing And Private Blogs


We see an occasional report in Blogger Help Forum: Get Help with an Issue, about custom domain publishing.
My readers can't view the blog - they get a redirection count error!

DNS analysis shows a properly setup domain. When we try to examine the blog, we see a private blog notice - or we are required to login.

But why a private blog, using a custom domain?

The purpose of publishing to a custom domain is to increase readership - by making a blog more visible, using a non BlogSpot URL.

A private blog has limited readership, based on permissions provided by the owner. The need to make a blog private conflicts with the need to increase reader population.

Besides the functional conflict, there's a second problem with combining a custom domain published blog, and access by invitation. Both the custom domain redirection, and the private blog redirection involve interstitial code.

This is a private blog. Combine this, and a custom domain redirection - and you get trouble.

A potential blog reader, when accessing the blog by the BlogSpot URL, will redirect to the domain URL - and then to the access checking interstitial. Some browsers will interpret this as a possible security issue, and cite

Too many redirections!

In other cases, the two redirections may lead to a redirect loop - and the reader will see a white screen of death.

What ever the result - "Too many redirections", or a redirect loop, the potential reader will never see the blog.

If you want to publish a blog, and limit reader access by invitation, you're better off publishing to BlogSpot. If you want to use a non BlogSpot URL, a public blog makes sense.

You are allowed to publish a #Blogger blog with a designated reader population - and you're allowed to publish a blog to a non BlogSPot URL.

You can publish a private blog to a custom domain, if you wish - but this is not recommended. Learn why combining limited access with a non BlogSpot URL is not a good idea.!category-topic/blogger/5IUByvxKYeg

Blogger Custom Domains, And Publishing Spam Control


Some blog owners want to know why custom domain published blogs are subject to daily activity spam control limits. We see the occasional query, in Blogger Help Forum: Learn More About Blogger.Does the 50 posts / day limit apply to all blogs that use the Blogger platform - or only for these hosted on BlogSpot?With Blogger, all blogs are subject to a daily publishing activity limit - pages and posts, combined.Some blog owners question the need to control post limits, for custom domain published blogs.There are a lot of WordPress blogs, posting more or less just the short feeds of others blogs. That seems to be impossible if you use Blogger.Using WordPress as an example does make Blogger seem overly strict. However, Blogger custom domain publishing is not the same as WordPress private domain publishing.All Blogger blogs are hosted on Google servers.With Blogger, all blogs - including those published to custom domains - are hosted on Blogger / Google servers. Blogger limits publishing activity - and scans for malware, porn, and spam - based on server content.One of the problems with Blogger blogs that were hosted using FTP publishing - which was similar to WordPress private blogs - involved problems with content control. It simply was not possible to prevent hacking, porn, and spam on remote, non Blogger servers - whether or not Blogger blogs were involved.WordPress blogs published to private domains are hosted on private servers.With WordPress, blogs published to private domains are hosted on private servers. WordPress avoids limits and abuse scanning, on private domain published blogs, not only because they don't want to - they can't control or scan private servers.WordPress private blogs use the Wordpress engine, for publishing static websites onto privately owned and controlled remote servers. This is how Blogger FTP Publishing worked, long ago.All Blogger blogs are subject to daily posting limits.Thanks to imaginative domain publishing techniques, it's not possible, with 100% certainty, to identify what Blogger blogs might use non BlogSpot URLs. Blogger blogs published to custom domains simply have an alternate, non BlogSpot URL.The much hated CAPTCHA.All Blogger blogs - including this one - are subject to daily page / post publishing limits.When the limit is exceeded, we have the much hated CAPTCHA. This encourages each of us to spend time publishing informative, interesting, and unique content.Publish quality - not just quantity.All #Blogger blogs - not just those published to BlogSpot - are subject to daily publishing limits. Some blog owners would like custom domain published blogs to be exempt from abuse control - including the daily publishing activity limit.It's not likely, however, that Blogger will relax daily activity limits - custom domain or not.!category-topic/blogger/hW5xai9FqH0[...]

Custom Domain Setup, And The Blogger Instructions


Custom domain setups continue to confuse blog owners - and lead sometimes to frustration, expressed in Blogger Help Forum: Get Help with an Issue.When I am trying to set up a custom domain for my new blog, I'm not getting the 2nd CNAME Record, but the settings get saved.In some cases, the domain may be operational - and other times, the domain will be broken, and no corrective instruction is provided.The details in the instructions, Blogger Help: How do I use a custom domain name for my blog?, are misleading - and have resulted in broken domains.The Blogger instructions are confusing.5. Go to your domain registrar's website and locate the DNS (Domain Name System) settings in the control panel.Not a lot of details, there.10. Before you move onto the final step, wait about an hour for your DNS settings to activate. If you attempt the final step before your settings are activated, we'll let you know with a warning message.All registrars don't use "3600" second TTL.That's 2 examples of possible problems.Publishing a blog to a custom domain is so much easier - and produces more reliable results - if you follow basic principles.Learn to use your registrar's zone editor.Learn to read a Dig log.Setup the DNS addresses, for your domain.If necessary, add domain ownership verification.Learn to use your registrar's zone editor.The registrar dashboard / zone editor is the portion of the registrar's website, that is created to let you, the domain owner, setup your own domain.The zone editor is unique, for every different registrar - just as every website is different. One of the signs of uniqueness is hinted, by Blogger.Each CNAME is composed of two parts - Name, Label or Host and Destination, Target or Points to.These two (only two) terms here refer to the most essential details, in the zone editor, that make your domain operational. The two details have no consistent names - so we use examples.The first CNAME is the same for everyone, Name being "www" and Destination ""That one sentence is the most essential, for all domains. It looks so simple - but it's so easy to get it wrong. Not every blog owner will see "Name" and "Destination" in the zone editor display. This leads to many imaginative - and wrong - alternatives.Each registrar labels their zone editor, as they see fit. I've seen other terms used, in addition to the 6 implied. Both "Name, Label or Host" and "Destination, Target or Points to" are merely three examples, for each of these two essential elements.These details are only hinted, by the Blogger instructions.Go to your domain registrar's website and locate the DNS (Domain Name System) settings in the control panel.Now it's time to enter the CNAMEs. Where it says Name, Label or Host simply enter "www" and list as the Destination, Target or Points to.Learning how to look, in the zone editor, is much more reliable than being told what to look for.Learn to read a Dig log.Compared to the confusion behind the registrar's zone editor, a Dig log is simplicity.There are three basic DNS configurations, which produce a reliable domain for publishing a Blogger blog. 99.99% of all blog owners will use only one of the 3600 IN A 3600 IN A 3600 IN A 3600 IN A 3600 IN CNAME is the asymmetrical DNS address configuration. Excepting one known variation, the asymmetrical configuration - with no options - is most reliable.Setup the DNS addresses, for your domain.As long as you have access to the zone editor, and understand the above issues - "Learn to use your registrar's zone editor" and "Learn to read a Dig log" - the rest wi[...]

Don't Always Blame Blogger, With Your Blog Down!


Some of my favourite problem reports, in Blogger Help Forum: Get Help with an Issue, are about inconsistent blog online status.It was fine yesterday. Why is it down, now?andI see the blog, just fine! Why are some of my readers complaining?andI can access it, using my phone! Why is Blogger down, on my home computer?andThe registrar tells me everything is OK!Whenever I see the latter report, I know exactly where to start.Particularly when I see the latter symptom, I know exactly where to start.The registrar tells me everything is OK!The "registrar says" is a frequent indicator of the problem. I'm not naming names, but the initial "G" (and not "Google") is very frequently involved, in this case.So, I start with a Dig log, for the domain. And 99% of the time, that's all that is needed.Bogus DNS addresses are a very commonly seen diagnosis, in so many of these cases. For 99.99% of the blogs, published to a custom domain, there is simply no effective substitute for the "Asymmetrical DNS" setup, provided long ago.Maybe the blog will be up for you, and some would be readers - but others will be seeing the "404".Maybe it was fine, yesterday - and today it is suggesting spam and viruses.It will only work, for some people, some of the time. That is the only constant.So you call the registrar - and they tell you that it has to be Blogger, because they have no problem accessing it. But the registrar is part of the problem.The righteous address 3600 IN A 3600 IN A 3600 IN A 3600 IN A 3600 IN CNAME domain root uses 4 x "A" addresses, accessed in a round robin sequence. And the published URL uses a single "CNAME", resolved using a complex name server array. With both domain root and "www" alias properly addressed, your blog has much better chance of being consistently and reliably accessed.One possibly righteous address setup.One Blogger Engineer recommended a modified version of the asymmetrical DNS setup, to be used by 1&1 customers. Only time will tell if this setup is reliable. I have seen several 1&1 customers, this year, suggesting that this is not long term 3600 IN A 3600 IN CNAME spurious address setups.Spurious address setups are unlimited, in variety. Here are a random 3 examples, from recent forum history.Error when adding domain i am trying to adding the domain it shows the errorWhoops, that's an error! (bX-6g9yx1) 600 IN A 3600 IN CNAME appears to be detecting this setup as a problem - and throws a bX code, to indicate a problem.Mobile Redirection Failure I am on mobile on google chrome (only browser I tested) does not redirect to on 600 IN A 3600 IN CNAME blog is online - and visible, using broadband - but no domain root redirection, for mobile browsing. "" is not a Blogger / Google name server, and won't provide reliable redirection.Can't publish my blog I entered the "" domain in 3rd-party domain settings, I did not receive an error. I did not see the 2 CNAME 600 IN A 3600 IN CNAME ea[...]

Changing Your Custom Domain - The Next Chapter


We see some blog owners deciding to change their custom domain URLs - and discovering an unexpected limitation, in re indexing the blog, under the new URLI received email from Google, advising that my previous domain is pulling up a number of 404 errors. I've noticed that these are for individual blog posts.When you change one custom domain to another, you may not see the domain re indexed, transparently.Changing a Blogger blog, from one custom domain to another, is a reasonably simple project - if you're able to plan the change.A domain change should involve simply re indexing the blog.A simple custom domain name change involves republishing the blog, under a new domain. Retaining readers, and search engine access, requires slightly more work.Renaming a custom domain - if it involves a BlogSpot rename - becomes significantly more complicated.Renaming a custom domain - and having the individual post URLs in the old domain working, after the change - will require slightly more effort, than any of the above requirements.With GoDaddy, using specific settings, you may be able to forward post URLs.In one forum topic, a domain owner was able to forward a domain, using instructions provided by GoDaddy - so individual post URLs redirect properly.In the GoDaddy domain settings for the old (original) custom domain, activate Domain Forwarding.Set the "Forward to:" address to the new custom domain.Choose the Redirect Type as "301 Permanent".Choose the Forward Settings as "Forward only".This may not be the effect seen, by all blog owners. Not all registrars will provide this ability.This is the GoDaddy DNS wizard, as of 2016.If your domain was not registered by GoDaddy, you will have a different wizard - and most likely, ""Forward only" will be a different option. Maybe, "Forward without masking" will be a useful description.Blogger does not support redirection, from blog URL to blog URL.Blogger does not support redirection, between BlogSpot or custom domain URLs - as transparent redirection would simply encourage spam activity. Any redirection, from the old custom domain, has to be provided by the domain registrar.Most registrars provide simple DNS forwarding, from one domain to another - if you are able to pay for both domains, simultaneously. Generally, most registrars will setup forwarding, from the old domain to the new published blog URL.Not all blog owners may get the redirection, for their domain, correct.With a domain forwarded to the published URL - using most registrar provided instructions - readers who click on the URL to a specific post, using the old domain URL, will find themselves unexpectedly viewing the blog home page, under the new domain. This will cause some confusion.Search engine bots won't find a specific blog post, under the new domain.A search engine bot, indexing a specific post, using the old domain URL, will be redirected to the blog home page, under the new domain URL. This will not enhance indexing of the blog.Some search engine bots may report this as a "404 Not Found" - and blog reputation will suffer.Here's an example of the problem.The specific post URL (" fashion-river-island-plus.html") redirects to the main page (""). For most obvious benefit, "" should redirect to "" - not to the blog main page "".Let's look at an HTTP trace. This shows an individual post in the blog, with forwarding provided by GoDaddy.[...]

The DNS TTL Setting Is Chosen By The Registrar


Some blog owners, publishing their blog to a custom domain, wonder about the mysterious TTL setting for the domain.What is "3600"? Why do I see "7200" in my Dig log?andWhy do I have to wait 8 hours, after changing my DNS addresses?DNS latency (aka "TTL") is not understood, by many blog owners. A mistake in setting TTL can cause anger and frustration."Time To Live" aka "TTL" is a registrar individual setting, that is used for providing proper performance from the registrars name servers and network.There are multiple TTL settings - and each can have a different effect on your domain. TTL controls caching of the DNS addresses, used to access your domain.TTL indicates how long a DNS address will remain in cache, on a computer, before that computer requests an updated value. It's an essential (but obscure) component, in setting up a custom domain.Since you're reading this blog, your computer has the address of this blog in cache - and won't be requesting an update, until "TTL" for "" expires. GoDaddy, the registrar for "", uses "3600" seconds, or 1 hour TTL.Your computer probably uses the nameservers provided by your ISP - and your ISPs nameservers get updates from the nameservers provided by GoDaddy. Changes to "" go from Google, to GoDaddy, to your ISP, to your computer - and TTL applies to each DNS cache.A typical Dig log, for a domain with a low TTL value.Look at a Dig log extract, for "". 3600 IN A 3600 IN A 3600 IN A 3600 IN A 3600 IN CNAME set the TTL, for each individual DNS address, when you setup your domain. The registrar provides a recommended TTL - but most registrars let you select a different setting, within a given range.A lower TTL ("600" seconds or 10 minutes) provides faster refresh after a change is made - but puts more load on the registrars name servers, and requires a more responsive network.A higher TTL ("7200" or 2 hours) provides slower refresh - and puts less load on the registrars name servers. And when a change is made, by Google, a higher TTL can cause problems.If you don't understand DNS, you will be better off not changing from the registrar recommended setting. Some registrars won't even have a TTL setting, in their zone editor - and others may hide it, behind an "Advanced" menu or similar.If you generate a Dig log for your domain, you'll see the TTL settings for your addresses.A typical Dig log, for a domain with a high TTL value.Look at a Dig log, for "".Here, the current DNS addresses (correction pending).Here, we see a TTL of "14400" (displayed as "14399") - or 4 14399 IN A 14399 IN CNAME best results, we suggest that you wait 2 x TTL, after making DNS changes.I recommend waiting 2 x "TTL", after making any DNS changes, before acting from those changes. Having diagnosed the painful "Another blog ..." domain database corruption, too many times, I suggest this whenever possible.After you correct the addresses, please wait 8 full hours (2 x "14400" seconds) before continuing. This will let all DNS servers on the Internet receive the corrected addresses.In many cases, TTL will be "3600" or "1 hour" - and with a typical forum diagnostic session taking several hours between posts, a one or two hour TTL is transparent to the forum[...]

Blogger Magic - The Custom Domain Root Redirect


When you setup a custom domain, for a Blogger blog, the DNS addresses are the most important issue.A close second in importance, to righteous DNS addressing, is redirecting the domain root to the published URL. We see frequent problem reports, in Blogger Help Forum: Get Help with an Issue.Why does my domain only work, with the "www" in the address?The domain root provides a backup to the published URL, in many domain setups. If the domain root is not redirected, and DNS for the "www" or other published alias is down, the domain is down.With the proper DNS addresses in place, redirecting the domain root is a very simple process.Start from Settings - Basic.Start from the dashboard Settings - Basic page.Click on "Edit" in the Publishing "Blog Address" wizard.With this blog, I have the option to select "Redirect to"You can only redirect the domain root - no virtual hosts.Generally, you would publish to "" - then you would have the option to "Redirect to".Note that you can only redirect the domain root - even if you publish to a virtual host, such as "". "" and" are separate hosts - and cannot be aliased. Whatever you have, the option will work best, when you start with righteous DNS addresses.Given righteous DNS addresses, publishing a #Blogger blog to a custom domain will produce a more stable blog, with the domain root redirected to the published URL. As the blog owner, you need to be sure to select the redirect option.[...]

Blogger Magic - Reading A Dig Log


Whether you're setting up or troubleshooting a custom domain, knowing how to read a Dig log is a useful skill.There are hundreds of registrars, serving the Internet community, each with their own dashboard. Blog owners, setting up their domains for their Blogger blogs, must deal with the syntax and terminology used by each different dashboard.A Dig log lets the blog owner identify the DNS addresses for the domain, using a consistent display.By identifying the DNS addresses used in a given domain, a blog owner or an experienced forum helper can diagnose many custom domain DNS related problems.Here is an example of Dig log use, showing an excerpted Dig log, in a typical forum topic. For more detail, see my earlier post, Diagnosing Problems With Custom Domains: Dig.I have a domain ( - and want to link my blog ( by verifying URLs involved.Continue with Dig Web Interface.A full screen print of the Dig log.The relevant portion of the Dig log, from the screen print.The relevant portion of the Dig log, as text.The advice provided, to the blog owner.Alternate / complementary tools used.Start by verifying URLs involved.Whenever possible, make a screen print, and a text copy, of the Blogger dashboard Publishing wizard, at Settings - Basic. Knowing the status of the blog and domain - and the exact URLs involved - can go a long way to diagnosing many custom domain publishing problems.Continue with a Dig Web Interface log.The best tool for generating a Dig log is Dig Web Interface. Alternate / complementary tools are listed below.I use DWI, for this purpose, by preference. DWI lets you:Package the URLs in the Dig target, in the reference URL.Include multiple target URLs, in one reference URL.Both capabilities are very useful, in diagnosing Blogger custom domain publishing problems.Start from the Dig Web Interface page.Add the domain root and "www" alias, under "Hostnames or IP addresses:".I select Type: "A", and Nameservers: "Authoritative", for my actual diagnoses.Click "Dig".The Dig Log reference URL, for "", generated from DWI. Target URLs are "" and "". full screen print of the Dig log.This is the complete Dig log, resulting from the Dig Log URL (above), and containing the relevant portion (below).This is the Dig log, for "".The relevant portion of the Dig log, from the screen print.This is the important portion of the screen print (above), and showing the text (below).This is the relevant portion of the Dig log, for "".Note the TTL value of "14399" - which is a typical Dig log display for TTL set as "14400" (14400 seconds or 4 hours), in the registrar's zone editor. TTL is a setting which is used to adjust name server performance.Unless you are experienced with DNS setup (and probably don't need to read this advice), you should use the default TTL provided by the registrar, for your domain. Your registrar wants to provide a stable domain for you - and the TTL value affects domain stability.The relevant portion of the Dig log, as text.These are the important details from the screen print (above), with colour highlights corresponding to domain specific details (below) (Default) 14399 IN A (Default) 14399 IN CNAME 21392 IN CNAME [...]

A Domain Root, With Blogger And Non Blogger Hosts


Some blog owners publish a domain, and try to combine a Blogger blog, and a non Blogger website, in the domain root.They publish one host to the domain root - and the other to the "www" alias.This combination may be supported by the non Blogger host - but Blogger blog reliability will suffer. And the readers may become confused, when they click to view the blog, and get the website - or vice versa.There is a special relationship between the domain root and "www" alias. Blogger takes advantage of this relationship, to provide improved reliability for a blog, when published to a custom domain.Ignoring the special relationship, and splitting the domain root and "www" alias, leads to confusion - and decreased blog reliability.Please don't publish two different hosts into the domain root / "www" pair.Please, don't combine a Blogger blog and a non Blogger website, in the domain root / "www" alias duality.There are 3 mutually exclusive configurations, for combining a Blogger blog and a non Blogger website in a domain, which will produce a reliable blog. Your readers will be happier - and the search engines will index the blog better - if you stick to one of the 3 supported configurations.Taking the 3 supported Blogger configurations, we can add a properly published non Blogger website - and produce 3 more possible variants.Non Blogger website published to the "site" alias.Non Blogger website published to the domain root.Non Blogger website published to the "www" alias.Non Blogger website published to the "site" alias.Here, the blog is published to the "www" alias, with the domain root redirected to the "www" alias - and the website is published to an additional virtual host, such as "site". This is a variant of the Blogger asymmetrical DNS 3600 IN A 3600 IN A 3600 IN A 3600 IN A 3600 IN CNAME 3600 IN A Blogger website published to the domain root.Here, the blog is published to the "blog" alias - and the website is published to the domain root. The website may or may not support redirection of the "www" alias to the domain root. This is a variant of the Blogger additional virtual host DNS 3600 IN A 3600 IN A 3600 IN CNAME Blogger website published to the "www" alias.Here, the blog is published to the "blog" alias - and the website is published to the "www" alias. The website may or may not support redirection of the domain root to the "www" alias. This is a variant of the Blogger additional virtual host DNS 3600 IN A 3600 IN A 3600 IN CNAME blog will be more reliably online - and your readers will be happier. And happier readers leads to better search engine indexing - and to more readers.#Blogger blogs published to custom domains use both the domain root / "www" alias, for reliable connectivity. Trying to publish a blog, and a non Blogger website, to the domain root / "www" alias, leads to confusion - and decreased reliability for the blog.[...]

Search Engine Reputation, And Vanity Domains


One hot Internet topic, these days, involves specialised ("vanity") domains.The hot names seem to change, by the week. This week, enom is hyping ".family", ".live", ".rocks", and ".social". Other registrars may have other recommendations.The blog Address (Name) is a key blog identity element, in a well designed blog. It's visible both to people, and to search engine crawlers.The requirement that addresses must be unique is a supposed benefit of vanity top level domains - but vanity TLDs, alone, will not provide blog uniqueness. There will always be competition for some names, in any useful Top Level Domain.My suspicion is that the shinier the TLD, the more competition you may see, between people who plan their uniqueness around choosing the perfect name.Any popular blog / website subject will have name competition.I could publish this blog as "" - and that would be a shiny and unique name. Until another "Chuck" registered "", or maybe "". How unique would "chucksblog" be, then? How many readers could I expect, if they know "chucksblog" - but can't remember if it is "", "", or ""?If your blog has a popular subject, you won't have a unique name - unless you register your name, in every possible TLD that might be relevant to your name. And that will be a financial limitation, for many blog owners.What name would you want your blog to have? For a truly shiny domain, you'll have competition.Complete uniqueness == No competition == No interest == No readers.McDonalds, for instance, may be able to register "", "mcdonalds.franchises", "mcdonalds.hamburgers", "mcdonalds.smallbusiness", etc (as each hypothetical TLD comes online) - and local domains "", "", "", and so on.Very few of the readers of this blog will be in a financial position to do all of that.enom is hyping ".family", ".live", ".rocks", and ".social" - this week.Your uniqueness strategy should include content.You will have to develop a "uniqueness" strategy based on content - not solely on the address. You will need to understand that your blog may lose traffic, from people who know the blog "name" - but may not remember if "yourname" is a ".com", ".net", or ".us".Of course, if you publish only to "blogspot", you will automatically have "", "", "", and so on. You won't have "", "", and "", however - unless you pay for the privilege.Are you getting a feeling for the complexity of the branding issue? Good. Concentrate on content. The search engines index your blog - and provide you traffic - based on informative, interesting, and unique content.Google denies the value of vanity domains, for raw SEO.AdWeek weighs the issue, in What’s in a Name on Social?.When it comes to vanity domains, Google has long denied that they affect search rankings. Their in-house tech team advised way back that registering a vanity domain for the sheer, hopeful sake of page rankings would be a fool’s errand. But there’s a solid number of marketers that disagree, and they watch these things very closely. Chalk it up to wishful thinking, if you like, but time will tell. And there are only so many .com domains available.Only time will tell. I suggest that you keep your traffic and uniqueness strategy diverse. Don't depend upon a vanity domain, alone, for search reputation and traffic.For best results, keep it in perspective.Consider[...]

CloudFlare, Custom Domain Publishing, And HTTPS


A few blog owners, who publish blogs published to custom domains, are becoming impatient, waiting for Blogger Engineering to finish the Blogger upgrade to support HTTPS / SSL.If I get a domain through Google Domains, will I be able to get HTTPS?Unfortunately, no. HTTPS / SSL is simply not available, to blogs published to custom domains.HTTPS is not available, for non BlogSpot published blogs.Whether registered by eNom, GoDaddy, or Google Domains, it simply is not possible to publish a non BlogSpot URL as a supported custom domain, and make HTTPS / SSL available. CloudFlare, a supposed alternative, does not produce a supported custom domain.A proxied CloudFlare domain looks like malicious redirection.In some cases, a CloudFlare DNS "solution" tried by some blog owners, will look like dangerous / malicious redirection. Some blogs will show up as "Deceptive sites", aka "phishing".Some blogs using CloudFlare, for custom domain publishing, will be classified as "Deceptive" sites.Others will produce alarming warnings about malware."This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware."Click on "Details".Look at the warning.Phishing sites pretend to be other websites to trick you.And there is the typical Dig log, with a redirecting proxy service, like 300 IN A 300 IN A 300 IN A 300 IN A is the basis for malware / phishing classification.Any observed malware warning is generally a false positive - most custom domain published blogs do not contain malware. Even so, it's not likely that the "Deceptive site" classification will be easily corrected - or the malware warning interstitial display removed.And this is one more blog owner, who must next be provided instruction to correct the DNS addresses.Having corrected as instructed, DNS addresses will be asymmetrical, and 86400 IN A 86400 IN A 86400 IN A 86400 IN A 86400 IN CNAME DNS corrected, Google shows "Not dangerous" - but the warning still displays."Not dangerous".Note "CloudFlare" is still seen as the host.You can report an error, to SafeBrowsing.False classification now requires time consuming site review.Use "Report Incorrect Phishing Warning", if you believe the site is safe.Finally, get the site reviewed, from the Security Issues page in Security Console (Webmaster Tools) - Security Issues.And while the blog remains offline, search reputation - and the owner - will suffer.Some #Blogger blog owners want to provide blogs published to custom domains - and offer HTTPS connectivity. Since Blogger cannot provide custom domains with HTTPS right now, the blog owners are using CloudFlare, which provides an HTTPS proxy.Unfortunately, a CloudFlare proxy looks like malicious redirection - and blogs using CloudFlare are being labeled as "Deceptive" sites.!category-topic/blogger/ApuJ58a4-kg!category-topic/blogger/-LoJCeX6DEA!category-topic/blogger/DhAFOtJFoCw[...]

Hosted AdSense Accounts, And Blogger


Some Blogger blog owners are confused by the ability to use AdSense, with various Google and non Google services.I monetized my YouTube videos - but when I try to sign up for AdSense, it says I need a website. So I went to Blogger to make one - but it says that I now have to buy a domain. How do I start?The blog owner has an AdSense account - but it's Hosted by YouTube. And you can't use a YouTube Hosted AdSense account, with native Blogger.In general, hosted accounts are useful only under the service that hosts them - and only "blogspot" published Blogger blogs can be used with a Blogger hosted account.Rules for Blogger, and for non Blogger, content are complicated. Each service has different standards.An AdMob hosted account is good, only with AdMob, on a mobile computer.A Blogger hosted account is good, for a Blogger blog, when published to "".A YouTube hosted account is good, only with a YouTube channel.These are rules which affect Blogger published content. Rules for Non Blogger published content are not symmetrical.AdMob Hosted AdSense Accounts.If you want to use a Blogger blog with a AdMob hosted account, you have to fully activate your AdSense account.Blogger Hosted AdSense Accounts.With a Blogger hosted account, you can only use a blog published to "". To use a Blogger custom domain published blog, you have to upgrade your Blogger hosted account.YouTube Hosted AdSense Accounts.With a YouTube hosted account, you have to upgrade your YouTube hosted account, to monetise a Blogger blog.Interestingly, if you start with an approved and verified Blogger hosted account on a properly qualified blog, you can use that account to monetise a YouTube channel. You just can't go from YouTube to Blogger so easily.Fully Activated AdSense for Content.To upgrade to AdSense for Content, you need a properly qualified top level domain website - and a verified address with an AdSense PIN.Blogger custom domain published blog.Non Google hosted top level domain published website.You need to plan any upgrade, carefully.As I have observed previously, standards for publishing to an AdSense for Content account are much higher, than for a hosted account. You need to plan any upgrade, for a Blogger blog using a custom domain - or when you're using any other AdSense account.The end result here is that AdSense Help Forum: Blogger, YouTube, Partner sites will not go away, from lack of questions. The online forums will always be needed, for answering AdSense hosting and upgrade questions.Some #Blogger blog owners, enjoying successful AdSense use with AdMob, YouTube, or other hosted accounts, want to add AdSense ads to their Blogger blogs. They do not always understand the complications involved, in the upgrade.!category-topic/adsense/partner-sites-eg-youtube/jB3MjTjNl_A!category-topic/blogger/G3cdbaKFSyM[...]

Custom Domain Publishing, And World Culture


People who speak (read / write) languages, that do not use Roman character sets, need to publish in their native language - and the Internet now supports that need.Some registrars will register domains which use non Roman character sets, in the URL. Not all Internet services will accept non Roman characters, however.My favourite online DNS diagnostic services, DigWebInterface, and intoDNS, and Rex Swain's HTTP Viewer, only use ASCII. One cannot use non ASCII ("non Roman") characters, with either service."بحث-سناب.com", as converted, shows an example of an Internationalized domain name.To use DigWebInterface to retrieve DNS addresses, and intoDNS to check the domain setup, we have to convert the native URL to Ascii.I use three reliable online services, which will convert URLs to ASCII.DomainToolsWhoIs - Identity for - Powered by Name.comConverting "بحث-سناب.com" to ASCII involves use of one of the latter services.DomainToolsWhoIs - Identity for - Powered by Name.comUsing the 3 tools, we see that "بحث-سناب.com" == "", "XN----ZMCBCML8B0J.COM", and "", respectively. Look carefully, in the body of the display for each service, for the IDN equivalent.We can then use "", with DigWebInterface, and intoDNS - and get the necessary diagnostics.And using the latter tools, we see a properly setup domain - which is now being used for a properly published Blogger blog, verified in Rex Swain.DigWebInterfaceintoDNSRex Swain's HTTP ViewerAnd when assistance is requested, in Blogger Help Forum: Get Help with an Issue, we can use these tools with non Roman character URLs.There may be limitations, though.Here is a blog published to "www.राजभाषाअनुभाग.भारत" - aka "www.xn--l1b0bn3cxacq2d2ccbd1b.xn--h2brj9c".The IDN concept has now led to another domain name concept - "emoji" domains.Some people have taken the ability to setup a domain, using non Roman characters, to another level. How about a domain name, which includes a smiley face?This is a limited use feature. Maybe, the limit will save us?The availability of emoji domains is limited. As of August 2017, there are eight top-level domains for which registration is possible, all of which are ccTLDs: .ai, .cf, .ga, .gq, .ml, .tk, .to, and .ws.This is intriguing - but is it useful?If people don't know how to "type" it, how will new readers access the blog? Will search engines index it? Does the Blogger "Create a blog" wizard actually support it?The jury is still out, here. ".whatever" vanity TLDs started this trend. I'm not sure where this will go, with TLD "emoji" domains.Houston, we may have a problem with TLDs that are IDN encoded.For a TLD that is in English ("بحث-سناب.com"), both of these work: a TLD that is IDN encoded (राजभाषाअनुभाग.भारत"), we have mixed success.This works: does not work:[...]

Stats And "Don't track", And Custom Domains


Blog owners have been trying to block tracking their own Stats pageviews, for a few years.This option has long been unusable, for blogs published to custom domains. Recently, Blogger Engineering updated the option - and the dashboard page with the link.The new Stats option to "Manage tracking your own pageviews" is an improvement, over the old dashboard page.The new Stats option page is run as part of the blog - not the Blogger dashboard - so it does not require third party cookie access. Unfortunately, this provides no obvious help, to people who publish their blogs to custom domains.To see the problem, start from the Stats dashboard page.Click on "Manage tracking your own pageviews".And, you get "This site can’t be reached" or a similar error.Custom domain published blogs do not support HTTPS access - even from the Blogger dashboard.So, change "https:" to "http:", in the address window.If you manually remove the "s", you can access the "Would you like to have your pageviews counted when you visit this blog?" wizard. can't access the "Manage tracking your own pageviews" for a custom domain published blog, by simply clicking on the dashboard link.This suggests an interesting detail. Now that "Manage tracking your own pageviews" runs under the blog URL, it will be subject to script filtering - for "", any applicable country local domains, and / or a custom domain URL.You may need to correct your browser script filter, to make "Don't track" work, now.Owners of custom domain published #Blogger blogs have been wanting to block Stats from counting their own pageviews, for a few years. This option is now available - but not in an obvious way.[...]

Custom Domain Publishing, And Alias Blocking


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

We see the confusion, in Blogger Help Forum: Get Help with an Issue.
The addresses were right - and all the DNS servers updated correctly. But when I open the website, it does not open. It continuously reloads for 5 minutes and after 5 minutes it shows an error.
It's frustrating, when everything is setup properly - but still no results.

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

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

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


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

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

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

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

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

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

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