Blogger Magic - Export From A Blogger Blog

One of the most useful skills, when maintaining and publishing a blog, is backing up the content.

As you publish a blog, it's a very good idea to periodically backup the content - comments, pages, and posts. Sometimes, backed up content may save you hours of anguish.

Backed up content is not a waste of time or resources.

Backing up content - comments, pages (static pages), and posts (dynamic pages) is a very quick task - that consumes a minimal amount of resources.

Many people will benefit from a daily routine of backup. Backed up content can be used, in a variety of ways - if it is available.

Periodic backup of content is simple - and may save you much inconvenience.

Start from Settings - Other.

Click on "Back up Content".

Click on "Save to your computer".

Some operating systems may leave the browser, to save your content.

Click on "Leave".

Now, you use the file manager provided by your operating system, to select a file / folder, and actually save the file.



"Back up Content" is useful, in several tasks.

You'll find that daily backups uses a minimal amount of time, and computer resources. And even if you don't ever use the backed up content, you will be better off having it.

• Exporting content, to a different publishing system.
• Moving content, to another blog.
• Recovering from a corrupted template.
• Saving updated content.

All of these tasks use the "Back up Content" wizard. Do this regularly - and you won't regret it. Just remember where you save the content. Setup one or more standard folders, on your local computer.

---

Using the "Back up Content" #Blogger dashboard wizard is a good task to do frequently - and regularly. It will save you a lot of time and trouble, if ever needed.

Blogger And iOS Mobile Computer Support

People frequently observe significant differences between products from Apple / Google / Microsoft.

Since all three corporations are separate (and highly competitive), they have their own corporate philosophies and development timelines. Despite all of that, Blogger tries to make their product supportable, across all corporate lines.

Unfortunately, the Blogger service is not always consistently usable, with all browsers - or mobile computer / smart phone apps.

One problem, that not all Blogger blog owners may realise, is that Apple does not submit their product changes to Google, for testing.

With a lack of advance testing, Blogger Engineering cannot react fast enough, to changes in iOS. The Blogger iOS app has long been a source of complaints, in Blogger Help Forum: Get Help with an Issue.

Blogger is rolling out SSL - and this delays other needed changes.

Right now, Blogger is making a major overhaul to their infrastructure, to support the SSL rollout. Simultaneously updating the Blogger app, to support iOS, would not likely be a productive activity.

With the SSL Rollout in process, Blogger suspended iOS app support some time ago. The Blogger app was removed from the Apple Store, several months ago - and this has been a source of various complaints, since.

Owners of iOS based computers need patience.

Apple Phone owners may need to be patient. Blogger Engineering may have to finish the SSL Rollout - hopefully, with support for custom domain publishing - and then rewrite the Blogger app for iOS.

In the mean time, iOS computer owners are suggested to use the Blogger dashboard, in a desktop browser, for maintaining and publishing their blogs. In order of recommendation - they should use Chrome, Firefox, or Safari.

---

The #Blogger smart phone app for iOS was removed from the Apple Store, some months ago. This was not a popular change - but it was a responsible business decision.

Blogger And iOS Mobile Support
http://blogging.nitecruzr.net/2016/06/blogger-and-ios-mobile-support.html
Blogger And iOS Mobile Computer Support
http://blogging.nitecruzr.net/2016/06/blogger-and-ios-mobile-computer-support.html

Effectively Testing Reader Access To Your Blog

People reporting a problem with blog access / performance, in Blogger Help Forum: Get Help with an Issue, will be frequently advised to diagnose their problems using affinity / differential testing.

Some diagnostic advice starts with simple instructions to "clear cache, cookies, and sessions". Some people, alternately, advise "use a different browser" - and test as a reader. These different strategies, seemingly redundant, will frequently lead to different results.

When you test reader access to a blog, some experts will casually advise you to "use a different browser" or "use a second computer".

There are specific reasons why this strategy may or may not be successful, when part of affinity / differential testing. When you test blog access, you're going to see varying reliability - based on a number of browser and reader details.

There are multiple ways to test blog access, of owner vs readers.

Any experienced testing technician knows that the most reliable testing, in affinity / differential analysis, will use identical browsers, on identical and separate computers.

Very few blog owners will have use of a bank of identical computers, for testing. There are alternate possibilities, when identical computers can't be used.

• This browser, in the primary session - after "clear cache, cookies, and sessions".
• This browser, in a secondary session - aka "Incognito" / "Private" browsing.
• A different browser, on the same computer.
• The same branded browser, on a different computer.
• Any browser, on a different computer.

All of these details will be relevant, sometimes - though not always. The differences between "always" and "sometimes" will lead to some testers using incomplete testing techniques - and cause inconsistent results.

This browser, in the primary session - after "clear cache, cookies, and sessions".

The best way to avoid environment based inaccuracy is to re use the environment, sequentially. This approach requires more time - plus development of a testing script, to keep testing procedures consistent.

It is, however, the best way to avoid confusion from inevitable testing variations.

Using the same browser, in the same browser session, one can try using a different identity. This technique starts with the apocryphal instructions to "clear cache, cookies, and sessions".

This browser, in a secondary session - aka "Incognito" / "Private" browsing.

Some browsers support multiple sessions. In Chrome, a secondary session is provided as "Incognito" mode - and in Firefox, a similar (not identical) option is called "Private" browsing. The differences between the "Incognito" and "Private" features are significant - and can cause different testing results.

This blog, displayed in "Incognito" mode.



A different browser, on the same computer.

Each different browser will have differences in the browser itself. Plus, different add-ons and settings, on the different browsers, will produce differing results.

Having both browsers on the same computer will eliminate computer setup differences, present when multiple computers are involved.

The same branded browser, on a different computer.

If the branded browser, on the two computers, is maintained identically, there is a chance for consistent results. Having two different computers involved, however, may offset the consistency gained by using identical browsers.

Any browser, on a different computer.

This is the most inaccurate testing procedure, of the choices listed. Any difference between the browsers, or computers, can lead to inaccuracy.

The differences, in testing, involve multiple details.

• Login identity in use.
• Cookie filters, that block identity.
• Script filters, that block identity access.
• Browser add-ons, that may or may not be present.
• Browser brand and design differences.

