Blog PageView Counts, And Social Sharing Activity

Ever since 2009, when Blogger introduced the Stats visitor activity counter, blog owners have been reporting inconsistencies between Stats and other visitor activity counters.

Recently, Google+ changed their +1 counter. Now, we wait for Blogger Engineering to update their +1 per post display counters, which use the +1 counts from Google+.

Blog owners continue to report various Stats inaccuracies - such as discrepancies between Stats pageview counts, and the various social sharing counters. They fail to observe the functional differences between the various activity counters - and similarly, between Stats counts and social sharing metrics, such as Google+ +1 counts.

Stats pageview counts and Google+ +1 counts compare no better, than Stats and various other visitor activity counters.

Social sharing contributes to your blog reputation, in a number of ways. Some social sharing relationships, compared with blog activity counters, may lead to confusion.

Social networking activity counts will resemble blog visitor activity counts - with the activity mentioning the blog.


There will be differences, between the two, however. The differences will contribute to perceived blog visitor activity count inaccuracy.

• You will have Followers - in asymmetrical and symmetrical relationships.
• You will have Followers - in direct, and indirect relationships.
• Not all Followers will read your blog posts.
• Some folks who do read your blog posts will be invisible, to you.
• The bottom line is reputation, for you and for your blog.

You will have Followers - in asymmetrical and symmetrical relationships.

Social sharing helps to connect people, through their interests.

You may read some posts in your Google+ stream, which will interest you. Some people will contribute many posts that interest you - and you will decide to Follow them. Those people may observe your activity, and decide to Follow you, in a symmetrical relationship.

You won't Follow everybody, symmetrically. Nobody can Follow everybody - or even everybody who Follows them.

Some people will share few interests with you, and have many interests that you don't have. You won't Follow those people.

Similarly, some people who you Follow won't Follow you, because you don't interest them.

You will have Followers - in direct, and indirect relationships.

If you use FaceBook or Google+ enough, you will see random posts in your stream - and decide to Follow some authors. Similarly, some of the people who see your posts, in their streams, will decide to Follow you.

You will +1 / Like / re share some posts from your Followers - and some of your Followers will do the same, with your posts, directly. Some folks who Follow your Followers - not you, directly - will +1 / Like / re share your posts, indirectly.

Not all Followers will read your blog posts.

If you spend time reading your activity notifications, you may observe that some Followers may +1, like, and / or re share, your various stream posts - including some stream posts which reference your blog posts. You may also observe that some activity takes place seconds, or minutes, after you share or re share a stream post.

Your ability to observe, and to react, will depend upon your relationship with each Follower - direct vs indirect, and asymmetrical vs symmetrical.

When a stream post is liked or re shared shortly after you share it, it's possible that your Follower did not spend a lot of time reading the content of the post. If your share included a reference to your blog post, it's likely that they did not read your blog post - even though they contributed a +1 / like / re share of your stream post.

Even though your direct Followers may not all read your blog posts, their Followers (your indirect followers) may do so. These followers will contribute to your reputation, indirectly, with a +1 / like / re share of your stream post.

Some blog owners, not aware of, or interested by, these details, may believe the +1 counters to be 100% accurate - and this contributes to perceived Stats pageview counts inaccuracy - with Stats counts seen as "lower than reality".

Some who do read your blog posts will be invisible, to you.

Nobody who uses Google+ will Follow - or be Followed by - everybody.

Most Google+ publishers will have direct Followers, who they know - and indirect followers who they don't know. Google+ will protect indirect followers identities, by not displaying their activity to people who don't know them (you, for instance).

Since Google+ protects everybody's activity and identity, from people who they don't know, Likes and +1s against your posts will include people who you don't know. People who Follow your Followers will contribute likes and +1s against your posts, indirectly - even though you will not see their activity in your stream, directly.

In the 8 hours since I published this post, I've seen one Google+ notification about a "+1", from a Follower. Yet Blogger shows a "+4".


The first "+1" came when I shared this post, to my Google+ stream. Where did the other 2 "+1"s come from?

These people will contribute to your reputation, even though they may be invisible to you. This is one of the reasons why the +1 counters are thought to be inaccurate.

Some of these invisible people, encouraged by your Followers, will read your blog posts - and contribute to your Stats activity counts. Some may decide to Follow you directly - and / or to subscribe to your blog, even though you don't see them, in your stream.

This, too, contributes to perceived Stats pageview counts inaccuracy - with Stats counts seen as "higher than reality".

The bottom line is reputation, for you and for your blog.

Higher or lower than "reality", it's all good - even when you don't always see the details, in FaceBook or Google+.

---

People who use social sharing, such as FaceBook and Google+, with their #Blogger blogs, will find discrepancies between social sharing activity counters, and blog visitor activity counters. These discrepancies will be as intriguing as the differences between the many activity counters.

Adding Whitelist Entries, To Adblock Add-Ons

Ad blockers are popular Chrome add-ons, which let us manage various websites abilities to serve ads in our browsers.

Many ad blockers include a script blocker. Like NoScript in Firefox, ad blockers may interfere with various Blogger features - such as the "Don't track" script, in the dashboard.

If you publish a Blogger blog, and you have a problem with any pages in the Blogger dashboard, you will want to whitelist "blogger.com" in your ad blocker.

You will do better if you not whitelist "blogspot.com". BlogSpot includes many Blogger blogs - and third party code on those blogs. If you are not very picky about what Blogger blogs you view, you won't do well permitting scripts on every Blogger blog.

Adblock Plus is an extension, in Chrome.

I use "Adblock Plus" as an ad blocker, on my Chrome installations. "Adblock Plus" installs as an app, or an extension.

There are several ad blockers available, for Chrome.



I use the "Adblock Plus" extension, in my Chrome installations.

Start with "More tools" - Extensions.

Select "Options" for "Adblock Plus".

Adblock Plus "options" are also accessible from the browser toolbar. Right click on the ABP icon, and select "Options".

Select the "Whitelisted domains" tab.

Let's whitelist "addthis.com".

Paste / type "addthis.com" into the box. Hit "Add domain".

And now, "addhis.com" is whitelisted.



And having whitelisted "addthis.com", I can support a useful third party social sharing blog accessory, by permitting ads that they host.

---

Some #Blogger blog owners use ad blockers in their browsers - and see problems with using various Blogger features. The Stats "Don't track", for instance, is vulnerable to ad blockers, and similar filters.

Fortunately, it's not difficult to whitelist "blogger.com" in your adblocker.
target="_blank"

Is There A Purpose To Referer Spam?

