When you have set up recovery URLs and already set up 301 redirects, some host networks will continue to update the share counts on the old permalink every time the 301 is triggered. Social Warfare is smart enough to look for duplicate counts. However, the caching between the two URLs may not be the same, which Social Warfare cannot tell apart.
For example, let’s say the old permalink was https://blog.com/how-to-plant-trees, and the new permalink is https://blog.com/planting-trees.
Let’s also assume you already set up a 301 redirect and updated all your links.
I’ll share /planting-trees on my Facebook, but not the old permalink.
Now let’s look at the Facebook debugger for each one.
It shows that /how-to-plant-trees has 641 shares and /planting-trees has 642 shares.
This might be because the old permalink isn’t updated as frequently as the new one, so when Social Warfare asks Facebook how many shares this post has had, we ask for the number of shares for both /how-to-plant-trees and /planting-trees. Facebook has data for both, so we get 641 and 642.
Anyone can tell that those two numbers are not equal. Since they are not duplicated numbers, we must assume they are both valid counts. If we did not, then you would be “losing” all of your shares from the old permalink.
Therefore, our Facebook button on /planting-trees is going to show 1,283 shares instead of 642.
Please note that this is a rare condition. Most of the time, if the host network is tracking shares for the old permalink, it usually is accurate in matching the shares to the new permalink. In these cases, Social Warfare filters out the duplicated count and only shows the one valid number.
More often, though, the host network does not track counts for the old permalink, so we end up with data that looks like 25 shares for /how-to-plant-trees and 642 shares for /planting-trees. In cases like this, share recovery works exactly as we expect, and the total number displayed is 667 shares.