Login identity in use.

This is the one difference that you intentionally need, to test the reader experience. In the primary session, you are logged in as the owner. You require at least one secondary session - where you are not logged in as the owner, to test your blog as a reader.

The secondary session is where the need for sequential session reuse - or use of a different browser and / or computer - becomes necessary.

Cookie filters, that block identity.

Many Blogger features - involving both the dashboard, and access to the blog - use cookies to determine identity and permissions. Cookie filters, inappropriately managed, can cause havoc with Blogger. As an example, consider commenting ability, and third party cookies.

Different browsers may have different cookie filter settings. In some cases, identity is not relevant, for testing as a reader.

If you are testing access to a private blog, though, reader identity - which is cookie based - will be essential. A cookie filter involved, with a private blog being tested, will cause problems.

Similarly, testing Google+ comments requires known identity - for both the blog owner and readers. With Google+, identity is essential, to guarantee consistent display of comments.

Script filters, that block identity access.

Many Blogger features - involving both the dashboard, and content in the blog - are JavaScript based. Script filters can cause havoc with Blogger.

Different browsers may have different script filter settings - and different browser brands may have completely different script filters.

Browser add-ons, that may or may not be present.

The Firefox browser does not have native script filters, so many computer owners who use Firefox will add NoScript.

NoScript is a very intense add-on, with a lot of options, and opportunities for confusion. If you were to use Firefox on two different computers, you would need to carefully synchronise NoScript settings on both computers, for reliable testing.

Firefox with NoScript is the best known example - but it's not the only possibility for confusion. Every browser can have script filters, which will make browser to browser testing comparison a challenge.

With Chrome, one can select each individual add-on to be present in the secondary session ("Allow in incognito") - and this will create uncertainty. Some advice to "try using a Chrome incognito window" will be successful, with other advice being useless - and the absence or presence of the necessary add-on will be one of the issues.

AdBlock, optionally included in incognito mode, will produce uncertainty in testing - and is a well known script block.



Browser brand and design differences.

Every different browser produces differences in displayed content. Even a formatting discrepancy can lead to difference in test results.

The end results.

Interpreting test results, based on comparison of different browser displays, will be a challenge for anybody trying to produce reliable conclusions. The most reliable results will come from testing using the same browser session, sequentially. This will start with instructions to "clear cache, cookies, and sessions" - a painful but necessary process.

---

Many #Blogger problems need to be diagnosed using repetitive testing, and affinity / differential analysis. People who don't understand organised testing will sometimes recommend testing procedures, such as use of different browser sessions - which will produce inconclusive results.

Blogger Magic - Backup The Template

It's always wise to backup the blog contents - and the template.

If you are publishing a blog, you may occasionally make a mistake. Being able to recover from a mistake, using backed up content, is always a good idea.

Blogger provides a dashboard wizard to backup the blog template - and a complementary wizard, to backup blog content - comments, pages, and posts.

Backing up a Blogger blog template is reasonably simple.

The template backup wizard is on the dashboard Theme page.

Start from the dashboard Theme page.

And click on "Backup / Restore".

Then click on "Download full template".

This will give you a standard file save wizard, that is used by your computer.



The file save wizard will depend upon the operating system.

On my computer, the file save window is "Save file as". Your computer operating system might have a similar wizard - or it may be different.

Other than choosing file and folder (your choice, on your computer) for backing up the template content, you just sit back and let the backup work. Don't wait too long though - a few seconds is all that it should take.

Understand how and why to backup.

Just don't backup blindly - or for the wrong reasons. To be useful, a backup needs to consider how to restore - and why you might restore.

Any backup is more useful, if you plan how and why you might need to restore.

---

As you develop a #Blogger blog, making regular backups of the template is always a good idea. Everybody makes mistakes - and recovering from a template coding mistake is a lot easier, if you're able to restore a previous template copy.

https://productforums.google.com/forum/#!category-topic/blogger/-7808eOAZ7c

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.

The Publishing display, for a "blogspot.com" published blog.



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

The Publishing display, for a custom domain published blog.



Useful text details, for a custom domain published blog:

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

With a custom domain published blog, next 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 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.

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


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


If you purchased the domain using a credit or debit account, the bank statement and / or charge advice will frequently have a description which details the purchase. In some cases, this will include the domain name.

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.

Our Blog Content Is Our Responsibility

We see evidence of occasional confusion, in Blogger Help Forum: Get Help with an Issue, about blog content responsibility.

One of my blog posts disappeared. I have tried every known recovery procedure. There is no way to actually contact anyone from Blogger Support.

Long ago, Blogger Support would provide assistance, in recovery of deleted posts. That service ended some time ago.

Blogger promises us that our blogs will be ours, forever - and that they will support that promise.

That promise is most likely to be upheld if we maintain control of our blogs - and of the content in the blogs.

Blogger will ensure that our blogs remain under our control - but we have to maintain the content. If we change or delete a post, Blogger is not going to second guess our intention, and revert our change, or un delete our deletion.

If we change a page or post, there are two possible recovery procedures.

• Undo the change - using the browser editor menu.
• Recover the contents - using search cache.

Undo the change - using the browser editor menu.

If you make a mistake, the Blogger post editor, like many edit windows, supports "Undo" aka "Ctrl - Z". You have to act immediately, though. If AutoSave becomes active, you may not get the chance.

Recover the contents - using search cache.

This is the procedure currently used, for recovering deleted pages and posts. It is most effective, for established (cached) pages and posts - draft and new pages and posts may not be found, in cache.

Our chances are otherwise limited.

Short of using undo or cache recovery, we may be out of luck - if we make a change that needs to be reversed. As long as we do not violate Content or TOS Guidelines, our content is ours - to have and to maintain.

---

As we publish our blogs, Blogger promises us that they will ensure our ownership, forever. That promise requires that we take responsibility for any mistakes - and that we take responsibility for the content in our blogs.

Don't Backup Your Blogs, By Duplicating Them

THis month, we have several reports in Blogger Help Forum: Get Help with an Issue from owners who make backup blogs.

Why was my blog deleted, by Blogger, as spam?

Some blog owners innocently create multiple blogs, to back up their main blog.

