Custom Domain Redirection, And "A" Referral Servers

One of the advantages of custom domain publishing, and the domain root to published URL redirection, used to be transparent redirection of the URLs.

As Blogger blog owners become more sophisticated with their blogs, and custom home pages (aka "landing pages"), become more popular, we have blog owners with concerns with home page access and the root redirection. We are also seeing concern with direct access to specific posts - with posts advertised, using the domain root URL.

In some cases, redirection only shows the reader the blog home page when the casual reader first sees the blog - even with a specific post being linked in the advertised URL.

With this blog, which is the redirect target of my domain, nitecruzr.net, this post "Custom Domain Redirection, And "A" Referral Servers" has a URL of "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Since "blogging.nitecruzr.net" is the redirect target of the root redirect for "nitecruzr.net", this post "Custom Domain Redirection, And "A" Referral Servers" should have an alternate URL of "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Click on the 4 links, in the 2 paragraphs immediately above, and compare the results - if you don't yet see the seriousness here. Please. It's not a cosmetic detail.

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "http://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "http://nitecruzr.net/".

This post "Custom Domain Redirection, And "A" Referral Servers", advertised as "https://nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html", redirects to "https://nitecruzr.net/".

Note that this blog does not yet use "HTTPS Redirect", so if you click on a link to "Custom Domain Redirection, And "A" Referral Servers" you will see "http://blogging.nitecruzr.net/2018/08/custom-domain-redirection-and-referral.html".

Here's an example of the problem.

Here's a an example of this problem - diagnosed using a previous post blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

A normal redirect - to "blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html"

http://blogging.nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:25:09 GMT
Date: Mon, 23 Apr 2018 03:25:09 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A normal redirect - to the specific post, using HTTPS.



A broken redirect - to "blogging.nitecruzr.net"

http://nitecruzr.net/2016/08/delete-permanently-means-delete.html

HTTP/1.1 301 Moved Permanently
Location: http://blogging.nitecruzr.net
Date: Mon, 23 Apr 2018 03:23:18 GMT
Content-Type: text/html; charset=UTF-8
Server: ghs
Content-Length: 226
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

http://blogging.nitecruzr.net

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Expires: Mon, 23 Apr 2018 03:23:19 GMT
Date: Mon, 23 Apr 2018 03:23:19 GMT
Cache-Control: private, max-age=0
Last-Modified: Mon, 23 Apr 2018 03:23:01 GMT
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Server: GSE
Accept-Ranges: none
Vary: Accept-Encoding
Transfer-Encoding: chunked

A broken redirect - to the blog home page, using HTTPS.



Unfortunately, some blog owners are observing that redirection of a specific root URL - maybe a custom landing page, or a specific post advertised using the root URL - appears to lead only to the home page of the published blog.

This is a problem with domain / website design, in general - and with Blogger custom domain design, in particular.

The domain root to published URL (for most blogs, the "www" host) appears to use a version of frame forwarding, with some blogs being reported.

I never recommend using Frame Forwarding, in the custom domain DNS setup.

One of the disadvantages of frame forwarding is that redirects using frame forwarding drop the post URL.

We've been seeing this problem reported, for several years.

The problem, rarely - but not never - reported, started several years ago. This was before HTTPS for BlogSpot - and even farther before HTTPS for custom domains - was rolled out.

This was shortly after we started observing other problems involved, in the deployment of HTTPS.

The first HTTPS issue was reported in 2014. HTTPS for BlogSpot was rolled out in 2015.

I'm betting we first saw reports of the post URL being lost, in the ""http://xxxxxxx.whatever.com/whatever.html" -> ... -> "https://www.whatever.com"" was maybe 2 years ago. During deployment of HTTPS.

My guess is that Blogger Engineers upgraded the domain root servers ("A" address) redirection code, to support HTTPS - and made a business decision to use frame forwarding.

From what I've seen of Blogger Engineering in general - and custom domain design in particular - I am convinced that if they decided that frame forwarding is necessary, it's necessary. Until they can correct the problem, that is. My advice to every domain owner to not use registrar supplied frame forwarding in the domain DNS, notwithstanding.

