Share Count Not Updating or Wrong? A Fix List in Order

A column of paper discs split by a gap as if frozen mid-fall, beside a small numberless paper clock face

Work through it in order

Is there still a count to fetch?
X and LinkedIn no longer publish counts. If those buttons show zero, that is correct. See how share counts work.
Is the token valid?
Facebook counts need an access token. User tokens expire; app tokens stop working if the app secret is reset. Test the token in the Graph API Explorer.
Are scheduled tasks running?
Many plugins refresh counts from WP-Cron. On low-traffic or fully cached sites, WP-Cron may rarely run. Set up a real cron job; see external cron jobs for WordPress.
Is a cache serving old numbers?
Page caching stores the HTML with the old count. Counts refresh in the database but visitors see the cached page until it expires or is purged.
Which URL is being checked?
After moving to https or changing permalinks, the network holds the old count on the old address. Plugins that check both variants recover it.
Rate limited?
If counts work on some posts and not others, the plugin may be asking too often. Slow the refresh schedule for older posts.

Symptoms and their usual causes

Symptom	Most likely cause
Every network shows zero	Token missing or cron not running
Only X or LinkedIn show zero	Those networks removed counts
Count dropped after moving to https	Shares recorded on the http address
Counts update in admin, not on the page	Page cache
Counts stuck at an old value	Scheduled refresh stopped or rate limit
Facebook page shows more shares than the post	Page shares and URL shares are counted separately

The figures here are invented, but the sequence is a real one. A site moved to https on 3 March. Before the move its most shared post showed 1,240 Facebook shares; the morning after, it showed 0. Nothing else had changed. Step one passes, since Facebook still reports counts. Step two passes, because a manual Graph API request with the app token returns a response. That request, made for the https address, returns share_count 18: the 18 people who shared since the move.

The same request for http://example.com/post/ returns share_count 1,240. The count was never lost; the plugin simply stopped asking for the address that holds it. Turning on the plugin's option to query both schemes, then forcing a refresh, produced 1,258 within the next cron run. The page still showed 0 for another hour because the page cache had stored the zero, which is step four.

Clear them in this order; clearing the outer layers first only re-caches the stale inner value.

The cache-clearing sequence

After any fix, clear the layers in the order shown, inner first. On a site with WP-CLI access the whole sequence is four commands; without it, each layer has a button in its own settings screen. The transient delete command is documented on the cited WP-CLI page.

wp cron event list --fields=hook,next_run_relative | grep -i share   # is the refresh scheduled?
wp cron event run --due-now                                          # run it now
wp transient delete --all                                            # plugin count cache (if it uses transients)
wp cache flush                                                       # object cache
# then purge the page cache and the CDN from their own dashboards, and reload in a private window

Layer	Typical lifetime	How to clear it
Plugin count cache	1 hour to 1 week per post	Plugin's refresh or reset button; or delete the transient
Object cache	Until flushed	wp cache flush, or the host's object cache panel
Page cache	10 minutes to 24 hours	Purge all in the caching plugin or host panel
CDN edge	Minutes to days, per URL	Purge the post URL, or purge everything
Browser	Per the page's cache headers	Private window, or hard reload

Third-party count services

Some plugins fetched counts through an aggregator service instead of each network, using an API key from that service. If that service changes plans or limits, counts stop without any change on your site. Check whether your plugin relies on one and whether the key still works.

Editing counts by hand

Several plugins, MashShare among them, let site owners adjust counts manually or add a multiplier sometimes called fake shares. Restoring a count you lost in an https move is defensible if you can show the old number. Inflating counts is not: it misleads readers, and in many places presenting invented social proof to consumers can fall foul of advertising and consumer protection rules. If a count is low, hide it until it is not.

What goes wrong during the fix

Judging too early. A refresh that runs every twelve hours will not show the fix for up to twelve hours. Force one run with the command above, then wait for the page cache to expire or purge it.
Fixing the wrong layer. Purging the CDN while the plugin cache still holds zero re-caches the zero. Inner layers first.
Testing while logged in. Most page caches bypass logged-in users, so the admin sees the new number while every reader sees the old one. Check in a private window.
Resetting the app secret to "fix" a token. That invalidates every app token in use, including the one in your plugin. Regenerate and paste the new token everywhere at once; see how to create a Facebook access token.
Restoring a count nobody can verify. If you set a count by hand, keep the API responses that justify it. The Graph API request in Facebook share count: getting it from the Graph API is the evidence.

Check it worked

The plugin's stored timestamp for the test post is newer than your fix.
The number on the page, in a private window, matches the number in the plugin's admin screen.
A manual Graph API request for the same URL matches the stored figure, or the sum of the variants the plugin asks for.
The cron event for the refresh has a next run time in the future, and it moves after each run.
Networks that no longer publish counts are hidden rather than showing zero.

More on this topic sits in the share counts section: start with how to create a Facebook app ID, then tracking shares and pageviews in analytics.

Sources

Questions

Why are my share counts stuck?

Usually a scheduled refresh stopped, a token expired, or a page cache is serving old HTML.

Why did my share counts drop after switching to https?

Networks count http and https addresses separately. Use a plugin that checks both and adds them.

Is it OK to add fake shares?

No. Inflated counts mislead readers and can breach consumer protection rules. Hide low counts instead.

How long does a share count take to update?

One refresh interval plus the page cache lifetime. With an hourly refresh and a one hour page cache, expect up to two hours; force the cron run and purge the cache to see the change at once.

Why do my share counts show in admin but not on the page?

The page cache stored the HTML before the refresh. Logged-in users bypass the cache, so you see the new number and readers do not. Purge the page cache and any CDN, then check in a private window.

Hannah Voss, Editor. Checks every guide against a working WordPress install and the networks' current documentation. Last reviewed September 2026.

About the editor and our methods

Work through it in order

Is there still a count to fetch?

Is the token valid?

Are scheduled tasks running?

Is a cache serving old numbers?

Which URL is being checked?

Rate limited?