Unfortunately, having multiple blogs with the same content may make the blogs look like a spam blog farm - and Blogger detects and deletes spam blog farms.

I've been advising blog owners, for years, that Blogger blogs need informative, interesting, and unique content, to survive as Blogger blogs.

Scraped blogs - whether you scrape your own, or another person's - are a bad idea.

The general focus on "unique" is intended to discourage scraping. Blogger Help: Spam, phishing, or malware on Blogger discusses spam blogs.

Spam blogs cause various problems, beyond simply wasting a few seconds of your time when you happen to come across one. They can clog up search engines, making it difficult to find real content on the subjects that interest you. They may scrape content from other sites on the web, using other people's writing to make it look as though they have useful information of their own. And if an automated system is creating spam posts at an extremely high rate, it can impact the speed and quality of the service for other, legitimate users.

In the past, Blogger has been focusing on blog owners who steal the work of other blog owners, ie, "scraping" - or who copy by permission, ie, "syndication".

Blogger Content policy defines scraping more explicitly.

Examining Blogger Content Policy, we see the problem expressed more vividly.

Spam: Spam takes several forms in Blogger, all of which can result in deletion of your account or blog. Some examples include creating blogs designed to drive traffic to your site or to move it up in search listings, posting comments on other people's blogs just to promote your site or product, and scraping existing content from other sources for the primary purpose of generating revenue or other personal gains.

Having backup blogs can look like "blogs designed to drive traffic to your site or to move it up in search listings". This is a technique, used by spammers. Why bother to write content? Just use some of the clones, as clones - both to backup each other, and to boost search engine results.

Duplication of content, online, hastens classification as spam.

Backing up a Blogger blog actually duplicates Bloggers efforts. Blogger / Google stores content - ie, your blog - in a cloud of servers, worldwide. If any one server goes out of service, the others are there, to provide immediate backup. You will, likely, never even notice if any one Blogger server goes down.

Alternately, a blog owner might backup a blog because of the spammer publicised unfair blog deletion policy. Here, the blog owner is playing into the spammers hands. If backup blogs were permitted, spammers could publish their spam blog farms with impunity.

Here, what the blog owner wants to plan for by having duplicates, unfair deletion, actually hastens the unfair deletion. This will happen, even if you make the "backup" blog private.

Classification of duplicate content, as abuse, isn't spurious.

If you think about it, a blog classified as spam, because of multiple clones, isn't actually spuriously deleted. If your blog gets a spurious classification, as a possible spam host, you have to appeal the classification. Creating a new blog, with identical content, just makes you look like a non repentant spammer - and increases your vulnerability.

If you want to retain comments and posts, export to an offline file. Just don't spread duplicate content across the Internet.

Diagnose Problems, With Blogs Using Dynamic Templates, Using Non Dynamic Templates

The process of examining browser source listings for a blog, and of having a blog owner carefully examine blog template code, is an important part of diagnosing many Blogger problems.

With blogs published to dynamic templates, neither source listings, nor template "Edit HTML", contain as much useful information, as with blogs published to non dynamic templates. Dynamic templates reference scripts, that are hosted in external libraries - and that cannot be updated or viewed.

The idea of having templates that were less customisable was originally supposed to encourage people to work on post content, and increase stability of their blogs - not create instability.

One of the original reasons for having the dynamic templates was to have templates that would encourage blog owners to work more on content - and less on style.

Dynamic templates were designed for less customisation - and increased reliability.

Having the less customised templates would, hopefully, have made the dynamic templates more reliable. Unfortunately, Blogger chose to add features to the dynamic templates, to make them more popular.

The "infinite scrolling" feature of the dynamic templates impressed people, who decided that "infinite scrolling" would be useful for their blogs - but without having noted that dynamic templates have less options for customisation.

People, who like the existing dynamic templates features, demand more features for them. And, they cause more problems, for themselves - since many of them lack the ability to diagnose their own problems.

Eliminate general blog problems, by re publishing to a non dynamic template.

Any time a blog problem is diagnosed, and the problem involves a blog that uses a dynamic template, it's a good idea to start by re publishing the blog to a non dynamic template. Try to diagnose and eliminate any general blog problems, before tackling problems caused by tweaking of dynamic templates.

Just go to the dashboard Template wizard, and choose any non dynamic template - then "Apply to blog". Then, reset the post template (if the posts are involved, in the problem).

Publishing to a non dynamic template lets us use standard diagnostic tools.

With the blog published to a non dynamic template, you (the blog owner) can use the Template Editor to examine general (non dynamic) template CSS, HTML, and / or XML code. Also, you (and any helpers) can use a browser "View Source" window, to examine the rendered blog code.

If you diagnose a problem with non dynamic code, you can edit and correct any problems found. Once that is done, and you are satisfied that there are no non dynamic template related problems, re publish the blog to a dynamic template - and diagnose any remaining problems.

As always, template backups are strongly advised.

If you decide to make any changes to the template code, as always, I advise that you backup the template - before and after making changes. Whenever you detect a problem, recover the template to the backup taken before the changes, and see if this fixes the problem noted.

'Good Enough' Never Is, With Custom Domains

This month, we're seeing an interesting collection of problem reports, in Blogger Help Forum: Get Help with an Issue, about custom domain setup.

Why is my blog offline - occasionally?

And

Why do some (just some!) of my readers tell me they can't see my blog?

Investigating the problem, we see that the domain is, indeed online - some of the time.

Investigating the DNS addressing, robustly, we find an all too frequently seen set of name servers:

mydomain.com. 14400 IN A 216.239.32.21
www.mydomain.com. 14400 IN CNAME ghs.google.com.

What we see here is a domain, setup by someone who thought that one server would be 'good enough' to get by.

One server will, sometimes, get by - for a while, and for some people.

What some blog owners fail to realise, though, is that DNS service is never the same, all over the world (or the Internet). People in some places will use one DNS name server - and people in other places will use another.

And similarly, DNS service is never the same, from day to day. Today, you might need the services of one DNS name server, and tomorrow you might need another.

This month, we're seeing a number of reports that suggest that the Google name server at "216.239.32.21" is not responding for everybody. Now - don't everybody, who has a custom domain published Blogger blog start spitting coffee, and calling their registrar for emergency support.

