Hello,
We’re sorry to hear about the issue you’re facing with your OG metadata not being recognized by social media platforms. It’s definitely frustrating when something that worked fine for months suddenly stops working.
From your description, it seems like you’ve already tried the troubleshooting steps mentioned on our website. Since those didn’t resolve the issue, we’d recommend checking if there have been any recent changes to your website’s caching or compression settings. Sometimes, these settings can interfere with how social media platforms read the OG metadata.
If you’re using a cache plugin and have minification enabled, it’s possible that the inline CSS is pushing the OG tags too far down in the source code. This can cause social media platforms to miss them. You might want to move your inline CSS to a file and clear your website and server cache.
Additionally, if you have gzip compression enabled, we’d recommend disabling it as it may not play well with Facebook’s Open Graph detection.
You can also use Facebook’s Open Graph Object Debugger to test your OG implementation. Just enter the URL of the page you want to test and click the “Fetch new scrape information” button.
If none of these steps resolve the issue, please feel free to reach out to our support team directly from here, and we will be more than happy to help.
We hope this helps resolve the issue. Thank you for reaching out to us!
Sources:
How to Fix the ‘og: image’ Property Should Be Explicitly Provided » Rank Math
Open Graph/Social Preview Image Is Not Displayed » Rank Math
Open Graph Meta Tags » Rank Math
Analyzing Your Site’s SEO with Rank Math’s SEO Analysis Tool
Yes, we’ve already tried all of those steps, and as noted, the metadata appears to be displayed right near the top of the source code.
Hello,
Thank you for contacting support.
We checked the page you shared and noticed that the image is in the WebP format, which is not fully supported by OpenGraph, and also that the image doesn’t end with an image extension which causes the following issue:
That screenshot is taken from the Facebook Share Debugger which can be used to test the page for its metadata and how they will look when shared: https://developers.facebook.com/tools/debug/
Don’t hesitate to get in touch if you have any other questions.
After some troubleshooting and tinkering, the fact that it didn’t end in an image extension did not cause the error, as it is still having an error even though the image now ends in .png when you test it.
Is there a reason that these systems aren’t capable of falling back to the original image, which still exists on our server for compatibility for reasons like this? Especially given WebP’s age at this point?
This also doesn’t explain, though, the fact that the Author and the Publish Date metadata were also not found by LinkedIn’s tool? Oddly, after these tweaks, the Author is now found, but not the Publish Date.
Hello,
Regarding the WebP format, while it’s true that some platforms might have limited support for it, it’s unusual for metadata issues to persist after changing the image format. Please confirm that the og:image format has been truly converted from WebP.
We have checked the post inspector, and it seems that LinkedIn is not using the og:image meta tag on your site. You can check the page’s source code that Rank Math already outputs the metadata correctly.
In this case, please note that LinkedIn prioritizes the oEmbed code instead of the OpenGraph meta tags
For a workaround, you can add this in the last line of your active child/theme’s functions.php file, and this will remove links on your site:
remove_action( 'wp_head', 'wp_oembed_add_discovery_links', 10 );
Please take a complete backup of your website before applying any filter on your site.
Once done, clear your website’s cache and check again using the inspector tool.
Let us know how this goes.
Phew, this ended up taking me down so many rabbit holes and blowing up my Friday and my weekend. I’ve been going through it all day, and I’ve got it all working pretty well now, but I still have a few issues on the RankMath side. Let’s go through this one at a time.
1. I did have to ultimately disable WebP to get the images to work on Facebook, which is less than ideal, but it didn’t hurt our Pagespeed scores too much, so I can live with that for now. However, the images still were not displaying at first after disabling – which it finally clicked with me was because RankMath defaults to the WordPress “large” thumbnail size if you are using a social image, or your default image is, larger than 1200 px wide. Since these large thumbnail sizes were not displayed on the front end elsewhere on our site, the images did not exist on our CDN which led to 404 errors. Once I worked that out, I reworked our blog landing page to use the large thumbnail sizes to intuitively work around this for existing and future posts. You might consider noting this in your backend for current and future users to avoid unnecessary confusion, as this default setting was not clear to me anywhere in the backend.
2. To best fit the recommended size, we changed our large thumbnail setting to 1200 px W and regenerated our large thumbnails. However, for some reason, RankMath is still defining the images to OG as only 800 px W, as you can see in the Facebook Sharing Debugger. Given that even the plugin notes the “Recommended size is 1200x630px”, I hope this is something we can get resolved quickly.
3. LinkedIn’s Post Inspector is now finding the images, as well, but is still not finding the Author or Publish Date metadata, even with your provided filter added. This is less mission-critical, as that data’s not displayed currently when posts are shared, but if that changes from the LinkedIn side in the future, that will quickly become a problem. So, I’d much prefer to find a fix sooner than later and get out ahead of it.
Let me know what we can work out here and if you have any additional questions. Thanks!
Hello,
Could you please try to clear your website cache including any server-level cache and check again? If the issue persists, then we might need to take a closer look at the settings. Please edit the first post on this ticket and include your WordPress & FTP logins in the designated Sensitive Data section.
Please do take a complete backup of your website before sharing the information with us.
It is completely secure and only our support staff has access to that section. If you want, you can use the below plugin to generate a temporary login URL to your website and share that with us instead:
https://wordpress.org/plugins/temporary-login-without-password/
You can use the above plugin in conjunction with the WP Security Audit Log to monitor what changes our staff might make on your website (if any):
https://wordpress.org/plugins/wp-security-audit-log/
Looking forward to helping you.
Thank you.
Hello,
I have updated the sensitive data as requested. Can you please check further?
Thank you.
Hi,
Confirming the caches were all cleared previously, and again today, but the issues noted in #2 – with the width and height being defined smaller than they should be – and #3 – with some missing, but less critical LinkedIn metadata – persist.
We’ve added the login info above as requested and also disabled Nginx caching on the server temporarily to avoid any login issues during your testing.
Thanks!
Hello,
We checked the page further and it seems that the images are currently returning a 404. Even if I disabled the CDN via W3 Total Cache settings. This is the reason why Facebook is seeing invalid content for your og images.
We would like to check this further but the FTP login you shared isn’t working. Can you please verify this from your end so we can continue debugging the situation?
Looking forward to helping you.
Hello,
I have updated the sensitive data as requested. Can you please check further?
Thank you.
Hi,
Did you all make any changes on the site before seeing the latest images issue? The images for all blog posts, including this post, were all displaying as expected at the time of my last update. I went ahead and cleared the full site and off-site CDN cache, and after giving Facebook and LinkedIn about 30 minutes to reset their caches, and the images now seem to be starting to display again in the debugger.
Please also note that we did not find the actual images to be having 404 errors, either – if you go directly to https://cdn.gridiron.digital/wp-content/uploads/2023/06/ongoing-maintenance-tiny-1200×800.png?x60708, for example, you can see the blog image in question just fine. If no changes were made on your end, we may have to reach out to BunnyCDN to see if the query strings the CDN is adding to the end of the URLS seem to be causing unexpected, intermittent issues we are finding with the images resolving here.
While we’re not quite sure what the problems are there, these were also not the direct issues we were noting open. The problems we’re having on your end are still with the incorrect image height and width being defined in the metadata, and the missing, somewhat less critical LinkedIn Author and Publish Date metadata.
Not sure what happened with that FTP password, either – that seemed to be working in testing when we shared it before, but maybe it was a copy and paste error? – but we updated again and tested that just now, and that login should now work, too.
Thanks!
Hello,
The image URL you shared is indeed returning a 404 error and that’s what the Facebook Share Debugger sees as well which causes the error we initially shared:
We also noticed that the image you are trying to add has dimensions that are outside the limit that can be used by OpenGraph. You should set a maximum height and width of 2000 pixels and the current image is 2560 pixels wide.
Both of those issues are behind this and both need to be corrected for the images to appear correctly when sharing the pages on social media.
Don’t hesitate to get in touch if you have any other questions.
Ah yes, so please also note that if you go to the image link directly from here, it leads to a 404, but if you view the image source on the website directly and click the source link, it works as expected. This is because of our hotlink protection on our images, set up in cPanel, that prevents linking from outside domains.
FYI, we went ahead and disabled hotlink protection on the server, to see if that helped, and that seems to have resolved both the image issues on LinkedIn and the intermittent image issues on Facebook in our testing. We’re leaving hotlink protection off since it seems to be more of a headache than it is worth, and that should hopefully resolve that part of our issues moving forward.
Interestingly, the Author metadata on LinkedIn also seems to be resolving correctly now, as well, with that turned off.
That leaves us with only the following issues for the RankMath side:
The image sizes are all still being defined by RankMath incorrectly. For example on this 1200 x 800 image, the metadata is instead being defined as –
<meta property=”og:image:width” content=”800″>
<meta property=”og:image:height” content=”533″>
And LinkedIn’s Post Inspector is still missing the Publish Date metadata, without your previously provided line added to functions.php.
Note that with your provided line added in testing –
remove_action( ‘wp_head’, ‘wp_oembed_add_discovery_links’, 10 );
We were actually missing more metadata on LinkedIn – both the Author metadata and the Publish Date metadata – so we removed that line from the code, leaving us where we are now, missing only the Publish Date.
We also added an Activity Log plugin for tracking going forward (we missed that suggestion originally), to make things easier on both sides, since it’s been tough to get answers directly on whether or not changes have been made in the backend.
Thanks!
Hello,
Since we did not hear back from you for 15 days, we are assuming that you found the solution. We are closing this support ticket.
If you still need assistance or any other help, please feel free to open a new support ticket, and we will be more than happy to assist.
Thank you.
