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

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

Use The Post Feed Redirect URL, When You Rename Your Blog

When we rename a blog, we use the Post Feed Redirect URL to redirect all feed references, from the old URL to the new feed URL.

When we setup a custom feed for a blog, maybe using FeedBurner, we use the Post Feed Redirect URL to redirect all feed references, from the blog, to the FeedBurner feed. That lets us use a FeedBurner feed without having to change all of the feed links in the blog.

Besides using the Post Feed Redirect URL to setup a FeedBurner feed, you can use the Post Feed Redirect URL when you re publish the blog to a new BlogSpot URL.

Please! Be sure to setup the Post Feed Redirect in the proper direction.

Using the post feed redirect is a simple, 1 - 2 - 3 exercise.

1. Publish a stub blog, to the old URL.
2. Determine the URL of the blog post feed, under the new URL.
3. Set the post feed redirect, for the stub blog.

Publish a stub blog, to the old URL.

Immediately after you re publish the blog to its new URL, you should be setting up a stub blog, to visually point your readers to the new URL. Besides visually pointing your readers, you can re point your subscribers - again using the stub blog.

Determine the URL of the blog post feed, under the new URL.

Copy the updated feed URL from the blog header. Precision is essential when redirecting the feed, so let Blogger do the work for you here - determine the new post feed URL, properly.

Set the post feed redirect, for the stub blog.

Go to Settings - Other, for the stub blog, published to the old URL. Edit the "Post Feed Redirect URL", and paste the new feed URL, as just copied.

When you do this, all subscribers to your blog, under the old URL, should see the blog feed in its new home, with linked content. The search engines, indexing the blog using a sitemap based upon the old URL, should start indexing it using the new URL.

Properly done, this should give your blog, under the new URL, a good start towards regaining the search engine reputation that it had, under the old URL.

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.

The Blog Feed Redirect Option Needs To Be Used Properly

When you setup a Blogger blog, and use a properly configured feed, the combinations of comments, labels, and posts feeds can do wonders for making your blog more accessible and maintainable. You have a number of feeds, with URLs based upon the URL of the blog, to work with.

For more possibilities, you can use a custom feed, provided by an aggregation service like FeedBurner or FeedDigest. When you use a custom feed, you can even redirect references, within the blog, to the custom feed, so you don't have to manually reconfigure things like post footer feed links.

You redirect feed references using the dashboard setting in Settings - Other - "Post Feed Redirect URL".

Always use this setting properly - only put a valid feed URL in the box, or you will end up with a broken blog feed. A valid feed could be:

• A feed from another Blogger blog, as when you move the blog to another URL, and setup a stub blog with a redirected feed.
• A valid external URL - one provided by FeedBurner, FeedDigest, or a similar service.

Do not point this internally, to the same BlogSpot or domain URL. You cannot use this to simply change the URL of the feed for any one blog - it must be used in conjunction with a second blog, or a custom feed setup.

Here's the redirect setting, for this blog:

http://feeds.feedburner.com/Nitecruzr-Blogging

That's my FeedBurner feed URL. Yours will be similar, excepting the

Nitecruzr-Blogging

If you use the URL of a feed for the same blog, you'll end up with a feed redirect loop. If your readers see anything from the feed, when it's directed to itself, it will be something like

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

If you have no FeedBurner or second blog feed to redirect into, or if you don't know what is needed here, leave this setting blank. If you're using the setting, and you're experiencing a feed related problem, you should first clear the setting.

Also, be aware of the interaction between the Google Sitemap and the blog feed. A Google Sitemap will break, if you redirect your blog feed to a URL outside the blog naming space.

Finally, note that the blog feed is intended to let your readers read your blog, with greater ease. It's not designed to let you randomly distribute the blog content to the Internet, while abusing your Followers and subscribers.

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.