People who have a properly setup domain should not worry, needlessly.

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

People with domains that provide a robust set of addresses are in better shape. The odds that all 4 name servers will fail, simultaneously, is near zero. It's much better than those with one name server, that is 'good enough for me' - and that, right now, provides the basis for this post.

Really, folks.

mydomain.com. 14400 IN A 216.239.32.21
www.mydomain.com. 14400 IN CNAME ghs.google.com.

One "A" name server was good enough for you, last month. It's not, now. How many of your readers, since last month, saw

404 Not Found

How about your search reputation. What happens, when your blog is being indexed, and the search engine gets

404 Not Found

Neither your readers, nor the search engines, appreciate

404 Not Found

And both will react, negatively - and you won't like the results.

'Good enough' isn't - for everybody, all of the time. And this affects the reputation of your blog, both with people, and search engines.

Complaint Volume Affects Speed Of Abuse Resolution

We see various complaints, in Blogger Help Forum: Something Is Broken, about perceived poor response, in removing offensive blogs.

I've reported this blog, repeatedly, for impersonating me - and it's still online!

or

That other blog was removed from service after only a couple of days! Why is this blog still online??

These bloggers do not understand that complaint volume, against different blogs, can affect how promptly Blogger Policy / Google Legal can take action, and remove problem blogs.

Various details affect how many complaints are placed, against any blog.

• Offensiveness. A blatantly offensive blog will offend more people - and will be reported by more people, than a mildly offensive blog.
• Traffic. An offensive blog that gets hundreds of hits daily will be seen by more people, than a blog that gets a few hits daily - and will be reported by more people.
• Victims. An offensive blog that attacks hundreds of people will get reported more than a blog that is only personally offensive, to a few people.

Each of these minor details will cause some blogs to attract more complaints - and to be examined sooner, by Blogger and by Google staff.

Blogger Policy Review and Google Legal prioritise blog investigation, based on complaint report volume.

Blogs which get hundreds of complaints will receive attention sooner than blogs which only get a few complaints. In some cases, the complaint volume may even be used as a major factor, in the final decision to terminate the blog. This is simple business practice, and one more principle of Risk Management.

Knowing that complaint volume affects resolution speed, do not make unnecessary multiple complaints - maybe under multiple accounts or names. Google Security uses sophisticated traffic analysis techniques in dealing with denial of service attacks - such as referer spam, and brute force password guessing. They can apply similar techniques to determine that multiple abuse complaints, against specific blogs, are coming from one person.

Don't subject your computer, or Google account, to placement in a "Denial Of Service" complaint offender database, from detected multiple attempts to have a mildly offensive (or personally offensive) blog deleted, for odd reasons - such as you need to delete your blog, but forgot the password.

Don't misuse the abuse reporting system. Remember that the other blog owners have rights.

Report an offensive blog once - then, be patient. And let Google Legal objectively evaluate the content of the blog in question.

Please, NEVER Share Your Blogger Account!

We see signs of naivete, in Blogger Help Forum: Something Is Broken. too often.

I gave my boyfriend (girlfriend, former spouse, Internet acquaintance, whatever) my account password - and now, I can't access my account.

This is a problem which Blogger cannot resolve, in any way.

Please, never ever share your Blogger account. Blogger accounts, like Blogger blogs, are free.

If someone who you know would like to read your private blog - or contribute to your team blog - add that person as a blog member, and let her / him use his / her own Blogger account (new, or existing).

There is absolutely no need for you to ever share your Blogger account.

Use private / team blog membership, when applicable.

Shared Blogger accounts carry all of the risks of team blog ownership - and more. Do not share your personal Blogger account to provide private blog membership, or team blog ownership.

Blogger does not provide an option to protect blog content, using a shared password. If you want to password protect blog content, make the blog private, and add readers. Let your readers use their own password (with their own Blogger account).

Split a blog into a security cluster, if necessary.

If you want to password protect a portion of a Blogger blog, break the blog into two portions - the public portion, and the private portion, and provide the private portion as a private blog.

Private blogs, with large reader communities, will require imaginative setup.

If you must have a private blog with more than 100 members, and you cannot use Google+ as an email based distribution medium, setup a read only account to access the blog - and let the members share that Blogger account.

If you setup a shared Blogger account as a blog member (read only), you'll need to maintain a separate mailing list of all shared members. Use BCC to email everybody (don't share everybody's email address with everybody else), giving them the shared account name and password. Save the mailing list, carefully.

With 100+ shared account members, chances are that one day, somebody will change the password on the account, and lock out everybody else. You'll have to then setup a new Blogger account, make that account a new read only blog member, cancel the old member, and email everybody with the new shared account name and password.

If you must have a community, of over 100 members, and let everybody share (not just read), use Google+ - or setup a wiki based website. Your needs are far beyond the ability of Blogger.

When another person works on the blog, they can use their own account.

If you need someone else to work on the blog, make them a blog member or administrator - with their own Blogger account. If their usefulness is temporary, when they are done, revoke their access to the blog - then verify that they did not leave any back door code behind.

Your account name and password is your personal identity.

In any case, keep your account and password (and the blog ownership) private, to you.

Use common sense. Do not share your Blogger account.

• Do not share your Blogger account with your boyfriend.
• Do not share your Blogger account with your girlfriend.
• Do not share your Blogger account with your husband.
• Do not share your Blogger account with your wife.
• Do not share your Blogger account with your boss.
• Do not share your Blogger account with your employee.
• Do not share your Blogger account with your collaborator.

I've warned everybody that team blogs are security risks - but they are way safer than team Blogger accounts.

• Do not wear other peoples underpants.
• Do not share your Blogger account.

Both are rules to live by.

Spammers, And Content / Risk Management

Spammers protect their content against "unfair" deletion, and provide uninterrupted service to their "customers", by publishing multiple blogs, in spam blog farms.

Owners of better designed spam blog farms minimise the risk to their blogs, by separating the hacking / porn / spam content (Payload), from the immediately visible Blogger blogs (Collector). Spammers use a tiered structure of blogs, in their blog farms.

• Collector blogs.
• Distributor blogs.
• Payload blogs.

