With the https://www.alexanderrybaknews.com/alexander-rybak-about-love-bullying-and-friendship-in-herna-18-08-2015/53643/ post in particular, here’s what is happening.
The background: Facebook said that they were deprecating the API version that we were using to pull in shared counts, which did not require authentication. The new version required authentication, which is something we couldn’t do directly in Jetpack.
To resolve this, we setup a system on WordPress.com that Jetpack could query to ask for the Facebook count. WP.com, in turn, would poll Facebook.
To eliminate issues with different sites having different permalink structures and WordPress.com not being up to date with what your site is using, we poll using your site’s default permalink ( https://www.alexanderrybaknews.com/?p=53643 ).
Facebook will follow the redirect and using the canonical URL, then report back those numbers.
In your particular case, Facebook had bad data in their system, so they did not return the share counts for your actual post. I refreshed the data using FB’s debugger ( https://developers.facebook.com/tools/debug/og/object/ ).
The values on the wp.com are cached for a short amount of time, but the count is now appearing for me: https://cloudup.com/cTh-CwJW6YY
Since we made those changes (for Facebook’s API shutting down on April 30th), we realized that Facebook was still returning share counts against the old API. After a request for more information, we learned that they have opted to leave the API on specifically for shared counts.
Since our middle-man system is no longer required, Jetpack 3.7 will poll Facebook directly for the share count to reduce some of the opportunity for issues like this.
Cheers,