Verify BlogSpot And Domain URLs

Whenever dealing with any problem with a blog, you should verify the URLs involved.

Some of the most baffling problems, with blog connectivity, identity, or ownership, can start from simple typographical errors. This possibility will involve both native "blogspot.com" and custom domain URLs.

The Publishing wizard window, in the Blogger dashboard Settings - Basic page, is essential for identifying errors. Whether you paste or type a URL into the registrar's zone editor, the Publishing wizard, or the browser address window, you can make a mistake. Checking the Publishing wizard is as important as examining a Dig log extract - or as viewing an HTTP trace.

Verifying the URLs involved, in the dashboard Publishing wizard, is as important as examining a Dig log extract, or an HTTP trace.

This will be the case, when dealing with various "blogspot.com" connectivity problems, researching a custom domain problem, or a dashboard or ownership problem.

Both screen prints, and text copies, are very useful - and not redundant.

Both a screen print, and a text copy, of the Publishing window (and / or the browser address window) is very useful, when diagnosing connectivity problems - or possibly, researching ownership issues, or similarly vanished blogs. And with a custom domain, similar detail from the registrar zone editor is useful.

A text copy of the contents is needed, to avoid having to re type the URL - and maybe cause a different problem when comparing the URL. And a visual copy of the Publishing wizard is good, to identify the context of any problem.

Let's look at two blogs - and what we need to examine / verify.

My test blog, published as "nitecruzr-test-ssl.blogspot.com".

Here, we see a "blogspot.com" URL, in the browser address window.

http://nitecruzr-test-ssl.blogspot.com

Here, we see the Blogger dashboard Settings - Basic page, for a "blogspot.com" published blog.

And the Publishing display, for a "blogspot.com" published blog.



And essential text details, from Publishing, for a "blogspot.com" published blog:

nitecruzr-test-ssl.blogspot.com                                 Edit

If you are requesting assistance with your native Blogger blog, the latter details, in both a screen print and text copy, will be useful.

My blog, published as "blogging.nitecruzr.net".

Here, we see a custom domain URL, in the browser address window.

http://blogging.nitecruzr.net

Here, we see the Blogger dashboard Settings - Basic page. for a custom domain published blog.

And the Publishing display, for a custom domain published blog.



And essential text details, for a custom domain published blog:

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

With a custom domain published blog, always click on "Edit", and make a second screen print.

The second page of the Publishing display - which only applies to a custom domain published blog.

You maybe have seen this display, similarly formatted, in an infamous "Error 12" or similar display.



The latter display is seen, frequently, in an "Error 12" et al domain ownership verification demand.

And the domain root redirection, properly selected.



More essential details, for a custom domain published blog:

Third party domain settings
http:// blogging.nitecruzr.net
  X   Redirect nitecruzr.net to blogging.nitecruzr.net.

If you are requesting assistance with your custom domain published Blogger blog, the latter details, in both a screen print and text copy, will be useful.

And a zone editor display, for my domain "nitecruzr.co.uk".


A zone editor display, from GoDaddy. Every registrar will have a different display.


Comparing the URLs in the browser window, and in the Publishing window - and in Dig logs and zone editor displays (for custom domains) - we can identify typographical errors, and other mistakes. Typographical errors can be a cause of various problems, when publishing blogs to custom domains - and to "blogspot.com".

Some problems result from failure to copy and paste, properly. They can be as challenging to diagnose, as failure to observe registrar name server syntax.

Having verified the URLs, in some cases, you will continue with an affinity diagnosis, and with a differential diagnosis. This is all part of my simple 12 link test set.

You, the blog owner, may consider "duplicate" and "redundant" to be synonyms. When we research a blog problem, "duplicate" != "redundant". Many confusing problems have been solved, by comparing combinations of various above details - and by finding inequality, in one or more displays.

---

Diagnosing problems with #Blogger blogs can require careful diagnostics, using details found in dashboard screen prints and detail text copies, in Dig logs, and in HTTP traces. All details must be carefully compared, both visually and using text extracts, to diagnose some problems.

Much of this may seem superficial, to experienced support analysts - yet be obscure to some blog owners.

Read More

The New "CNAME" Needs To Be Added, And Used, Promptly

One oddity, observed by a few blog owners, is that even after adding the "CNAME" to verify domain ownership, not every blog owner is able to see theirs successfully verified.

I added both "CNAME"s - and I'm still getting "Error 12" when I try to publish.

There are several "common sense" rules, that not everybody observes.

1. The new "CNAME" can't use the example values.
2. The new "CNAME" has to be a "CNAME". Don't let your registrar add a "TXT" instead.
3. The new "CNAME" has to be specific to the URL in question. Enter your published URL precisely, into "Advanced settings".
4. The new "CNAME" has to be added with attention to domain manager address entry convention.

Even with these rules observed, there are still a small handful of unsuccessful blog owners, seeing "Error 12" - or "Error 32".

One of the possible reasons for these last few hold outs, I believe, relates to timing.

Let's consider the "CNAME" setup process.

1. Get the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values, for your unique blog / domain.
2. Add the new "CNAME" to your domain.
3. Publish the blog to the domain URL.

In the "settings instructions" document, How do I use a custom domain name for my blog?, we are instructed to

wait about an hour for your DNS settings to activate

In various other instructions, you will typically see

Wait for up to a day, for settings to be updated

or similar miscellaneous waiting instructions.

Besides the waiting factor, there's a "negative waiting" factor. Several blog owners have observed that the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values, for their unique blog / domain, seems to change, from day to day. This tells me that the ownership verification "certificate" (which is what the "Name" / "Label" / "Host" and "Destination" / "Target" / "Points To" values provide), like most security certificates, has a limited use period.

If you get the certificate in Step #1 above, you have to use the certificate in Step #3 reasonably promptly after doing so. If the certificate for your domain expires within a 24 hour period, then you have, at most, 24 hours between Steps #1 and #3. In other words, you get 24 hours to re publish your domain - after you add the new "CNAME" - and that's including the period that you

wait about an hour for your DNS settings to activate

It's alternatively possible that the expiry is based on an arbitrary time of day - not 24 hours after being issued.

Whatever the nature of the expiry (absolute and arbitrary - or relative to time of issuance) the existence of an expiry time is normal, for a well designed security certificate. By giving the certificate a temporary lifetime, it becomes less useful to would be hijackers and similar miscreants.

So, you may not really benefit from waiting a day to re publish your domain - unless you like seeing "Error 12" (possibly "Error 32"), repeatedly, when you try to publish. Personally, I would wait an hour at the most, after Step #2, before trying Step #3. I would then retry Step #3 hourly, until successful. If you have more patience than I, fine.

>> Top

Read More