I’m experiencing issues with OpenGraph meta content not working in WhatsApp link previews. The same issue is happening across all my Kirby sites – Kirby 3 and Kirby 4 – and with three different plugins. So I’m wondering if it’s me!
The best live example is the Skywood Cars website. This client uses WhatsApp to direct customers to specific pages and the issue is impacting his customer service experience.
I have populated the relevant OG tags in the Panel. And the link previews are fine for Facebook, both in the Panel and using the Meta Share Debugger. However, if I copy/paste or type a URL into WhatsApp, the link preview ignores the OG meta information and instead uses actual page content.
This is a screenshot from desktop WhatsApp but exactly the same thing happens in the app, both regular WhatsApp and WhatsApp Business…
It starts with the page <title> but then the  items are on-page logo image assets. Then it moves on to mobile menu open/close buttons, the header nav items themselves and lastly dark/light mode buttons.
I have tried copying and pasting URLs from other general sites and the only difference I can see is that on sites whose link previews work, the meta tag property attribute comes before the content attribute. But with all my Kirby sites, the content element is appearing first, regardless of which plugin is used. I don’t know if this is the issue but it is the only thing I can see where my sites are different…
The Skywood Cars website uses the MetaKnight plugin. I looked at the plugin code and the snippet does have property appearing before content. But when I look at the Dev Tools, as above, they are the other way around.
The same ordering happens with the Meta and Kirby SEO plugins that I’m using on other Kirby 3 and Kirby 4 sites respectively.
Questions
Does anyone have any suggestions on how I might force the property attribute to appear first inside the OG meta tags, so I can see if that’s the cause of the link preview problem?
And if that isn’t the problem, does anyone have any idea why my WhatsApp link previews aren’t working?
Possibly unrelated but i did notice you have quite a few HTML warnings - extra closing tags in places. Long shot i guess but maybe thats preventing the meta tags being read properly.
Thanks for the reply, Sonja. I’m using Ahmet’s Minify HTML plugin and I realised that’s what sorting the attributes. I tweaked a couple of options in config.php to prevent the sorting but it hasn’t fixed the WhatsApp challenge, so I need to look elsewhere.
Thanks, James. Where are you seeing those warnings?
When I look at the Console, I do see a couple of issues and warnings but nothing about extra closing tags. And when I use the W3C validator, I see some messages about tag hierarchy, which I’ll look at too.
A lot of the validator messages relate to my use of Alpine.js. I’ll investigate that as a possible cause but I don’t want to have to scrap Alpine and go back to regular JS if I can help it.
I did a view source in the browser and copied the code into VS code. When i formatted it with Prettier, it threw some errors about about extra tags and wouldnt format the code so i could read it properly.
The W3C validator extension in my browser reported 137 errors, but yes, some of those are related to Alpine.
Yes, the missing </head> tag will surely be the culprit. There is definitely a </head> tag in my snippet, so I suspect it might be another impact of the Minify HTML plugin. I’ll look at the config options again to see if I can correct it whilst still being able to minify.
James, the same goes for the missing closing tags you found (or didn’t!). They are almost exclusively missing </p> tags stripped out by the minification.
As regards the hx tags within spans, that’s where I’ve created a custom text block in order to add a text-align selector. I’ll correct that using a div and classes instead.
If I may say so, I think it would be more important to improve performance by using responsive images rather than minifying HTML… Don’t think the impact of that is that great.
I’ve managed to find the Minify HTML config option I needed to keep the closing tags in place –'doRemoveOmittedHtmlTags' = false – but that hasn’t solved the WhatsApp issue.
I’ve also added a few quick fixes to cut down on the validity errors. Still a handful to tidy up but now the vast majority of errors are Apline.js-related. Again, the WhatsApp issue persists. So Alpine.js is my next area of investigation.
Sonja, I am using optimised images throughout and they’re responsive where relevant. For example, the homepage hero image uses a range of srcset sizes. The smallest of those is 450px wide. If I resize the viewport down to mobile, refresh and then look at the Dev Tools Properties, the currentSrc is the image file with the suffix (and width) -450x.webp at 18KB. If I resize back up to laptop width, the currentSrc is the -1536x.webp version at 85KB.
But if you’ve spotted something not right with the responsive image setup, your guidance is much appreciated as always.
I think I was a bit hasty there! It seems that my most recent fixes have worked… to a degree. Probably the </head> tag going back in was the fix.
I am no longer seeing  and then the nav content. The link preview does now look like a link preview. I just need to work out why the og:image isn’t displaying.
have you tried running it through the facebook debugger? I would think but dont know for sure that whatsapp does siimilar to Facebook and caches the link and image data the first time some one shares that link. My hunch is it may have cached one your earlier attempts with a missing image.
Maybe look into that. I know facebook has a meta debug tool, which can be used to flush a cached link share. Maybe try that or see if whatsapp has an equivelant.
On Find your perfect partner | Skywood Cars there is a single car with an image that is only has a src attribute, no srcset and sizes attributes, so the image turns out too big for size at which it is shown. And while the performance of the home page with the single big images is fast, it is less on that buy page (and I guess, there are supposed to be more used cars with more images available on that page).
James, yes I did run it through the Facebook debugger. It worked perfectly from the get-go. So the issue was specific to WhatsApp. And there isn’t a WhatsApp version of the debugger. As it’s Meta. I think it’s meant to cover all the Meta products.
Having researched it, the image showing in Facebook but not WhatsApp is a common issue and no-one seems to have a working solution.
The fixes I’ve made today, with your and Sonja’s help, have at least got the link preview working properly, image on not. It might be as good as I can get it but it least it’s bearable.
Thanks for spotting that, Sonja. Those ‘summary’ images pull through from the relevant car pages. The banner images are responsive on the car pages but I obviously need to do a bit of work to resize the summary versions on the Buy page.
James, I think there might have been a caching/timing thing after all because OG images are now displaying. So, my WhatsApp link previews are now working perfectly.
Just so I can mark this issue as solved…
The issue was that the Minify HTML plugin was stripping out some closing HTML tags, most crucially the </head> tag, as highlighted by Sonja.
The solution was to add a plugin config option to the config.php file – 'doRemoveOmittedHtmlTags' = false