Only the Payload blogs contain easily identified hacking / porn / spam material - and only the Collector blogs are immediately visible to the abuse detection processes.

A tiered blog structure makes a more easily managed spam blog farm.

Collector blogs (lots of these) link to the Distributor blogs (many of these), which link to the Payload blogs (a few of these). This is good risk management, by the spammers, because it separates the visible content from the identifiable content.

In some cases, the Payload "blogs" might be non Google websites. Content hosts which have no objection to hacking / porn / spam content can host the Payload, with no risk.

Risk levels differ, according to content in each blog.

• Payloads (much risk, because of the detectable hacking / porn / spam content).
• Collectors (some risk, because of the detectable ads - plus invisible, automated links, to the Distributors).
• Distributors (little risk, only because of the invisible, automated links, to the Payloads).

As an example, one spam blog farm might be structured in geometrical progression.

Collectors (25) --> Distributors (5) --> Payload (1).

See the triangular structure, and the redundancy?

If automated links were permitted, only the Gateway blogs would be need to be advertised, to Blogger blog readers. If any of the Collector and / or Distributor blogs are detected and removed, the spammer can simply activate more blogs - and the Payload blogs can remain undisturbed.

If any Payload blogs are detected and removed, the spammer simply adds more Payload blogs - then updates the links in the Distributor blogs, with the URLs of the new Payloads. This is good project and risk management.

To interfere with this activity, Blogger prohibits automated linkage of blogs to other blogs and to non Google websites. This forces the spammers to provide visible links between the blogs and websites - and requires them to imaginatively publish both "legitimate" Collectors and Distributors with interesting and unique content and links.

Tweak The Post Template, Only When Necessary

Occasionally, we see the query, in Blogger Help Forum: How Do I?

How do I change these captions? / Add this feature? / Remove specific components of this feature?

Conversely, we see in Blogger Help Forum: Something Is Broken

Why does this new Blogger feature not work in my blog?

These questions, in many cases, may be related. We can see the connection, when we look closer at how the changes are applied.

Many changes to our blogs, that are part of the comments / posts / post header / footer, are made in the post template.

The post template is an unobtrusive section in the blog template, that lets us change the blog template as we wish - while allowing Blogger to update the comments and posts code, as they add new features, or update existing features.

Blogger lets us change the post template, using "Configure Blog Posts".

Blogger provides the "Configure Blog Posts" wizard - and lets us change specific features in the post template.

The options in "Configure Blog Posts" do not satisfy everybody - and here is where many problems start. Some blog owners want features or selections that are not provided by "Configure Blog Posts" - but are part of the post template.

Some features have to be installed as post template tweaks.

To install these features, the blog owner uses the Template Editor, and tweaks the "Blog1" template widget.

Once the post template is tweaked, by the blog owner, the blog has a non standard post template. When Blogger applies their next post template update, to install or update a Blogger supplied feature, against a blog with a non standard post template, they have 3 options.

1. Overlay the entire post template, with their updated post template. The blog owner sees all tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
2. Overlay specific portions of the post template, with their updated post template changes. The blog owner sees some tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
3. Not install the updated post template. The new Blogger feature doesn't work - and the blog owner is left complaining about broken Blogger updates, while other blog owners are enjoying the new feature.

When Blogger upgrades the post template, what happens to your tweaks?

If Blogger updates the post template, and some owner applied features disappear or stop working, the blog owner can simply install the necessary tweaks, again. Having kept the notes, or code snippets, from the original install, many blog owners simply install everything again.

Unfortunately, if the Blogger post template changes were applied in the same post template section as the owner applied tweaks, the owner retained notes or code snippets may be out of date - and installing them again may break one or more Blogger supplied features.

Some post template tweaks can have effects outside the post template.

Some owner applied changes, if installed improperly, can affect other sections of the template, in general - and cause mysteries such as problems updating accessory gadgets, and problems using the Template Designer.

The end result is that owner installed post template tweaks must be made, selectively - and any Blogger changes, publicised or non publicised, may necessitate re install of any owner applied tweaks. Owner applied tweaks must be re installed, character by character - and frequently with the readers complaining about an unexpected change or broken blog.

The post template is actually another example of "well enough", for many blog owners.

---

Tweak The Post Template, When Necessary - And Only, When Necessary

Copy And Paste The Ownership Verification Details

The Custom Domain Ownership Verification requirement has been with us for over a year - and we still see confusion, and easily corrected mistakes.

One of the most frustrating mistakes involves mistyping of the details.

I keep getting an "Error 12". My registrar insists that the DNS addresses are right.

But, the registrar must be wrong, since the blog just can't be published!

When you type the base domain DNS addresses, into the registrar's zone editor, eyeballing what you type is somewhat obvious. Either you get it right - or you don't. Typing the domain ownership verification details, on the other hand, is not so simple.

When you setup your domain, you know the domain name. Who's buried, in Grant's Tomb, anyway?

You probably spent hours, choosing just the right domain name. Choosing an available, yet memorable, domain name is not a simple task. Some consultants make the domain name an essential, initial choice, in setting up a company.

Since you know the domain, when you setup the base DNS addresses, it's reasonably easy to get that right. Having gotten the base DNS addresses setup just right, you try to publish the blog to the domain - and now you get the infamous "Error 12".

An example of the "Error 12" display.
See the short, and long, tokens?


The problem with the "Error 12" is not just having to setup one more DNS address. You already setup 2 - or maybe 5 - to get the base DNS addresses. The big problem here is the content of this second "CNAME".

You know every character of the base DNS addresses. You've typed all of that, over and over. Then, you look at the second "CNAME" - which contains pure random garbage.

Pure random garbage that is essential, on a character by character basis. Get just one character wrong - or omitted - or reverse any characters, in sequence - and the "Error 12" never goes away.

• The “Name / Label / Host” value ("short token") is exactly 12 characters.
• The Destination / Target / Points To” random value ("long token") is exactly 14 characters.
• Do not confuse a “O” / “o” (alphabetic characters) with a “0” (numeric character).
• Do not confuse an “l” or "t" (alphabetic characters) or a “1” (numeric character).
• Do not confuse a "w" (single, alphabetic character) with a "vv" (two alphabetic characters).