We've been experiencing - and discussing - referer spam, since 2011.

We still see unaware blog owners, asking in Blogger Help Forum: Get Help with an Issue.

When I checked my stats for my blog, and looked at traffic sources, I noticed a link from a different country - and it just seems weird that Russian readers would then go to a US site.

When we explain that they're probably seeing another referer spam attack - and that clicking on the links is not always a good idea, we get a variety of responses. Some want to know if there is a purpose, to this noise.

Referer spam has a variety of purposes - ranging from commercial, to dangerous, to deceptive.

Garbage? Or a purpose?



Here are just 3 examples, from Blogger Help Forum: Get Help with an Issue.

• Advertise any paying customer.
• Lead you to a website with hacking content.
• Attack innocent third parties.

Advertise any paying customer.

This is the commercial possibility. If there's money to be made from publishing informative, interesting, and original content, there is probably lots more money to be made herding innocent third parties to ads on any website needing traffic - and lacking informative, interesting, and original content.

This may even represent a variation of GPT. And with the volume of referer spam that's possible, there are surely enough naive blog owners to make this a very lucrative activity.

Lead you to a website with hacking content.

This is the dangerous possibility. With hacking activity as a possible destination, clicking on a Stats link blindly is like playing "Russian Roulette", with your computer.

And, don't expect the website URL to provide a clue as to the destination. "www.innocous-name.com" could itself be hacked - and might unknowingly serve content from "www.hacking-website.com" - or redirect to "www.hacking-website.com".

Attack innocent third parties.

This is the deceptive possibility.

My blog was a "victim" of referer spam attack, in 2011. I have seen similar referer spam reports, that suggest this is not an unusual use of referer spam.

Protect yourself - if you must investigate your referers.

Surely, there are still actual people surfing - and some referer links are genuine. Eventually, you will want to check out some of the more intriguing URLs, in "Traffic sources".

If you decide to investigate one of the links, copy the text of the link URL - then use a proxy server.

Just don't investigate links, without protection. That's what proxy servers are for.

---

Some #Blogger blog owners want to know if referer spam has a purpose - or if it is simply random noise. It actually has a variety of purposes - commercial, dangerous, and deceptive.

Blogger Magic - Enabling Scripts, In Your Browser

Similar to the need to properly filter cookies in the browser, we have the need to properly filter scripts.

Cookies and scripts are completely different elements - but proper filtering of each is essential, to making many Blogger features operate properly.

If you have a problem with Blogger - either accessing / using the dashboard, or using / viewing a blog - one of the simplest things to check, complementing cookie filter settings, is the browser script filter settings.

The browser is the most important component, when setting up security - and scripts, like cookies, are a common challenge.

Script filters are adjusted differently, for each browser. Consider the multiple domains used by Blogger / Google - and layered security, on any computer, used by the owner and readers of any blog.

• Chrome.
• Firefox.
• Edge / Internet Explorer.
• Opera.
• Safari.

Setting the script filters in Chrome.

With Chrome, you enable scripts, using Settings ("Customize and control Google Chrome") - aka the 3 bar toolbar icon.

In Settings, if necessary, click on "Show advanced settings" at the very bottom of the page.

Under Privacy, click on "Content settings", which gives you the "Content Settings" wizard. Here, you have selections for Cookies and Javascript - including "Manage exceptions" for each section. Select the recommendation.

• JavaScript: Allow all sites to run JavaScript

Hit "Done" - and close the Settings tab.

From "Privacy", hit "Content settings".

Under "JavaScript", select "Allow all sites to run JavaScript (recommended)".



Alternately, you may select "Do not allow any site to run JavaScript" - then use "Manage exceptions", and allow all blog(s) that you publish, and the many Blogger and Google domains, to run JavaScript. Make your exceptions complete, for best results.

Setting the script filters in Firefox.

Firefox does not contain any native script filters. The most popular add-on for Firefox is NoScript - and this is how most Firefox users filter scripts.

You'll need to designate "blogger.com", "google.com", and any Google domain excepting "blogspot.com", as trusted - when you load any display for the domain in question. An untrusted domain will show a "NoScript Untrusted" icon in the status area at the bottom of the window. To enable each domain, you position the cursor over the NoScript icon and select "Allow (domain URL)" in the popup menu.

Setting the script filters in Edge / Internet Explorer.

With Internet Explorer, you enable security settings - both cookies and scripts - from the browser menu, using Tools - Internet Options. Optionally, you may access the "Internet Options" applet directly from the Windows Control Panel.

• IE uses a zone defense setting, where you designate "blogger.com" and "google.com", in Security, as being in the Trusted zone. Please note that "blogspot.com", in general should not be in the Trusted zone - .
• You will want the published URL of your blog(s) - including any country local domain URLs, in the Trusted zone.
• Default settings for the Trusted zone will allow proper filtering of scripts.
• Verify proper settings, with "Trusted sites" selected, and the Security level slider control set to "Medium". Hit "Custom level", and examine the Settings list.
• Look for the "Scripting" section, 3/4 of the way to the bottom of the list.
• You will observe 6 options under "Scripting". Default settings will have all options Enabled, except "Allow Programmatic clipboard access"; you may wish to Enable this to allow easy use of Post Editor.
• Hit "OK", and "Yes" if necessary, then "OK" again.

Setting the script filters in Opera.

With Opera, you enable cookies and scripts from the Advanced tab, in the Preferences wizard. The Content menu contains selections for scripting.

Setting the script filters in Safari.