I can only hope that we will see this problem corrected, this decade. Remain optimistic - and report the problem, when it can be identified.

---

It appears that some of the #Blogger custom domain "A" address name servers are using "Frame Forwarding", instead of "Referral", to redirect the domain root to the published URL. Frame forwarding strips away the post address portion of the URL - leaving only the domain root.

Some blog owners use the domain root to advertise their blog posts - and are seeing only the blog home page, instead of the individual posts, when linking to the posts.

https://productforums.google.com/d/topic/blogger/NtQHoVNJ5PM/discussion

https://productforums.google.com/d/topic/blogger/pePwPhr_H-Y/discussion

https://productforums.google.com/forum/#!category-topic/blogger/pePwPhr_H-Y

https://productforums.google.com/forum/#!category-topic/blogger/nr-cIIgjBGg

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 "blogspot.com" causes a redirect loop - or a security check.

<script type='text/javascript'>
var blog = document.location.href.toLowerCase();
if (!blog.match(/\.blogspot\.com/)) {
  blog = blog.replace(/\.blogspot\..*?\//, ".blogspot.com/ncr/");
  window.location.replace(blog);
  }
</script>

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.

https://productforums.google.com/forum/#!category-topic/blogger/71k8xOXxByI

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 URL

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

1. Set the "Forward to:" address to the new custom domain.
2. Choose the Redirect Type as "301 Permanent".
3. 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 ("www.chloellio.co.uk/2016/05/ fashion-river-island-plus.html") redirects to the main page ("www.chloeincurve.com").



For most obvious benefit, "www.chloellio.co.uk/2016/05/fashion-river-island-plus.html" should redirect to "www.chloeincurve.com/2016/05/fashion-river-island-plus.html" - not to the blog main page "www.chloeincurve.com".

Let's look at an HTTP trace. This shows an individual post in the blog, with forwarding provided by GoDaddy.

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://www.chloellio.co.uk/2016/05/fashion-river-island-plus.html&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=AUTO

Sending request:

GET /2016/05/fashion-river-island-plus.html HTTP/1.1
Host: www.chloellio.co.uk
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 79.170.40.4
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·302·Found
Date:·Sun,·15·May·2016·17:17:57·GMT
Server:·Apache/2.2.24·(Red·Hat)
Location:·http://chloellio.co.uk/2016/05/fashion-river-island-plus.html

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://chloellio.co.uk/2016/05/fashion-river-island-plus.html&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=TXT

Sending request:

GET /2016/05/fashion-river-island-plus.html HTTP/1.1
Host: chloellio.co.uk
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 79.170.40.4
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·302·Found
Date:·Sun,·15·May·2016·17:17:58·GMT
Server:·Apache/2.2.24·(Red·Hat)
Location:·http://www.ChloeInCurve.com

http://www.rexswain.com/cgi-bin/httpview.cgi?url=http://www.ChloeInCurve.com&uag=Mozilla/5.0+(X11%3B+CrOS+armv7l+7978.66.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/50.0.2661.91+Safari/537.36&ref=http://www.rexswain.com/httpview.html&aen=&req=GET&ver=1.1&fmt=TXT

Sending request:

GET / HTTP/1.1
Host: www.ChloeInCurve.com
User-Agent: Mozilla/5.0 (X11; CrOS armv7l 7978.66.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.91 Safari/537.36
Referer: http://www.rexswain.com/httpview.html
Connection: close
• Finding host IP address...
• Host IP address = 74.125.28.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...
Receiving Header:

HTTP/1.1·200·OK(CR)

<meta·content='blogger'·name='generator'/>
<link·href='http://www.chloeincurve.com/favicon.ico'·rel='icon'·type='image/x-icon'/>
<link·href='http://www.chloeincurve.com/'·rel='canonical'/>
<link·rel="alternate"·type="application/atom+xml"·title="ChloeInCurve·-·Atom"·href="http://www.chloeincurve.com/feeds/posts/default"·/>
<link·rel="alternate"·type="application/rss+xml"·title="ChloeInCurve·-·RSS"·href="http://www.chloeincurve.com/feeds/posts/default?alt=rss"·/>
<link·rel="service.post"·type="application/atom+xml"·title="ChloeInCurve·-·Atom"·href="https://www.blogger.com/feeds/5573572064729110417/posts/default"·/>
<link·rel="me"·href="https://www.blogger.com/profile/03895481660022671513"·/>
<link·rel="openid.server"·href="https://www.blogger.com/openid-server.g"·/>
<link·rel="openid.delegate"·href="http://www.chloeincurve.com/"·/>

Even if the domain, redirected to the new domain home page, does not generate a "404", blog reputation will not benefit. An individual post, will not be indexed immediately, when hidden behind the home page.

Not all registrars will help you change domain URLs - and retain post URLs.

If you are going to change custom domain names - and transparently redirect readers and search engines, you will need the extra effort, as described above.

Alternately, simply forward the domain, to the published Blogger URL (generally, the "www" domain host) - then concentrate on getting the blog re indexed, under the new URL. Once the blog is completely indexed under the new domain URL, people won't bookmark the old domain - and the new domain URL will be the reference, for the blog. That's what you want, at the end of the day.

Your readers will see the home page of the blog, when clicking on individual posts, indexed under the old domain URL. Then add a Featured Post, mentioning the domain change - and maybe setup one or both blog searches, for reader convenience.

---

It's possible to redirect a #Blogger blog, as published under a custom domain, to a new domain. It's not always possible to transparently redirect an individual post URL, to the new domain, however.

If you change your custom domain, you may have to expect some problems from readers and search engines.

https://productforums.google.com/d/topic/blogger/ZiozKZOS07Q/discussion

https://productforums.google.com/d/topic/blogger/9rTL7U2ZMvU/discussion

https://productforums.google.com/d/topic/blogger/Yd5qUg77wUw/discussion

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 nitecruzr.net to blogging.nitecruzr.net."



You can only redirect the domain root - no virtual hosts.

Generally, you would publish to "www.mydomain.com" - then you would have the option to "Redirect mydomain.com to www.mydomain.com".

Note that you can only redirect the domain root - even if you publish to a virtual host, such as "www.blog.mydomain.com". "blog.mydomain.com" and www.blog.mydomain.com" 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 (www.rockchickenz.com) - and want to link my blog (rockchickenz.blogspot.com).

• Start 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 "rockchickenz.com", generated from DWI. Target URLs are "rockchickenz.com" and "www.rockchickenz.com".

http://www.digwebinterface.com/?hostnames=rockchickenz.com%0D%0Awww.rockchickenz.com&type=A&ns=resolver&useresolver=8.8.4.4&nameservers=

A 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 "rockchickenz.com".



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



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

rockchickenz.com@8.8.4.4 (Default):
rockchickenz.com. 14399 IN A 78.137.164.51

www.rockchickenz.com@8.8.4.4 (Default):
www.rockchickenz.com. 14399 IN CNAME ghs.google.com.
ghs.google.com.  21392 IN CNAME ghs.l.google.com.
ghs.l.google.com. 92 IN A 64.233.183.121

The latter is typically seen, with a blog owner having received bogus advice - and reporting an inconsistently accessible blog.

The advice provided, to the blog owner.

The typical advice, provided to the blog owner, would include domain specific details - accompanied by a link to Setting Up DNS Addresses For Custom Domains.

First, generic advice:

Remove the addresses highlighted in red - and add the addresses highlighted in green - and keep the addresses highlighted in yellow.

Then, specific advice:

This is what you have:

rockchickenz.com. 14400 IN A 78.137.164.51
www.rockchickenz.com. 14400 IN CNAME ghs.google.com.

This is what you need:

rockchickenz.com. 14400    IN    A    216.239.32.21
rockchickenz.com. 14400    IN    A    216.239.34.21
rockchickenz.com. 14400    IN    A    216.239.36.21
rockchickenz.com. 14400    IN    A    216.239.38.21
www.rockchickenz.com. 14400    IN    CNAME    ghs.google.com.

The advice references a typical ASymmetrical DNS custom domain setup - the address set used in 99% of all custom domain setups. Note here, the specified TTL of "14400" (4 hours).

Using the above advice, the blog owner can then, if necessary, research the syntax used by the registrar's dashboard (aka "zone editor") - and make the necessary changes.

Alternate / complementary tools used.

Alternate tools, which can be used to generate a Dig log, are the Kloth.Net Dig DNS Lookup, and the Who.Is DNS display. Neither alternate is as compact and complete - but they can be used to verify results.

Complementary tools include the Global DNS Propagation Checker, the intoDNS domain DNS health checker, the Rex Swain HTTP Viewer, and the Whois Lookup.

In some cases, my 12 link affinity / differential connectivity test may be useful.

For more information.

See WikiPedia: dig (command).

---

One of the most useful tools, for diagnosing #Blogger custom domain problems, is a Dig Log. Learning how to read a Dig Log is a useful skill, for any blog owner wishing to publish a blog to a custom domain.

Custom Domains Redirecting To Google Sites

Similar to a redirection to the Google Apps Start Page service, some custom domains will be found to be directed to Google Sites. Again, we'll see an apparently normal (asymmetrical) DNS address configuration.

mydomain.net.            3600    IN      A       216.239.32.21
mydomain.net.            3600    IN      A       216.239.34.21
mydomain.net.            3600    IN      A       216.239.36.21
mydomain.net.            3600    IN      A       216.239.38.21
www.mydomain.net.      3600    IN      CNAME   ghs.google.com.
---
ghs.google.com.         282206  IN      CNAME   ghs.l.google.com.
ghs.l.google.com.       300     IN      A       74.125.43.121 

The diagnosis, again, will be made using an (abbreviated) HTTP trace.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://sites.google.com/a/mydomain.com/sites/system/app/pages/meta/domainWelcome(CR)(LF)

Unlike the generically known "Server Not Found Error 404" symptom, this one won't be solved by merely publishing back to Blog*Spot, then re publishing to the custom domain.

What we see here is that Sites, similar to Start Page, is apparently enabled, and published to "www.mydomain.net". In this case, you're going to first have to disable Sites. If you don't, you're going to see another old friend

Another blog is already hosted at this address.

After doing that, then you can publish back to Blog*Spot, then re publish to the custom domain.

A second variation on this redirect may not start with an explicit "Server Not Found Error 404", and the HTTP trace will be slightly different. You will probably see "Another blog is already hosted at this address." in the usual places.

Sending request:

GET / HTTP/1.1
Host: mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 216.239.34.21
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·302·Moved·Temporarily(CR)(LF)
Location:·http://www.mydomain.net(CR)(LF)

Sending request:

GET / HTTP/1.1
Host: www.mydomain.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Connection: close

• Finding host IP address...
• Host IP address = 209.85.171.121
• Finding TCP protocol...
• Binding to local socket...
• Connecting to host...
• Sending request...
• Waiting for response...

Receiving Header:

HTTP/1.1·200·OK(CR)(LF)

(Here is a short excerpt of the rest of the trace -
you have to look carefully for these clues)

<body·xmlns="http://www.google.com/ns/jotspot"·id="body"·class="·en">(LF)
<div·id="sites-page-toolbar">(LF)
<div·id="sites-status"·class="sites-status"·style="display:none;">(LF)
<div·id="sites-notice"·class="sites-notice">·</div>(LF)
</div>(LF)
</div>(LF)
<div·id="sites-chrome-everything"·style="direction:·ltr">(LF)
<div·id="sites-chrome-page-wrapper">(LF)
<div·id="sites-chrome-page-wrapper-inside">(LF)
<div·xmlns="http://www.w3.org/1999/xhtml"·id="sites-chrome-header-wrapper">(LF)

As shown immediately above, we have Google Sites involved, though less obviously. Resolution of this scenario, too, seems to involve disabling Sites. After doing that, you will likewise need to publish back to Blog*Spot, then re publish to the custom domain.

>> Top

Blogger Magic - Custom Domain Redirects

Money is a popular artifact used in magic tricks - everybody loves looking at it, and playing with it.

The disappearing quarter - which starts out in your hand, and is found behind your ear - is intriguing. Equally as intriguing is the magician who can take two 50 cent pieces, and turn them into a dollar bill.

The two into one conversion is a neat trick - and that's part of a properly designed and properly setup custom domain.

1. The BlogSpot URL is redirected by URL forwarding, to the domain URL. This picks up the traffic from the BlogSpot blog, and transfers it to the domain. And, it picks up the identity of the domain.
2. The domain is redirected by "A" / "CNAME" referral, to Google (and within Google to the Blogger blog). This picks up the traffic from the domain (including the traffic forwarded from the BlogSpot URL), and transfers it to the Blogger blog.
3. "CNAME" referral retains the identity of the domain, with the traffic.

"CNAME" Referral merges traffic to the blog, using the domain identity.

What we have here is traffic (BlogSpot + domain) merged together, to the domain. Blog content gets indexed by the search engines under the domain URL - and contributes to page rank, and search engine reputation, for the blog, as published to the custom domain URL.

Identity * Traffic == Search Engine Reputation, for the domain.

Remember that the value of a custom domain is based on the increased reputation - to the blog, when seen under the domain URL.

Frame / URL Forwarding merges traffic to the blog, using the blog identity.

An alternative to "A" / "CNAME" referral, provided and recommended by some registrars, is Frame / URL Forwarding.

1. When re published to the domain, the BlogSpot URL is redirected by URL forwarding, to the domain URL. This picks up the traffic from the BlogSpot blog, and transfers it to the domain. And, it picks up the identity of the domain.
2. The domain is redirected by Frame or URL Forwarding to the BlogSpot URL. This picks up the traffic from the domain (including the original traffic, forwarded from the BlogSpot URL), and transfers it to the blog - and back to the BlogSpot URL.
   
3. Forwarding picks up the identity of the BlogSpot URL, with the traffic.

No Identity * Traffic == No Search Engine Reputation, for the domain.

All that work - and the identity (and search engine reputation) goes back to the BlogSpot URL.

If you pay extra to just merge traffic to the blog, what's the benefit?

In terms of magic, the latter trick is a dud. Nobody sees your domain. There goes your dollar bill, in a puff of smoke.

There's no benefit to the blog, if it's just seen under the BlogSpot URL.

Don't let your registrar sell you a puff of smoke!

If your registrar tries to tell you to use Frame or URL Forwarding, because they don't provide "CNAME" referral, or because they won't allow 4 x "A" referrals, your best choice is to find another registrar - or possibly, use a (free) third party DNS hosting service.

If you're here because you got technical advice to use URL Forwarding anyway, because it will work just as well as "4 x A" / "CNAME" referral, get better advice.

It's your domain - you want the benefits of publishing your blog to a domain URL? Publish it properly, using "A" / "CNAME" referral.

Your Blog, Moved Permanently vs Moved Temporarily

If you're lucky, and can afford to have 2 homes, you may occasionally plan an extended stay in the second for while. You may email (or snail mail or maybe Tweet) your friends and family

I'm going to be staying at the cottage (mountain lodge, desert camp, ...) for a while. Send all of my mail there for the next couple months, but keep my current mail address on file.

This is different from sending them, and your business acquaintances (and banks, credit card companies, etc) a second notice

I'm moving next month. Please change your address for me.

Your blog, or other web site, can use either of the above address changes too.

Understand the differences between a Permanent and Temporary redirection.

The first, a "302 Redirect", returns a "302 Moved Temporarily" when addressed by your readers browser. The second, a "301 Redirect" returns a "301 Moved Permanently", similarly. The effect, for your reader, is the same - they see the new address when they type the URL of the blog into the browser address window.

The difference between the 301 and 302 Redirects differs by how the search engines see your blog, and this is what's important.

A server based 301 or 302 redirect is most reliable.

A "301 Moved Permanently" causes the search engine to replace all references in its files, to the source URL (the current address), changing them to the object URL (the new address). This is quite legal, the old address is simply replaced by the new address. All search weight is transferred from the old URL to the new.

A "302 Moved Temporarily" will have a different effect.

This causes the search engine to retain the old address, and the new address, simultaneously. This, in turn, causes duplicate content indexing, which search engines see as a typical spammer tactic. They will penalize the search weight of any blog or web site using a "302 Moved Temporarily", for this reason.

You can use a browser based meta refresh to redirect your blog.

It's not hard to setup a meta refresh in the blog template, to redirect your readers from the old URL "myblogoldurl.blogspot.com" (where you publish a stub blog) to "myblognewurl.blogspot.com" (where you publish your current blog).

Find

<head>

Add

<meta content='0;url=http://myblognewurl.blogspot.com' http-equiv='refresh'/>

Giving

<head>
<meta content='0;url=http://myblognewurl.blogspot.com' http-equiv='refresh'/>

Browser based redirects are detected by Blogger as malicious.

Unfortunately, browser based redirects, using a meta refresh, or JavaScript redirect, will be seen by the search engines as a "302 Moved Temporarily".

Blogger may detect this as a browser hijack, as it's splog detection constantly detects splogs that are using this same tactic. Plus, the search engine will continue to index the content after the meta refresh as "myblogoldurl", giving no weight to "myblognewurl".

When you forward the address of your blog, for any reason, be it the BlogSpot address to the domain, or any secondary domains to the primary domain, using a "301 Moved Permanently" redirect is by far a better idea.

Custom Domains Use 301 Redirect, From BlogSpot

When you setup a Custom Domain, the setup wizard provides encouraging advice

We won't leave your readers behind!
http://myblog.blogspot.com will redirect to your custom domain.

Blogger accomplishes this bit of trickery, using standard Internet protocol - a 301 Redirect - but it's done in two steps.

Blogger redirects a Blogger blog, using two steps.

• When you publish your blog, "myblog.blogspot.com", to your custom domain, "mydomain.com", all internal links within the blog are changed, from "myblog.blogspot.com" to "mydomain.com".
• When the transition period ends 72 hours later, Blogger sets up a standard server based "301 Moved Permanently" for your blog.
• Note that only the blog internal links are changed - any links which you added, from post to post, are your responsibility. Likewise, all external links are your responsibility.

The search engine spiders, which previously indexed your blog as "myblog.blogspot.com", now index it as "www.mydomain.com".

Everybody who looks at the URL sees the blog published as the domain URL.

Similarly, your readers see "www.mydomain.com". To everybody, even those intending to look at the old BlogSpot URL, you now have "www.mydomain.com" for a blog URL.

The "301 Moved Permanently" referral from BlogSpot is similar to the "301 Moved Permanently" referral used in Custom Domain DNS setups, to equate "mydomain.com" to "www.mydomain.com".

In both cases, when this technique is used properly, the clients - either the people who read the blog, or the search engine spiders that index the blog - see the contents of the blog as being part of the redirect target. Now, they see "www.mydomain.com", instead of "myblog.blogspot.com".

The BlogSpot to domain redirect is installed in the Blogger server, not in the blog.

This "301 Redirect" is server based. If you put a meta tag, or JavaScript, based "301 Redirect" or "302 Redirect" into your blog, you will cause problems for your readers. Both are treated similar to a "302 Moved Temporarily", and your blog loses search engine weight.

In some cases, your readers will see

Too many redirects!

or a similar error, following a gratuitous redirection to block country local domain redirection, installed by you. In other cases, the BlogSpot URL simply does not operate.

The "Too many redirects!" error is more frequently seen, with "HTTPS" accessible blogs published to custom domains - and with the "HTTP" to "HTTPS" redirection. Here, too, a properly setup custom domain is essential.

Some non Google services, which use a URL to identify you, must be updated.

Note that this redirect applies mainly to search engines, following links. It won't apply to feeds, which need the updated URL in their database. It will apply to your readers - but readers who monitor the address window in the browser may become confused, if they see the new, non-BlogSpot URL where they are accustomed to seeing a BlogSpot URL.

You still need to notify your readers, and you still need to update all external fixed URL references to the blog, such as FeedBurner and other custom feeds, Google Webmaster Tools, and the various visitor meters.