Do you have a good quality magnifying glass handy? Use it - and look at the differences and similarities, in the above 5 cases used above, as examples.

When you get an "Error 12" or similar, and the message includes a section

Name, Label or Host field Destination, Target or Points To field

The only proper procedure here involves use of the clipboard. Copy / paste the short token, then copy / paste the long token.

Don't type by hand. Please. And when you copy then paste, keep in mind the zone editor entry syntax, which is essential to a working domain - and differs from registrar to registrar.

After Setting Up Your Custom Domain DNS Addresses, Always Verify Your Work

So many problems with custom domain publishing start with incorrectly setup DNS addresses. Sometimes the problems start with misunderstanding about the rigid requirements of DNS addresses, other times misunderstanding about how to use the Domain Manager tools provided - and sometimes the registrar gets involved, and causes problems.

Many times, I'll offer advice in Blogger Help Forum: Something Is Broken, and the reply will indicate the confusion.

Here's a screenshot of my settings - I can't see a problem!

or

I just got my registrar to setup the DNS addresses, as you gave me. Surely, they are right?

But we diagnose the problem, and find that the addresses are still wrong.

In business, we learn of the importance of using well known, standard testing procedures. People setting up a custom domain would do well to learn this concept, also.

I have a diverse assortment of online tools, which I use for diagnosing custom domain publishing problems. Here are three (as always, in alphabetical order), which I use to examine and verify DNS addresses.

• Kloth Dig.
• Name.com Dig / Who.Is Lookup.
• WebMaster Toolkit Dig.

Each tool complements the other two - none of them are a replacement for the other two.

Kloth Dig

• Lets you copy and paste the output, easily.
• Lets you Dig the domain root, or any specific aliases.
• Lets you select what host to perform the Dig.

Name.com Dig / Who.Is Lookup

• Lets you check results promptly, not waiting for TTL to expire.
• Lets you reference the result using an included URL.
• Lets you do a Who Is lookup, to complement the Dig.

WebMaster Toolkit Dig

• Lets you copy and paste the output, easily.
• Lets you Dig the domain root, or any specific aliases.
• Lets you reference the result using an included URL.

Prompt Verification Is Essential.
When you make changes to the DNS addresses, you will want to check your results, promptly - waiting for DNS cache to expire, varying according to TTL, causes confusion. The Name.com Dig accesses the domain master server, so you can generally see results promptly. To cross check the Name.com Dig, you can use the Kloth Dig - and reference the domain master server, explicitly.

All Domain Hosts Must Be Verified.
When you make changes to a Non Root Virtual Host, you'll need to Dig the results. Both Kloth and WebMaster Toolkit let you specify the host name, to target in the Dig, so you can target any host - not just the domain root and "www" aliases.

Ability To Copy And Paste Results Is Useful.
It is useful to copy and paste the results from any Dig transaction. Both Kloth and WebMaster Toolkit Digs provide results that are not table bound, and can be easily copied and pasted.

Ability To Reference The Result In The URL Is Useful.
It is useful to save a one click link to check Dig results, to avoid having to repeatedly paste or type a domain URL to be checked. Both Name.com and WebMaster Toolkit provide results that can be checked by clicking on a link, which you can bookmark.

A WhoIs Lookup Is Useful
Many times, the domain status, examined using a WhoIs lookup, provides an essential clue. Both when a domain purchase is unsuccessful, and when a domain registration has expired, a Name.com Who.Is Lookup will lead to the problem diagnosis.

Each of these tools provide vital details and features, that the others do not provide. And each of these tools, used properly, can help somebody to avoid posting in Blogger Help Forum: Something Is Broken, frantically asking for help.

>> Top

Account Recovery, Evaluated As Return On Investment

Too many Blogger blog owners, seeking recovery of a long dormant account, overlook the realities of the Blogger business relationship.

I started the blog 10 years ago, I have forgotten the password, the email address is long gone - and I need the blog deleted now.

When told that deletion is not possible, if you cannot provide proof of ownership, they next ask for personal assistance.

But isn't there a person to whom I can explain my problem? Surely we can reach some understanding!

The reality is that Blogger wants to help their customers - when helping their customers provides them some business benefit.

Any business, that hopes to remain a business for any amount of time, has to understand the realities of Return On Investment, combined with Risk Management.

One basic calculation of ROI is

(Sum of benefits) / (Sum of costs)

Both benefits and costs can be tangible (income, expense, etc) and non tangible (inconvenience to customers, increased / decreased reputation, etc). Projects which provide more ROI can be scheduled, with more urgency - and projects which provide less ROI, with less urgency.

In problem management, problems which affect many people, when solved, produce some benefit. Problems which affect few people, when solved, produce little benefit.

A project which involves account recovery requires individual assistance, and benefits only the claimant - thus provides very little benefit.

It will require considerable research, to verify the identity of the person who setup an account or blog, and to verify the identity of the person asking for assistance - thus much cost. Additional cost would be the risk of encouraging more Blogger blog owners to overlook the necessities of blog ownership - and to not bother with remembering account name and password - thus ensuring more of the same, later. And there's the risk of enabling a deceptive blog hijacking.

ROI for most account recovery projects is very low.

A project which requires blog deletion (when ownership cannot be proven by the
claimant) provides even less benefit than simple account recovery - as the only result is the removal of one dormant Blogger account / blog. And it involves the same cost - both the same amount of research - to verify identities - and the same risk of encouraging more, similar thoughtlessness. And again, there's the risk of enabling a deceptive blog hijacking.

ROI for blog deletions is even lower than for simple account recoveries.

Both account recovery and blog deletion, when accepted as activity in the Blogger Support action queues, will, out of necessity, not receive high priority.

The memory of impatience, from previous claimants, will motivate many Blogger experts and Blogger Support staff to simply quote the Google Help advice.

At Google, we take your privacy and security very seriously. Therefore, we're committed to returning accounts only when we're sure we're giving them back to the accounts' owners. Because Google doesn't ask for much personal information when you sign up for an account, we don't have many ways to verify that you own an account.

Some advice given will be somewhat perfunctory.

Please, read the FAQ, and objectively consider the bigger picture.

