Fixing Facebook Share attachments blocked by W3TC

So you’ve just set up W3 Total Cache (W3TC) on your WordPress site, write a post, set up all the social share content in Yoast/The SEO Framework/RankMath/etc, go to share the site in Facebook, and realize: Your blog post featured image and meta excerpts aren’t showing up despite all of the Open Graph tags being generated! What next? Well, we just fixed this ourselves, so we’ll show you how to get your Facebook social share meta data to show up properly.

First-step troubleshooting: Re-scrape your URL

There’s definitely a few things to check right out of the gate. It’s possible that the first scrape of your blog post was just bad, and needs to be re-scraped by Facebook. Pop on over to the Facebook Sharing Debugger and enter in your URL (you can include the UTM parameters you intend to use in your post link as well).

Once on the Debugger and you’ve entered your URL, check the errors, and then hit Scrape Again. Wait a few minutes, and see if the preview below now works properly. If so, bam! All good! This does happen every once in a while, so just keep this in your back pocket for next time.

Open Graph settings in WordPress plugins and themes

If it still pulls up cURL errors and other issues, time to look at your WordPress install and various plugins. Clear any sort of caches from W3TC, Autoptimize, or an Nginx cache with Nginx Helper or something similar. Afterward, rescan your URL in the Debugger again.

If the Debugger still shows errors, it may be your SEO software. Ensure that your SEO software is set up to send Open Graph tags. If your theme has an option to turn on/off Open Graph tags, turn that on as well (our current theme, Blocksy, has this option).

Might as well go ahead and add in your Facebook App ID while we’re at it. Jump on over to https://developers.facebook.com/apps and create your App. Fill in the basic info, and then get your App ID and pop it in the appropriate location in your SEO plugin (some themes have a spot for this as well, such as Blocksy, in case you don’t want to use an SEO plugin).

Once this is all set up, clear your sites’ caches, and then re-scrape on the Debugger. Still no luck? Let’s move on…

Have you turned it off and on again?

When all else fails in WordPress troubleshooting, it’s time to start turning things off one at a time. If you think the issue is stemming from your SEO plugin, turn it off, clear your caches and re-scrape. No change? Try switching themes. If that doesn’t work, try disabling your cache plugins.

If you find one that seems to be the culprit (as in, when you turn it off, the Debugger shows valid output and previews), then it’s time to start mitigating those issues. If it’s your SEO plugin, there’s probably a setting (or combination of settings) that’s actually causing the Open Graph tags to not output properly in all scenarios.

But to be honest, the SEO plugins, theme settings, and the like, are all pretty easy to get right in the UI, and they won’t be the cause of the issue in many situations. In reality, we’re probably looking at a caching plugin problem.

W3 Total Cache is a total jerk to Facebook

In our instance, we found that while the source code being generated by WordPress from the cache worked properly. Even in Incognito mode, the post has the appropriate Open Graph meta tags created by The SEO Framework. Unfortunately, Facebook still somehow couldn’t see these tags properly, and we had previously verified that all SSL and redirects were without error.

We also found that by disabling W3TC we could get Facebook to see the meta tags and generate the previews without any issue. So, W3TC is the cause of the issue in our case, and it’s most likely due to a User Agent issue.

W3 Total Cache and the Facebook User Agents

Basically, W3TC is serving up cached data to users, however, is not serving up the proper cached data to Facebook–or, more particularly, User Agents from Facebook’s scrapers. User Agents are identifiers of what type of “user” the URL request is generating the request. These are identifiers like “android”, “kindle”, “incognito”, or even phone or device specific like “alcatel”, or “hp-tablet”.

They can also be used to identify software applications or tools. Thankfully, we found a workaround for this issue with the offending User Agents from the most excellent Justified Image Grid plugin developers. These are the User Agents they’ve identified:

facebookexternalhit
FacebookExternalHit/1.1
FacebookExternalHit/1.0

They present two different options, depending on how you wish to address the issue.

Solution A: Create a Facebook-specific User Agent Group

This solution makes a new User Agent Group within W3TC to specifically serve cached files to bots with listed User Agents. This means that any changes to the tags or metadata will require a cache clear before the Facebook scraper sees any changes you may make on your site.

1. From the WordPress Dashboard > W3 Total Cache settings (Performance) > User Agent Groups
2. You may see pre-existing groups here, perhaps a High and a Low group, or a Tablets and Phones group (for certain configs, such as from WPX Hosting), and these may or may not be enabled. Whether you enable them is up to you, depending on how you want traffic handled based on device type or how you compress data to device groups.
3. Click Create A Group
4. Name the group Facebook (or something to identify the group purpose to you)
5. Add the following User Agents to the User Agents field:
   facebookexternalhit
   FacebookExternalHit/1.1
   FacebookExternalHit/1.0
6. Click Save All Settings

Solution B: Reject caching for Facebook User Agents

The above solution is great for when you still want Facebook to get cached data for their scraper bots. But what if you a) don’t want to deal with making a new group and b) would rather Facebook not have to go through the cache in order to get updated information? Thankfully that’s also pretty simple to set up within W3TC.

1. From the WordPress dashboard > W3 Total Cache settings (Performance) > Page cache > Advanced section > Rejected User Agents
2. Add the following User Agents to the Rejected User Agents field:
   facebookexternalhit
   FacebookExternalHit/
   1.1FacebookExternalHit/1.0
3. Click Save All Settings

This is the implementation we opted for here, as we figured it would be easier to ensure that Facebook’s scraper always had the most up to date meta tags available if we just skipped the caching. Perhaps eventually performance needs will dictate we switch this back, but at least at this point, it’s not really impacting us at all.

Refreshing existing Facebook posts

You may have shared a handful of posts to Facebook already, and they didn’t get the right image or meta tags. Now that you’ve fixed the meta scraping issue, you may think that you should delete and re-post them, but that’s not the right call. You’ll lose any engagement on those posts, of course, and the easier way is to just refresh the embed data in the first place.

From your Facebook page, you’ll want to click on the date/time link for the post to open it individually.

Tip: if you have a bunch of posts to refresh, either middle-click the date link or right-click > Open in New Tab for each one to save time instead of going back to the profile page for each new post to refresh.

Once you’re on the individual post page, you’ll want to click the three dots icon at the top right corner of the post card, and then click Refresh Share Attachment.

It will look like there’s not much going on for a few moments, but eventually you should receive a confirmation prompt asking if you’re sure about replacing the share attachment, and a preview of the new share attachment.

Click Save on this dialog, and then the individual post page should update and you’ll see the updated Share attachment.

Final thoughts

This definitely began as a pretty annoying situation for us, as we realized that it wasn’t just a temporary glitch or something that Facebook’s scrapers would “iron out”. But as we realized it wasn’t anything like that, running down weird issues with meta tags can get annoying. Thankfully, after finding the actual cause of the issue it was a pretty easy case of tracking down the right data for the fix.

We hope that this may come in handy for someone else trying to run down this issue with W3 Total Cache blocking Facebook from scraping the correct Open Graph data. If you’ve found a similar issue and fix that may be helpful, drop a comment down below!