Social sharing buttons are everywhere. They sit at the top of blog posts, float along the side of long articles, and squeeze into the footer of product pages. But if you’re running a website, you’ve probably wondered whether anyone clicks those icons in the first place.
In most cases, people do not click social sharing buttons. Real-world usage data from large sites has repeatedly shown share-button engagement well under 1% of page views.1
What the Data Shows
One of the clearest public datasets came from the UK government’s GOV.UK site. After launching social sharing buttons, the team reviewed the first 10 weeks (December 3, 2013 to February 17, 2014). They reported 14,078 shares from 6.8 million page views, which works out to roughly 0.21%.1 That is not a rounding error. That is the actual story of what happens on a very high-traffic, highly useful website when you add share buttons and then watch what people do.
Share buttons are often added because internal stakeholders request them, not because users ask for them.
In GOV.UK’s earlier announcement of the experiment, they said the feature had been queued for a long time because “zero end users” had requested it, and users in testing were already able to share links by copying and pasting them.2
On mobile specifically, multiple write-ups of Moovweb’s research have pointed to extremely low use of sharing buttons. A WARC news item (dated August 26, 2015) summarized Moovweb’s findings as “only 0.2% of mobile users do any social sharing,” based on analysis of over 61 million mobile sessions. It also highlighted a core friction point: users often need to log in before sharing, which is a bigger barrier on a phone.3
Why visitors ignore social sharing buttons (even when they like your content)
There are a few overlapping reasons share buttons underperform. Some are behavioral, some are technical, and some are about trust.
1) The share moment rarely happens where the buttons live
Many pages put social sharing buttons at the top of an article, before a person has read anything. At that point, the visitor has not decided whether the content is worth passing along. Other pages put them at the bottom, but the visitor has already mentally “completed” the page and moved on. In practice, the moment someone decides to share often happens after they’ve read a key line, or after they’ve formed an opinion, or when they remember a specific person who would care.
2) People share inside apps, not inside browsers
A lot of content discovery and sharing now happens inside social apps, group chats, newsletters, and messaging tools. Even when someone starts on your website, the share action may happen later, after they copy a link and switch contexts. This is one reason “share button clicks” can be a misleading metric. The sharing happens somewhere else, in a different way than the one your share icons are offering.
3) Login prompts and permissions add friction
On mobile, that friction is especially brutal. If tapping a button sends someone to a login screen, you lose most people right there. The WARC summary of the Moovweb research calls out this exact issue: the need to log in first can make sharing feel like work, while other actions are one tap.3
4) Privacy expectations changed, and browsers respond
Many social widgets historically came with tracking. That created a trust problem with users, and it also created a technical problem because modern browsers actively reduce cross-site tracking. Mozilla’s documentation of Enhanced Tracking Protection explains that social media trackers appear on other websites, and that Firefox blocks common social media trackers. It also notes that like and share buttons can allow tracking even if the visitor never clicks them, which is exactly the kind of thing privacy-focused users and tools push back on.4 Even if your specific implementation is privacy-friendly, visitors have learned a general “this looks like tracking” pattern over the last decade. That learned distrust makes a low-intent UI even less likely to get used.
5) Share buttons can be a performance tax
Share button bundles are often implemented via third-party JavaScript. Even when the code is not huge, it still adds requests, adds execution time, and adds more things that can fail. Google’s web.dev documentation explicitly lists social sharing buttons as a common use of third-party JavaScript and explains that third-party scripts can be particularly problematic for performance.5 So you end up paying a cost (speed, complexity, privacy review, maintenance) for a feature that many sites see used by a fraction of a percent of visitors.
People still share. They just do it “manually” (and analytics often calls it something else)
If share buttons are rarely clicked, how do people share content?
Most sharing happens when someone copies the URL and sends it wherever they’re already talking. It’s sending a URL in a text message, dropping it into a Slack channel, or forwarding it in email. It is also sharing from inside apps where the browser never sees a click on your page UI. This creates a measurement problem. When someone shares in a private channel, it often looks like “direct” traffic, or like traffic with limited referrer data.
Chartbeat’s documentation discusses this explicitly. It describes an “Email, Apps, Messages” bucket as its answer to “Dark Social,” meaning visits that arrive without referrer data even though they likely came from shares over secure connections like email, messages, or apps.6 In other words, your site might be benefiting from sharing behavior while your share buttons sit untouched.
When social sharing buttons can still be worth keeping
There are a few scenarios where keeping a sharing UI can be reasonable, as long as you are honest about what it can and cannot do.
Your content is highly time-sensitive or culturally shareable
On GOV.UK, some individual news items had noticeably higher sharing rates than the site average, depending on topic and timing. Their report shows that “shareability” varies a lot by subject matter, even within the same site and the same button design.1 If you publish breaking news, event recaps, or content that prompts immediate “you have to see this,” you may see higher-than-average button use. Still usually not huge, but sometimes meaningful.
Your audience wants to copy the link
Interestingly, the BBC’s Global Experience Language documentation (for “Share tools”) cites research indicating as little as 0.25% of visitors use social media buttons. But its recommended pattern includes a “Copy this link” option, which aligns with how people actually share today.7
A “copy link” button can be much more useful than a row of social media logos.
You treat share buttons like a convenience feature, not a growth strategy
If your plan is “we’ll add buttons and get tons of free distribution,” you’re lying to yourself. If the pitch is “we’ll provide a lightweight share option for the small slice of visitors who want it,” then it can be a fine, low-drama feature.
What to do instead (or how to do share buttons in a way people might actually use)
If you want a practical approach that matches modern behavior, focus on making sharing frictionless and platform-agnostic, and on reducing the “third-party widget” baggage.
- Make the page look good when it’s shared. Use proper metadata so link previews are clear and attractive. This supports sharing regardless of whether it happens via buttons, copy-paste, or native share sheets.
- Add a “Copy link” action near the content. This maps to how people share in group chats and email, and it is often faster than choosing a platform icon.
- Use the native share sheet when possible. The Web Share API allows a site to open the device’s native sharing mechanism (share targets chosen by the user). It is designed to share links and text through the operating system, not through a platform-specific widget.8
- Keep the UI minimal and contextual. If you include social sharing buttons, avoid putting them on every page template by default. Put them where sharing intent is highest, such as a standout article, a resource page, or a post-share moment like a thank-you page.
- Audit the performance cost of third-party scripts. If your share buttons load external JavaScript, measure what it does to page speed. Third-party JavaScript can slow down performance, and social sharing buttons are a common example of that category.5
- Decide what you are optimizing for. If your goal is “more distribution,” you may get better ROI from improving headlines, preview images, and email capture than from adding more share icons.
If you do keep social sharing buttons, consider a privacy-forward implementation. WIRED described an approach where buttons are disabled by default so visitors are not tracked unless they actively choose to enable and use the sharing control.9 That extra click is not ideal for conversions. But it’s honest, and it reflects the reality that many users would rather share manually than accept silent tracking on load.
Make a decision based on your own numbers
The smartest way to handle social sharing buttons is to treat them like any other product decision. Measure them, then earn their spot on the page. Track share button clicks as events, compare them to page views, and look for patterns by device and by content type. If you discover your buttons get 0.1% usage, you are not failing. You are seeing what many large publishers and platforms have already observed.1 Then decide what you want: remove the clutter, keep a small “copy link” affordance, or replace a row of icons with a native share flow. In most cases, the best outcome is a cleaner page and a sharing experience that fits how people actually behave.
Assume people won’t click social sharing buttons, and design your content to be easy to share anyway.
References
- Francis, G., & Chohan, A. (2014, February 20). GOV.UK social sharing buttons: The first 10 weeks. Inside GOV.UK. https://insidegovuk.blog.gov.uk/2014/02/20/gov-uk-social-sharing-buttons-the-first-10-weeks/
- Williams, N. (2013, December 2). A time for sharing (government content on Facebook and Twitter). Inside GOV.UK. https://insidegovuk.blog.gov.uk/2013/12/02/a-time-for-sharing-government-content-on-facebook-and-twitter/
- WARC. (2015, August 26). Mobile users prefer ads to sharing. https://www.warc.com/newsandopinion/news/mobile-users-prefer-ads-to-sharing/en-gb/35293
- Mozilla. (2025, February 22). Trackers and scripts Firefox blocks in Enhanced Tracking Protection. Firefox Help. https://support.mozilla.org/en-US/kb/trackers-and-scripts-firefox-blocks-enhanced-track
- Mihajlija, M. (2019, August 13). Third-party JavaScript performance. web.dev. https://web.dev/articles/third-party-javascript
- Chartbeat. (2023, March 30). Real-Time metrics glossary. Chartbeat Help & FAQ. https://help.chartbeat.com/hc/en-us/articles/208982958-Real-Time-metrics-glossary
- British Broadcasting Corporation. (n.d.). Share tools. BBC GEL. https://bbc.github.io/gel/components/share-tools/
- MDN contributors. (2025, March 13). Web Share API. MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/API/Web_Share_API
- Gilbertson, S. (2013, March 26). Social sharing buttons that respect your visitors’ privacy. WIRED. https://www.wired.com/2013/03/social-sharing-buttons-that-respect-your-visitors-privacy/