This attitude, too, is an expectation of low ROI - special service demanded by people who never did anything with their blogs - and now, plan to simply move their blogging activity to WordPress.

Identify The Gadgets In The Template, Reliably

When you tweak the code in a gadget, based upon my instructions, you'll be editing the template HTML. Or, you might be using the Layout wizard, to locate and remove a problem gadget.

You'll do most editing with widget code unfolded. You'll have a lot of code to sift through - and with many gadgets in your blog, there's always the chance that you'll see the code for one gadget, and confuse it for another.

If you delete or tweak the wrong gadget, you may not like what you get. Before deleting anything, or editing the template, take an extra minute, and find the specific gadget, by its name. This could save you a lot of grief.

Here, I'll look at the Welcome message in my Buzz blog.

This is what I did, as I tweaked it to make it show up only on the Home page.

So, welcome to The Buzz.

If I right click on the screwdriver / wrench ("dragonfly") under that gadget, and select "Copy Link Location" (or possibly "Copy link address"), I can paste the URL into Notepad for easy examination.

Alternately, use the Layout wizard, click on "Edit" - and stretch the gadget window out horizontally, until the entire URL is visible.

http://www.blogger.com/rearrange?blogID=6525860816441104874&widgetType=Text&widgetId=Text1&action=editWidget

The gadget in question is "Text1". To find the code to tweak, I use the Template "Edit HTML" wizard - and completely unfold the code for "Text1".

<b:widget id='Text1' locked='false' title='' type='Text'>
<b:includable id='main'>
<b:if cond='data:blog.url == data:blog.homepageUrl'>
  <!-- only display title if it's non-empty -->
  <b:if cond='data:title != ""'>
    <h2 class='title':gt;<data:title/:gt;</h2>
  </b:if>
  <div class='widget-content'>
    <data:content/>
  </div>
</b:if>

  <b:include name='quickedit'/>
</b:includable>
</b:widget>

That beats an eyeball based search, any day. It's 100% reliable, and takes just a few seconds to find the code for "Text1". After you do this a few times, you'll be able to hover the mouse, and spot the widgetId=Text1 in the URL display in the browser status area - and go straight to

The gadget in question is "Text1".

---

(Update 2014/12): If you use a text browser, you can locate and identify a problem gadget, much more easily.

---

>> Top

Renaming Your Blog - Planning The Change Properly

Your blog depends upon traffic for its success.

Anything that affects the traffic to your blog, such as a change in the URL, affects the success of your blog. If you republish your blog to a different BlogSpot URL, as with migration to a custom domain, you will not lose any content. Both comments, posts, the template, and all custom settings, will stay with the blog. And if you plan the republishing effort, you can minimise the loss of traffic.

Properly planning the migration, to a different BlogSpot URL, will require different techniques than a simple custom domain republishing.

All 3 URL changes produce similar effects, though - and it's in your best interest to do what you can, to minimise the effects.

1. BlogSpot to BlogSpot URL change.
2. BlogSpot to custom domain re publishing.
3. Custom domain to BlogSpot re publishing.

All 3 changes require your blog to be re indexed by the search engines - and leave the blog with less search engines generated traffic, while being re indexed.

A BlogSpot to BlogSpot URL change is different from a custom domain publishing.

Custom domain re publishing has a feature that BlogSpot to BlogSpot URL changes lack. This will reduce negative effects of the URL change - with the domain properly setup.

With a custom domain republishing, the old (BlogSpot) URL is redirected to the new (domain) URL, using a "301 Moved Permanently" instruction. A "301 Moved Permanently" redirect simply repoints each individual URL in the blog to the new URL.

Unlike a custom domain renaming, you cannot choose an available URL, before you begin.

This post (using the domain URL) is "blogging.nitecruzr.net/2010/03/renaming-your-blog-planning-change.html". I can, alternately, advertise it as "bloggerstatusforreal.blogspot.com/2010/03/renaming-your-blog-planning-change.html". That's the "301 Moved Permanently" redirection, in action. All traffic is forwarded, automatically.

There is no way to add "301 Moved Permanently" redirect to a BlogSpot rename.

Blogger won't provide a "301 Moved Permanently" for a BlogSpot rename, as this would encourage spammers to move their splogs around, endlessly. The best that you can do is to use a stub blog, with proper planning.

If you want the blog offline permanently - or if you don't want other people recreating the blog under its current name, you will want to plan the renaming - just as you would (or should) plan a deletion. If the URL becomes available, the same content / impersonation / privacy issues will exist.

Consider the categories of traffic sources, and the effects.

As with a custom domain migration, you'll want to consider the traffic to the blog, in categories.

• Blog Feeds - Automated processes, that help your readers track changes to your blog, using a newsfeed reader.
• Following - The two way community process, that lets you see who your readers are.
• Google Webmaster Tools - Key diagnostic and management utilities, that - among other things - enable indexing of the blog by the search engines.
• Search engines - Robotic processes which methodically surf your blog, and provide dynamic indexing to people who search for information.
• Viewers - People who read your content from their browser.

Blog Feeds are the easiest and cleanest category to redirect. Even though Blogger won't provide a "301 Moved Permenantly" for the blog URL, they will provide this for the feed URL, using a blog post feed redirect URL.

With the post feed enabled for both the live blog (under the new URL), and the stub blog (under the old URL), set the Post Feed Redirect URL for the stub blog to the exact value of the feed URL for the live blog. Your Followers and subscribers, using the old URL, will continue to see newsfeeds for your live blog, while using the old URL.

Following, with the renaming done correctly, is easy to redirect. Your Followers, as mentioned above, can view the blog feed using the old URL, with no problem. With the blog renamed simply using Settings - Publishing, your Followers will continue to be associated with the blog, with no further action by you.

Google Webmaster Tools are a vital part of the migration, and should be handled immediately after you re publish the blog, and then immediately after you setup the stub blog. You'll have several challenges here.

1. The "robots.txt" file for the blog, as renamed, may contain the old URL.
2. The new URL for the blog won't exist in Google Webmaster Tools, so you have to add that. When you verify blog ownership, you'll have to remove the GWT verification tags for the blog, that were used under the old URL.
3. You'll have to setup sitemaps for all posts in the blog, under the new URL, to complement / replace those under the old URL before the blog was re published.