With Safari, you enable scripts, using the Preferences wizard. The Privacy wizard, in Preferences, contains selections for scripts ("Cookies and website data”).

Script filters cause problems with Stats "Don't track ..." and other Blogger features.

Many problems, reported in Blogger Help Forum: Get Help with an Issue, with various Blogger features - and the Blogger dashboard - involve script filters.

Stats and the "Don't track ..." option used to involve third party cookies, for many years. In March 2016, the "Don't track" wizard was rewritten to run under the URL of the blog, when being set - and now requires enabling scripts from the blog URL.

Consider how your blog is published.

If your blog is published to "blogspot.com", consider the non "blogspot.com" alias that may be relevant to your country. If your blog is published to a custom domain, consider the custom domain URL.

Many computers have other relevant settings, which block scripts.

Many blog owners and readers will have computers, and networks, with additional protection. Scripts, in the browser, may not be the only filter that needs to be checked - but this is a start, to learning how to control the script filters.

Having checked and corrected your script filters, continue by checking browser cookie filters - then check cookie and script filters, outside the browser. Also check settings on any ad blocker add-on - which may be an app, or a browser extension.

Be aware that many settings may not be obvious - and that both obvious and obscure settings may be updated, without your intention or knowledge.

---

Many #Blogger problems are cause by overly restrictive script filters. If you, a blog owner or reader, are going to use Blogger successfully, you need to configure your browser properly - for both cookies and scripts.

Stats "Don't Track" - You Cannot Satisfy Everybody

Blogger recently redesigned the Stats "Don't track ..." option - and removed third party cookies from the picture.

The "Don't track ..." wizard is now accessed from the blog URL. The wizard still produces cookies - but they are ordinary first party cookies, which are much less feared than third party cookies.

But, every silver lining has a cloud.

In making the "Don't track" wizard accessed under the blog URL, Blogger created a new requirement - which is no more understood, by some blog owners, than "third party" cookies.

"Don't track" now runs scripts from the blog URL, instead of the Blogger dashboard.

In order for a blog to observe - and preserve - the "Don't track" setting, any computer that the owner uses has to permit first party cookies - and all scripts - from the blog, instead of from the Blogger dashboard.

Since "Don't track" is designed to be used by the blog owner, this new requirement should not be a problem. Every blog owner should be able to trust herself / himself, to not add dodgy code to his / her own blog.

Owners of blogs published to custom domains will have to tweak the URL used by the "Don't track ..." Stats wizard, to set "Don't track" - since custom domains do not support HTTPS.

Many security products block scripts from personally owned blogs.

Unfortunately, general security practice is to block scripts from "blogspot.com", "blogspot.xx" (for every "xx" for every country local domain"), and preferably for blogs published to custom domains.

You can trust scripts from "blogger.com", and the Blogger dashboard. You cannot trust the individual blogs, since you cannot trust every blog owner. Even if you could trust some people not to intentionally try to hack your computer, you cannot trust everybody to not stupidly install malicious software from a very convincing hacker, providing one more "gotta have this" blog accessory.

And since you cannot trust the individual blogs, you will have filters. And those filters have to be adjusted, to trust your own blogs - if you want to ignore your own pageviews.

Some blog owners add security software, and don't know how to maintain the filters.

There are too many Blogger blog owners who have installed protective software on their personal computers - without knowing how to adjust the filters, in the protective software. And some of those owners think that it is a Blogger responsibility, to provide them instructions, how to adjust the protective software on their own computers - when only they are capable of knowing what they installed.

---

The new version of the Stats "Don't track" option is an improvement, because it no longer requires third party cookies - and involves the associated security risk. Unfortunately, it now requires blog owners to permit scripts, from the blogs themselves.

This is not a security risk, in that only personally owned blogs need to be trusted - but the blog owners do need to know how to adjust the filters involved. And not everybody with a computer knows how to configure their security accessories.

Blogger Magic - Stats Accuracy And Consistency

One of the least understood Blogger features is the Stats visitor counters, and the various displays.

We see the confusion, in Blogger Help Forum: Get Help with an Issue, periodically.

The "weekly" Stats numbers don't add up, properly!

or

Why is "Popular Posts" so out of touch, with reality?

Magic is fun to watch, when it's just for amusement. When your numbers seem to have magical quality - changing from day to day, or display to display - it becomes annoying.

With its many lines and pages, the various Stats displays look like they could be part of one big balance sheet - but they are not.

With a balance sheet, you'll have detail lines in one page, that can be added up and reconciled against totals, in another page. This makes some balance sheet components redundant.

With Stats, nothing is redundant. Whether provided in a dashboard page, for you to examine - or in a gadget, to encourage your readers - all numbers are significant, exactly as displayed.

What you see for each day cannot be added up and balanced against a week - nor can a collection of weeks add up to a month. Nor can detail lines in "Pages" add up to totals, in "Audience".

• Components and features are provided for different purposes.
• Different dashboard pages reflect different details.
• Time periods do not begin and end equally.
• You may, or may not, be able to ignore your own pageviews, consistently.
• Social sharing activity will cause confusion.

Components and features are provided for different purposes.

The "Popular Posts" gadget displays popular posts, for the convenience of the blog readers - and there is no "Popular Pages" gadget, for people who choose to build a blog, based on static pages. The dashboard Stats pages are displays for informing the blog owner.

The (3) time range selections in "Popular Posts" also differ from the (5) selections in the dashboard Stats pages - further preventing comparison between Popular Posts and dashboard displays.

Different dashboard pages reflect different details.

The "Posts" dashboard page lists (only) the 10 most popular posts ("dynamic" pages), and the 10 most popular pages ("static" pages). "Pageviews today", and "Pageviews yesterday" reflect all blog activity - all index pages, all "pages", and all "posts" together.

Time periods do not begin and end equally.

"Pageviews today", and "Pageviews yesterday" counts are reset based on the global day - not on any local clock. Your "today" will never be the same, all days of the year - if ever. 23 / 24 of the world will never see their "today" equal to "Pageviews today", and "Pageviews yesterday".

And everybody knows that weeks, months, and years never begin and end in synch. You cannot add up weeks into months - nor months into years.

"Pageviews today", and "Pageviews yesterday" are the best known objects of confusion - but by no means the only - in the Stats data complement.



You may, or may not, be able to ignore your own pageviews, consistently.

Even given the recent improvement to the "Don't track" option, not all blog owners will be able to ignore their own pageviews. Every blog owner has their own required complement of performance and security products, which may interfere with the Stats "Don't track" code.

Social sharing activity will cause confusion.

Blog owners who use social sharing services for community building - and who follow activity in their stream - will observe various inconsistencies. Both inflated counts, and deflated counts, will be perceived, when reconciling stream activity and blog visitor counts.

The bottom line.

Everybody needs to accept reality - that Stats will simply perform differently, for every different blog, and for every different owner of every team blog. Enjoy and use Stats for what it is.

---

Many #Blogger blog owners become concerned, when they add up detail Stats numbers on one display, and find the numbers do not agree with the totals from another display. They do not notice that the numbers have different origins, and purposes - and simply cannot add into any different display, with any degree of accuracy.

The New Stats "Don't track" Option, And Script Filters

The new Stats "Don't track" option is an improvement, to many blog owners.

"Manage tracking your own pageviews", as before, starts from the Stats dashboard page. The wizard now runs from a sub directory of the blog managed by the dashboard - and uses a normal (first party) cookie.

Now, blog owners no longer must enable third party cookies, to make Stats ignore their page views. This is an improvement - but it can still present a challenge, for some blog owners.

Besides filtering "third party" cookies, not all blog owners and readers will permit complete control by content under the individual blogs.

If you want "Don't track" to work reliably, enable scripts for the blog URL.

If you want the "Don't track" option to work reliably for your blog, you now must enable scripts to run under the published URL.

We have to trust scripts run from "blogger.com" - that is the Blogger dashboard. The Blogger dashboard is produced by Blogger Engineers - and if we trust Blogger to host our blogs, we have to trust their code.

Scripts which run under the individual blogs - "blogspot.com", local country domains, and custom domains - can be added by the owner of each individual blog. Not all blog owners should be trusted.

People who mistrust third party cookies may also mistrust scripts which run under "blogspot" etc. Unfortunately, to make "Manage tracking your own pageviews" work, you (the blog owner) now have to open up any script filters, which block content run as part of your blog.

Start from the Stats dashboard page.

Click on "Manage tracking your own pageviews".



"Manage tracking your own pageviews" now runs under the blog published URL. This removes "third party" cookies from the problem.

With a custom domain published blog, you must use the wizard in "HTTP:" mode.

By default, the new wizard runs in SSL mode. This will be a problem, with blogs published to custom domains.

If the blog is published to a custom domain, you will need to change "https" to "http".

Check "Don't track my views for this blog." - then close the tab / window.



The new wizard, "Would you like to have your pageviews counted when you visit this blog?", now runs as "blogging.nitecruzr.net", for this blog.

http://blogging.nitecruzr.net/b/statsCookieManage

If you publish to a custom domain, and you can correct the URL, you will see the same, for your blog. If you publish to "blogspot", you can see the same also. This is a script - and the script is subject to security filters.

And yes, there is no "Save" button, or link. Just the box.

Don't track my views for this blog.

Click the box or don't. As soon as you click, it's set. If you change your mind - now or later - click the box, again, and clear the option.

You should trust your blog - even though you do not trust other blogs, in general.

Generally, as the blog owner, you can safely trust content run under your blog. You probably should not trust "blogspot.com", and all blog publishers, however. This means that you will require multiple filter rules - for every browser and security add-on, that contains a script filter.

• Block all "blogspot.*". (Please!).
• Permit "yourblog.blogspot.com".

If you publish to "blogspot.com", and live in a country which has a local domain, such as the UK, you need a rule to permit the local domain alias.

• Permit "yourblog.blogspot.co.uk".

If you have multiple blogs - and want to block pageviews from being counted, for each blog, you need permissive filter rules for each blog.

• Permit "yourblog1.blogspot.*".
• Permit "yourblog2.blogspot.*".
• etc.

If you publish your blog to a custom domain, you need a rule to permit the domain URL. For this blog, I need

• Permit "blogging.nitecruzr.net".

If you do not permit the proper URL(s) for your blog, you will find Stats counting your own pageviews. Possibly, this will happen even with "Don't track my views for this blog." checked. In some cases, the check mark will be cleared, when you close the window.

---

Owners of #Blogger blogs who don't want their activity tracked by Stats now see a new "Don't track" wizard. Using the "Don't track" option no longer requires enabling third party cookies - and worrying about the security issues.

Unfortunately, this now means that the "Don't track" wizard may now be vulnerable to filters which restrict scripts that run under blogspot, and any custom domains.

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

Blog owners have been trying to block tracking their own Stats pageviews, for a few years.

This option has long been unusable, for blogs published to custom domains. Recently, Blogger Engineering updated the option - and the dashboard page with the link.

The new Stats option to "Manage tracking your own pageviews" is an improvement, over the old dashboard page.

The new Stats option page is run as part of the blog - not the Blogger dashboard - so it does not require third party cookie access. Unfortunately, this provides no obvious help, to people who publish their blogs to custom domains.

To see the problem, start from the Stats dashboard page.

Click on "Manage tracking your own pageviews".

And, you get "This site can’t be reached" or a similar error.



Custom domain published blogs do not support HTTPS access - even from the Blogger dashboard.

So, change "https:" to "http:", in the address window.



If you manually remove the "s", you can access the "Would you like to have your pageviews counted when you visit this blog?" wizard.

http://blogging.nitecruzr.net/b/statsCookieManage

You can't access the "Manage tracking your own pageviews" for a custom domain published blog, by simply clicking on the dashboard link.

This suggests an interesting detail. Now that "Manage tracking your own pageviews" runs under the blog URL, it will be subject to script filtering - for "blogspot.com", any applicable country local domains, and / or a custom domain URL.

You may need to correct your browser script filter, to make "Don't track" work, now.

---

Owners of custom domain published #Blogger blogs have been wanting to block Stats from counting their own pageviews, for a few years. This option is now available - but not in an obvious way.

Stats Logs, And Cached Page Access

Some blog owners like to validate their Stats displays, using third party visitor logs like StatCounter.

Since Stats displays aggregated page view counts - not individual visitors - a blog owner will find many discrepancies between Stats and StatCounter. One observation might involve Stats indicating periods of no activity, where StatCounter shows an interesting visit.

A visit, registered by StatCounter - but not by Stats - indicates an apparent problem with Stats. Or, so the blog owner might think.

StatCounter displays page views, by counting clicks on the readers computer.

---

(Note): Please observe that "page views" come from both dynamic pages ("posts") and static pages ("pages") being accessed. When I refer to "page views", don't get confused about dynamic pages ("posts") vs static pages ("pages") - "page views" apply to both.

---

Stats displays page views, from the Blogger servers. If a page being accessed, by a reader, is already in cache on the readers computer, there will be no access to the Blogger server, and no Stats activity.

This discrepancy can contribute to confusion about visitor count. If two readers, sequentially sharing a public computer, access the same blog page, StatCounter may indicate two visitors.

If the first reader does not cautiously clear the computer before vacating, the second reader will access the page from cache - and will not register Blogger server activity. Stats will show no page views, indicating a second reader.

If a computer is being used with other people waiting for a turn, a reader may not have a chance to clear the computer before giving control to a second reader. The busier the computer, the greater the chance that Stats and StatCounter may show an apparent discrepancy.

There will always be differences between Stats and any other visitor log - just as there will always be differences between any two visitor logs, in general. A discrepancy is not always an inaccuracy.

Renaming Your Blog, And Historical Stats Pageview Counts

Occasionally, we see odd questions about Stats, and the history of someone's blog (or maybe, the URL of someone's blog), in Blogger Help Forum: Get Help with an Issue.

If I started my blog last year, why does my Stats display show pageviews from 2, or even 3, years ago?

and

If I rename my blog to a better URL, how do I carry the Stats numbers to the new URL?

Neither blog owner shows an accurate understanding of the historical nature of Stats pageview counts.

The Blogger servers record access activity by URL - not by blog.

Stats extracts pageview counts as needed, by URL, from the Blogger server logs. If the URL of your blog is "myfineblog.blogspot.com", and you request pageview counts for your blog, for "All time", you will see pageview counts against "myfineblog.blogspot.com", for Stats since May 2006 (as currently the case).

If the URL of your blog was "myexcellentblog.blogspot.com" until you renamed the blog to "myfineblog.blogspot.com" 6 months ago, you will see historical pageview counts for "myfineblog.blogspot.com" - which will include your blog, starting 6 months ago. You won't see pageview counts for "myexcellentblog.blogspot.com", from a year ago, because you'll be seeing historical pageview counts for "myfineblog.blogspot.com".

If someone else had a blog, published to "myfineblog.blogspot.com", before you renamed your blog to its current URL, your Stats displays could include pageview counts reflecting access to that blog. If "myfineblog.blogspot.com" was never used before you renamed your blog to that URL, it's possible that your pageview counts include attempted access to a non existent URL.

If you're using Google Webmaster Tools with your blog (and you should be doing that), you can check the access logs for "404 Not Found" events in the WMT logs. Just as a tree, falling in the forest, makes a sound even when nobody is around, so can access attempts exist against URLs where no blog is published.

Some referer spam appears to be sent to all likely URLs, ignoring whether or not a blog actually exists, at that URL. Referer spam is not unique to Blogger, and has been a problem since before Blogger became a major player in the Internet world.

If you just started a blog, or just renamed your blog to its current URL, your pageview counts can reflect historical referer spam, against your current URL, from before your blog was published to the current URL. As Blogger identifies specific referer spam campaigns, and eliminates some referer spam from Stats logs, this is one more possible cause of fluctuations in pageview counts.

If the possibility of seeing bogus pageview counts, for your blog as published to the current URL, does not please you, I will again point out that you'll get more out of your blog if you spend less time worrying about the details of the Stats displays, and more time working on your blog.

Look at activity before the blog was published as "noise", and look at current activity as "signal" - and work on improving the "signal to noise" ratio. Be aware of the value of your blog, and work on improving the value.

>> Top

Reading Posts In Main Page View Affects Stats

Some blog owners don't understand why Stats displays show that no one is reading their latest post.

I know that my most recent post is being read - but Stats shows pageviews, for that post, as 0!

This owner does not understand the difference between main page, and post page, access.

If you read this blog, without being interested in any particular post, you can access the main page. On the main page, and other index pages, you'll see anywhere from 10 to 15 carefully summarised, recently published, individual posts.

Clicking on "Read more »", at the end of any of the summaries, you can read any complete article. This complete article, and others in this blog, is published as an individual post page - and summarised on index pages, using Jump Break.

Not every blog owner uses Jump Break, to display the posts. Some blog owners publish complete blog articles, in each index page post. Depending upon how any blog is designed, some readers may click on a link, to read any individual post - and others may read some posts from the main page.

Stats enumerates pageviews for individual post pages, in the "Pages" / "Posts" displays. Since the main page is an "index" page, main page activity is not tracked, in the "Pages" / "Posts" displays - and that causes some confusion.

For any given blog not using Jump Break in the posts, the unconscious decision to read a post from the main page, as opposed to a post page, is affected by various blog design details.

• Physical size of main page.
• Number of posts published on main page.
• How frequently new posts are published.
• Whether the blog is publicised, using main page links - or individual post page links.
• Presence - and position - of the Archive index accessory, on the blog face.
• Presence - and position - of any search accessories, on the blog face.
• Use of label indexes - at the end of the posts, and / or a Label index on the blog face.
• Use of links in post content.
• Choice of comment display style - combined with the blog content which may or may not encourage comments.

All of these details, and more, may cause a reader to read a given blog article on the main page, or on an individual post page.

Physical main page size. Larger main pages require more scrolling. The more scrolling is involved, the greater the chance that the reader may find a link to an individual post page, click on the link, and read the article from the post page.

Number of posts published on the main page. Number of posts affects physical main page size. Thanks to auto pagination, some blogs may be displayed with a few posts on the main page, and other blogs with many posts on the main page. Blogs published with less posts on the main page will have more readers clicking on links to the individual post pages, for older posts that won't appear on the main page.

The most recent post published will appear at the top of the main page, in its entirety. Readers accessing the blog, using the Home (main page) address, are almost certain to read the most recent post as part of the main page. Other posts, further down the page, may or may not be read in the main page, or in individual post pages.

Frequency of publishing. Blogs with posts more frequently published will see older posts pushed from main page view sooner, increasing the chance that older articles will be read from the posts pages.

How the blog is publicised. Blogs that are publicised using the main page URL will see more traffic to the main page, while blogs that are publicised using the individual post page URLs will see more activity to the post pages.

Presence and position of the Archive index. If an archive index is present, and visible at the top of the page, a reader may click on an archive index entry, and read an article from an individual post page.

Presence and position of a search accessory. If a search accessory is present, and visible at the top of the page, a reader is more likely to use the search, and to read an article from an individual post page.

Use of a label index may lead to reading the blog using a label index page. Similar to main page, a label index page is a page which groups posts under the label in question. A label index page may be reached from an end of post label list entry, or from a Labels index accessory.

Pageview counts for label index pages, like main page, are not counted under "Pages" / "Posts", in Stats. Here, too, you can have articles read without clicking to the individual post pages.

Use of links in post content. Posts which contain direct links to other posts - as opposed to use of the end of post label index - lead directly to other individual post pages.

Comment display style, and use of comments in the blog. Blogs which use embedded comments will have activity on the individual post pages, when the reader feels the need to examine previously published comments, and / or publish a new comment. The embedded comment display, and entry form, are at the bottom of the individual post pages. The Comment Count Link - "nn Comments" - goes to the bottom of the individual post page, and will generate activity, as counted by Stats.

Blogs with full page or popup comments - and blogs which don't encourage comments - will have less activity on the individual post pages. The post pages are not loaded, with full page or popup comment forms. The full page and popup forms are published under "blogger.com", not under the blog's URL.

All of these seemingly insignificant details, which are present in every blog, in different combinations, will affect access to individual post pages, as opposed to various index pages (archives, labels, and main page).

This will determine whether access to a given article in the blog is counted (as a page or post) or ignored (as an archive, label, and / or main page). The infinitely variable combinations of these details will determine the relative "accuracy" of the Stats "Pages" / "Posts" display, for different blogs. You'll see similarly variable search engine indexing of the blog, with these combinations of details.

And remember also that in the "Page" / "Post" Stats lists, only the top 10 most active Pages and Posts are displayed, at any time. This will also affect "accuracy".

Referer Spam Cannot Be Blocked, Immediately

That is the unfortunate truth.

Every day, some new member of Blogger Help Forum: Something Is Broken asks, innocently

What is all this traffic from dodgy websites?

and after we explain what the dodgy traffic is, and why it does not reflect real traffic, the next question is

So why doesn't Google block it? Why should I have it polluting my Stats displays, and be unable to find actual traffic in my counts?

and the unfortunate truth is simply that Google cannot block it, because it's not significantly different from normal traffic - and the insignificant difference is not easily detected.

Referer spam cannot be identified, because it is identical in structure to legitimate Stats pageviews - and because its content changes, constantly.

What does a normal blog page "pageview request" look like?

When you click on a link from, say, a post in Blogger Help Forum: Something Is Broken, to this article, your computer sends a single message to the Blogger server, containing three essential details.

1. The IP address of your computer.
2. The URL of a forum discussion, which contains a link to this article.
3. The URL of this article.

From the message, the Blogger server creates a server activity record.

1. An IP address.
2. The URL of the page containing a link to the webpage requested.
3. The URL of the webpage requested.

That server activity record, in the Stats display for the blog, is known as a "pageview".

Finally, the Blogger server starts sending web page content back to your computer, so your computer can display this article to you. As the webpage content is sent back to your computer, your computer receives, and displays, the received content - and asks for more content.

What does a referer spam "pageview request" look like?

Simple enough? So, what is referer spam? Simply, a single message from a spammer computer, to the Blogger computer, containing three essential details.

1. An IP address - possibly, but not predictably, of their computer.
2. The URL of the website being pimped (the spammed website).
3. The URL of the blog being spammed (your blog).

From the message, the Blogger server creates a server activity record.

1. An IP address.
2. The URL of the page (supposedly) containing a link to the webpage requested.
3. The URL of the webpage (supposedly) requested.

That server activity record, in the Stats display for the blog, is also known as a "pageview".

Finally, the Blogger server starts sending web page content back to the IP address provided. If the IP address does refer to the spammers computer, what is received is simply ignored. The spammer computer moves on, and sends another fake pageview message to another server - maybe referencing this blog.

The "pageview request" is generated, before referer spam discontinues.

The problem is simply that no web server can detect a message from a client computer, that results in a response that is just ignored. Web traffic is lossy, and clients drop offline constantly. Even if the response could be detected as ignored, the ignored request might still reflect legitimate activity, initiated by a client that immediately went offline.

There is simply no way for Google to block the spam - because the spam is simply one message that results in a response, by the Blogger server, that is subsequently ignored by the client computer.

That's it.

So why can't Google block the numbers generated by referer spam, as the referer spam hits the servers? Simply because the numbers may not really represent actual spam. They can, just as easily, reflect intense, legitimate activity - or possibly a devious attack against a legitimate website.

Google can only detect referer spam in context, against multiple blogs.

Specific pageview counts and details are observed in context - are blocked only after the same activity is observed against multiple blogs, over long periods of time (similar, in concept, to stateful network traffic analysis) - and the numbers are removed, retroactively.

All of this is a simple unavoidable side effect, of blog owners needing site activity figures that are not affected by script filtering by the blog readers, complicated by fraudulent activity by hackers and spammers.

Referer spam is not unique to Blogger - it is simply tuned to abuse Stats logs.

Please note that referer spam did not start with Blogger - it's an Internet wide problem. Even though it appears mindless and random, some of it is craftily designed and executed.

For a comprehensive look at how referer spam works, outside Blogger, see Wikipedia: Referer spam.

The problem here is threefold.

1. Too many blog owners obsess over raw pageview counts.
2. Too many blog owners do not understand the origins of referer spam.
3. Too many blog owners are not interested in understanding the real problem.

That's it!

What Does Stats Provide, That Third Party Visitor Activity Meters Cannot Provide?

Not all blog owners realise how unique Blogger Stats is, in its design.

Some owners may idly suggest that Stats can easily be replaced by any third party visitor activity log / meter.

Why bother to use Stats? Since Blogger Stats shows referrer spam, it's pretty useless - just use SiteMeter, StatCounter - or Google Analytics.

They have no idea why Stats was designed as it is, nor what information Stats provides, that no competing product can possibly provide.

Every add-on accessory, such as any visitor activity counter / log / meter, has to be manually installed in your blog.

Most visitor activity counter / log / meter products require installation.

Simple accessories, which depend upon your visitor clicking on a link, can be installed easily - just add a clickable link on your blog - either in a post, or anywhere in the body of the blog. Visitor logs or meters such as SiteMeter or StatCounter, in order to produce usable statistics, can't depend upon the blog readers clicking on a link.

Most such accessories use add-on JavaScript code, installed in the body of the blog (as an accessory gadget), or in the blog template (installed using "Edit HTML"). With add-on code, that references any external server, the installed location on the blog page, of the accessory code, is crucial.

• Install the add-on at the top of the web page (or in the template code), and as your reader loads each page, he / she gets to watch the page load pause, as it waits for a distant accessory server to respond (while recording the visit).
• Install the add-on at the bottom of the page, and any reader, who closes the display before the page finishes loading, will not be counted by Analytics / SiteMeter / StatCounter.

In either case, the page takes longer to load. This causes reader impatience, and motivates the reader to close the display before the page finishes loading. The result - your blog gets one less new reader.

Most visitor activity counter / log / meter products are affected by filters.

Besides reader impatience causing statistical inaccuracy, all third party accessories that use JavaScript have a second problem - script filtering by our readers.

Analytics, SiteMeter, and StatCounter are known to be explicitly blocked, by some browser setting or third party application that may run on any given client computer. Some security products specifically list "sitemeter.com" or "statcounter.com" in their Block Lists.

A lot of malicious activity, encountered when surfing the web, can easily be blocked by proactive script filtering - just permit scripts, from any given domain, only when explicitly told to do so.

Every reader uses security accessories in the browser and on the computer - and many security accessories and settings provide script filtering. Most security is now provided as "deny by default, permit only on demand".

Most security products update automatically, as updates are produced - and this leads to other problems. Many of our readers, who are concerned with security, or who use computers that are well protected, may not be counted, consistently, by Analytics, SiteMeter, or StatCounter.

Stats does not require installation, and is not affected by filters.

Blogger Stats avoids the issues of page load delay induced impatience, and client filtering, by not using JavaScript add-on code. Since Stats is a Blogger accessory, it can retrieve data directly from the access logs produced by the Blogger servers. Access to server access logs:

• Does not cause page load delays.
• Is not subject to page load delay impatience.
• Is not subject to reader security settings.
• Does not require installation of any accessory, on individual blogs.

Besides the problems of our readers visits not being counted, we have the issue of what information is provided, and for what period of time. If you have installed SiteMeter or StatCounter on your blog, look at the displays provided. Each product will mention a limit of either 100 or 500 log entries - and will display details or statistics based upon the log used.

Many Blogger blogs get more than 500 visits in a single day - requiring blog owner visits to the log website at least daily, or to pay for extra service, to provide any benefit. And of course, that log was started only after the product was installed.

Blogger Stats, on the other hand, is able to provide statistics for the current day, week, month, and for "all time" (starting in May 2009, for all blogs in existence at that time).

Stats does not discard old statistics, they just extract from the server access logs, for any time range provided.

• All time.
• Last 30 days ("Month").
• Last 7 days ("Week").
• Last 24 hours ("Day").
• Last 2 hours ("Now").

Any blog owner can see any available statistics, at any time. Stats never has to be installed, by any blog owners - it is already there.

Stats is vulnerable to bogus activity records, created by spammers.

Unfortunately, the biggest strength of Stats - use of the server access logs to gather the visitor activity data - leads to its best known weakness - abuse by referer spammers, which leads to inflated blog read counts.

It may help to understand that referer spam did not start with Stats - nor is referer spam unique to Stats. Referer spam has been around ever since people published websites, and displayed a visitor log extract ("My Recent Visitors") to make their website more interesting to new readers (The suggestion that "This website should be more interesting to YOU, because it has readers from all over the world!").

Stats, like every visitor activity counter / log / meter product, resets totals.

Besides the concern of referer spam, we see various evidences of confusion about Stats displays.

• "Daily" counter resets that occur during the day - never at midnight.
• The inability to compare detail in one display, with aggregated counts in another display.
• Inability to display pageview counts for all posts in the blog.

All of these limitations are simply the direct result of how Stats is designed.

Every visitor activity counter / log / meter product differs, from every other product.

In reality, both Blogger Stats and third party visitor activity logs or meters have their respective advantages - and neither choice can ever replace another.

• If you want to see demographic details about some readers of your blog, you can use Analytics, SiteMeter, StatCounter - or any number of third party visitor activity logs and meters - after the chosen accessory has been installed.
• If you want to see comprehensive statistics about all readers of your blog - without being limited by install time or reader security policy - only Blogger Stats will help you.

Fortunately, all products are free - and Stats requires no installation. Your Stats data is there, waiting for you - on the Blogger dashboard menu.

Search Engines, Visitor Logs, And Country Domains

Some blog owners are seeing the recently added Country Code Top Level Domain Aliases in their visitor logs / meters, and various non Google search engines.

Possibly unaware of the aliases, they are afraid that their blog has been hacked.

My SiteMeter logs show that I've had incoming traffic from "mybloggerblog.blogspot.in". Clicking on one of the links in SiteMeter, I see my blog, "mybloggerblog.blogspot.com". Has somebody cloned my blog?

In reality, the scenario is not so ominous.

Those of us aware of the CC aliases, and how they are being used by Blogger, will understand that simply seeing a non canonical alias in our referer lists, in any search engine or visitor log / meter, is not an indication of malicious activity.

People unfamiliar with the country code aliases may be confused.

People long used to seeing only "blogspot.com" and "google.com", and not yet experienced with the CC aliases, may become confused, however. Blogger blogs owners with long established blogs that have audiences outside the USA are probably used to seeing all references to their blogs based on the canonical URL, such as "mybloggerblog.blogspot.com".

Now that BlogSpot published blogs are being served using the CC aliases, in many countries outside the USA, the readers of BlogSpot published blogs are seeing each blog under non "blogspot.com" URLs in some search engines, and in many visitor logs and meters.

Many search engines will aggregate search references, to the canonical URL.

Most major search engines, which reference the "canonical" tag in the blog header, are aggregating all SERP entries to use the "blogspot.com" URLs. Our important search reputation is not being fragmented, such that readers in Australia provide reputation to "blogspot.com.au", readers in India provide reputation to "blogspot.in", readers in New Zealand provide reputation to "blogspot.co.nz", and so on.

Every hit, from every reader in every country, still provides reputation to the canonical alias, "blogspot.com".

Some specialised search engines like Alexa, DMOZ, etc - and most visitor logs like SiteMeter, StatCounter, and Stats, may not be designed to reference the canonical tag. It's also possible that visitor logs, by their nature, should not aggregate CC aliases to the canonical URL - as the country code, relevant to the individual readers, may be important to some blog owners.

Until the canonical tag is used by every Internet service, there will be confusion.

Until the use of the canonical tag, and the CC aliases to our readers, becomes mature, it's possible that we will see various oddities like a perceived problem with Alexa, SiteMeter, or StatCounter. It's likely that not all Internet services will ever reference the canonical tag consistently, and aggregate all statistics and visitor demographics, canonically.

Given the latter probability, this may be yet one more reason why Blogger Help Forum: Something Is Broken may never go out of business.

---

Some Confusion Over Use Of The CC TLD Aliases, By Search Engines And Visitor Logs
http://blogging.nitecruzr.net/2012/02/some-confusion-over-use-of-cc-tld.html

Search Engines And Visitor Logs, And The Country Specific Domains
Search Engines, Visitor Logs, And Country Domains
http://blogging.nitecruzr.net/2012/02/search-engines-visitor-logs-and-country.html

The Stats "All Time" Display, And The 2010 Numbers

Occasionally in Blogger Help Forum: Something Is Broken, we see a curious question.

My blog Stats display is missing a complete year.

The problem is actually right there, in front of all of us - if we look.

Look at the Stats Overview tab, and the graph at the top of the display.

What happened to "2010"?


My suspicion is that it's a deliberate omission, to get the graph to fit in the limited horizontal space. How will they get "All Time" to fit in that space, as the Stats display gets older, and "All Time" covers more years?

That being the case, it should not be that much work to add a little "broken line" symbol in the border, between "2009 October" and "2011 March". Look how smoothly the line flows, in my graph, right through 2010. What does your blog show?

Fast forward to 2015, and we'll know the answer.

---

And in 2012, we now see the same display oddity with the numbers from 2011.

---

>> Top

Referer Spam Does Not Represent Real Traffic, To Our Blogs

We've been discussing referer spam for many years.

Every week, besides many people who wonder

Why doesn't Google put an end to this, for good?

there are occasionally some folks who wonder

But is this all bad? Doesn't this help us in our overall Blogger statistics as far as traffic counts go? If so, it's not all bad - for those of us with less than ginormous followings.

And both attitudes reflect people who just don't understand what it is.

We've already discussed, repeatedly, why Google can't just put a end to it, unilaterally.

The latter musing, considering that it may possibly be beneficial to any Blogger blogs, is no more valid than the former. Referer spam simply cannot be blocked, because it is not different from legitimate traffic.

Stats logs entries, from referer spam, do not reflect people viewing the blog.

The numbers reflected in our Stats logs do not represent any actual traffic against our blogs, or any websites with links to our blogs. The only person who benefits from referer spam is the owner of the advertised (fake referer URL) sites - and that happens only when we click on the links in the Stats display.

Only Stats, which builds its pageview counts and graphs using the Blogger server activity logs, is subject to referer spam. All third party visitor logs and meters, which depend upon snippets or widgets added to the blog template, are not subject to this problem.

Don't click on the links - and use a third party visitor log for verification.

So, besides my facetious advice that you simply

Don't click on the links.

comes equally facetious advice that you

Get a third party visitor log / meter, for accurate and comprehensive pageview counts.

Jump Break, Main Page Contents, And Search Engines

The articles in this blog, which discusses production and use of Blogger blogs, are written as posts.

The various posts are combined, using embedded links, in different ways. Each new post appears on the main page, as it is written - and the various posts, appearing together on the main page, create opportunities for confusion, with the readers of the blog.

Long ago, the task of moderating comments was rather depressing to me, as the focus of many of the comments made me think that nobody was actually reading the articles. Maybe, I would write an interesting post about URL availability; but when moderating comments, I would find questions about posting comments on static pages. Or maybe a post about dynamic template concepts would attract complaints about referer spam.

Why should I publish my advice, if nobody cares enough to read the articles and comment relevantly?

Just previous to this post, I wrote about Stats displays, and the contents of the Posts lists.

In the process of writing the latter article, I discovered one obscure benefit of using "Jump Break" - and how "Jump Break" affects main page view, search engine indexing, and finally, relevance of comments to post subject.

A home page, with a variety of posts, naturally produces un focused comments.

Why the apparent lack of focus, of the comments? One reason is that many different posts, published one after the other, appear in sequence, in the blogs main page.

People will read the posts - and the search engines will index the posts - using main page view. Only after newer posts force the older posts, one by one, from main page view, will the individual posts have any significance - to people or search engines.

Using my example above, and looking at my main page when this post was new, one would have found a post about URL availability, published a week after a post about posting comments on static pages. By the time the search engines indexed the latter post, I would have published the former post. The post about URL availability would be visible in main page view, ahead of the post about posting comments on static pages.

Clicking on the link to my blog, attached to a SERP entry referencing static pages, the reader will read my main page from the top, find the previously visible post about URL availability, and the Comments link following the post. Clicking on the first Comments link found, the reader will post his question about static pages, against my post about URL availability.

Use of Jump Break gives a home page that can be easily read, top to bottom.

So, what effect does the use of "Jump Break" have on this problem? Using "Jump Break" on all main page posts makes it more likely that a potential reader of the blog, following a home page link to the blog, has more chance to see all recent posts, with their summaries.

The reader is more likely to scan down the page, see a summarised relevant post, click on "Read more" - and read the relevant post, on the individual post page, before commenting.

Use of Jump Break gives more weight to the individual posts, as indexed.

Additionally, with the posts summarised in main page view, the search engines will find less content on the main page. The full posts will be indexed as individual post pages, more than as part of the main page. This gives more weight to the individual posts, and less weight to the main page.

When indexed using an automatically generated, robust sitemap (2014), the posts will appear individually in SERP lists, decreasing reader main page confusion. Each SERP entry, pointing to an individual post, will be more relevantly focused - giving it more weight than a SERP entry, pointing to main page view.

Use of Jump Break, consistently, produces a win-win-win scenario.

In summary, careful and consistent use of "Jump Break" leads to:

• Better focus on individual and relevant blog articles, by the search engines.
• Less confusion to the blogs readers, when accessing the blog using SERP hit lists.
• Less frustration for the blog owner, when moderating comments.

It's really a win-win-win, when used consistently. And, it's so simple to apply, on a post by post basis. Check it out, in action.

Stats Not Displaying Newer Posts, In "Posts" Lists

The problem of last week, with Stats, was fixed late yesterday, and our Stats displays once again are showing Posts pageview counts and enumerating individual Posts. Now, we have a perceived problem, being reported by newer blog owners.

My Stats display does not show my newer posts!

This concern is visually valid - but it's not real. It's most common with blogs that have just over 10 posts, which are owned by people who are not aware of the Stats display limitations, as we have explored.

The Stats Posts displays enumerate the 10 most popular posts, for any given time period. Newer posts will seldom appear in the Posts lists, for many blogs.

• The "Posts" lists enumerate individual posts, and shows pageview counts for posts viewed in single post view. Newer posts will be displayed in their entirety on the main page, and read as main page views.
• The lists show only the 10 most popular posts. Newer posts, not yet indexed by the search engines, or linked by your readers, won't have as many inlinks - and the post page URLs won't get as much traffic from other blogs and websites.

Owners of newer blogs will not be aware of these details - and with just over 10 posts, may not see the significance, in their Stats displays. These owners will simply see, from time to time, posts that don't appear in the lists.

If you look at the main page, for this blog, you'll see use of "Jump Break" in my newer posts. Each of these posts, to be read in their entirety, can only be read using the "Read more" link - and from the individual post page. Look at the address window above.

http://blogging.nitecruzr.net/2011/10/stats-not-displaying-newer-posts-in.html

Since you're viewing these words, this post is being counted in Posts, as a pageview. Thus the Posts lists, for this blog, will enumerate this post, sooner.

Here, we see another benefit of using "Jump Break" over other auto summarisation techniques. The "Jump Break" links directly to the single post view of each post - and it uses HTML, which makes it search engine friendly. Some previous auto summarisation techniques used JavaScript to hide the full post content, preventing search engines from indexing the full post text.

Besides encouraging the post content to be read as a post page, the search engines will index post content in the post pages. The archive retrievals, and main page, will only list the partial content of each post - and search engine hit lists will contain more relevant content.

>> Top