The search engines will be the most frustrating part of any blog rename. Without any possibility of a "301 Moved Permanently" redirect, or anything remotely similar, any SERP hits will land the prospective viewer on a 404 display. Your best strategy is to manage the other categories aggressively, and hope that the search engines re index your blog promptly under the new URL.

Your viewers will have to be redirected using the stub post in the stub blog, published under the old URL. Your viewers looking for the main page of the blog will see the stub post, with no problem. Your viewers clicking on a direct link to a single post, an archive or label search, or possibly a SERP hit, will get a 404 display.

Page not found
Sorry, the page you were looking for in the blog The Real Blogger Status does not exist.

Go to blog homepage

The "Go to blog homepage" link will, hopefully, display the stub post - and they can follow the link to the new URL. That's a start, and it's all thanks to the Blogger custom 404 display.

OK, lets summarise the tasks involved.

1. Is this blog published to a Google custom domain? If so, read about specific issues related to custom domain URL changes.
2. Re publish the blog, under the new URL.
3. Enable the feeds, and verify feed URLs.
4. Setup Google Webmaster Tools for the blog, under the new URL. Look in the Sitemap list for the blog. Any sitemaps in there right now will likely point to the old URL, so these need to be removed. Then, add sitemaps for all posts.
5. Setup a stub blog, under the old URL.
6. Set the Post Feed Redirect URL, to point to the feed for the new URL.
7. Check Google Webmaster Tools for the blog, under the old URL. Look in the Sitemap list for the blog. You'll probably have to re add all sitemaps for the blog, to enable the search engines to index the blog, starting from the old URL, through the redirected feed.
8. Are you using a FeedBurner (or another custom feed)? If so, update FeedBurner, then check the Post Feed Redirect URL setting.
9. Check and update all Google Webmaster Tools settings, between the old and new URLs. Think carefully about each setting, and decide whether it should apply to the blog under the old URL, under the new URL, or both.
10. Are you using Mail-to-Blogger to publish to the blog? If so, check your Mail-to-Blogger addresses.

And if possible, read about the details involved in the rename process before you rename the existing blog. This last caution especially applies to changing one non BlogSpot URL to another non BlogSpot URL.

Including Content From Other Websites In Your Posts

I use excerpts of articles from other websites, in a few of my posts - when the other websites provide more in depth description of the issue being discussed.

I use some websites, such as WikiPedia, more than others. It's good practice to at least link back to the originating website, when copying or quoting any significant amount of unique content. There are so few restrictions, in general, what content we may include in our blogs - so it makes sense to be polite when we include content from other websites.

In most cases, and to keep my posts relatively short, I prefer to simply quote a brief, relevant snippet of content, and link back to the originating website.

In WikiPedia: Occam's razor, we see the advice

the simplest solution is usually the correct one.

For best results, ask for permission from the legal owner.

Since every different blog / website, with a different owner, could be published under a separate content policy, it's always best to ask for permission, before copying. Without permission, you could find yourself here later, asking about various content related penalties.

• Some owners might appreciate the free publicity.
• Other owners might not want their content used in another website.
• Some owners might be paying a third party for the right to use their content.

You won't know, until you ask.

I like to add " target="_blank"" to any link that takes the reader to another website, however temporary.

In WikiPedia: <span style="font-style:italic;"><a href="http://en.wikipedia.org/wiki/Occam%27s_razor" target="_blank">Occam's razor</a></span>, we see the advice<blockquote>the simplest solution is usually the correct one.</blockquote>

Content such as Lorem Ipsum is ancient public domain, and it's available all over the Net. It may or may not be necessary to attribute that, for brief snippets.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

When you include original content from a specific website, however, it's good practice to attribute.

The text is derived from sections 1.10.32-33 of Cicero's De finibus bonorum et malorum (On the Ends of Goods and Evils, or alternatively [About] The Purposes of Good and Evil ).[3] The original passage began: Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit (Translation: "Neither is there anyone who loves grief itself since it is grief and thus wants to obtain it"). It is not known exactly when the text acquired its current standard form; it may have been as late as the 1960s. The passage was discovered by Richard McClintock, a Latin scholar who is the publications director at Hampden-Sydney College in Virginia, by searching for citings of the rarely used Latin word "consectetur" in classical literature.[1][2]

The original version (with the excerpted items highlighted) appears in Book 1, sections 1.10.32-33 (pagination varies by publisher):

[32] Sed ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo. Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet, consectetur, adipisci[ng] velit, sed quia non numquam [do] eius modi tempora inci[di]dunt, ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit, qui in ea voluptate velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla pariatur?
[33] At vero eos et accusamus et iusto odio dignissimos ducimus, qui blanditiis praesentium voluptatum deleniti atque corrupti, quos dolores et quas molestias excepturi sint, obcaecati cupiditate non provident, similique sunt in culpa, qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio, cumque nihil impedit, quo minus id, quod maxime placeat, facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet, ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.[2]

- From Wikipedia: Lorem Ipsum

Blogger spam classification looks for scraped content.

Blogger is now diligently screening blogs for "spam" and other forms of misbehaviour. One of their classifications of "spam" is termed "scraping". Many blogs consist, largely, of content scraped from various websites, minimally relevant.

Your blog needs more than scraped content - if you wish to continue.

People who publish blogs that contain material from other websites, simply must make it a consistent practice to distinctly attribute copied material - or face the possibility of spam classification by the Blogger bot.

Note that, however you attribute, yor blog will simply serve as a gateway to the other source blog / website. With the other website higher in page rank than yours, you'll just be sending your readers to theirs - and the SERPs will list theirs ahead of yours.

You're not going to gain much - except empty volume - by including their content.

You will be responsible for content from other blogs and websites.

Note that any time you include material from - or link to - another blog or website, what you include or link to must be abuse and malice free. You are responsible for the comfort and safety of your readers - and anything that you do, to possibly disturb their comfort or safety, can cause your blog to be locked or deleted, as abusive or malicious.

A connection to another blog or website - using a feed, iframe, or link - puts a portion of your blog under the control of the other blog or website. If an abuse / spam classification bot determines the other blog or website to be abusive / malicious, your blog will suffer the consequences.